Tuesday, November 23, 2010

Podfade

Yikes, the dreaded Podfade!

When I started the Retrobits Podcast, one of my primary goals was to maintain a regular schedule. This was suggested in a book I read on Podcasting (one of the first books out there, and an excellent one) by Todd Cochrane. Basically, the idea is that if you drift on your schedule, your listening base will drift, too, because you're being unpredictable with your shows. Makes sense. That notion kept me on an every-week basis for a long time. But once you get derailed from your schedule, it's difficult to get back on the tracks.

There is a phenomenon known as "Podfade" - where podcasts start strong, but then get less predictable over time, or disappear. Part of the reason this happens is that the barrier to entry for podcasts is pretty low. All you really need is a way to record and edit, and an audience of an acceptable size that would be interested in your topic. From there, it's trivial to find a cheap or free location to host your podcasts, and to get listed with iTunes and various podcast directories.

But once you're up and running, next comes the sometimes hard slog of putting together the show on a regular basis. Life can get in the way. Once you've slipped once - well, it's like an exercise plan. It's hard not to go ahead and slack off again - you've blown the sit-ups for this week anyway, right?

Well, speaking of that, I have an idea to fight my own podfade - one that is drawn from recent life experience. But first, I needed to take a look at a couple of key questions:

  • Am I still interested in maintaining a regular podcast on computing history and the retrocomputing hobby?
  • Is there enough remaining and/or new material out there to fill a regular schedule?
Check, and, check. Now, how to get back into the saddle?

Sometime a little over a year ago, I decided that I needed to improve my physical condition. I was tired, overweight, and generally unhappy about the years creeping up on me. I knew the fate that would await me if I tried to jump in head-first into a workout and diet plan. Namely, it would work for a while, but then I'd get overwhelmed, and it would falter. My wife came to the rescue with a great idea. Her suggestion: Start small, give yourself small but fun rewards for success, and establish a track record. Make consistency, rather than quantity, a goal. Once you've established a solid, predictable routine, bump it up ever so slightly. Integrate it into your life, so it's not such a struggle. Sneak up on it.

So, I did exactly this. I started walking twice a week, and knocked off eating out so much. (This helped financially as well as holistically). Once this became habit, I added a little bit more, and a little bit more. My reward was a weekly sushi splurge, or some great food from our local Korean supermarket (H-Mart). For me, asian food is quite motivating. Over the course of a year or so, I've worked up to 4 cardio workouts per week, strength exercises six times per week, and 8 cups of water per day, every day. And I've just allowed the fast food to go by the wayside. The result? I'm fifty pounds lighter, have more energy, feel stronger, and it's not really that hard to talk myself into it each day.

Sometimes in life, it's about finding out what works for you. Since this incremental improvement method worked for me on workouts, I'm hoping it'll also help me overcome my podfade. Retrobits is a lot of fun to do, and it's something I'd very much like to continue. So, one possible plan is:

  • Make a new show every three weeks. If it's more frequent, that's fine - but never less frequent.
  • Give myself a little reward (maybe a few extra bucks in my retro budget?) each time I hit the mark.
  • Once that schedule is established for a few cycles, creep up to once every two weeks.
  • Lather, rinse, and repeat, until it's where it can be sustainable (possibly weekly?).
Eventually (someday) I'd like to get back to a weekly show. It worked for years, and might work again - but if I make that the goal right now, it won't work. I think a slow and steady ascent is the better choice. I'm off and running...

On a side note: It's hard to find material on the Internet for other strategies people have on fighting podfade. I only found one article, and it was behind a paywall. I wonder what other methods have been successful for podcasters? If you have any insight, shoot me an e-mail.

Hope everyone (in the States) has a great Thanksgiving!

- Earl

Tuesday, October 12, 2010

My IBM 5155 Zip Drive adventure

The IBM 5155 "Portable"

One of my favorite retro treasures is my IBM 5155 Portable PC. It is a very nice unit, almost brand-new looking. It's also mostly in stock configuration, the only addition being some expansion cards installed for RAM and I/O. The system was gifted to me years ago by a friend who swore she dragged it around on airplanes back in the day. This surprised me because (a) it's REALLY heavy, and (b) it doesn't show any signs of travel wear and tear. It was a very nice gift and I've had a good amount of fun playing with it.

Still, with two floppy drives, there's only so much you can do. Another friend of mine years ago had given me a pile of mid-80s PC software (with books and licenses and everything) to use in my retro collection, but a lot of it is difficult or impossible to really enjoy without a hard drive. For instance, "dbXL", a clone of dBase III Plus, can work on a floppy system, but really wants a hard drive.

