Before I could even begin modifying view, I had to be able to build it from source.  My first attempt at doing this was on a regular CoCo3 using DriveWire, simply because it was already set up and ready to go.  I had to squash a little bug in root.a, which is a library file that came with the OS-9 Level II development system, re-extract a corrupted source file from the view44_source.lzh archive, locate the right version of ‘make’ (also by Tim Kientzle), and figure out which archive program I needed to use to unpack the source file.  (The first one I got to work was lha211.)

Tonight I made myself a good working system disk image to serve up over DriveWire so I could replicate my previous work on the CoCo3FPGA.  I couldn’t use the same one I had used on the CoCo3, since I am using the 6309 version of NitrOS-9 on it.

But this gave me the opportunity to compare the two CoCos head-to-head in a real-world computing task.

It takes a CoCo3 with a 6309 11:05 to assemble view 4.4 from source over DriveWire 4 at 115Kbps.  (The rma assembler is the stock program from the OS-9 Level II Development System disk image, so it doesn’t take advantage of any 6309 features, other than possibly benefiting from the 6309′s executing some instructions in fewer clock cycles in native mode.)  CoCo3FPGA does the same job in 5:31 — almost exactly twice as fast.  The CoCo3FPGA was also working over DriveWire 4 at 115Kbps, but I had it running at its 25MHz clock setting, which has some missing cycles, so it comes out to roughly 21MHz effective clock speed.  There’s a fair amount of I/O overhead involved with assembling view.  There are about 34 separate assembly source files that are read, assembled, and written out as relocatable object modules before being linked into the final executable, along with root.r.  All in all, I suspect that the assembly is not all that computationally intensive.  The fact that CoCo3FPGA still did it in half the time is pretty impressive.

It would be interesting to try to build it again from a ramdisk on each system and see how much faster it would go.  I should also try the CoCo3 running in 6809 mode.  Not tonight, though.  ‘Fall Back’ means that I feel like it’s almost midnight by now, and even though I’m working on a program from 1990, I guess I’m not 20 anymore.

Of course a bigger palette requires further modification of the Digilent board.  The Altera DE-1 already supports 12-bit color.  Feeling lazy, I chose not to mess around with the existing modification, and opted for the second method Gary has provided, which is adding a VGA breakout board to connector B1.  Instructions for doing this mod are in the documentation in the .zip file.  There are also photos showing how to wire up the breakout board and a message describing the details.

Since I first installed the CoCo3FPGA bit file on the Spartan 3 board I had a problem with the Windows 2000 computer I had used to run the Xilinx WebISE software.  So this time I installed WebISE 13.1 on my main PC, which is running Ubuntu LTS 10.04.  I have to say, it strikes me as a bit ridiculous that just to program the flash ROM on the FPGA board I had to download a 4Gigabyte archive file (seriously!)  I also had to compile a driver to get the parallel port JTAG cable working.  (Apparently you need to compile a driver even if you’re using a USB cable.)  This didn’t scare me — I’ve done plenty of that kind of thing in the past.  But it seems like quite a few hoops to jump through for what should be a simple process.  Furthermore, the process to compile the driver seemed a bit rinky-dink.  I’m used to ‘make config’, ‘make’, ‘sudo make install’.  But here you just do a ‘make’ and it will compile the module and plop it into the source directory.  You can’t really install it to any sensible place automatically.  I manually copied it to /opt/Xilinx/13.1/LabTools/LabTools/lib/lin/libusb-driver.so

But once you’ve got the software installed, you still need to figure out how to use it.  It isn’t immediately obvious.  The reason is that there isn’t a menu item or GUI widget called “Burn fusemap” or “Program device” or anything sensible until after you leap through some more rings.

First of all, I couldn’t get access to the parallel port as a regular user.  There’s a way to make it work, but I didn’t have the patience to get that all set up, so I just ran the program as superuser.  In order to get the application to see the library you need to load it on the command line when you start the program.  I tried to put that all in Ubuntu’s Application menu, but it wasn’t happy.  However the exact same syntax worked from a terminal window.  Maybe I need to put something in quotes in the application launcher.  I don’t know, but that’s an exercise for later.

