• Hello Guest! We're hosting a challenge to welcome vintage Intel macs to the MLA during the month of July! See this thread for more information.
  • We've made some quality of life improvements to the Trading Post. More info here.

Turbo 601 Upgrades: 1MB cache and 120MHZ!

Oh interesting, I didn't know they had two ROM revisions. What are the checksums on those?

Has anyone modded the multiplier on the 040 PDS cards? The board layouts are so similar I assume it's the same?

Attached are soft dumps. Of the 040 PDS cards, only the 100mhz daystar cards would have the ability to change it as the 66mhz cards don't use the ICS chip with adjustable multipliers nor do they have the empty footprint as the turbo 601 does. Haven't checked for differences but I would be particularly interested in the early initialization code (post-reset) and to a lesser degree the common video primaryinit and then driver load for RBV.

2.5f1 7C810464
2.5f2 7C4F0317

The big difference between the 030 and 040 cards (I feel) is that the 030 cards have their own clock source while the 040 cards multiply the host bus speed.

Also keep in mind there are Apple and Daystar versions of the 040 cards with a different board layout. Only the DayStar has the jumpers broken out to let you set the multiplier to X3 or X4. The Apple cards seem to only be available in 66MHz and don't have the jumper.

Moreover the 66mhz cards don't have the ICS PLL at all so they're stuck with 2x and cannot be upgraded to 100mhz. I would be interested if a 100mhz board modified to a 4x jumper has the same apparent race condition at initialization the T601 seems to have (currently). Some boots it comes up fine, others are no-chime, but a full power cycle is required to retry. An Interesting finding on the initialization issue: it also affects 030 boots, suggesting it's something with the card's initial power up sequence, maybe that mystery ARM core?

Oh, right, that's why if you clockchip a wombat the 601 card runs faster. Forgot about that too.

Wouldn't it be better to run it separate from the system bus, though, so that one clock doesn't hold back the other?

No; if you decouple the buses you have to synchronize in both directions always (= added delay) on *any* bus transaction and require bidirectional registered transceivers (= expense) on your data bus. With both 601 and 040 buses being synchronous it makes sense to run them in lockstep. Only if there's a major difference in clock speed or bus architecture does it make sense to run differently clocked busses, as is seen in the case of 040 accelerators in 030 systems.
 

Attachments

Attached are soft dumps. Of the 040 PDS cards, only the 100mhz daystar cards would have the ability to change it as the 66mhz cards don't use the ICS chip with adjustable multipliers nor do they have the empty footprint as the turbo 601 does. Haven't checked for differences but I would be particularly interested in the early initialization code (post-reset) and to a lesser degree the common video primaryinit and then driver load for RBV.

2.5f1 7C810464
2.5f2 7C4F0317



Moreover the 66mhz cards don't have the ICS PLL at all so they're stuck with 2x and cannot be upgraded to 100mhz. I would be interested if a 100mhz board modified to a 4x jumper has the same apparent race condition at initialization the T601 seems to have (currently). Some boots it comes up fine, others are no-chime, but a full power cycle is required to retry. An Interesting finding on the initialization issue: it also affects 030 boots, suggesting it's something with the card's initial power up sequence, maybe that mystery ARM core?



No; if you decouple the buses you have to synchronize in both directions always (= added delay) on *any* bus transaction and require bidirectional registered transceivers (= expense) on your data bus. With both 601 and 040 buses being synchronous it makes sense to run them in lockstep. Only if there's a major difference in clock speed or bus architecture does it make sense to run differently clocked busses, as is seen in the case of 040 accelerators in 030 systems.
Ah interesting, I didn’t realize the Turbo 601s had an empty footprint. That explains it!

Supposedly these cards have an upgradable patch ROM (though I wonder if those are actually patches applied by the control panel). 7C4F0317 was previously noted as corresponding to a “v1.1” patch, with 7B34B470 noted as a mystery “v1.2d4”. IIRC this came from DayStar documentation. I would guess that puts 7C810464 as using patch v1.0.

The 040 cards shipped with the significantly older 2.1f2, at least the Apple versions.

Edit: Oh, you already mentioned the patch ROMs.

To avoid derailing this thread, I'll just mention a couple observations:
- The 66MHz 040 has a large resource titled "PatchROM place holder"...that I think that contains a previously unknown easter egg image??? I'll start a thread.
- The Turbo 601 card does not, though it does have two curious "DRVX" resources, a "SuperMac BlackBird" and ".Display_Video_Apple_Control".
 
Last edited:
Ah interesting, I didn’t realize the Turbo 601s had an empty footprint. That explains it!

Supposedly these cards have an upgradable patch ROM (though I wonder if those are actually patches applied by the control panel). 7C4F0317 was previously noted as corresponding to a “v1.1” patch, with 7B34B470 noted as a mystery “v1.2d4”. IIRC this came from DayStar documentation. I would guess that puts 7C810464 as using patch v1.0.

The 040 cards shipped with the significantly older 2.1f2, at least the Apple versions.

Edit: Oh, you already mentioned the patch ROMs.

To avoid derailing this thread, I'll just mention a couple observations:
- The 66MHz 040 has a large resource titled "PatchROM place holder"...that I think that contains a previously unknown easter egg image??? I'll start a thread.
- The Turbo 601 card does not, though it does have two curious "DRVX" resources, a "SuperMac BlackBird" and ".Display_Video_Apple_Control".
Yes, these have a 29F010 onboard and it is indeed upgraded by the control panel automatically. So installing control panel 1.1 will give you patchROM 1.1. A full image can be found inside it, actually - attached. Oddly enough, the address 0x4ED10000 which the patchrom would cause a jump to doesn't seem to actually be *in* the patchrom, nor is it mapped once the OS proper has booted.

I also found this string in the PatchROM: Engineers: David Dipert, Jay Hamlin, Bob Hudson, Henry Kannapell, Irvan Krantzler, George Smith, David Sowell, Bill Wilson. PC Layout: Russ Brown. Product Manager: David Methven. Testing: Jason Shoaf, Bill Wilson.

This is my best guess on versioning:

7C810464 - 2.5f1 - IIci only
7C4F0317 - 2.5f2 - Universal for all machines. (600, IIsi, IIci, IIvi, IIvx). 256 colors on 600/vi/vx
7B34B470 - 2.5f2 - Universal for all machines. (600, IIsi, IIci, IIvi, IIvx). Thousands of colors fix for 600/vi/vx, only with patchROM 1.2d4

Patch ROMs 1.0 and 1.0.1 are mentioned in the Daystar release notes. 1.2d4 comes from "The Unofficial Turbo 601 Site"

At some point I might get some W27E040 EEPROMs and try upgrading to the F2 7C4F0317 ROM. Original PLCC-32 ROMs are TMS27PC040-15 512Kx8. There's open footprints for some x16 ROMs, presumably 512Kx16, similar to the ones used on IIsi. Never used, as far as I've seen.

Still haven't come up with any leads on the initialization issues, but if it boots, it's been completely stable at 120mhz. I'm assuming some sort of race condition at initialization, but the prospects for getting further visibility are dire.... I may try to hook the LA up and capture what happens at early boot with reset, cpudis, and other relevant signals. *Something* has to be coming up to read PRAM and figure out which CPU we're supposed to boot with.

Edit: Also, a correction, @dkjones96 the fellow that upgraded a 475 Powercard to 1MB *did* post here and I even replied! Apparently I forgot. Would have saved some time if I'd remembered that hint about the resistors. D'oh.
 

Attachments

Last edited:
Back
Top