First mass storage attempt: FAIL

A few years back, I purchased a "hard card" (hard disk on an expansion card) in the hopes I could add a hard drive to the 5155, while still keeping the unit minty fresh. The hard card was cheap, but some research should have preceded that purchase - the 5155 is quite limited on physical space in the card slot area, and my new hard disk card wouldn't fit.

How about a compromise?

Recently, I saw an Iomega Zip Drive available for free on Freecycle. This got me thinking - I wonder if I could use a parallel Zip drive on my 5155? It's got a parallel port! But it is old... After doing some checking and finding that it might be possible, I indicated an interest in that Zip drive on Freecycle, but it was gone already. Checking eBay and Craigslist, I found devices that I could purchase, but something (my pocketbook, maybe?) told me to hang on. Sure enough, some more units popped up on Freecycle. Not only did I wind up with a parallel port model, but also a USB model (which would come in VERY handy, more on that in a bit).

I realized the Zip drive wouldn't be as fast as a hard drive, even an old hard drive. However, the Zip drive would give me basically unlimited storage, which would be cool. So, it's a compromise, and one that I'd happily live with if I could get it to work. I mean, if I was after speed, would I be using a 5155? :-)

The famous "Chicken And The Egg"

OK - so now, I've got a parallel Zip drive, and an IBM 5155 with no drivers for a Zip drive. Once I get the Zip drive working, I can easily move files to/from the 5155. But until I do?

Step 0 - Test the parallel Iomega drive

It was really easy to test the USB Iomega drive - it was plug and play with Windows XP, and worked great. The parallel drive was harder. For this, I actually went into Linux, and used some old and magic Linux kernel module incantations that I found on the web. It took a little fighting and some trial/error, but it worked - proving that the parallel Iomega drive was not broken. Basically, I didn't want to work at hooking it up to the 5155 until I was sure it actually functioned... OK, full speed ahead.

Step 1 - find the drivers

For some reason, Iomega doesn't make it easy to find their old DOS drivers. But they are still on their FTP site. So, I got the latest DOS version.

Step 2 - get those drivers to the 5155

Whenever in doubt, fall back to basics - in this case, the serial port. I hooked a null model cable between my 5155 and my Windows box, loaded Procomm Plus on the 5155, HyperTerminal on the XP box, and moved the files. (Thanks Walter, for that pile of DOS software!)

Step 3 - Fail

Iomega drivers - at least the version I got - require an 80286 or above. They've apparently got some real mode instructions. Since the 5155 is essentially an XT crammed into a portable case, of course it has an 8088. Now, some helpful folks on the Vintage Computer Forums let me know that a NEC V20 (8088 drop-in compatible upgrade) would probably help me out, but I didn't want to soup-up my 5155 with a non-stock chip. Next?

Step 4 - Success with Palmzip drivers

If I haven't said so lately, I really do love the Vintage Computer Forums. The folks over there pointed me to the Palmzip drivers, written by a fine gentleman named Klaus Peichl. The Palmzip drivers allow the use of an Iomega Zip drive with an 8088, but they do more than that - they include partitioning, formatting and copying utilities, and an automatic check to see if your parallel port is capable of bidirectional (faster) operation (mine isn't). They also fall back to 33MB partitions automatically if you're using DOS 4.x or below. Awesome! Klaus makes a time-limited demo version available to let you see if you like the software, and to test your hardware for compatibility. I downloaded the demo, moved the software to the 5155 (via serial port again), and it lit up the first time!

Once I had payed my 8 Euros (a little over 11 U.S. dollars), Klaus quickly sent me the fully registered version, which also worked great and removed the restrictions.

The Wide-Open (but somewhat Slow) Spaces

Along with the Zip drives that were given to me, I also got 41 Zip cartridges. That's 4.1 GB! This is enough for a lifetime of DOS software. I am cruising with dBase(ish), Turbo Pascal 3 and 5.5, Microsoft QuickC, and other cool DOS software.

The speed was about what I expected - it's not as fast as the hard drive solutions I've used on the old 8088 machines. When I'm waiting for software to come up, I do yearn a bit for a Western Digital controller and Seagate ST-251 drive with optimal interleave configured. However, my 5155 remains safely stock, and now there is space to play with. I'm quite happy.

Eventually, I might look around to see if there are any ECP or EPP 8-bit parallel cards. This would speed up my experience.

One More Hurdle - DOS 6.22

Using PC DOS 3.3, I was wondering, where'd my EDIT.COM go? Well, it's not there! Among the other software I have is a set of MS-DOS 6.22 disks on 3.5" media. Hmm, now how do I get a DOS 6.22 5.25" boot disk?

