Sunday, July 31, 2011

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...

SUCCESS!

Full blog post coming next - but I'm packing a happy hooray and sigh of relief, as my Retrochallenge finishes successfully with hours to spare!

Details within a few minutes...

Saturday, July 30, 2011

One more day on Retrochallenge...

I've got one more day on the Retrochallenge.

And I've figured out the cause of the technical problem I was having with serial communications between the Propeller microcontroller chip, and the Epson PX-8 laptop.

Need to do a little soldering, and then hopefully, I can crank out enough code tomorrow to meet my objective!

Saturday, July 16, 2011

Detour #2 - The PC/XT Clone

One of the best times of my career was working with IBM PC/XT systems. Like many things we retro nerds play with, it seems quite primitive by today's standards. But this machine really did usher in the age where business got done with personal computers. And I had the good fortune to be right in the middle of it.

At Hughes Aircraft in the mid 80s, we were pretty much standardized on true-blue IBM. There was a small installed base of Compaq systems, and eventually clones got good enough to rely upon. While the clone dealer we worked with made very good systems, nothing really ever beat the tank-like quality of PC/XTs. I'm not convinced anything short of mil-spec equipment ever will. They were very nearly indestructible, and I can attest to this firsthand.

For this reason, using my PC Portable 5155 has been a joy. It's basically a PC/XT in a portable case, with 9" amber screen, dual 5.25" 360K floppy drives and CGA video in a very well-built case. The 5155 does have some inherent limitations, though - most notably, room for expansion. The form factor of the case makes it difficult to upgrade, since much of the card slot area is blocked by other components. Many of the card slots will only accept half-length cards, and 2 of the 3 full length slots are blocked by the built-in cards (CGA, floppy controller). I was able to get an AST SixPak Plus in there, luckily - otherwise I would have been stuck at a listless 256K of RAM.

Years ago, a buddy of mine gave me a turbo XT clone that he had used back in the day. To the best of his knowledge it was working, but it was missing parts. I had thought a couple of times of robbing parts from the PC 5155, since the clone case would be much more expandable, and more like the desktop machines I used back in the day. But I couldn't bring myself to gut a perfectly working piece of history.

Until it died.

I have a pretty pragmatic approach to my vintage computing. I don't buy something unless it works - no museum pieces. I also don't buy anything so expensive that I'm hesitant to play with it. So when it dies, I either repair it, or give it away. This time was weird and different, since I decided to harvest parts. But it was clear from troubleshooting that something on the motherboard was amiss, so I knew I could get working boards, etc.

It was a challenge to extract the keyboard. The keyboard just snaps off the unit, but the connector is an RJ-style hookup. Inside the 5155, the cable is translated to a standard 5-pin DIN cable by an adapter. I had to extract that adapter, which required some careful disassembly.

Here is the keyboard cable and attached adapter (extracted from within the 5155):



Here is the clone box open:



Card from left to right: CGA video adapter (from 5155), AST SixPak Plus (recovered from 5155), Western Digital FileCard hard drive on a card (10 MB), D-Link 10 Mbps ISA Ethernet card (yes, it networks!), and floppy controller (from the 5155). That's a single 5.25" 360K floppy on the right.

This case and power supply has a very PC/XT reminiscent feel. However, it is clone hardware, lacking a bit of the fit and finish of a real XT. It is pretty nice, though.

I connected it all and fired it up - success!



I did have to install DOS and other related software onto the hard card - more on all that later.

Here's a close-up shot of the computer with DOS running, showing the memory usage:



