• 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:
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.
I wonder why they couldn't modify the base ROMs. Makes sense for field upgrades, but it seems like it was patched from day 1?

Interestingly, the 9150/120 also ran 2.5f1. 2.5f2 is the latest known PDM/STP ROM, so there's a good chance it's universal to all NuBus machines.
 
I wonder why they couldn't modify the base ROMs. Makes sense for field upgrades, but it seems like it was patched from day 1?

Interestingly, the 9150/120 also ran 2.5f1. 2.5f2 is the latest known PDM/STP ROM, so there's a good chance it's universal to all NuBus machines.
Reading between the lines, given comments from Daystar in their FAQ and release notes, the contract around licensing of those ROMs and support for the OS development required was very strictly limited. I'd expect the PPC ROMs were essentially the minimum viable product that could correctly initialize RBV and eventually the related V8(ish?) hardware used on cache slot machines. The testing cycle on any baked-in code probably would have required a round trip to apple so my assumption is that as much of it as possible would have been in the patchrom instead to avoid involving apple and the associated overhead.

I'm a little curious what the patchrom's actually doing, though, given the odd jump-to address, AFAIK it is patching floppy stuff, but a quick skim of the contents looked more like data than code though I didn't spend much time on it.

Fun fact, this card seems to be pulling nearly 20 watts - 4x what the cache slot is specified for. That's more power budget allocated at the PSU than actual limitations on power delivery via slot though.
 
Back
Top