First stab at CoCo Cartridge Housing.

This is a preview of a CoCo cartridge housing I’m designing in OpenSCAD.  The next thing that needs to be done is to add snapping clips on the inside so the top and bottom halves will snap together, and some internal structures to hold a circuit board in the right place to plug into the CoCo’s expansion bus.  Then it will be time to print the first prototype on the Thing-O-Matic and see how much I have to tweak the measurements to get it to print exactly what I want.  Then it will be time to add extra optional features, such as cut-outs for connectors and cables, ventilation slits, various PCB stand-offs, and so on.

I don’t think I’m going to try to design the sliding door that was on the original Radio Shack game carts.  But I could redesign the inside so that it is essentially closed, leaving only a slit for the card-edge connector to stick out if people thing that’s important.

I put the CPU board I picked up on Saturday, along with the 64K SRAM board.  I had to re-read my earlier post on getting the S-BUG monitor to run to remind myself which serial port to use and such.  But I still got nothing on the terminal.  I got as far as determining that the data lines on the SS 30 bus appear to be tri-stated (though the 68B09 does seem to be running the monitor) before I had to stop for the night.

Not yet sure what’s going on, but next time I work on it I need to check the MP-ID board, which provides the select signals and buffers the data bus for the SS 30 bus, among other things.

There isn’t universal agreement upon the location of these circuit boards at the time I acquired the others.  But whatever their original disposition, they have now been reunited with the rest of the SWTPC equipment under my custodianship.  Yay!  Sooooo…
What has been unearthed in this batch of antiquated computational goodness?  Essentially all the stuff I was missing before.  There is the second 6809 CPU board, a 64K DRAM board, a 64K SRAM board, two 32K SRAM boards, and a 6800 CPU board.  There are still parts of a couple SWTPC chassis and the housing for the cassette interface in Keith’s storage.  One of those chassis is undoubtedly for the 6800 CPU board, but I think one or both may be missing a backplane.

Want pics?  Here’s what we’ve got:

SWTPC MP-09B

Here is the other CPU board I knew must once have existed.  This one has been modified for 2MHz operation, but it doesn’t have the extra hack to switch between different boot ROMs.  It has SBUG 1.8 and 2K of SRAM on the board.  If I want to run this board I’ll have to check which memory and peripheral boards I have (if any) that can keep up with the 68B09 it’s fitted with.

SWTPC MP-A2

Here’s a 6800 CPU board.  I will definitely try to get this one running at some point.  It would be interesting to run FLEX on this, or go really old-school and put a tiny-BASIC in ROM.

32K Static RAM Board

There are a couple of these 32K static RAM boards.  These should be useful, assuming they can be made to work.  They have some jumper blocks to configure the addressing, but it isn’t immediately obvious from the silk screening how the jumpers are to be used, and I can’t find any documentation (or even mention) of these boards online.  Of course these things just use TTL chips on double-sided PC boards, so it shouldn’t be too difficult to reverse-engineer the address decoding if it comes to that.

64K SS 50 Tanner Computers, Inc.

This is a very nice memory board.  I gather that this board was sold by Digital Research (which I presume is Gary Kildall’s  Digital Research of CP/M / DR-DOS TOS fame) and designed by Tanner Computers.  This board can fill the entire 64K address space of the 680X with static RAM and/or (EP)ROM, using 2Kx8 chips.  Its addressing is pretty flexible, allowing 3 16K banks to be enabled or disabled separately, with the 4th 16K bank addressable in 2K blocks, so that memory can be packed fairly neatly around I/O devices in the upper address ranges.  In addition, this board can be used with the extended addressing that the MP-09A/B boards can produce with their DAT circuit, if I understand it correctly.

SWTPC M-64 64K DRAM Board

Here’s a 64K DRAM board.  Again, I can find no documentation for this board online, though it looks fairly straightforward.  This particular board has a 74S85 chip that is currently half hanging out of a socket labeled “ext[ended] addr”, which is right next to an empty socket labeled “non ext addr”.  This suggests that you can put the chip in one socket to put the memory into the lower 64K, or in the other socket to place the board (somewhere) in the extended address range.  But this may not be how it’s supposed to work.  It’ll probably take a little more digging to figure out how to make this memory appear where I want it to.

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.