Getting started on my Retrochallenge project

Wow, I'm behind!

I got started yesterday on my Retrochallenge 2008 project. I've been putting it off, but sometimes you just have to get the ball rolling.

(A picture will come later today.)

My project is to create a hardware-based virtual disk drive - specifically, an emulator for the PF-10 disk drive, used with the Epson PX-8 laptop computer.

The hardware platform I want to use for this virtual drive is the Propeller microcontroller chip from Parallax.

A little background - microcontrollers are like combining a microprocessor, some RAM, I/O functions, and sometimes some flash memory for storing programs, and sticking it all on one chip. This makes the microcontroller good for embedded scenarios in which a chip is used as a controller for a hardware application (hence the term microcontroller). Since my project involves interfacing to some hardware, and since I want a low cost, highly self-contained design, a powerful microcontroller is a decent choice.

Specifically, the Propeller chip is an amazing microcontroller. It can run at high speeds (80 MHz being a norm), has eight parallel processing cores (or "cogs"), has 32 I/O lines and is a 32-bit internal architecture, and has facilities for both a high level language ("Spin") and machine language built-in. It's pretty amazing, and is fun to just play with. I think it will make a good basis for my disk drive emulator.

Here are some challenges I expect to encounter:

The Propeller chip doesn't have much RAM, at least when compared to programming on a PC. Only about 32K of RAM, in fact. So, therefore, things like disk buffering may be hard. However, the computer that this virtual drive is designed to serve, the PX-8, only has 64K itself; hence, I don't think this will be a show-stopper.

The PX-8 talks to the PF-10 disk drive using an RS-232-like protocol, at 38400 baud, 8 bits, no parity, 1 stop bit. Pretty standard stuff. This is a good thing, because it's easier to emulate than, say, the IEC protocol on the Commodore drives. However, the protocol itself still remains somewhat timing sensitive, and the handshake sequence and command vocabulary are only tersely documented. There is an open-source C program called vfloppy that implements this protocol (on Linux), and reverse-engineering that program has proved useful, especially when it's compared to the Epson documentation on the protocol for reference.

The storage (disk images) will be stored on a Secure Digital card, interfaced to the Propeller chip. There is a set of publicly-available code and schematics to interface the Propeller with an SD-card, and it works well.

So, yesterday I took out my Propeller breadboard environment, dusted it off, and did a little work on it to prepare. Specifically, I added a breadboard-mountable DB9 connector for the serial programming interface, and re-routed some wiring to make room for both a 3.3V regulator and a 5V regulator. Although the Propeller is a 3.3V chip, some things you have to interface with (e.g., PS/2 style keyboard and mouse) are 5V.

Next, I went to wire it up to my laptop. Oops, my laptop docking station is at a customer site, and without the docking station, I don't have a serial port.

Regrouping, I went to hook it up to my desktop PC. Next oops - the breadboard DB9 is a male connector, and so is the PC, but all I have are male-female cables. Gender bender? Nope, not a DB9. Wait, though - I do have two DB9-DB25 adapters, and a DB25 gender bender. Frankencable? You bet.

Excellent, it worked. I was able to talk to the Propeller with the "Propeller Tool" programming environment.

Next, I wanted to check proper operating of the Propeller chip and EEPROM. I have no I/O (composite, VGA) connected to the Propeller, so instead, I used a clever program called PropTerminal that lets you talk from your PC to your Propeller using the same serial line that you use for programming. It worked, everything is great!

Last step - check the operation of the SD card. After doing the necessary programming, I was able to read a disk directory from the SD card. Success!

Next steps - add the components to talk to a PS/2 keyboard, VGA monitor, and of course, the RS232 connector to talk to the PX-8 laptop.

Also, I need to recharge the batteries in my PX-8s. They've been sitting around for a while, and I'm not sure the NiCads will be happy with me. But I'll see how they're doing. If I have to, I'll replace the NiCad batteries with some NiMH AA cells that I have...

Check back soon for more updates!

- Earl