Winter Retrochallenge – 64K SRAM Board

After finally getting my FPGA CoCo up and running, I think it’s time to get back to work on Slim’s SWTPC, so I’m using the winter 2011 Retrochallenge as a motivator to put together a memory board that can be used to boot OS-9 Level I.  None of the memory boards that came to me with the computer have enough capacity, though I could probably put 56K together with several.  But they also appear to be unreliable.  So I intend to make a 64K memory board using 2 32K x 8-bit static RAM chips pulled from the level 2 cache of Pentium or ’486 motherboards.

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

 

First Power

After a little sanity checking to make sure the gigantic power supply caps were still OK, I powered on one of the SWTPCs yesterday afternoon.  With a linear power supply, I could check it with no load and make sure it was putting out the proper voltages.

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'

Terminals and Floppy Disks

This week I’ve spent my free time inching forward on some of the prep work for getting the SWTPC running.

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.

Disk Image Complications

A couple realizations have hit me about the OS-9 boot disk images that came with SWTPCEMU.

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.

Disk Image Fun

Well, I guess it’s been half a year since I did anything with the SWTPCs.  Before I try to power them up, I want to put forth some minimal effort to see if the big power supply caps are going to be any good, and I don’t have time to do that right now.

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.

Forensic Computology

So just what kinds of computers do we have here?  Sorting the pieces out is a little like separating the remains after a plane crash.  Well, not quite that bad.

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.

Understanding the DAT

After staring at the schematic and thinking about it for a while, I’ve convinced myself that the DAT circuit is actually more straightforward than I was initially thinking it to be.  There are actually 2 74S189 chips on the board.  One is soldered in, and is a standard component.  It doesn’t expand the overall physical address space, since its data outputs are hooked up to address lines A12-A15, which are already present on the 6809′s address bus.  But it does make it possible to remap 4K chunks into any of 16 slots in the 64K address space.

The second 74S189 is apparently an optional component, plugged into a socket.  It reassigns the function of four lines on the SS-50 bus.  These had been baud rate signals, output by the MC14411 on previous versions of the bus, but are converted into extended address lines A16-A19.  The first ’189 occupies the least significant nybble of the bytes from FFF0-FFFF (for writing only — when reading, these must provide reset and interrupt vectors from ROM), and the second ’189 occupies the most significant nybble.

I’ve seen information suggesting that these computers could use 384K, 768K, or 1M of RAM.  I don’t see any reason why they couldn’t address up to 1M through the DAT with a 20-bit extended address bus.  I’ve never seen any explanation for why they should be limited to 384K or 768K, unless it was just a practical limiatation given the memory technologies available at the time.  But even so, documentation from SWTPc suggests that a maximum of 384K can be realized using 128K memory boards.  That would make 3 boards.  Add 1 for the CPU board, that would make 4.  On an MP-MB or MP-B3 motherboard, there would still be 4 more SS-50 slots into which one could put memory boards.  That comes out to 896K.  I don’t know why these days one couldn’t build a board interfacing an old 1M 30-pin SIMM to the SS-50 bus if one was sufficiently motivated.

Initial Investigation of Slim’s MP-09A CPU Board

I wonder if the modifications and “Rev. B” sticker constitute a factory upgrade to the MP-09B.  Does anyone know about this?  I’ve also read a web page that suggests that the MC14411 Baud Rate Generator and the DAT RAM are mutually exclusive.  Slim’s doesn’t have the baud rate generator, but does have the74LS189 DAT chip.  This suggests that this CPU board may be able to address more than 64K, which would be very nice.  It has a Unibug 1.9 EPROM, which suggests that at one time this computer ran UniFlex.  I don’t yet know whether UniFlex required or supported the DAT, but it was a later development of Flex, so it wouldn’t surprise me.

The leftmost ROM/SRAM socket held an unlabeled 2716 EPROM, which I popped out and stuck into my UDP to read and back up.  The ASCII strings in the dump revealed it to be SBUG 1.8.  The UniBug EPROM lies just to the right of the SBUG EPROM.  I’ve backed it up as well.  The next socket over to the right contains a 6116 2K SRAM, and the fourth socket is empty.

MP-09A Component Side

MP-09A Solder Side

Catalog of Slim’s SWTPc Stuff

Here’s an initial catalog of the SWTPc 6809 bits as received.

Loose Boards:

• Qty. 2 SWTPC MP-M 4K Static RAM Board — fully populated, 1 w/ RAM, missing heat sink, 1 w/ 2 missing 74ls138s
• Motorola SMS3508 SWTPC 32K DRAM Board
• Qty. 2 Midwest Scientific Instruments 8K Static RAM Board
• Digital Research DRC SS-50 16K Static RAM Board — with modification
• F&D Associates PMB-1 6845 CRT Controller Board
• MP-09A 6809 CPU Board (Rev. B Sticker) — lots of modifications, missing MC14411 & 1.8432MHz Crystal
• SWTPC DC-4 Floppy Disk Controller Board
• SWTPC MP-S 6850 Serial Board — strapped for IRQ; some components removed, or not stuffed
• SWTPC MP-T Timer Board — missing 6821 PIA
• SWTPC MP-N Calculator Board — missing 6821 PIA
• Qty. 2 SWTPC MP-LA Parallel Interface Board — 1 PCB Only, still sealed in plastic bag; 1 partially assembled
• SWTPC AC-30 Cassette Interface — board only
• Unidentified RTC Board w/ MSM5832RS
• 2 Unidentified Homebrew Boards
• 1 Homebrew Bus Extender Board
• 2 Bus Extender Boards

Boards that were in the two backplanes:

Chassis Serial# 189009

• SWTPC MP-MB Backplane — Stamped Aug 6 1981
• SWTPC MP-R EPROM Programmer — modified with a daughterboard and a switch
• Unidentified RTC Board w/ MSM5832RS — as above
• Qty. 2 SWTPC MP-S 6850 Serial Board — strapped for IRQ; some components removed, or not stuffed
• SWTPC MP-S2 Dual Serial Interface
• SWTPC MP-ID Interface Driver Board

Chassis Serial# 058807

• SWTPC MP-B3 Backplane
• SWTPC MP-LA Parallel Interface Board
• SWTPC DC-3 Floppy Disk Controller Board
• SWTPC MP-S2 Dual Serial Interface

One observation is that it appears we have only one CPU board, which is kind of a shame.

Slim’s SWTPc 6809 Computers

My friend Keith helped sort through a large amount of electronic equipment left when his friend ‘Slim’ died.  Among the things he received were parts of several SWTPc computers.  At least two of these were SWTPc 6809 systems, including two 5.25″ floppy disk systems.

When I saw these I immediately expressed interest, and today I’ve brought them to my house for the purpose of restoring them to working condition and doing something interesting with them.  One of the conditions for my stewardship of these machines is that I blog about my activities with them for the edification and amusement of those who are interested in such things, and to prove that they don’t simply disappear into an ignominious obscurity in the depths of my basement.

We don’t appear to have any floppy disks or documentation, but that stuff is available on the Internet.

Projected Milestones:

1. Get one or both systems to power up without exploding capacitors or letting out any smoke.
2. Use a ROM monitor to play in RAM.
3. Get a floppy disk system running.
4. Boot Flex.
5. Boot OS-9.
6. Get some archaic text adventures and BASIC games to run.

But first I need to figure out just what is here in these boxes of boards.  So I’ll begin by cataloging the boards.  I’ll try to post some photos, especially of unusual boards and details.