Most 8008 based computers are very similar, the CPU, some static memory, maybe some EPROM with a monitor and I/O ports.

The 8 bit I/O instructions of the 8008 lead to very simple hardware interfaces. Typical interfaces include serial “bit banged” ports, where is single output and a single input bit is tied to a simple current loop or RS232 level interface. The other basic type is a parallel byte oriented interface, where bytes are sent to the output ports and latched by external (outside the CPU complex) hardware for use. An example of the latter type would be a UART, which converts a byte of data handed to it, into a serial stream of bits.

Like many programs of the time, most 8008 applications were written for a specific hardware platform and included drivers for that platform. Example platforms include the Mark-8, SCELBI, Mike, RGS, Microl, and so on.

The driver is the piece of code responsible for moving data between the CPU and whatever peripheral devices are used by that program. Any program of the period will initially be written with drivers appropriate for the platform that that programs original author is using.

Moving programs between these platforms with different I/O interfaces, involves replacing or rewriting the drivers, so the ported program will interface correctly with the hardware on the target platform.

What sometimes makes porting 8008 programs so difficult, is that often, different drivers make different use of the limited register set of the 8008. Programs written for a specific driver will be written to take account of the registers used by the driver. This is so that when the driver is called, the driver does not corrupt any registers that are in use by the main program.

So here’s the problem. Let us say that we are porting a program to a system that requires usage of an extra register in the user input handler program. The person porting the code has to go back to every place in the program that calls the user input driver and make sure that the extra register is available for that driver. Not only that, but any place that calls the routine that calls the driver, also has to take into account how those registers may be affected. With the 8008, this affect tends to cascade though the subroutine call stack, making reservation of a single register more complicated than expected.

For most processors, this isn’t a great big deal. If necessary, the programmer simply saves the register to memory, before calling the driver. However, with the 8008, saving the register requires that you set up H and L registers with the address in memory in which to save the register. If H and L are being used already, this means that not only do you have to save the first register, you first have to save H and L. Saving H and L requires 2 additional registers. To save the original H and L, you need to move them to different registers so that you can put the address of where the original H and L are to be saved into H and L. Then after the driver is called, you may have to restore all the registers back to the original settings.

If you are seriously constrained in total amount of memory, things get worse. An example of a memory constrained program is MCMON, which runs in a single 256 byte EPROM, plus a little bit of SRAM for variable storage. In the MCMON case, adding a bunch of code to save and restore registers everyplace a driver might get called, could could easily end up causing the program size to expand beyond the 256 bytes of available memory. It took considerable amount of work to make MCMON fit in the available space.

On the surface, porting 8008 programs would seem straight forward. In actual practice, I find it far from straight forward, and often a difficult process. I still recall porting the Starshooter game that was documented in an early Byte Magazine article. This game was written for the SCELBI and I was porting to a SCELBI, which would seem simple. However, the original author’s SCELBI must have had an UART, which simplified his drivers. A UART handles all the serialization in the UART chip. My SCELBI only had a bit banged serial interface, which required a more complex driver, which used additional registers. I managed to port the program, but it took me a number of hours to work through all the changes needed to make the game work on my system.

Down below is a link to a modified MCMON that supports SCELBI keyboard input and Scopewriter output. This monitor rewrite took a lot longer to get working than I expected. I had all kinds of issues figuring out a register and memory allocation scheme that wouldn’t bloat the code to beyond 256 bytes. In the end, I managed to squeeze it down enough so that I actually have 5 free bytes for additional features or bug fixes.

I verified this monitor is functional by first running it out of SRAM, and finally, when I thought everything was working well, I burned a 1702 EPROM. I installed the EPROM on the modified SCELBI 1K SRAM memory board which has provisions for a single 1702 EPROM. In the past, I had the serial interface version of MCMON in that spot.

It turns out that the Scopewriter output is much easier to read than the SCELBI CRT interface. This clarity comes at cost, as it only has one line of output compared the the SCELBI CRT’s five. However, it’s pretty clear to me, that because of the vastly more complex design, that the SCELBI CRT interface couldn’t compete, once the Scopewriter came out.

I had to delete the serial bootstrap function when I ported the MCMON to the keyboard/scopewriter combination. Anyway, a keyboard bootstrap wouldn’t work that well anyway. You might as well use the built in monitor commands to load memory. Manually entering a bootstrap isn’t going to be the end of the world. I did a test by entering in the complete MCMON into one page while running it out of another page. MCMON is amazingly efficient in terms of keystrokes when it comes to reading and writing memory. I was able to successfully type in a working copy of the monitor in just a few minutes. Entering a boot loader shouldn’t be much of an issue.

One thing about these vintage computer projects, is that one project always leads to more. I now need to upgrade my OS/X SCELBI emulator to support the Scopewriter.

I’ll also need to come up some kind of demo application, that will run with only one line of output visible at a time and can run in less than 4K of memory. This will preferably be some kind of game or other entertainment mechanism. Maybe someone knows of a small version of Colossal Cave or a similar app floating around.

