840AV boot issue

[glm]

I decided to go back to my old 840AV after ~20years. Similar to other stories I read on this site: powers up, no chime, checkerboard video, no boot. Re-capped, probed supplies: all fine, probed some of the '040 pins. It seems the CPU runs for ~30" (see R/W trace below) then stops. The address on the bus when it stops is $A1E4, consistently across reboots. /BG is asserted low and clock is running fine, so it seems the CPU is waiting for somebody to respond on that address. According to some memory maps I found that address maps to the NU-BUS space, but there is no card plugged in.
Any idea what might be happening?

Thanks, GLM

 

[glm]

Typo, address is actually 0x52F22106, so in the I/O space.

 

[glm]

probed address and control signals on the 68040. CPU keeps reading at address 0x50F2A100 now. based on PST0-3 (traces below together with /TS and /TA) it keeps running the same instructions in supervisor mode (PST3=1, PST2=0). Probably the program does not like what it is reading. It will be interesting to know what is in that IO address space. /TA is correctly asserted at the end of the /TS cycle so whoever is at that address it is responding. Today in one case it went past that and showed mouse pointer and flashing question mark on disk (there is no disk connected to the board right now). Unsure how that happened. In trying some key combination I also found that CMD + power button halts the CPU. Keep digging.

 

[croissantking]

Gosh, that's a pretty graph. Good luck with the Quadra.

 

[Arbee]

50F2A100 on QAVs is in the "New Age" floppy controller area. If you don't have a drive plugged in now might be a good time.

 

[glm]

Thanks! @Arbee do you know where to find the detailed IO mapping? the only thing I was able to find is the generic Apple documentation that says "reserved to Apple" for that segment (and the replicas).
BTW: last night I had a look at the data bus during the repeated read cycles and found something interesting (traces below): some of the bits do not show a solid 0 or 1 but have a slow slope during the reading cycle. I thought that this could be due to the responder at 0x50F2A100 being physically disconnected from the bus on those pins and unable to impose an effective drive. So I looked around and possibly found some corrosion on few of the data bus pins of the DSP. In fact after trying to push down on the chip I was able to reproduce the "flashing question mark on drive" (still no drive attached). The DSP happens to be just below one of the electrolitics that leakad long ago and that I replaced a few years back. It sounds like it is time for some flux-assisted local reflow?

 

[Arbee]

Material on those systems is sketchy, although the "SuperMario" System 7.1 source tree that's been around for 15 years helps a lot. The ultimate source of I/O mapping truth is the ROM itself, which e.g. my UniROM utility (https://github.com/rb6502/unirom) can dump out.

That all said, it sounds like bad contact on the DSP is likely what's messing up the bus signals. I'd suggest removing the DSP entirely to clean out any trapped capacitor gunk and then reflowing it.

 

[croissantking]

I had a bad trace leading up to the DSP on one of my 840AV boards. Repairing that got it booting. It's one of the worst hit chips from cap gunk. I have another board I am trying to repair and I am a bit worried about desoldering it in case it falls apart as the legs are ever so fine.