ROM diagnostic mode on a Wombat Quadra?

[eharmon]

I'm trying to see if I can get my Wombat Quadra board to enter diagnostic mode, as seen here: https://web.archive.org/web/20140921020853/https://mac68k.info/wiki/display/mac68k/Diagnostic+Mode

I suspect Pin 156 on U16 (the IOSB) is PA0 for VIA1, which I would think should bring the system into diagnostic mode if grounded. Tracing to the bottom of the board there's a test point just off to the side to make things a little easier.

But grounding it doesn't seem to have any effect. I tried from the test point and (carefully) from the top side, as pin 155 is ground it's relatively easy to touch to it's neighbor despite those tiny legs.

No dice, it just boots normally. Any ideas?

 

[Arbee]

Pin 156 is listed in the ERS as TEST, non-inverted, so maybe it needs to be connected to Vcc instead of grounded?

Although the ERS also indicates that's a test pin for the IOSB itself and it remaps a bunch of the other pins so maybe that would be dangerous in a production system.

Edit:

Test Support
BIOS has a very interesting test matrix. The TEST pin, when asserted (HI), followed by a low-to-high transition of the SERINSNDIRQ_ pin, puts the chip into test mode. When in test mode, the PWRSWOFF* and SY DL Y input pads define which test mode is selected.

The test modes are enabled and described as follows:

