PX-8 virtual drive mock-up - the gory details

I am quite pleased to report that I managed to create a prototype of a virtual disk drive for the PX-8, using a Propeller "Professional Development Board", and a cable (more on this later) to connect to the PX-8. Here is a brief background of the project, and what I wanted to accomplish for the Retrochallenge:

The Goal

Create a prototype of a PX-8 virtual disk drive using the Propeller microcontroller.

Measurement of Success

The virtual drive should respond to a DIR command from the PX-8, and load a single file.

Main Obstacle

Garbled communications between the Propeller and the PX-8 "serial" (peripheral) port.

What we have here is a failure...

The PX-8 communicates with its peripherals over something called the "serial" port. This is different than the RS-232 port (it's got one of those, too); however, it is actually RS-232 under the hood. Specifically, 38400 baud, no parity, 8 bits, 1 stop bit.

The Propeller development board has built in a MAX3232 level converter and a female DB-9 connector wired as "DCE" (like a modem). Part of the stock software that comes with the Propeller IDE (called the "Propeller Tool") is a module for doing serial communications.

I had a model of software to work from - the "vfloppy" program. This software runs under Linux, and is a virtual disk drive for the PX-8. It is open-source, and works great.

But in order to make any progress at all, I first needed to find a solution to garbled communications between the Propeller and the PX-8. When looking at the bytes going to and fro, it was clear something was haywire.

That something was me.

When I constructed the cable for use with vfloppy, I neglected that a serial cable has two types of ground. One is similar to chassis ground, and the other is signal ground. The reference I was reading at the time for the PX-8 serial port connector did not differentiate, so I hooked the PX-8 signal ground to the PC side chassis ground. This made it kind of work, but not reliably, as there was obviously impedance between the two types of ground. Once I figured this out, just a few days ago, the garbled communications went away. Just in time, I hoped, for a Retrochallenge entry.

Now to make the Prototype

I knew I wouldn't have time to actually duplicate the EPSP protocol in time, so I thought, why not capture a session with a working package (vfloppy), then make a Propeller program to play back that session. It's a very dumb program, with hard-coded bytes in and bytes out. However, although a one-trick pony, it would demonstrate that not only could the PX-8 and Propeller now communicate, but actually have a working conversation.

vfloppy has a great debug mode that can output everything that's going on in a session. I captured that output for a session that included:

• Go to the E: drive
• Do a directory
• Load a program called "BATTERY.COM"

The session was REALLY long, with lots of bytes. I knew I couldn't write a Propeller program that duplicated that session by hand. So, I dusted off my Perl brain cells, and wrote a Perl program that took the session output from vfloppy debug mode, and converted it to Propeller "Spin" code (Spin is the native language of the Propeller). Here's the ugly Perl code:



By the way, I know the pictures are not good. The lighting was bad, and I'm out of time. I'll get some better pictures later...

And here is a portion of the Spin program that it helped me to write (this is the Propeller Tool, the IDE for Propeller programming):



Here's a picture of the Propeller development board, wired up with VGA output and RS232 output, functioning as the PX-8 virtual drive:



And here's a picture of the PX-8 before power-up:



In the next picture, I power up the virtual drive and PX-8, then navigate to the E: drive. When this happens, the in/out byte sequence plays between the PX-8 and the Propeller exactly as recorded when I did the real session with vfloppy.

(For the next pictures, you'll have to click the image to get a bigger version to make it readable. Again, sorry for the bad lighting, and the notoriously bad contrast on the PX-8 display...)

Notice the PX-8 happily shows the E> prompt, perfectly fooled that it's talking to a real drive:



This thing is functioning like a player piano - so I have to type everything just like I typed it in the real session. Any deviation will make the house of cards fall down. So next, I type DIR (return), just like I did for real with vfloppy:



Now, the big moment - I actually run a program! From the PX-8's point of view, it still thinks it's talking to a real floppy drive. From the Propeller's point of view, it's just waiting for the right bytes to come in, then spewing what was recorded earlier:



Smoke and Mirrors


Before you say it, I know - this approach is smoke and mirrors, because there's really near zero intelligence on the Propeller side. However, it met my goal in proving that the PX-8 and Propeller could successfully communicate, and that the Propeller, when properly programmed, can be a virtual drive for the PX-8.

Next Steps!


Now that the facade has proven the viability of the project, my next step is to begin to crank out the code that makes this thing a virtual drive for real.

An SD card will serve as the mass storage for this device. I've used an SD card with the Propeller before, so that assumption should be a safe one.

The vfloppy code is a very useful reference implementation, but I want to make sure I understand everything that it does, and not just copy the logic from it. As I work through the reverse engineering and compare with the published Epson protocols, I'm sure it will be fun and enlightening.

I will keep my progress updated on this blog, and as the project matures, I may actually start a dedicated blog and progress site.

Yay! Time for some sleep! See you all in the Winter Warmup...