Programmable Diagnostic ROM Idea for Mac "Post Codes"

[David Cook]

We've long had reprogrammable ROM SIMMs replacement. Those ROMs often have little improvements, such as skipping memory tests and adding ROM disks.

I wonder whether anyone with experience in developing those ROM boards would consider the following: Add a latch chip with sufficient drive for a small 8-segment or 16-segment LED display. When the Mac writes to the ROM, the bits would light up the various LED segments to provide a "post code" similar to the IBM PC community. Since the ROM is reprogrammable, we could pepper the code with writes to ROM (which would update the display) at various check points as it was booting.

Hopefully, the ROM SEL line is driven low even during writes. If so, one could add address decoding to either select the ROM or the LED latch (which would be placed perhaps at the end 32-bits of ROM space). This would avoid reads to the ROM being written to the latch.

If the ROM SEL line is not driven during writes, then a bodge IC clip would need to be included to attach to the read/write line.

Frankly, even if the ROM SEL line is driven during writes, then a bodge IC clip could be included anyway, and an address decoder would be unnecessary. In that case, the read/write line would control whether the ROM would output, and all writes (to any ROM address) would be placed in the LED latch.

The other cool usage of this would be to aid general hardware/software development. With a "diagnostic ROM" in place, you can display whatever values you want on the LED latch to hunt down bugs or indicate status. For example, if you have a driver where timing is critical or is difficult to debug, a simple write to ROM is all that is necessary to help trace your code.

Any thoughts on the concept?

- David

 

[zigzagjoe]

This would be difficult, sadly. Only the late quadras that support flash ROMs provide a write strobe (and only available under special conditions), unfortunately, and the ROM does not see a consistent select signal across models. Essentially you can only depend on the presence of a single combined OE (read) with implied CS if you want to support all the II and Quadra models. You could do something like a special address range and use spare address lines to encode your byte. Something like if bits A22, A21, A20, A6 set, latch A15-A8, but the ROM space is cachable, you'd need to deal with that too....

For ROM and card driver troubleshooting, I instead took the approach of hijacking a SCC channel and just using that to get bytes out. It's not terribly complex, you can see what I did in the 060 source: https://github.com/ZigZagJoe/Macintosh-Q650-68060/blob/main/src/serial.S I admit it's terribly cushy to be able to blast out entire human readable strings and hex values; the diagnostic variants of my NuCF and 30Video ROMs are quite chatty as it makes debugging so much easier. As the ISP-SIMM has the capability for USB<>Serial, that meant one cable (and device) to upload new ROM images to the system/card under test as well as capture debug info.

I also used capturing the address bus in conjunction with the ROM strobe to gather execution traces since chunks of the ROM map are provided by apple, mostly on the 060 project. This was very useful but of course does require the CPU caches to be inhibited for full accuracy. At one point I briefly used a RP2040 to capture write to a certain slot space and output via serial, but the simplistic implimentation I made didn't have any benefits over serial other than speed and was replaced by serial.

 

[David Cook]

the ROM does not see a consistent select signal across models.

Ahh. That's a problem

What about a 30-pin RAM SIMM + LED latch? Let's say the SIMM is 1 MB and is always put in a specific slot of a specific bank. Although the CAS+RAS+WR+address lines combo are more complicated to decode, you could essentially obtain 8-bits on a write to a specific address. I assume we could locate a byte in low memory that was reserved/unused by Apple. In other words, it is just a standard RAM SIMM that has something that snoops a specific address and copies the data line to an LED latch.

The benefit of this is you'd just use one of the existing custom ROMs that you could code to write to the low memory location as it booted.

If one also burned diagnostic ROMs for non-SIMM computers, a 30-pin RAM SIMM display would also support Plus, SE, and Mac II. A IIfx would instead need a PDS LED snooper, but could use the same custom ROM SIMM.

I admit it's terribly cushy to be able to blast out entire human readable strings and hex values; the diagnostic variants of my NuCF and 30Video ROMs are quite chatty as it makes debugging so much easier.

Nice clean code. I can see how useful this is, particularly for verbose logging. It does require that the stack, SCC, and GLU is working and it does impact timing. However, at that point in booting, it could provide much more intelligent and dynamic messages to the user

- David