So the command line ends up looking something like this:

sudo LD_PRELOAD=/opt/Xilinx/13.1/LabTools/LabTools/lib/lin/libusb-driver.so /opt/Xilinx/13.1/LabTools/LabTools/bin/lin/impact

‘impact’ is the one little program out of the 4G(compressed) of junk I had to install that you actually use to program the flash ROM.  Yes, I realize that when Gary Becker releases the source as he’s said he plans to do, I may actually want to use a little more of the Xilinx software if I get ambitious and try to add my own features.  But I think a lot of the stuff in there pertains only to other Xilinx parts.  It would be nice if you could download and install just the parts you actually need.

Once you’ve got the program running (which you should do after connecting the JTAG programming cable to the computer and the FPGA board) it will ask if you want to automatically create a project file.  My initial inclination was that I didn’t want a project file, as I simply wanted to burn a file that had already been created.  Nope.  Let it make a project file.  It will then do a ‘boundary scan’, which means it will look for devices attached to the programming cable.  On the Digilent board it should find the FPGA chip itself and a flash ROM.  The CoCo3FPGA file needs to be put into the flash ROM.  The Spartan 3 chip bootstraps itself from the flash chip upon reset.

After ‘impact’ finds the parts on your FPGA board an icon will magically appear on the toolbar allowing you to program it.  Use the CoCo3FPGA.mcs file included in the archive.  I gather that the .bit file itself is for programming the FPGA chip directly.  This is probably not what you want, since it will not survive a power cycle.

Gary includes a disk image file in the Altera DE-1 archive that has some BASIC programs on it, including a demo of the 12-bit palettes and the 256 color mode.  For some reason that isn’t included in the Spartan 3 archive.  So I downloaded the Altera version and got the demo disk.  As neat as the demos are, I really want to see some digitized photos in 256 colors.  I think that even with a 16-color image, having a palette of 4096 colors should produce a much better image than an ordinary CoCo 3 display (without tricks).  And double vertical resolution ought to help as well.  I’ll be really curious to see how the CoCo3FPGA’s real 256 color mode stacks up against the 8-bit artifact colors that are possible on a stock CoCo 3 with an NTSC monitor or TV.  When I have something to show I’ll do a side-by-side comparison.

But for that I’ll have to cook up some kind of a quick and dirty picture file viewer.  Time to do some programming.

I would eventually like to put together at least 256K of static RAM on a board and make use of the SWTPC’s DAT to run OS-9 Level II.  But I want to start with a simpler rendition of it, and 64K would be adequate to boot OS-9 LI.  For me, that should feel like a minor accomplishment, and running OS-9 LI ought to motivate me to make LII work.  That may require a little back-porting from the CoCo 3, because I don’t know of any Level II boot disk images for the SWTPC.  (If anyone has any, I would be interested.)  The CoCo 3′s DAT uses 8K blocks, while the SWTPC uses 4K blocks.  This will require a little rework — probably to OS9P2.  Otherwise, I think the Level I device drivers for the SWTPC hardware should work OK in Level II.  But all that plus a more complicated memory board is probably too much for a January project.

This afternoon I sat down to figure out a few of the details of the board I’ll have to make.  I found the schematic for a 32K static RAM board on Mike Holley’s web site, which shows me that I’m on the right track.  But I want my board to use 2 32K chips, and I need to disable the the chip select on the SRAMs when the upper 8K of memory is being accessed, because that’s where the I/O devices and ROM are mapped in the SWTPC.  Actually, if I change the addresses in the OS-9 device descriptors I think I can move them all into the uppermost 4K of memory, along with the 2K monitor ROM, leaving an additional 4K (very precious in an OS-9 Level I system) available for programs.