(Sorry that last pic is a bit dark - the screen doesn't show up well with a flash.)

That's all for now - I need to get started on my real Retrochallenge project! More later on the hard card, networking with Novell Netware 3.12, etc...

Saturday, July 9, 2011

Detour #1 - The HX-20

I'm trying to get started on my Retrochallenge 2011 entry. It's already July 9, and I've only got until July 31st to finish. However, I have stumbled over two hobby-oriented detours on my way to the work on the PX-8 disk drive. The first one? Rejuvenating my dear old Epson HX-20.

The HX-20 is widely regarded as the world's first notebook computer. Epson introduced the system in 1981, and I sold them in retail when they were released. Later, when working for Epson, I had the pleasure of being on the portable computer tech support team.

Back in '07, I received an HX-20 system, along with accessories, as a gift from Bill, a Retrobits listener. Since then, I have used the computer from time to time, but it was somewhat hobbled by an old and flaky NiCD battery pack. I replaced that battery with a 4 AA cell NiMH homebrew pack, but there were two things wrong with this. One, the charging dynamic on NiMH is different than NiCD, and I was never quite sure if I would smoke the NiMH and cause it to leak inside my HX-20. Second, the 4 AA pack was a weird fit and thus, an unsuitable replacement for the 4 sub-C cells that ships with the unit.

I considered buying 4 sub-C NiCD cells and making my own pack, but this gets complicated. The soldering and heat-shrink work is pretty exacting, especially since the 4 sub-C cell pack fits really, really tight in the HX-20's battery compartment. So, after some research, I found out that Batteries Plus makes custom batteries, and I gave them a try. The result was very good.

Here is the HX-20 disassembled, ready for the new pack. Disassembling the unit is pretty easy, but there are flat ribbon connector cables to worry about. These can be fragile and brittle in older computers, so I was quite careful in working with them.



Batteries Plus obtained and used the right connector type, so the battery fit snugly but perfectly. This is the battery they made:



Here it is installed, with the battery holder back in place:



The flat ribbon cables I mentioned before were a little tricky to get re-seated properly when I put the two halves of the computer back together. At first, some of the keys on the keyboard didn't work. I needed to take it back apart and re-seat those cables, then all was fine. Here's the unit back together, and running from the charge the battery had as delivered:



Happy me - 1981 computer, 2011 batteries. As you can see, the system itself is in great shape. I've got all the manuals and everything. So, in a little while, I'm going to crank out some new BASIC programs.

Next post - Detour #2 - my PC/XT clone Frankenstein!

Thursday, June 30, 2011

Tomorrow starts the 2011 Retrochallenge

The Retrochallenge 2011 officially kicks off tomorrow (well, really, tonight at midnight). This year, again, I am trying to jump-start my project for a Epson PX-8 virtual disk drive.

Yes, this is the 3rd attempt. And since the third time is the charm, as Bullwinkle would say, "This time for sure!"

More info tomorrow with pictures, specifications, links, and other fun.

Friday, February 4, 2011

Retrochallenge 2011 Winter Warmup results

And the results are in!!!

Check out the Retrochallenge site for the 2011 Winter Warmup results! Congratulations to the 2011WW winners!

Sunday, January 30, 2011

Retrochallenge Success!

To recap - my goals for the Retrochallenge 2011 Winter Warmup were:

  • Build a cable to connect the Commodore SFD-1001 drive to the PET 2001-8N.
  • Test the cable and the drive by successfully formatting a disk, saving a program, then re-loading that program into memory.
  • Get some software from the Internet, load it into the PET, then save it to the SFD-1001.
Having done the first two steps, I set out this evening to finish step 3 - getting some bits from the Internet to the PET. And - success!

(With one caveat - I actually created the program that I moved from my PC to the PET/SFD-1001, using VICE. But it could have been a PRG program from anywhere.)

Here are the steps I used to get the program from my PC to the PET, then to the SFD-1001:

Create program in VICE

I typed a small (very!) program into the VICE Commodore PET emulator program, then saved it to a virtual tape file ("TAP" file). It's pretty easy to create and use a virtual tape image in VICE. I'll leave the "how" as an exercise to the reader, but you'll figure it out in less than a minute.



Create a WAV file with an analog C2N-compatible audio image of the program

Next, I used a program called "Audiotap" that converts a virtual TAP file into an audio "WAV" file.



This program prompts you for the *.TAP file, then for the output *.WAV file. It then creates an audio WAV file that reflects the same signal you'd hear as created/used by a real Commodore C2N cassette drive.

Record the WAV file to tape

Now, creating this file and recording it to a cassette deck was pretty easy. Getting it to read on the PET was hard. The audio levels had to be adjusted properly, and I actually had to switch computers once. I was trying to use my laptop for this, but its sound output is too noisy. I eventually switched to my desktop, which has a SoundBlaster Audigy 2 ZS, and this was squeaky clean. Here's the mono cassette deck I used:



Load the program from C2N tape into the PET

Once the WAV file was recorded on the tape, then I moved it to the C2N cassette deck, and attempted to load the program from tape.



As I mentioned, getting the analog levels correct was tricky - but once done, things were looking up!



Save the program to the SFD-1001

With the program successfully in memory, I wasted no time in saving it to the SFD-1001:



Test that it all worked

With the program safely moved from the PC to the PET to the SFD-1001, I then did a cold-start (just to make sure there's nothing up my sleeves), and loaded the program back from disk:



Voila! Bits moved successfully from the PC realm to the PET via good ol' cassette tape, then tucked safely away on disk.

The future

As I've been reading up on moving programs between the PC and the PET, I've found that there are several options, all of which are better and more sophisticated than the cassette tape proxy method that I just performed. I'll be looking into these, perhaps building some more hardware, and then will blog with future results.

But for now, I will bask in the bright light of Retrochallenge success!

Saturday, January 22, 2011

RC 2011 Winter Warmup photos

As promised, here are some photos of my Retrochallenge 2011 Winter Warmup project. You click on the pictures to get a bigger version.

First, let's start with a photo of the PET 2001-8N, SFD-1001 disk drive, and handy 5.25" disk holder (containing a DS/DD disk!):



Here's a close-up of the PET:



Here is the SFD-1001 IEEE-488 drive. Notice the DIP switch on the lower right-hand side - this is the "hacked" device select that I talked about earlier:



Here is the drive side of the cable I made. Note that it's a 24-pin Amphenol connector - smaller than Centronics-style printer plug, but similar in appearance:



Here are a couple of pics of the PET side of the cable (this is the side I soldered). A bit ugly, but functional - and I got good solder joints. I think I'm doing better with my soldering these days. Note that it's the same type of connector as the PET (and later) user port:





This is the SFD-1001 formatting the disk:



And here is the result - notice the 4133 BLOCKS FREE - that's slightly over 1 MB. Read it and weep.



OK, here's where I chain two programs together, while not losing the variables in-between. There are two programs on the disk, creatively named PROGRAM1 and PROGRAM2. I've got screen shots; however, the first screen shot is pretty fuzzy, so here's the code...

PROGRAM1:

5 PRINT "NOW RUNNING PROGRAM1"
10 A=1001
20 A$="SFD1001":A$=A$+""
30 PRINT A
40 PRINT A$
50 PRINT "CHAINING TO PROGRAM2"
60 PRINT
70 LOAD "PROGRAM2",8

Hey, on line 20, what am I doing with the A$=A$+""? Why add a null string to another string? Here's a summary - When Commodore BASIC sees a new string defined like A$="HELLO", it leaves the string storage right in the BASIC program. Why move it and take up more space? Pretty efficient - except when you chain to another program, that line number is gone, and so is your string. So you need to do something to Commodore BASIC to make the string "dynamic" - stored in variable memory, rather than right in the BASIC program. Adding a null string is one way to convince the string to be "dynamic".

For a better and more lengthy explanation, see Jim Butterfield's 5 part series on this topic, as provided to me by Nathan (thanks Nathan!). (Links at the end of this blog post.)

PROGRAM2:

10 PRINT "NOW RUNNING PROGRAM2"
20 PRINT A
30 PRINT A$

Pretty simple, right? Line 70 of PROGRAM1 loads PROGRAM2 from disk, and it starts running, printing the variables to prove they made it! Here are the screen shots, including the program running:

PROGRAM1:



PROGRAM2:



Running PROGRAM1, which chains to PROGRAM2 - Drum roll please!



It's ALIVEEEEEE!!!

OK, here are the links to the Jim Butterfield articles if you'd like to read up.

Loading And Linking Commodore Programs by Jim Butterfield (Part 1,) Part 2, Part 3, Part 4, Part 5.

My next posting, perhaps later this weekend, will be a first shot at getting bits from the Intarwebs into the PET, and onto the SFD-1001! Stay tuned!

As a side note, my cat Stormie decided to upstage my retro hobby today. When she wants attention, she's pretty persistent. From one PET to another...

Tuesday, January 18, 2011

Episode #139 - covers my Retrochallenge 2011 Winter Warmup entry

Be sure to check out Episode #139 of the Retrobits Podcast, which I devote to the SFD-1001 drive, IEEE-488, and my Retrochallenge 2011 Winter Warmup entry!

Highlights:

  • The SFD-1001 drive and cable are functional and working well.
  • I've been able to "chain" two BASIC programs together to make a more "complex" program; however, string variables may not be preserved when loading one program from another. More research required.
  • My proposed first-pass method to move a program from the Internet to the SFD-1001 involves using an emulator to create a TAP (virtual cassette tape) file of the desired program, using another utility to turn that TAP file into a WAV file, recording the WAV to a cassette tape, then loading that program from that tape onto the PET 2001 using the C2N cassette deck. Finally, the program will be stored from the PET to the SFD-1001. Whew! Morse code goes faster!
Another week and a half to finish! Hoping for a success!

Saturday, January 8, 2011

Retrochallenge Step 1 COMPLETE (pics to come)

Hi all,

I successfully soldered up a cable, hooked up the PET 2001-8N and the SFD-1001, then proceeded to format a disk. Saved a BASIC program and loaded it back up - worked like a charm!

Retrochallenge Step 1 COMPLETE.

One speed bump - my SFD-1001 has a homebrew-added DIP socket on the front (lower-right side). I thought it might be a device select, but was assured it wasn't. Well, it was. When the drive refused to talk, I traced the wires back to the drive internals, and found that it had been hacked into the chip sockets where the device select is set. Hooked up a jumper, and blammo, drive working!

I have LOTS of free blocks. This drive stores 1 MB per floppy (!). Now I've got somewhere to put all the programs - ever made - and then some - for my 8K PET :-) Guess I'd better start writing some of my own programs!

Pics (and video?) to come...

Monday, January 3, 2011

Retrochallenge 2011 Winter Warmup!

I'm getting started on my Retrochallenge Winter Warmup 2011 project! Here is the description and some more details...

A while back, a friend gave me a PET 2001-8N. It's in really nice condition. The -8N means 8K of RAM (and a standard sized keyboard), so it's not a powerhouse - but it is among the first models of computers produced by Commodore. I have the accompanying tape drive - a C2N Datasette. But I have to admit, I've wanted a disk drive.

My PET is not the first model produced by Commodore - that honor would go to the smaller keyboard PET 2001 with the built-in datasette. (This is, of course, if you don't count the KIM-1 SBC, which was produced by MOS Technology prior to the Commodore acquisition.) However, my 2001-8N does have the correct ROMs to support a disk drive. So when the opportunity came up to get an SFD-1001, I jumped at the chance. It needed about $30 worth of repairs, but now it's up and running, and refurbished.

The SFD-1001 is an interesting device. It can store 1 MB on a single floppy disk. It is supposed to use "quad density" media, but even back in the day, this was pretty rare and expensive. So people figured out that you could use standard double-density media, and it would mostly work. That's what I plan to do. The SFD-1001 looks much like a standard Commodore 1541, but it has an IEEE-488 interface. And, as it turns out, I don't have an IEEE-488 cable. I could buy one, but I already have the pieces, so I'm going to try building one. Which brings me to my project:

Step 1: Build the cable

The PET user port is the same style connection as the VIC-20/C64/C128 user port. The pinouts are not all the same, but the flat-edge connector style is identical. As it turns out, the IEEE-488 connection on the PET is also the same style connector - it just has the flat-edge "notch" at a different location. If you're using a non-keyed connector, you can use a user-port connector for the PET side of the cable. I have a solder-style user-port connector, so I'm set on that end.

The other side of the cable is more of a problem. The disk drive end of the cable requires a male 24-pin Amphenol plug. I do have one; however, I'm going to have to harvest it from a non-working IEEE-488 adapter for the C64. It is a difficult decision to "snip" this cable from the adapter; however, the adapter is broken, and I don't have the facilities or inclination to fix it. So, the Amphenol connector and attached ribbon cable will be "re-purposed".

I have to sketch out the pinouts for both sides of the cable, then get out my wire strippers, soldering iron, multimeter, and make it happen.

Here's the rest (details coming in later posts):

Step 2: Test the cable by formatting a disk, then saving/loading a program.

Step 3: Get some software from the Internet, get it to the PET, then get it on the disk drive.

Step 4: (Extra credit) Figure out if it's possible to "chain" BASIC programs, so that an 8K PET can run some programs that are slightly more sophisticated.

Off I go! Pictures to come shortly!