TEST PWRSWOFF* 5V_DLY Mode
0 X X Normal
1 0 0 Tri-state all outputs, sound RAM test possible
1 0 1 VIA1 Isolation Test Mode
1 1 0 SWIM2 Isolation Test Mode
1 1 1 Reserved (same as 3b'100 for now)

 

[joevt]

The supermario source code has "STM Version 2.2, Aaron Ludtke" instead of "STM Version 2.0, Scott Smyers".
The source code should explain how the STM is triggered but I'm not sure what the entry point is.
Which ROM (checksum) does the Wombat Quadra have?

 

[Arbee]

$F1ACAD13 (2.3F2) and $F1A6F343 (2.3F1). The difference is mostly to support when the Centris brand was scrapped and the 610/650 became Quadras.

 

[zigzagjoe]

Pin 156 is listed in the ERS as TEST, non-inverted, so maybe it needs to be connected to Vcc instead of grounded?

Although the ERS also indicates that's a test pin for the IOSB itself and it remaps a bunch of the other pins so maybe that would be dangerous in a production system.

Edit:

Test Support
BIOS has a very interesting test matrix. The TEST pin, when asserted (HI), followed by a low-to-high transition of the SERINSNDIRQ_ pin, puts the chip into test mode. When in test mode, the PWRSWOFF* and SY DL Y input pads define which test mode is selected.

The test modes are enabled and described as follows:

TEST PWRSWOFF* 5V_DLY Mode
0 X X Normal
1 0 0 Tri-state all outputs, sound RAM test possible
1 0 1 VIA1 Isolation Test Mode
1 1 0 SWIM2 Isolation Test Mode
1 1 1 Reserved (same as 3b'100 for now)

Mind sharing the ERS?

 

[Arbee]

Might as well. The 343S1078 file is the software-side ERS with register descriptions and the 199207 is the hardware/production oriented document with timing diagrams and long listings in binary for 3 test PROMs to validate the chip. These are under the original name BIOS which was of course an IBM PC reference; apparently someone objected to that since it shipped as IOSB.

 

[Arbee]

CheckLoopBack in USTStartUp.a is where it does the check for going into diagnostic mode.

; Check for factory loopback on VIA Sound Volume lines. On Mac,MacPP,NuMac the
; jumper shorts SV2 to SV1. On newer Macs, the jumper simply grounds
; the SV1 line (bit 0, VBufA), except on Normandy, where it grounds bit 2, VBufB.

 

[dougg3]

If you dive deeper into that CheckLoopBack function, it looks like it only does the VIA1 PA0 check on the following models:

• Anything with boxFlag <= boxMacLC that doesn't have an OSS/FMC/Normandy decoder
  • This would be II, IIx, IIcx, SE/30, IIci, Classic, IIsi, LC, and a few unreleased variants
• A table of additional models that have the factory burnin connector, which according to SuperMario is:
  • Quadra 900
  • Quadra 700
  • Classic II
  • Quadra 950
  • LC II

If it has an OSS/FMC decoder (IIfx), it checks for grounded SCC WrReq.
If it has a Normandy decoder (Portable), it checks for grounded PB2 of VIA1, as Arbee already mentioned above.

Otherwise it does a SCSI jumper check which also appears to depend on a magic value in PRAM, if I'm understanding the code correctly. There's even a section that talks about how if something escapes from the factory it needs to clear the PRAM.

Edit: The 610/650 ROM with checksum F1A6F343 seems to have some extra code that checks some other stuff and only jumps to CheckLoopBack under certain conditions. CheckLoopBack starts at offset $4710C in the ROM, and there's a "beq" instruction that jumps to it. There's definitely some extra logic leading up to it in StartTest1 that isn't in the SuperMario source, but no idea what it does.

 

[Arbee]

It wants bit 17 of the D0 return value from GetHardwareInfo clear. D0 is documented to be the low 32 bits of the "hardware present" bits from the universal table, and bit 17 in the SuperMario source is "SCC IOP present".

The intermediate routine at $40847D0E that it calls if the BEQ isn't taken is recognizably SCCIOPHwInit, just slightly different from the SuperMario version.

 

[zigzagjoe]

Might as well. The 343S1078 file is the software-side ERS with register descriptions and the 199207 is the hardware/production oriented document with timing diagrams and long listings in binary for 3 test PROMs to validate the chip. These are under the original name BIOS which was of course an IBM PC reference; apparently someone objected to that since it shipped as IOSB.

Fantastic, thanks!

 

[eharmon]

Interesting, so my hunch PA0 had been relabeled as TEST was incorrect...it's not connected at all.

So for Wombat the implication is the test can only run if you have an SCC (Wombat should pass that), set a specific PRAM value, and bridge some SCSI pins? Or was the PRAM value a red herring and you're saying that's actually the SCSI check?

 

[joevt]

$F1ACAD13 (2.3F2) and $F1A6F343 (2.3F1). The difference is mostly to support when the Centris brand was scrapped and the 610/650 became Quadras.

ROM Maps for both of them exist in my fork of 68k-mac-rom-maps

It wants bit 17 of the D0 return value from GetHardwareInfo clear. D0 is documented to be the low 32 bits of the "hardware present" bits from the universal table, and bit 17 in the SuperMario source is "SCC IOP present".

My fork of rom_fiend with my fork of HexFiend can be used to view the Universal Tables with the Product Info, Decoder, box flags, hardware present bits, etc.

 

[Arbee]

So for Wombat the implication is the test can only run if you have an SCC (Wombat should pass that), set a specific PRAM value, and bridge some SCSI pins? Or was the PRAM value a red herring and you're saying that's actually the SCSI check?

The PRAM value must be set and the SCSI pins must be bridged (actually I think just straight connected to Vcc/GND in the right pattern). Not ideal for diagnosing a machine that can't boot, and it's not clear how that would've worked at the factory either.

 

[SuperSVGA]

The PRAM value must be set and the SCSI pins must be bridged (actually I think just straight connected to Vcc/GND in the right pattern). Not ideal for diagnosing a machine that can't boot, and it's not clear how that would've worked at the factory either.

The value probably would have been preset or set by the test ROMs they used at the factories. This interface was primarily designed for factory burn-in testing rather than troubleshooting, so if it couldn't get that far there was a bigger issue.

 

[eharmon]

Okay, made some progress reverse engineering from these clues and the 53c96 data sheet.. I haven't tried this on a real machine yet, but I believe for machines without an edge connector, the following should work, approximately:

• Connect a serial cable and configure 19200 baud.
• PRAM at 007800F8 must be set to "SCBI"
• The external SCSI connector must:
  • Pin 2 (MSG): Ground
  • Pin 3 (I/O): Pull-up - termination should get this for free?
  • Pin 15 (C/D): Pull-up - termination should get this for free?
  • The rest of the pins are not validated.
  • Roughly, I think this should consist of jumpering pins 2 and 14.
• if you do not configure SCSI correctly, PRAM will be wiped.
• If I understand correctly, the above should drop you into the serial test environment.
  • There's a different configuration for the burn-in test loop.

I'll give it a shot in a bit.

 

[eharmon]

That should be PRAM at offset 0078 OR 00F8 set to "SCBI" (0x53434249).

If I reboot with this set the machine resets its PRAM, so it appears to be taking the correct code path. Setting it to something like 0x11111111 it just ignores.

So I took the external SCSI connector and jumped:

1. 2 -> 14
2. 3 + 15 -> 25

That should pull 2 to ground and 3 and 15 to termination power. SCSI is active low, so that should give us MSG (2) at low, I/O (3) and C/D (15) at high. Theoretically I should probably have a resistor before pin 25, beyond abusing the system though this should still read the correct value I would think.

Upon doing so the machine indeed halts at boot after the chime. But I'm not getting serial output...hmmm...

It seems possible just 2 -> 14 is sufficient (due to internal termination?) but that gives me nothing as well.

 

[gsteemso]

You may find the internal drive is interfering with your manipulation of the SCSI bus. I do not remember specifics but I seem to recall that SCSI devices do not just ignore the bus until addressed...? Not sure how accurate that is. Still, even if it is safely tri-stated or whatever during boot, the fact that it’s electrically connected in parallel with your jumpers may be having an impact. If it was a factory test they may not have even had bus termination in place at that point, let alone a storage drive.

 

[CuriosTiger]

You may find the internal drive is interfering with your manipulation of the SCSI bus. I do not remember specifics but I seem to recall that SCSI devices do not just ignore the bus until addressed...? Not sure how accurate that is. Still, even if it is safely tri-stated or whatever during boot, the fact that it’s electrically connected in parallel with your jumpers may be having an impact. If it was a factory test they may not have even had bus termination in place at that point, let alone a storage drive.

IIRC, you did not have to remove the internal drive to use an Apple TechStep, which I thought relied on this same mechanism.

 

[gsteemso]

IIRC, you did not have to remove the internal drive to use an Apple TechStep, which I thought relied on this same mechanism.

Ah, OK. I am probably mistaken, then. I have no idea what the hiccup in the procedure might be though.

 

[eharmon]

Welp, I still haven't gotten the overrides to enter diagnostic mode to work quite right...scratching my head still.

But I can tell you how to get into serial diagnostics on newer machines with no fuss, tested on my Wombat:

1. Put a moderate amount of RAM in the system so the memory check takes at least a couple seconds
2. Turn on the machine
3. Wait for the chime
4. Wait 1-2 seconds
5. Press the NMI button (programmer's switch)
6. You'll hear the chimes of death

It'll drop directly into diagnostics over serial. Unlike earlier machines, it doesn't appear to print anything on serial immediately. Type *E to turn on local echo. Type *V to check the version.

STM Version 2.2, Aaron Ludtke
CTE Version 2.1
ROM Version 7C 23F2
*V

Serial settings, at least for Wombat, are 9600 8N1.

Yeah, it's that simple. It should have been obvious but I had to stare at it for awhile to realize you just need to trigger NMI while tests are running to drop it into the failure mode. Should work even for a very dead machine to let you do some diagnostics.

If your machine is giving you trouble and already giving you the chimes of death, I think you should be able to drop directly into serial without extra steps.