DenverA few months ago I decided to see if my first computer still worked. It's been languishing in various boxes and closets for nearly forty years now. This is what the computer, an Explorer 85 from Netronics Research, looks like:
The three S100 boards are a simple bus monitor and serial port on top. In the middle is a bubble memory board built around an Intel BPK-72. At the bottom is a 32K static RAM board. As it turned out, I had very little trouble with the basic hardware. I started with all the boards removed, of course. There's a built-in monitor program which resides in the 2K EPROM portion of an Intel 8755 on the main board. There was also 12K of static RAM in the form of four 2kx8 parts and eight 1kx4 parts, as well as 256 bytes of static RAM in an Intel 8155. I debated about whether or not to remove all the extra ICs, but decided to leave them in. I had made a number of hardware changes for various reasons, so I needed to spend some time going over those to make sure none of them were going to cause problems in getting this system running again. After checking as much as I could with no power applied, and verifying that the power supply was working properly, I attached the main serial port to another computer that I used as a terminal via GNU screen. When the monitor first starts it waits for a space character to figure out the correct baud rate to use. When I turned the power on and hit the space key I got a bunch of garbage back. I had thought that I had used 9600 baud back then, but that was 40 years ago, so perhaps not. I found that the system worked fairly well at 2400, but still garbled a character or two now and then, so I settled on 1200. It's possible that the terminal hardware I was using back then was more forgiving.
The Explorer 85 monitor uses the 8085 SID and SOD pins for console I/O, but I had modified most of the software to use one of the parallel ports for console in. The monitor program still used SID, but most of the other software used the parallel port. Using a parallel port for input allowed me to use interrupts for console in, and also made it a lot easier for programs to check for key presses. I no longer have the original keyboard that had a parallel output so I had to come up with some way for the computer I was using as a terminal to also generate transmit data in parallel form. One obvious answer these days is: Arduino! I put some connectors and a 1489 on an empty Shield that I had, wrote some fairly simple code for the Arduino, "toggled in" a short test program using the Explorer 85 monitor, and it all worked. The Arduino code simply reads serial data at 1200 baud, writes each received byte to eight data lines, then toggles a ninth line to generate a strobe signal.
With that out of the way I could focus on the bubble memory. Having a storage device isn't very useful without software tools of some kind. Back then I could have written something that would have allowed me to use the bubble like a cassette tape, but I wanted something better than that. In anticipation of building a floppy controller, I had already bought a copy of "K2FDOS A Floppy Disk Operating System for the 8080" by Kenneth B. Welles, and I still have that book. I also have a printout of what was probably pretty close to the version I was actually using with the bubble (printed by a Teletype ASR 35). The next step was to see if a final version of the source was on the bubble. I was hoping there was because I really didn't want to type all that in by hand again if I wanted to make any changes.
At some point in the past I had bought a second BPK-72 that I had never gotten around to using, so I wasn't sure if it even worked, but now seemed like a good time to find out. I didn't want to power up the original BPK board unless I was reasonably sure that everything else was working properly. My S100 bubble memory board employed a 44 pin socket that matched the edge connector on the BPK-72 boards, so it was easy to swap the two BPK boards in and out.
Apparently my original BPK board is newer than the unused one. For one thing it has an on board clock generator, while the unused one doesn't. There is also a difference in pullups for the RESET and PWR FAIL signals. It didn't take too long to figure out that the reason the "new" unused board wasn't working was because there was no clock signal. Once I had added a clock generator to the S100 board, and fixed the pullup issues, I could start testing the unused BPK board. I still have printouts of programs that I used for testing 40 years ago. With those I was able to satisfactorily test the Explorer 85, the S100 interface to the BPK board, the BPK board, and a number of bubble memory modules I had in my parts collection.
Now it was time to actually see if my original BPK board and module still worked. The Intel bubble memory modules organize data in 2048 pages of 68 bytes each (64 bytes if using error correction). K2FDOS organizes data in blocks of multiple disk sectors, and tracks of multiple blocks. When I adapted it originally, I used two bubble pages per FDOS block, and 16 FDOS blocks per track, resulting in 64 FDOS tracks. I assigned the first two tracks to hold the boot copy of FDOS and the next two tracks to hold the bitmap and directory. FDOS is booted by reading the first two tracks into the appropriate RAM locations. My old FDOS printout said that it was assembled to start at D000H, but there was a penciled note (and there were quite a few of those) that said E000H. If I could read the first two tracks successfully, then it wouldn't be too hard to determine what the correct address should be.
Fortunately the boot program is fairly simple, and FDOS contains a long set of jump instructions near the beginning, so I could start out by reading just one page. If the data looked OK, then I could try reading the entire two tracks and compare that data against my old printout. It wasn't going to be possible to do a complete byte-for-byte comparison, but I could at least make spot checks. It wasn't too long before I had two tracks worth of data read into memory starting at E000H, and was ready to tell the monitor to start there. I took a deep breath and hit "enter". And the terminal calmly came back and asked for the date (my inputs in bold):
.G E000
K2 FDOS VERSION 1.6
DATE?
That was a moment I'll not forget in a long time. It was almost shocking. Forty years ago I turned that system off and never turned it on again until recently, and it patiently waited all that time, without giving up. K2FDOS by itself doesn't provide much of a user interface, but there's an auxiliary program, PIP, that does, and there was a copy on the bubble. Here's what happened after I entered the date:
DATE? 26-NOV-22
-RUN PIP
8080 PIP VERSION 1.6
*DIR
FILE NAME DATE LENGTH
ASM1 .SRC 09-MAR-85 60
ASM2 .SRC 17-MAR-85 379
ASM3 .SRC 17-MAR-85 31
ASMLNK. 17-MAR-85 31
FORMAT.OBJ 15-JUL-84 3
LTTRS .TXT 11-NOV-84 46
MTDIAG.SRC 22-MAR-85 8
MTRELI.OBJ 31-MAR-85 7
MTRELI.SRC 05-APR-85 56
PIP . 21-JUL-84 16
PIP .SRC 21-JUL-84 115
SYSGEN.OBJ 06-AUG-84 2
SYSGEN.SRC 06-AUG-84 16
TEARDR. 06-AUG-84 49
106 FREE BLOCKS
*
Another exhilarating event, not diminished in the least by the fact that the FDOS source I was hoping for wasn't there. However, since I had both a functional binary image and a reasonably close printout, some quality time with a disassembler (DASMx) rectified that in fairly short order. It's remarkable that a hand assembled kit, including wire-wrapped boards, from forty years ago still works, and even more remarkable that data stored on a bubble memory module is still readable after that much time.