Work on reproduction of this PCB card nearing the end of the CAD phase. I’ve gone through numerous design checks and think that if I had a card made with the current CAD files that I most likely will have all the connections correctly made.

I’m currently going through a final pass of making sure alignment of reproduction traces matches with the original. Though I am close to finalizing those changes, close inspection is still revealing a few adjustments that will improve fidelity to the original design.

Once I get to the point that I can’t find any more tweaks to make, I’ll pull the trigger on getting a small batch of boards made. I expect very limited demand, so this will most likely be the only batch that I make.

I’ve also created modified schematics that includes part identifiers that match what I’ve done in my CAD program. The original Digital Group schematics do not include any part identifiers. Here is what the board with identifiers currently looks like in my CAD file. Note that chip orientation is not consistent on this board, so anyone building one of these will have to work carefully to make sure chips are not inserted backwards.

Those of you who visited my SCELBI/Scopewriter exhibit at VCF east may have noticed that I was dealing with some stability problems with the Scopewriter display. I finally found some time to resolve the issue.

The Scopewriter uses a TMS3112 Static Shift Register to hold the output. The design uses a clock to circulate the text through the shift register in order to refresh the display. This is somewhat similar to the Apple 1 or TV Typewriter design. It turns out that the clock feeding from IC1, pin 10, to the TMS3112, pin 7, doesn’t meet the pulse width, clock low specification of 150ns. A quick fix that seems to work is to add a .1uF capacitor in parallel to C2, which couples these two pins.

There is another change that I made a while back in order to get the Scopewriter to work. That is adding a 470 ohm resistor in parallel to the 100K resistor, R4. I can’t remember exactly why that change was necessary, but last week, as an experiment, I removed the hacked on resistor and I couldn’t get a good display on the scope. That may be documented in one of my earlier Scopewriter posts, but I don’t have the time to figure it out. I ended up putting the resister back in place.

At this point, Scopewriter seems to be working very well with the SCELBI.

In the following image of the Digital Group Video Card, the ground traces are highlighted in green.

I normally I try to refrain for making severe criticisms of the boards I work to reproduce. The people who designed these products were blazing new trails, something that should be respected. However, the routing of ground traces on this board appears to be something that should avoided by people producing new designs. Note how the route to ground for the 74123 (in the bottom center) runs completely around the exterior of the board before exiting on the board edge connector, which it is almost touching. When I finally build one up, I wouldn’t be surprised if I have ground issues with this design. The good news is that it should be pretty easy to resolve any issues that do crop up.

I have quite a bit of fine tuning and clean up to do before ordering a PCB, but as you can see by viewing the layout image in this post, the hardest part of the work is done. The existing schematics don’t have any kind of chip ID or location, other than part type. I’ll be rectifying this and be publishing a parts list, chip placement diagram and updated schematics, by the time I’m done with this project.

I discovered one other issue that I’ll have to deal with. The 6571 character generator needs a +12 volt supply. For now, I can use a separate 12 volt lab supply. I think I’ll have to create some kind boost converter to generate +12 from the +5 volt supply by the time I’m done with this project.

I’ve been working on reproducing the a copy of the Digital Group video card. In the process, I have found that the layout of the board is pretty convoluted in some places. In particular, the layout for the seven 1101 memory chips is pretty messy. Though, it is far from complete, the traces are all in place and you can see approximately what this part of the completed design will look like by viewing the following image.

Take a look at how the traces wind around the outside of the chips. Circuit board design was done by hand back in those days. The layout is made by making an image of the PCB on a piece of film that will be reproduced by photographic imaging. Each small section of straight trace is laid onto a piece of film by cutting an appropriate length of tape and laying it down on the film. Though the size is typically 2X the final size of the PCB, which makes things a little easier, it is still a time consuming process. With this many changes in direction for each trace, I can’t imagine how long it took the layout artist to produce the original artwork. Even digitally, it is taking quite a while for me to reproduce.

For quite a different approach to the same problem, take a look at the layout of 1 bank of the SCELBI 1K SRAM card, which uses the same 1101 memory chips. In this case almost all traces run in straight lines, making for a much easier layout process.

So why is there so much a difference? The Digital Group card has absolutely no traces running between the pads of a chip. I presume they did this in order to make the design a little more robust as tolerances can be a bit tight when you run traces between the small gaps between the legs of a chip. Tight tolerances can result in higher likelihood of PCB manufacturing defects or solder shorts during the assembly process. However, by making the small sacrifice of tighter tolerances, you can see that there is great improvement in the resulting design.

I’ve released a new version of my OS/X SCELBI app.

This version incorporates support for the SCELBI Scopewriter interface. This support is pretty barebones, and doesn’t include emulated hardware timing. While any real SCELBI Scopewriter application will work in this emulator, because timing is not emulated, applications developed in the emulator may not work on the real thing.

The second feature added, is integrated support for a 256 byte EPROM in the 4K/8H mode. There are two versions of the EPROM included. First EPROM image is a MCMON monitor with a 2400 baud bit banged serial driver. The second EPROM image is different version of the MCMON monitor that includes support for keyboard and the Scopewriter.

The best news is that this version freely available and downloadable from my website.

The Scopewriter version of MCMON is now downloadable from my MCMON page.

But that’s not all, in order to demo the Scopewriter with the SCELBI, I have SCELBI’s hangman game going on both versions of MCMON. It is also downloadable from my 8008 applications page.

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…