After watching videos from the Vintage Computer Festival regarding RCA1802 and Cactus, I am disappointed to discover that ROM programming remains an ongoing hassle. Although, it
doesn't help when people introduce endian problems or use portable programming software on a hostile platform. Some use toggle switches to directly program an EPROM or EEPROM. Others use a Parallax Propeller or Atmel AVR to poke memory before starting the "main" processor. In this arrangement, the bootstrap processor typically switches to an I/O function, such as video display. This is very unsatisfactory. I thought about the problem and I think that I have an old school solution. The most minimal implementation requires minor abuse of a static RAM's Write Enable.
It helps to know the scope of the problem.
BigEd solved the software part of this problem with a 27 byte serial bootstrap. This can be stored in various arrangements, such as diode matrix, lightbox or clock serial barcode. It is also generally known that a minimal monitor program fits into 256 bytes, although 8KB provides considerably more functionality.
I wondered if the design could be simplified and idiot-proofed. (When we have a bad day, we are all the idiot in question.) Starting with the barcode, eight light sensors eliminate shift registers and additional sensors eliminate counters. Idiot-proofing comes from a continuous loop on optical disk which may be an old vinyl record with a print-out taped to it. Given that bits are read in parallel, this is more like a Fischer-Price record player rather than a music stylus. I hope that is sufficiently idiot-proofed. What I have proposed so far is a neglected option but quite unoriginal. The originality is the order in which the data is loaded.
After doodling designs for high speed video dot clocks with consideration for Chinese Remainder Theorem and space filling curves, it occurred to me that it is possible to populate boot RAM where the addresses are specified as Gray code. I believe that the optical sensors in some digital scales use a similar arrangement to obtain a reading. Anyhow, we do not have to read the program in a sequential order. To quote the great philosopher, Eric Morecombe, it plays the correct notes, but not necessarily in the correct order.
The tricky part is write strobing. In the most minimal design, the boot RAM's Write Enable is tied to the processor's Reset. This depends upon a staggered arrangement where the data lines are steady and only one address line changes. Hopefully, this does not induce any write glitches. Unfortunately, it might require boot RAM address lines to be wired in a particular order and this may be specific to each variant of static RAM chip. In the worst case, a strobe signal may be required but I hope to avoid this overhead. The overall intention is that one turn of the disk may write 32 bytes (or significantly more) to RAM which may be optionally protected afterwards. There is another problem within this process. At the end of one turn, one memory location may have bad data. This is typically not a problem because sections of the disk may hold unimportant bytes. With Gray coding, these bytes are likely to be clustered. Therefore, it is possible to start and stop the disk in a region which is not critical.
The spirit of flippy disks remains alive. For whippersnappers, we previously called this "the B-side" and it often had superior content to "the A-side". In this case, I envision a monitor program on one side and a demonstration program on the other. On significantly larger disks ("long play"), it may be possible to fit Forth on one side and BASIC on the other. Unfortunately, such a disk may be comically huge. Assuming that bits are scribbled manually or printed onto two sheets of paper and then taped to a vinyl record, 8×11 inch paper (or similar) may only have an outer diameter of 10 or 11 inches. Assuming sensor separation of 0.2 inch, the inner diameter may only be approximately 7 inches. Pixels of data would be approximately square on a disk which only holds 128 bytes - and even this ignores the staggering of address bits and data bits. Beyond this, we require much better mechanical tolerance in one axis and/or a larger disk. How large? For 8KB disks, the outer diameter may be approximately 60 inches (1.5m).
Despite the impracticality of such a large disk, I am greatly amused by the thought of someone like CommodoreZ demonstrating it. Indeed, this may be a good adjunct for a 6502 Cactus (or similar) because it provides a hands-on method to quickly populate memory with something useful.
Anyone making a SBC [Single Board Computer], this optional boot mechanism requires less than USD3 of parts and less than 2 square inches of circuit board. (I envision the sensors on the reverse of the board so they may be placed closer to a boot disk.) Regardless, it saves considerable hassle and replaces ROM programming with something which can be verified visually. Furthermore, there is a particular advantage to using this within a 6502 system. Given the typical use of pull-up resistors on an address bus (or data bus), unused address lines are pulled high and therefore writes are naturally drawn to the top of the address-space, where the 6502's vectors are atypically located.
If there is any interest in developing this technique, I can write a suitably bodgeworthy conversion utility. I am inclined to use libgd from C but it may be preferable to use libgd or similar from PHP. This may aid the creation of boot "images" without the need to install any software.
Login
Register
FAQ
Search
