Anyone up for some IIcx troubleshooting assistance? We have clocks but no activity...

[Sideburn]

So now that one board is repaired I am back at it with the original board that this thread was started on and I have a new discovery. I received a ROMinator today and when I put that in the board it came to life, although a sick life.

With known good SIMMS I get one style of chime when I hit the reset and without RAM I get a different chime and I see activity all over the board now with the o’scope.

View attachment IMG_5979.mov
View attachment IMG_5980.mov

 

[bigmessowires]

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.

 

[Sideburn]

Interesting ok I’ll try this when I dive back into it. I had to set it aside for a bit.

 

[Phipli]

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

I think I remember reading that it disables the checksum.

 

[bigmessowires]

You might try reprogramming the ROM-inator with the IIcx ROM image. Then you'd get the checksum and RAM test, but from the ROM slot instead of the built-in ROM. If there's a problem with the built-in ROM or the traces running to it, that might make a difference.

 

[MJ313]

Just got a happy chime
Bad UJ3.. it looked pretty bad.
I went ahead and lifted UJ1,2, and 3 and cleaned the pads up good and im replacing all 3 with new ones now.
After that I'll see what the NUBUS and video loos like

Any chance you could point me to what you replaced them with? I have a sick IICX... it happy chimes... then deathchimes soon after. I think my issue is in this area of the board as it was in bad shape.

 

[JackRubin]

Following the reference in step 6... we find this :

View attachment 61590

Where you are falling over in step 1 or 2.

This begs two questions.
1. Hows your RAM?
2. Do you have a video card installed?

 

[JackRubin]

@Phipli - sorry for the trivial question, but where (which volume of Inside Macintosh) did you find the "initialization sequence" pointed to by the article on System Startup? I'd like to read the next section as well but I've been through the IM indices without much luck.

Thanks,
Jack