G3 Upgrade Card Checksum Errors

[saybur]

I've got a Newer Tech MAXpowr G3 upgrade card (400/200 DT351) on a PowerTower Pro logic board. When verifying checksums on larger DiskCopy self-mounting images, each time the calculation ends with different (and wrong) checksum values. Swapping RAM or loading the .smi files off the network doesn't fix the issue. Switching to a 180MHz 604e card I have laying around does fix the problem so I'm operating under the assumption that the G3 card is to blame.

Anyone ever experienced something similar with a G3 upgrade card? Am I missing something obvious that might be causing this problem?

The G3 card seems to run fine under normal desktop operations but I'm assuming a problem like this is going to result in creeping data corruption issues eventually. I unfortunately don't have another system around here with the PowerMac PCI daughtercard slot to test with, but I'm not opposed to increasing my collection to help test if needed

 

[Byrd]

Is speculative addressing enabled on the G3?

 

[saybur]

That's a great question; I honestly don't know. I have the MAXpowr 2.0.5 extension installed but some Googling seems to indicate that Newer was addressing that via ROM updates that required an RMA (see here) rather than software. Is there a way to check if this is applied?

 

[saybur]

Found it in Gauge PRO. It is active, listed as "Enabled (I/O Incompatible)", which isn't an encouraging way of describing it.

 

[saybur]

Okay I think I have this fixed. Tl;dr version is I needed to set DIP switch 3 on the CPU upgrade to ON. To explain here's a long(ish) narrative of the troubleshooting, along with the red herrings I ran into along the way.

The "incompatible" message from the driver in my previous post was fixed by a reinstall of Newer's 2.0.5 utilities. After that the message in Gauge PRO changed to "Enabled (I/O Compatible)". Not sure why this was the case. In any event it did not fix the problem on its own.

I then played around with all the settings in the MAXpowr control panel, turning caches on and off, turning virtual memory on and off, doing lots of reboots, that kind of thing. Frustratingly after some reboots one or two of the .smi files would check fine, then immediately not work the next time I tried them.

Doing some more research, I found there are RAM incompatibilities between certain Mac systems, some G3 upgrades, and some RAM sticks. This was documented here. Looking at my RAM none of them had bus hold ICs so that was probably not the issue. If someone reading is having a similar problem it might be worth checking though.

While hunting in the Wayback Machine I kept finding talk about instability of some G3 accelerators related to bus speeds. A good example was at xlr8yourmac.com. This got me thinking about the 50MHz reported in Gauge PRO, which was probably on the aggressive side of things: maybe it would be better if I slowed things down a little? The driver didn't offer an option to do that, but what about the four DIP switches on the card itself?

I finally landed at the solution by finding https://siber-sonic.com/mac/MAXpowrG3.html, which has some independent research on what the switches do along with a manual scan that had eluded me up to this point. Their card had a base bus speed of 46.5MHz, slowed to 43MHz via DIP 3. I applied that to my card, which resulted in the CPU bus speed dropping from 50MHz to 46.5MHz and the CPU dropping from 400MHz to 371.8MHz. After this was done the .smi files started working perfectly each time.

Hopefully this fixes the problem long-term. I guess it makes some sense: even though I've recapped this board there are a bunch of things that might not be working quite as well as when the thing was new 30 years ago. Maybe a 50MHz bus is flying just a bit too close to the sun.

Anyway, this all was a fun deep-dive into the world of late 90s CPU accelerators. These were big, flashy, unobtainable items that the 90s kid version of me wanted badly but could never afford. It's great to finally have one (mostly) working in a computer I own!

 

[obsolete]

Hmm...what are the odds that the G3 chip that Newer put on that card isn't actually rated for 400MHz?

 

[croissantking]

Hmm...what are the odds that the G3 chip that Newer put on that card isn't actually rated for 400MHz?

It could be the cache chips just as easily though…

 

[saybur]

Yeah I wouldn't be shocked if either the G3 or the cache was being driven too hard too instead of the bus. I'm not sure how common it was for them but this unit is on a green PCB, most of the pictures I've seen of Newer's stuff had black/dark brown soldermask: maybe a cost-reduction step taken as part of Newer's descent into harder times?

I've already replaced the thermal compound on the CPU but if I need to do that again I'll double-check markings and see if any parts seem to be overclocked.