Oh yeah, then there is the need to put this interface in a nice project box…

I had a few issues getting this set up working, but it had more to do with the fact that I hadn’t powered up my SCELBI 8H in a long time and I had forgotten how to set it up with MCMON and the serial port adapter. Once I had that all figured out, I just had to move the Scopewriter output ports from 4-7 to 0-3 and tweak the driver to reflect the changed port assignments. After that, the Scopewriter interface worked without any further problems. Well, to be honest, I did initially put a couple of the 74XX chips into the wrong sockets, but that was easily diagnosed and rectified.

The SCELBI-Scopewriter project has one more step. I’m going to create a modified version of MCMON that uses the Scopewriter for output and the SCELBI keyboard interface for input. This is a combination of historically available add ons. They will transform the SCELBI 8H from a very difficult to use computer to a machine that is fairly practical. If you added a cassette interface, the system ends up with pretty decent capabilities for the day. It’s true that the cassette driver would have to entered via the monitor program, but that shouldn’t take but a minute or two.

The neat thing about this, is that all this technology existed in one form or another, back in the mid 1970s. It’s true that I basically rewrote the Creed monitor for the SCELBI, but the rewrite was certainly something that was doable back in the day.

This interface is pretty simple. It uses the strobes and data bit 0 from three output ports to control the Scopewriter switches S1 through S3. It uses another strobe to load the character from the data bus into a 6 bit latch.

I thought about how best to implement this design. I even went through the effort to create a PCB design.

In the process of creating this PCB layout, I think I found one mistake in the schematics. OS7 should be connected to pin 13 on Z5 instead of pin 4. I’ll verify this when I power up and check it out.

When I remembered that I had a perf board with a 44 pin edge connector, I decided to build the Scopewriter interface with that. I could have etched the PCB that I laid out. This design requires a two sided PCB and etching those at home is quite a fiddly process. This perf board probably would have been slightly quicker to wire using wirewrap techniques, but I didn’t have a sufficient quantity of wirewrap sockets. I was able to complete the wiring on the perf board in about a half a day. That is about the same amount of time that it would take to cut, etch and drill a custom PCB. The result is shown below.

The interface uses 22 signal lines, which doesn’t leave room for power and ground on the same side of the edge connector. I decided to add +5 volts and ground to pins 1 and 3, on the top side. Those are the red wires in the photo.

Since I’m short on Amphenol sockets, I decided to connect three of the four strobes from the SCELBI chassis, without a full connector. I cut down and filed a finish nail so that it would fit snuggly into an Amphenol socket. Then I soldered it to the end of each wire.

It occurred to me that this interface could probably be redesigned to use two output ports instead of four. This can be done by latching data bits 1 and 2 with OS4, instead of using separate strobes to control S1 and S2. I decided to stay with the original design, so I could use the original software.

The build decisions were partly driven by what I had in my spare parts stash, which once again proved diverse enough to support this project without requiring any new purchases. That is a good thing.

This interface design is taken directly from the SCELBI Computer Digest, volume I, issue I. With the exception of the enclosure, it turns out that I had all the parts needed in my stash to build it. The dimension of the block of wood that I’m mounting this on, are set up such that it will be easy to move it into a Bud 3009-A enclosure. This is the enclosure in which most SCELBI peripherals are housed in.

It’s about ready to power up, but I’m wondering how much effort it will take to make it work. Unlike many people doing similar projects, I’m not real anxious to find out. More often that not, I’ve spent many hours trouble-shooting these kinds of designs before they could be made to work. Let’s just say that, at this point, I’m a little gun shy. I’ll most likely power it on tomorrow morning.

I’m preparing to try interfacing my Scopewriter to a SCELBI computer.  One issue I had with the Scopewriter was the character generator.  It was designed to use a TMS2501, which I have been unable to find a source for.  A while back, I adapted a GI 2513 for the purpose, but it was kind of a hack.  A while back, a friend in Europe sent me a substitute, a TESLA MHB 2501, which he says are readily available for low prices over there.

Tesla MHB2501 in scopewriter

This substitute works fine. Stay tuned for an future blog article describing how this interfacing project goes.

In September, I did a presentation on the history and technology of the SCELBI computer business at VCF-Midwest.  I enjoyed doing the research for that talk, and it inspired me to start writing down what I learned.  This story will be illustrated with many of the images that I have acquired over the years of researching SCELBI.

I’m about 2/3rds of the way through writing the initial draft.  As I put together this document, I am learning a lot more than I expected.  I have answered a few of the questions I had originally raised, in preparing the VCF-MW presentation.  Some other questions have been raised, but I suppose that that is how these things go.

As I started writing this story, I found it was necessary to put the SCELBI business in context with other start up businesses and hobby activities that were going on at the time.  This story is becoming almost as much, the story of the first generation of 8008 based home/hobby computers, as the story of SCELBI, itself.  I plan to have a draft to share in a month or two.

My hope that the vintage computer hobbyist or historian might enjoy this story, once I get it into shape.