Mike Holley’s SRAM board uses a 74ls139 to provide Chip Select and whatnot, but since his memory board is far from interfering with I/O and ROM, it can get by with a very simple decode circuit.  To do what I want to do, I think I’m going to have to use a GAL16V8.  I have the hardware to burn the fusemap on a GAL, and I should have a few of the chips around.  Also, since they’re electrically erasable I can change it if I decide to move the I/O addresses up and free up an additional 4K.

Here’s my first stab at the logic equations for the decoder GAL:

GAL16V8

# Decode circuit for 32K SRAM board for SWTPC

# Ver. 1

#

# Syn = 0

# AC0 = 0

# AC1(n) = 0,0,0,0,0,0,0,0

Clk A15 A14 A13 /VMA /E RW NC1 NC2 GND

/R0CS /R1CS /WR /RD /BUFOE NC3 NC4 NC5 NC6 Vcc

R0CS = /A15 * /A14 * /A13 * VMA

R1CS = A15 * /A14 * /A13 * VMA

WR = /RW * /E * /A14 * /A13 * VMA

RD = RW * /E * /A14 * /A13 * VMA

BUFOE = /A14 * /A13 * VMA

Every so often the Color Computer mail list will erupt with the perennial discussion of what a “CoCo 4″ would be like.  (I prefer the term Next Generation CoCo, since there were already at least 3 or 4 computer systems that made some attempt to claim the “CoCo 4″ title back in the early 1990s, notably the TC-9 Tomcat / TC-70, and the MM/1.)  The discussion generally falls into two camps.  One advocates an enhanced CoCo that is purely emulated, running on modern PC hardware, possibly distributed with a very minimalistic free operating system to host it.  The other camp favors a hardware approach, probably using FPGAs.  (Arguably, the present CoCo3FPGA project has more enhancements over the CoCo 3 than the CoCo 2 did over the original CoCo, from the perspective of features the user can appreciate, and Gary Becker has suggested future improvements, such as enhanced graphics modes.)

Much of the discussion centers around the question of what makes a CoCo a CoCo.  Aside from running some large subset of existing Color Computer software, which can presently be done on modern PCs running emulators, what qualities would one look for in a successor machine?  The aesthetic experience is often mentioned in these discussions.

Bearing that in mind, I remembered that I had a CoCo 3 case left over from repackaging one in a mini tower case back in the ’90s, and I decided to adapt it to house the FPGA CoCo.  In it I found a broken CoCo 2 keyboard, which I gutted to make a housing for a mini PS/2 keyboard.  I had to cut out a little of the CoCo’s upper case to get it to fit, but aside from the keys being colored a little differently than the CoCo’s plastic, it almost looks like it belongs there.

I made some internal cabling for the VGA port, the DriveWire serial port, and the reset button, and mounted connectors on the rear of the computer.  I reused the reset button that I had de-soldered from the CoCo main board when I adapted it for the mini tower case.

The result is an FPGA CoCo that looks like a Color Computer.  I call it the FPGA CoCo HGE *  It powers on in an instant and doesn’t have to boot some other OS before it becomes a CoCo.  It looks like a CoCo.  It feels like a CoCo.  And in my humble opinion, running at an effective 21 MHz, and with built-in DriveWire support, it is at least a CoCo 3++ with the potential for more great features in the future.

FPGA CoCo HGE 1

FPGA CoCo HGE Top View

FPGA CoCo Glow

Rear Connections

Under The Hood 1

Under the Hood 2

Under The Hood 3

Under The Hood 4 -- Notice the video DAC resistor mod. Ugly, but it works.

FPGA CoCo

*Hot Glue Edition — between the keyboard assembly, the video mod, and the reset switch, there is about an entire stick of hot glue in there.

