Turbo 601 Upgrades: 1MB cache and 120MHZ!

[zigzagjoe]

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.

 

[eharmon]

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".

 

[zigzagjoe]

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.

 

[eharmon]

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.

 

[zigzagjoe]

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.

 

[Phipli]

@zigzagjoe - weren't patchroms the norm at that point? Isn't the Q700 ROM basically a IIci universal ROM with a Q700/900 patchrom?

I perhaps misunderstood how things worked.

 

[zigzagjoe]

@zigzagjoe - weren't patchroms the norm at that point? Isn't the Q700 ROM basically a IIci universal ROM with a Q700/900 patchrom?

I perhaps misunderstood how things worked.

Ah, to clarify, when I'm saying patchrom I mean something that makes use of the diagnostic ROM hook in test manager; place a ROM section at 0x58000000 with a special identification longword and very early in boot prior to tests being run the mac ROM will jump to the arbitrary address which is the second longword in that ROM. Originally this was for factory burn-in testing, afaik, but Daystar and other accelerator manufacturers made use of it when the onboard ROMs needed some help (ie. for new processor support). In extreme cases like in the Turbo 040 it both uses the diagnostic ROM hook *and* hijacks ROM decoding so that the daystar ROM is actually the boot ROM the CPU starts running from before invoking the original ROMs.

 

[Phipli]

Ah, to clarify, when I'm saying patchrom I mean something that makes use of the diagnostic ROM hook in test manager; place a ROM section at 0x58000000 with a special identification longword and very early in boot prior to tests being run the mac ROM will jump to the arbitrary address which is the second longword in that ROM. Originally this was for factory burn-in testing, afaik, but Daystar and other accelerator manufacturers made use of it when the onboard ROMs needed some help (ie. for new processor support). In extreme cases like in the Turbo 040 it both uses the diagnostic ROM hook *and* hijacks ROM decoding so that the daystar ROM is actually the boot ROM the CPU starts running from before invoking the original ROMs.

Ah sorry, misunderstood

Sounds like a perfect time to load in 68060 traps to me

Edit - actually, is it too early?

 

[zigzagjoe]

Ah sorry, misunderstood

Sounds like a perfect time to load in 68060 traps to me

Edit - actually, is it too early?

It wouldn't be impossible, I think, but more work than I was willing to put into it in order to do it "right". When you're coming in that early in boot, you've got a lot of flexibility as long as you don't need RAM too badly the crucial part would be a new copy of the initial vector table and making sure that got loaded instead of the in-ROM initial vector table. Later the ISP/FPSP would need to be moved into RAM and further setup of the CPU done - not quite sure how one would hook that. Of course, there's more issues (namely slot manager's bus error handler) and the cache flush routines... Not impossible. Just a lot of work. And the structural issues with the System itself and other portions of the ROM code I didn't address would remain.

Hardware wise the 650 has a decoder for a patchrom in the BIOS ASIC and a footprint on the board, that was a contributing factor in my assertion that it would have been a candidate for a 060 model back in the day. To do a patchrom on the cache card/adapter board however would have not really been practical as ROMs on the 040 bus must be 32 bits wide as there's not dynamic bus sizing ala. the 030 bus. The logicboard patchrom lives on the 030 IO bus behind the BIOS chip so it'd handle the dynamic bus sizing.

 

[zigzagjoe]

Okay, I've got closure on the 4x multiplier failing to start up more often than not. So I've spent the last few days delving through the clock circuitry of these boards and how the 601 does things. These symptoms were reminiscent of an issue I had during initial bring up of my booster clones with the new PLL; by chance, occasionally I'd get the correct alignment, but more often than not I would get clocks aligned in a way that was incompatible with life. This was the issue with the Turbo 601, too.

Exhibit A: 3 clocks out of our brand new ICS9178-02 PLL. REFCLK (input), BCLK (1x output), ABCLK (weird duty cycle 1x output for BCLK_EN).

Per the datasheet:
But as we can see below on the left, they... aren't aligned? Randomly they would be properly aligned at which point the system worked correctly. It was never consistent. However, this seems to have not been an issue with the 3x multiplier which performs a different division to derive the weird duty cycle clock.

Anyways, so yeah, this is the problem. There's no errata from Renesas (né IDT, né ICS) addressing why this happens, but I seem to have found a simple fix. There is a /RESET input on the faulty PLL which will cause it to resync and instantly fixed the above issue; upon (soft) reset the machine would then boot correctly. The ICS9178 datasheet is spartan and does not at all address the need for a power on reset at all, so it seems like Daystar just tied the reset input high via a 1K resistor and called it a day - understandable. But it seems that a power on reset is in fact required.

So: If we tug on the /RESET line briefly after power on we can guarantee the necessary alignment. There two other PLLs which are used for distribution of both the logic board and 30mhz oscillator clock, MC88915. These have a LOCK output which indicates the PLL has started up, voltages are stable, and both the input and output clocks are locked. Takes about 10ms after power on. By hooking one of these to the /RESET input of the ICS9178, it will wait to synchronize its clocks until the other PLL is stable, and so always have the correct alignment. This allows the machine to boot reliably with the 4x multiplier as it occurs well before the Mac's power on reset process has completed.

Thankfully, these boards are lousy with test points and daystar kindly broke out the LOCK output to a test point for us. Run that over to R59 - the /RESET pull up - and we're done!


The 120mhz procedure, in full:

1) Perform the 100mhz upgrade or use a card that was 100mhz to begin with
2) Move R37 to R51
3) Install a 30mhz osc in place of the 33.333mhz osc
4) Add the bodge wire as seen above

Note: If you install and replace the heatsink, you should also clean and apply fresh thermal paste on the CPU. You can get away with it a few times, but I found my 601 started overheating after too many such swaps.