First, I tried moving the DOS 6.22 files to the ZIP drive, and ran SETUP.EXE with the /F option. This didn't work - it told me that my floppy had insufficient space. Drat! It says in the online docs (from Microsoft) that it works with a 5.25 drive, but no go.

Next, I had a brainstorm - if I could get a 5.25" disk image file, I could use something like RAWRITE for DOS to make a real floppy.

So, I loaded Bochs - an open-source x86 emulator. I booted Bochs from a 3.5" DOS 6.22 disk image, and created a virtual 5.25 B: drive image, which I then prepared with FORMAT B: /S. This resulted in a MS-DOS 6.22 5.25" virtual disk image. I took this image, along with RAWRITE.EXE, moved it to the PC 5155 with my newly-built Zip drive process, and used RAWRITE to create the real disk. It booted!

Tricking-out the Environment

From there, I loaded the Palmzip drivers to the 6.22 boot disk, and moved the 6.22 files to a Zip drive itself. I set the COMSPEC so it would look for COMMAND.COM on the Zip drive, and I set the paths properly so all my software was accessible.

Thanks to the help of many people, including Klaus, the folks at the Vintage Computer Forums, Walter (who gave me the pile of DOS software) and Kristen (who gave me the 5155), I now have a fully-functional, true-Blue IBM 5155, MS-DOS 6.22 environment with LOTS of storage space. I'm partying like it's 1984!

Now, if you'll excuse me, I've got to go wake up some dBase III Plus brain cells...

Saturday, July 31, 2010

CP/M, the Old Skool Way

First, the Agony of Defeat

A couple of nights ago, my friend Nick and I spent hours trying to get the PX-8 peripheral port to talk to the Propeller microcontroller using RS232. We did not succeed, and it is still not clear why. We tried changing parameters, re-examining our assumptions on wiring, and even broke out the multimeter to make sure that some signals were going across the wire. Alas, to no avail.

Why won't anybody talk to me?

The peripheral port on the PX-8, officially called the "Serial" port, uses RS232 at 38400 baud to speak to the disk drive. Although I don't have a PF-10 disk drive, I do have a cool program on Linux ("vfloppy") that emulates a disk drive. You plug the PX-8 Serial port into the PC RS232 port with the right kind of cable, run the vfloppy software, and voila, up to 4 simulated disk drives, each with storage of around 300 KB. Since my PX-8 works fine with vfloppy, I know that this RS232 link can be successfully accomplished. The Propeller development board that I use is equipped with a MAX3232 chip, which boosts the Propeller's 3.3V signals to the levels needed for RS232 communications. When I connect the Propeller to my PC using RS232, it works fine.

We checked to ensure that the voltage levels from the MAX3232 were not too loud or too soft for the PX-8. Turns out, according to the technical manual, the PX-8 has a pretty wide range that it will accept on either the "Serial" or the "RS232" port. So, we're still not sure why things didn't work. We will continue to work on this; however, it's clear that the problem won't be solved by the end of the Retrochallenge 2010.

So...

I decided to punt, and do something with the PX-8 that I've been interested in for quite a while - use it like an old skool CP/M system by connecting a terminal to it.

Driving a CP/M box like it was meant to be driven

Systems like the Altair, IMSAI, North Star, etc. used to be "headless" - you had to connect some I/O device to them to have input and output. Frequently this was a video terminal of some sort. Although I'd like to have a video terminal, like an old VT100 or Lear-Siegler, I do not currently own one. But I do have a Propeller development board, which has seen quite a bit of use on this fledgling project. I decided to rewire it, and use it as a standalone terminal.

The PockeTerm is a product of Briel Computers. It is, according to the site, a "A low cost color choice terminal that has VT-100 compatible commands for controlling cursor and screen functions." It's a neat little standalone terminal unit that was made for vintage computers, but can also be used to connect to Unix/Linux systems if you wish. The heart of the PockeTerm is the Propeller microcontroller.

Have I already got the hardware for my own terminal?

This got me thinking - my Propeller Professional Development Board (PPDB) has nearly all the hardware goodies included in the PockeTerm, short of the SD Card slot. I also have a breadboard-ready SD card unit, so I thought, why not breadboard my circuit, wired similarly to a PockeTerm, and use it with the PX-8, giving me a nice 80 column display?

Step 1: Wire the PPDB like a PockeTerm

On the Briel Computers site, there is a manual, a schematic, and a download of the PockeTerm software. I used the schematic diagram and wired up the PPDB the same as a PockeTerm, with the following result:



