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

 

[zigzagjoe]

Much as I love any reason for more blinkenlights, I think it'd be simpler to interact with test manager over the existing serial mechanism rather than patching the ROM so that every test routine writes a POST code. The interactive test manager mode check happens extremely early, if you can't get into the interactive test manager mode, something's gone so badly wrong you won't get anything useful from the machine's perspective. If the GLU/equivalent and SCC aren't working correctly, your system is fundamentally insane and probably not running code

I was poking at writing some basic routines to run down all the tests and report which failed, but I didn't get too far on it. I recall reading someone else working on a new UI for that recently, can't remember where. My idea would be to stick that on a modern uC (pick your poison) with native USB, add one of the ubiquitious 128x64 OLEDs, RS422 voltage translation, few buttons, and USB back to the host for power/status/serial passthrough/firmware upload.

Put the machine in test mode and interact with it via this magic dongle; default could be on test mode detected, run every possible test for the type of machine expected with a particular ROM and report failures.

This is interesting reading, though it has less bearing on the pre-universal ROMs. https://github.com/elliotnunn/super...MarioProj.1994-02-09/OS/StartMgr/USTStartUp.a

 

[Phipli]

I keep seeing the title of this thread and being confused. In the UK "Post Code" is the equivalent of "Zip Code" in the US.

 

[adespoton]

I keep seeing the title of this thread and being confused. In the UK "Post Code" is the equivalent of "Zip Code" in the US.

I'm glad it's not me, although we call it a "Postal Code" which helps me resolve the moment of confusion.

Regional addresses for classic Macs embedded in the PD ROM would definitely be innovative.

 

[Apache Thunder]

On the subject of custom roms, how difficult would it be to give older 68k macs a color happy mac screen like the newer PowerMacs had? I seem to recall my Performa 575 still has a black & white happy mac screen like pretty much all the other 68k machines of it's era. I suppose it could present issues with some machines that used external monitors where the end user could be using a monochrome display but the 5xx series use a built in color screen so it's a safe bet those will always be in color.