I’m working on a 8008 amateur radio project for the VCF east. This project needs 2 input and 3 output ports, plus a serial input port for boot loading.
I have a working SCELBI 8B. The 8B has a memory editor in PROM, which makes entering a bootloader much easier than on an 8H. However, my SCELBI 8B is mounted on a temporary chassis that still only has a minimal number of I/O ports connected. When I build the final reproduction 8B chassis, I plan on connecting the full array of I/O ports. Until then, the port requirements for this VCF project dictate that I use my 8H for that application.
At this point, I have no PROM on the 8H. Downloading is through a 37 byte bit banged serial I/O driver that must be toggled in one byte at a time, using the front panel. It typically takes me about 30 minutes to initially toggle in the bootloader and boot the chassis with an application. What follows, are some tips that make booting the SCELBI 8H less troublesome.
I frequently make mistakes toggling in the bootloader. Troubleshooting a mistake can be difficult on the SCELBI. It used to take me quite a bit of time to correct these toggling errors. I have developed some approaches that make troubleshooting the bootloader fairly quick and very straight forward.
After toggling in the loader, I set the “L” register to a known location past the end of the boot loader, but in the same “H” page. This saves the time of having to toggle in a new value into the “H” register. I’ll connect the serial device that will be used to download the application, which is my case is usually a laptop computer. I start the terminal emulation program, and run the boot loader and enter a few characters using the keyboard. After typing in a few characters, I’ll interrupt the SCELBI and use the decrement L instruction (061) to back up the L pointer. Then I’ll use the load A from memory instruction (307) to read the contents of what I’ve written and verify that the character that I typed went into memory correctly. Entering a few characters with the keyboard before downloading the full application, allows you to skip changing the H register to point to the start of the application, while verifying correctness of the bootloader.
If the data doesn’t look right or isn’t making it to memory at all, I’ll toggle in the jump instruction (104 XXX XXX) to jump to the start of the bootloader. I can then single step through the bootloader to make sure I’ve toggled in the correct code. When you enter a loop, just verify one pass of the loop. After verifying by stepping through one pass, toggle in the jump (104 XXX XXX) instruction to go to the next part of the bootloader. This is much faster than stepping through the loop until it exits or reading back all of the program by reading memory indirectly with the HL registers and the front panel.
If I find a mistake, I’ll toggle in the load L immediate instruction (066 XXX) to point HL to that location. I’ll then use the load A from memory (307) to double check the contents of that location. If it is wrong, I use the load memory, immediate instruction (076 XXX) to correct it.
Next, reset L to somewhere other than the middle of your bootloader, run the bootloader and try typing in a few more characters. Once you are able to enter characters correctly, then point HL to the starting address of your program and download it. Be aware that if you forget to move the HL pointer, you may overwrite the some part of the bootloader. I have found that if you make this mistake, all is not lost. The SCELBI usually halts after destroying just a few locations of the bootloader, not the entire thing.
After sending the program down to the SCELBI, I do two checks. First, I check that the HL registers are one past the end of the program by loading A from memory (307) and monitoring the address read. If it is correct, I’ll decrement L (061) and load A from memory (307). The data read should match the last byte of the downloaded program.
Once the bootloader is in memory, try to avoid overwriting it. If your application doesn’t touch that part of memory and you don’t power off, it can be used to load a new application or a different version of the bootloader that can be located elsewhere in memory.
Why not put a back-up battery on the RAM card? It will save your fingertips and is vaguely period appropriate.
Hi Jack,
There a number of solutions to making life easier, some used back in the old days. Examples include connecting eight switches to a port and toggling in a small program to read the data, store and loop, putting the boot loader in a PROM that can be switched with SRAM. The battery back up idea is interesting, but probably a bit more challenging, since the 1101 SRAM devices use both 5 volts and -9 volts.