Note that the PockeTerm does not do any hardware handshaking, so I had to also add a wire to bring up Clear To Send (CTS). (The PX-8 RS232 port won't talk to you unless CTS is active.)

Step 2: Load the PockeTerm software and test

Worked great! I hooked up the PPDB to my PC (with HyperTerminal), and the two were talking in no time.

Step 3: Connect the PPDB to the PX-8

Based on all the work we've been doing trying to talk to the Serial port, I had PX-8 compatible cabling at the ready. The PX-8 uses a Mini-DIN 8, same connector style (but not the same wiring!) as a Macintosh serial port. I have two cables, one wired as the virtual drive cable, and the other wired as a standard RS232 modem cable.

Once hooked up, I used the simple "TERM.COM" program on the PX-8 to ensure that it was happily talking to the Propeller terminal.

Step 4: Redirect I/O on the Epson PX-8

In order for the PX-8 to use a terminal for I/O instead of its own screen and keyboard, you have to run the CP/M "STAT" command with the right parameters. STAT is a program used for many various things in CP/M, among which is port redirection. The command:

STAT CON:=UC1:

tells the PX-8 to use the RS232 port for input and output, instead of using the screen and keyboard.

Note that it's important to have a terminal connected to the PX-8 (and tested) before you do this - otherwise you lose control of the PX-8 and have to do a low-level reset!

Step 5: Run some interesting software that uses the terminal

Using some of the utilities provided as part of the vfloppy suite, I was able to get both MBASIC and Turbo Pascal 3.0 for CP/M loaded into compatible disk images. Here's Turbo Pascal, running on the PX-8, and displayed on the Propeller-based VT100/ANSI terminal program:



I played around with Turbo Pascal and MBASIC for a while, and was quite happy with the results. The RS232 link worked quite well at 9600 baud, making for a fairly snappy response on the programs.

Just for grins, here are a couple of my reference manuals:





Because the PockeTerm software speaks many VT100/ANSI codes, I was able to write a small Turbo Pascal program to send the right codes to clear the screen. Wrote my own little CLS program...

Step 6: Play around with CP/M using a terminal for a while (this step is in progress)

Step 7: Get back to work on the PXDrive project!

Well, that's it for this year's Retrochallenge entry. Too bad we couldn't make more progress on the virtual drive - but this did get my PX-8s up and running for some fun, and in the end, I guess that's the point of it! I'll keep up the updates on this blog as more progress is (hopefully) made on the virtual drive!

Thanks to the Retrochallenge folks for another neat event, and for the great Twitter updates!

Monday, July 26, 2010

Voltage problem?

I'm still working on my Retrochallenge entry. There are only a few more days in the month, and I feel like I'm pretty close to the goal. However, it could be that a good ol' hardware issue has me stuck.

I've reverse-engineered some of the code from the "vfloppy" program, and figured out how the PC serial port is used to talk to the PX-8. It's very straightforward, as I thought, based on the specs - 8 bits, no parity, 38400 baud, no flow control, just raw I/O. No magic at all. And that's exactly the way the serial code for the Propeller works, too, by default. So, why do I not have reliable communication?

Based on the trouble I had making the vfloppy program work with one computer and not another, it occurred to me that serial port voltage/current might be an issue. I checked the Epson PX-8 tech specs, and it looks like the serial and RS232 ports on the PX-8 want +/- 8V. Standard RS232 voltage is +/- 12V, and that's what the MAX3232 chip (used on the Propeller development board for serial communications) puts out. So, I'm wondering if there's a sufficient voltage mismatch as to be causing communication issues? Seems unlikely, but I'm kind of at a loss to understand why this is being so difficult to get going.

Anyhow, I'll keep working - perhaps I can put some resistors in line, and see if that improves the situation.

Saturday, July 3, 2010

The first speed bump

When trying to accomplish something with technology, it seems like there are always these strange "gotchas". I've encountered the first on my road to a PX-8 virtual drive prototype...

As I set out to produce the PX-8 virtual floppy drive, one resource that I'm hoping to use for reference is the open source, Linux-based "vfloppy" program (see previous post). Turns out, vfloppy works great on my old Dell laptop, but not on my newer one (Dell D630). Both are running Ubuntu 10.04 LTS, both have the same serial UART, and they are configured identically. However, with the D630, I get serial communication errors, and with the older Dell Inspiron, I don't. Ugh.

Since I've got the source code, I went poking around to see how the serial port is initialized and opened in the vfloppy program (epspdv3.c). It's pretty straightforward stuff using the standard libraries. Should be about as hardware non-specific as you can get.

Thinking it might be my specific D630, I tested another that I had handy. Same issue. So the problem is not with faulty hardware, but with some specific hardware/software issue.

I know problems come up when trying to accomplish something - it's part of the challenge of a project. But this is my least favorite kind of problem, because it is, at best, only a tangent to the real problem I'm trying to solve.

I might just be stuck using my older laptop for the project, unless some magic happens...

Friday, July 2, 2010

Linux has come a long way, baby

Per an earlier post, I needed to install Linux on one of my machines in support of my Retrochallenge 2010 entry. Bear in mind, I've always been a Linux enthusiast, and have used it since my router QA days in the early 90s (Linux was a great, free environment for network testing). Ah yes, ye olde days of Slackware and disk sets. We only had a 56 Kbps link to the Internet (yes, for the whole company), and being able to get a working Linux with just a few 1.44 MB disks was awesome! But, I digress.

I've been using Ubuntu 10.04 on my Dell Inspiron laptop for about 2 hours now, and let me tell you, it is pretty, and it is fast. It's also quite complete, having transparently (and accurately) detected all the hardware in the laptop. It even let me turn off "tapping" on the touch pad (clicking with a tap, something that drives me NUTS). The laptop is a Pentium M 1.6 GHz with 1 GB of RAM, and runs like a dog under XP. It is not just usable, but snappy, with Ubuntu. I am writing this blog entry from it right now.

Is 2010 the famed year of Linux on the desktop? :-) Maybe for me...

