The Retrobits Podcast

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

2011-07-31T22:47:00.000-07:00

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!

2011-07-31T22:32:00.000-07:00

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

One more day on Retrochallenge...

2011-07-30T21:33:00.000-07:00

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!

Detour #2 - The PC/XT Clone

2011-07-16T14:28:00.000-07:00

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

Detour #1 - The HX-20

2011-07-09T12:36:00.000-07:00

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!

Tomorrow starts the 2011 Retrochallenge

2011-06-30T09:58:00.000-07:00

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.

Retrochallenge 2011 Winter Warmup results

2011-02-04T15:49:00.000-08:00

And the results are in!!!

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

Retrochallenge Success!

2011-01-30T22:42:00.000-08:00

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!

RC 2011 Winter Warmup photos

2011-01-22T14:55:00.000-08:00

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

Episode #139 - covers my Retrochallenge 2011 Winter Warmup entry

2011-01-18T21:30:00.000-08:00

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!

Retrochallenge Step 1 COMPLETE (pics to come)

2011-01-08T14:22:00.000-08:00

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

Retrochallenge 2011 Winter Warmup!

2011-01-03T11:51:00.000-08:00

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!

Podfade

2010-11-23T13:59:00.000-08:00

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

My IBM 5155 Zip Drive adventure

2010-10-12T10:48:00.000-07:00

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

CP/M, the Old Skool Way

2010-07-31T19:05:00.000-07:00

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!

Voltage problem?

2010-07-26T19:39:00.000-07:00

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.

The first speed bump

2010-07-03T17:07:00.000-07:00

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

Linux has come a long way, baby

2010-07-02T10:27:00.000-07:00

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

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

2010-07-01T18:53:00.000-07:00

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!

2010-07-01T10:39:00.000-07:00

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!

PX-8 Virtual Drive, take 2

2010-06-28T14:18:00.000-07:00

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

Learning assembly on the C64

2010-06-27T15:32:00.000-07:00

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.

Retrochallenge 2010 starts in two weeks!

2010-06-19T19:05:00.000-07:00

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!

Welcome!

2010-06-17T20:20:00.001-07:00

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