I received a ROMinator today and when I put that in the board it came to life, although a sick life.
I see we both have threads going about fixing a broken IIcx. The ROM-inator disables the initial RAM test. I can't remember if it also disables the ROM checksum test or if it uses a modified checksum, but I think the check is disabled. Both of the chimes in your videos sound a lot like normal ROM-inator startup chimes, but the end is wrong. Your "no RAM" test actually sounds closer to the correct chime than the test with RAM. You can hear what the chime is supposed to sound like at time 1:02 in this video:
The chime isn't an audio sample - the ROM code builds it programatically, with a short delay between each note in the chord. This part probably relies on having a functional RTC. I can dig up the chime code if you think it would be helpful for debugging.
One path forward might be to write some custom ROM code. This would be a pain, but since your IIcx is working well enough to read and execute code from ROM, you can begin to use it to debug itself. It probably doesn't feel like it, but a Mac that can play any kind of chime is close to working, because a lot needs to go right in order for that to happen.
Sort of like inserting print statements in a BASIC program to follow its execution, you could insert checkpoints at different spots in the existing ROM startup code to see how far it's getting before it dies, and use that info to guess at where the problem is. The checkpoints could play a sound, or put a repeating pattern on the address or data bus that you could detect with your scope. This wouldn't be an easy debugging method, and I'd probably only use it as a last resort if you're not able to find the source of the problem through other means. Right now it seems to be failing during the playback of the chime, which is a fairly small piece of code.