Thursday, July 1, 2010

PX-8 virtual drive: Next stop - Linux and vfloppy!

The vfloppy disk simulator is software that acts like a disk drive for the Epson HX-20 and PX-8 systems. It is written in C, for Linux. It's regularly updated, and now supports the D88 virtual disk file format used by the PX-4/PX-8 emulators produced by Toshiya Takeda.

All the software in play here is GPL/open-source, which is awesome. Having an open, working, updated implementation of the disk drive simulation will be very helpful in my efforts to produce a Propeller-based virtual drive.

This is the most current and best solution I'm aware of for emulating the Epson PF-10 floppy drive on a modern system, so I'm off to install Linux on a spare machine. Rather than use a virtual machine and have the potential hazards of uneven serial port support, I'm putting this on real hardware. I'm going with Ubuntu 10.04 on a Dell Inspiron laptop. Will be nice to take the new Ubuntu for a test drive anyhow!

Retrochallenge 2010 begins!




The Epson PX-8s are charging their NiCads - warming up for their role in my entry for this year's Retrochallenge event. May the games begin!

Monday, June 28, 2010

PX-8 Virtual Drive, take 2

The Epson PX-8 is a circa 1984 laptop computer, running the CP/M operating system (ROM based). Last I checked, you can still purchase new PX-8 systems from Star Technology. However, the PF-10 3.5" portable disk drive for the PX-8 is a very rare beast - the ones I've seen on eBay I've never been able to afford.

Communications between the PX-8 and PF-10 are over an RS-232 compatible connection at 38400 baud. The protocol is documented, and there are a couple of software packages - one for Linux, and one for DOS - that emulate the drive. I would like to extend the work that's already been done in this field, and create a portable, battery-operated virtual disk drive for the PX-8.

I'm hoping to be able to use a Propeller microcontroller chip as the "brains" of the virtual drive. The Propeller is cool - 8 parallel cores or "cogs" typically running at 80 MHz nominal clock speed. There are hardware/software solutions for interfacing with external storage, including SD cards.

Like last year, I've entered the Retrochallenge contest with the goal of producing a first pass at a virtual drive prototype. Unlike last year, this year I hope to achieve the goal!

More postings as I go. Look for details on this blog, with the tag label "retrochallenge".

Sunday, June 27, 2010

Learning assembly on the C64

I'm jumping back in to learning assembly on the Commodore 64. I'm going to start by making another pass through Jim Butterfield's Machine Language for the Commodore 64, 128 and other Commodore Computers. After that, I'll be looking to level-up to advanced stuff. This time, I really want to go deep on the guts of the C64 and C128. I've got an idea for a couple of projects, and I'm excited to get moving again.

Saturday, June 19, 2010

Retrochallenge 2010 starts in two weeks!

Hi all,

The Retrochallenge 2010 contest begins in about two weeks! If you've got a fun idea for a retrocomputing activity or project, head on over now!

Thursday, June 17, 2010

Welcome!

Hi there retrocomputing fans...

Welcome to the Retrobits Podcast blog!  Here you'll find my periodic musing on the vintage computing world, and also an occasional personal diversion.

- Earl