Since I last got distracted from this project, Gary Becker has modified the CoCo3FPGA, adding a built-in co-processor that emulates the WD1773 floppy disk controller chip and accesses disk images on a modern PC using the DriveWire protocol.  Earlier versions did a similar thing using a different server program Gary adapted from an Apple ][ implementation.  But DriveWire is more prevalent on the CoCo, and current versions also offer network support and use resources on the host PC for things like printing, and playing MIDI files.  This development reignited my interest in the CoCo3FPGA and motivated me to get it up and running.

CoCo3FPGA Running Disk Extended Color BASIC

CoCo3FPGA Running NitrOS-9

The SS-50 bus in these computers has been called “hacker friendly,” and this it undoubtedly is.  Unfortunately, it also has some hazards associated with it.  Most of these hazards have to do with the fact that the bus amounts to a forest of exposed conductors.  This fact, coupled with the enormous electrolytic caps in the power supply means that even if you unplug the computer, you can easily pop fuses while working inside the computer.

The first fuse I blew yesterday was while checking the 8V supply, but the second one blew while I was plugging in a dual serial board, with the computer powered off and unplugged.  The back panel bracket managed to bridge a couple of the protruding half-inch long pins as I was getting it lined up and I saw a little flash off in the direction of the power supply.  I had already bought a package of completely different fuses that afternoon and didn’t feel like going out again, so I borrowed a replacement from the other machine.

After that I was careful not only to unplug the computer, but also remove the fuse from the +16V line when inserting or removing interface boards, since that’s the last one of those I have at the moment.

The chassis I selected was the one with the MP-MB backplane and the MP-ID Interface Driver board.  I borrowed a 6821 PIA from the EPROM programmer and plugged it into the MP-T timer board.  I used a little hot glue to fasten Slim’s ROM selector switch to the side of the CPU board to keep it from blowing more fuses.

A little digression is in order here about the SWTPC bus.  It is in two parts, the SS-50, which is a proper bus, and the SS-30, which is “geographically” addressed.  In other words, each slot has its own select line, so it doesn’t have a full complement of address lines.  These board select signals are generated by circuitry on the motherboard in older systems, such as the MP-B3, or by the MP-ID board in the later system.  You can set the specific addressing with jumpers.  This makes the I/O boards simpler and cheaper, since they don’t need to decode their own addresses.  But they do need to be plugged into the slot that the monitor and OS expect them to be in.

The SS-50 bus has all the address lines (including the extended address lines on the newer system).  It is mainly used for the CPU board and memory boards, but of course one could make an I/O board that would go on the SS-50 bus and have its own address decoder.

So some time went into figuring out where the interface cards needed to be located in order to make S-BUG and OS-9 happy, and checking jumper settings for addressing and baud rates.

I plugged it all in and turned it on, hooked up the Wyse terminal, but got nothing on the screen.  I was looking for a ‘>’ character as a prompt from the monitor, but no such thing was forthcoming.  The 6809 felt slightly warmer than most of the other chips, so I thought it was probably trying to do something.  But whatever it was trying to do wasn’t making it as far as the terminal.   I was falling asleep, so I shut it off for the night.

This morning I came at it with a little more systematic approach.  I dug out my logic probe and took advantage of the “hacker friendly” bus to power it up.  The first things I checked were the Bus Status (BS) and Bus Available (BA) pins on the 6809.  They were both low, which indicated that it was in normal operating mode.  I could see the BS line go high when I hit the reset switch, which indicated it was servicing a reset or interrupt request.  I could also see that the high-order address lines were active, which added to my confidence that it was actually executing a program.

I figured out which toggle switch setting activated the S-BUG ROM and which one put it in UNIBUG.  The UNIBUG monitor apparently uses interrupts, which you could see periodically on the logic probe.  UNIBUG apparently doesn’t do much except boot UNIFLEX, unless you play dirty tricks on it, so I switched back to S-BUG.

I also determined that I had put the MP-S2 dual serial board in the wrong slot.  Actually I had moved it there from the right slot after reading the S-BUG documentation.  So much for TFM.  S-BUG was periodically asserting the board select signal for slot 0, so I moved the serial board back there.

I still wasn’t getting anything to come up on the terminal though, so I decided to see if I could get something else to talk to the Wyse.  I plugged in an old Pentium 133 laptop with Windows 98 and fired up Hyperterminal.  I hate that terminal program, but it was handy and came in a small package.  I set it to 9600, 8, none, 1, and hooked it up to the Wyse with a null-modem cable.

I could see characters from the Wyse in Hyperterminal, but nothing from the laptop showed up on the terminal.  Now I had set the terminal to half duplex while testing it.  The way I had understood half duplex was simply that it would echo on the local screen whatever you type.  But I thought that would mean that if the remote host echoed back your characters you would get two copies of everything you typed.  In this case it apparently means that it simply ignores anything that comes in from the outside world.  Whatever.

Switching it to full duplex resulted in the expected behavior.  So I plugged the Wyse back into the SWTPC and still got nothing.  Then I plugged it into serial port B, and you can see the results below.

First Power-on

S-BUG says 'hello'

I dug out an old Wyse WY-50 terminal, cleaned it up and got it working, more or less.  I don’t have many old fashioned text terminals among the mountains and piles of computer junk filling the basement and attic.  I could only dig up three:  The Wyse, a Televideo 950 that came with a Morrow CP/M computer, and a Soroc.

Of course, I have a wide assortment of computers with serial ports that could run terminal emulator programs and communicate with the SWTPC.  When I’m in a certain mood, I can enjoy the perverse, anachronistic thrill of using an Athlon XP+ as a terminal for a 1 MHz 6809.  But I view this project as more of a restoration than a wacky hack.  I want to get it to a state where it can be configured to provide a close facsimile of the aesthetic experience of computing in the mid ’70s to early ’80s.  I think that booting any operating system off a disk on the machine that’s supposed to be the terminal would really detract from the experience.

Even so, I contemplated turning one of several obsolete to archaic laptops into a terminal.  Even the largest of them is smaller by quite a bit than the smallest CRT terminal I have, and their lack of working batteries in no way diminishes their utility as a hard-wired serial text terminal.  I may end up using a ’386/sx booting DOS straight into a terminal emulator at some point in the game, but I really want to get a proper dedicated terminal working as well.

So of the three terminals, the Soroc and the Televideo were of the right vintage, but the Wyse has a superior keyboard.  I think the Wyse comes from around 1984 or so, which is just a few years later than what would be plausible for the SWTPC.  It shows in the styling.  The SWTPC case that houses the 6809 CPU board was little changed from the original one designed for the 6800 in 1975.  It is made of metal.  The metal is thick, and rectilinear.  An adult could use it as a chair with little fear of damage.

The Soroc is a thing of geeky beauty.  It has the keyboard and CRT all in one enclosure, and it looks like a prop out of a 1970s science fiction TV series.  Unfortunately, the example I have is in need of significant restoration itself.  It was stored under less than ideal conditions, and suffered some corrosion.  The main board seems to have escaped largely unharmed (after considerable clean up), but the keyboard circuit board needs about 54 5Ω resistors to be replaced.  It may someday work, but right now it’s out of the question.

The Televideo has the right look and feel, but it has one bad key on the keyboard.  Well, the key is now off the keyboard, and I think it’s something that would seldom if ever be used.  But the keyboard itself doesn’t type well, as was the case with many keyboards of that era.

So I may compromise with the Wyse.  It’s a real CRT serial text terminal that doesn’t load its software from mass-storage, though it’s a bit anachronistic.  But it has a nice keyboard.  If only the screen was amber instead of green…

In addition to cleaning up the Wyse terminal, I copied my OS-9 boot disk image to an old PC and used its 5.25″ 360K disk drive to write the disk image to a real floppy disk.  I hooked another 5.25″ drive up to a CoCo 2 and booted OS-9 to confirm that the floppy I made looked like a legit OS-9 disk.  I was able to read the root directory, though the stock OS-9 I booted just had single-sided, 35 track device descriptors, and no ‘dmode’ utility, so I got errors when I tried to look in any sub-directories or examine any of the files.  I may try to remedy that, though it will require some doing, since most of my good OS-9 stuff was done on 720K 3.5″ disks.

This still isn’t a proper reconstruction of the SWTPC OS-9 distribution disks I think, but it should work to boot the computer and get started playing.

First, there don’t seem to be any pristine copies of the original master OS-9 floppies, but rather somebody’s customized working copies.  I guess this is not a big deal, but it would be nice to have an idea of what came on the distribution disks for the SWTPC.  I have original disks for the Color Computer, so I can probably devise a plausible reconstruction.

The second issue is that many of the received disk images are not the right size for 40-track, Double Sided, Double Density 5.25″ floppy disks.  The emulator can use a disk image of any size, and some of the disk image files are 1.4, 4, 8, and 16 Megabytes — the size of period hard drives.  Some are 319K or 358K, which are plausible sizes for “360K” disks.  I think these have been formatted with 16 and 18 256-byte sectors per track respectively.  But what appeared to be the best bootable disk images were 640K files, which may be image files for 80 track disks, or possibly 8″ floppies with more sectors per track than 5.25″ disks.  So I needed to make a good set of disk images that could transfer onto real 40 track, low density, 5.25″ floppy disks.

So last night I copied one of the 319K image files and fired up  SWTPCemu to blank format it.  But the format utility  would just hang and I had to reboot OS-9.  Maybe it would eventually have done something, but I was falling asleep waiting for it.

SWTPCemu failing to format a disk image

I could just delete the contents of the disk, but I wanted the disk volume name to reflect the contents, since this was supposed to be an operating system master disk, and I couldn’t find a way to do that without reformatting.  So I fired up MESS, emulating a CoCo 3 with a 6309 processor, and booted a NitrOS9 image.  I selected this image because I knew it would have a good dmode usility I could use to set the disk parameters where I wanted them so I wouldn’t have to use an assembler to make a new device descriptor.

MESS CoCo 3 emulation did the job

MESS formatted the disk image just fine.  So I made one copy called ‘Blank’ and another called ‘OS-9 System Master’.  The latter I loaded back up into SWTPCemu.  I used cobbler to make a boot file on the new disk image, and ran a script called ‘makesys,’ conveniently left on the disk image, to copy everything else to the new disk.  I put the disk in drive 0 of the emulator and booted from it with no problem.

Now I need to look at my original CoCo OS-9 Level I disks and see what disks there were and what came on each disk, so I can create a reasonable facsimile of that for the SWTPC.

However, I also need to come up with an OS it can boot if it does come on.  There are three candidates:  FLEX, UNIFLEX, and OS-9.  Of the three, I’m much more comfortable with OS-9, since I’m a CoCo guy since 1980.  I would eventually like to see it boot all three, but I believe I’ll start with OS-9.  The CPU board has an EPROM that is clearly marked ‘UNIBUG 1.9,’ so it undoubtedly did run UNIFLEX.  I don’t know whether UNIBUG can be coaxed into booting OS-9, but I’ll probably have to burn my own OS-9-specific boot EPROM.

These computers came without any floppy disks.  Fortunately, boot disk images for all three SWTPC operating systems can be had on the Internet, in a package for an SWTPC emulator for MS-Windows.  So I need to make real floppy disks from the image files.

Fortunately, in addition to scads of random, assorted 5.25″ floppy disks I have lying around from days of yore, I also have a small supply of heretofore unopened boxes of 2s/2d floppies I’ve picked up in recent years from thrift stores.  True, they could have gone bad just sitting in their boxes, but given the fact that most of the ancient, abused disks I have been using on and off for the better part of 30 years still work, the chances that “New Old Stock” floppies will be reliable enough to serve as system master disks should be fairly high.

3 unopened boxes of low-density 5.25" floppy disks

So this evening I’m playing around with the SWTPC emulator.  It came with config files that put the emulator in the proper configuration for the various operating systems:  loading the proper boot ROM, selecting which peripheral cards are installed, setting them to the expected addresses, and so on.  I’ve booted the emulator up into OS-9, so I can figure out how to set up the real SWTPC.

One of the provided OS-9 disk images crashes the emulator hard.  In fact, it drives it so deep into the ground that I have to delete the registry entries associated with SWTPCEMU in order to get it to run again.  It’s a boot disk for the Peripheral Technologies PT-69K, which isn’t really an SWTPC anyway.  I’ve moved it into its own directory so I don’t keep clicking on it.  All the others work, or at least don’t bring down the program.

It appears that in addition to the 6809 CPU card, OS-9 requires the Console MP-S board at address 0xE00, the PT-FD2 floppy controller at 0xE014, and the MP-T timer at 0xE040.  The latter is probably used as the interrupt timer for multitasking.  Slim’s MP-T board is missing a 6821 PIA, but I’m sure I can supply one of those.  We have the DC-3 and the DC-4 floppy controllers, which I think may be compatible with the PT-FD2.  That will require a little looking into.

I’ll also need 64K of RAM to boot OS-9.  This may be the biggest problem.  If we use the 32K DRAM board, and the 16K and 2 8K SRAM boards, that will add up to 64K.  But they’re all different.  Will they work together in the same system?  Can we get them all addressed in such a way as to work with OS-9 and the required peripherals?  Actually, we may want just 56K of actual RAM because some of the 64K address space will be dedicated to I/O devices, and I don’t think the version of OS-9 we have for the SWTPC knows how to operate the DAT.  OS-9 Level II may be a back-porting project from the CoCo 3…

If worse comes to worst, I could probably build a simple static RAM board that would fill up the 64K address space with 1 or 2 chips salvaged from a ’486 motherboard’s LII cache and some interface logic.  But I hope I can use the original boards to boot OS-9.  There must at one time have been more memory boards than the ones that have survived, since this machine probably ran UNIFLEX and seems to have used the DAT to address more than 64K.

The next issue to get through is the format of the disk image files.  They have a .dsk extension, which is familiar from CoCo emulator files, but I wanted to make certain it was the same format, so I could use utilities I already have to transfer the image files to real floppy disks.  So I fired up a CoCo emulator and booted OS-9.  I was able to load up one of the OS-9 disk images from the SWTPC emulator with no problem, so that makes me a little more confident that it won’t be too difficult to make the actual disks.

I have an old PC that I keep a 5.25″ floppy disk on that I can set up and use to make the disks.

It is a little confusing though, because I don’t have any of the original documentation, and the information I do have seems at first to be contradictory.

Among the documents I’ve downloaded off the Internet I’ve found one that spells out what defines the different models of 6809-based SWTPc computers:

The /09 is “any SWTPC 6809 computer which uses an MP-B pr MP-B2 motherboard, … the single port MP-S serial interface and the MP-L and MP-LA parallel interfaces.”  The reset switch is on the right front panel.

“The 69A and 69K computers use the MP-B3 motherboard, … the MP-S2 serial and MP-L2 parallel interface boards.”  The reset switch is on the left front panel.  The 69A is the factory assembled version, and the 69K started life as a kit.

“The S/09 computer uses the MP-MB motherboard, … the MP-S2 serial and MP-L2 parallel interfaces.”  It has an MP-ID board, has a 20-bit extended address bus, and a reset switch on the right front panel.

One of Slim’s SWTPCs is clearly either a 69A or 69K, and the other is an S/09.  What makes this a bit confusing is that the name plate on the back of both computers has the model listed as ‘/09′.  But neither of these machines matches the description of the /09 computer.  Apparently the /09 designation can be a generic one that refers to any SWTPC computer with a 6809 microprocessor.  I might have thought that Slim put later motherboards into the earlier /09 chassys, except that what is called the /09 above has a different front panel than the later two models, and he would have had to have replaced that as well, which may have been possible, but probably wouldn’t have made much sense.

I’m not certain whether the 69 was an ‘A’ or a ‘K’, though the MP-LA parallel interface board looks hand-soldered, and there is a bare MP-LA board.  On the other hand, these computers may very well have been hand soldered even when assembled at the factory.  It’s also interesting to note that the MP-B3 motherboard in the 69 has been modified for extended ( >64K ) addressing.

I haven’t yet been able to determine which chassy the MP-09A CPU board originally belonged to, though it appears that it could operate in either one, as they are now.