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.

 

[Phipli]

Nice work investigating the issue @zigzagjoe

 

[zigzagjoe]

Here goes, probably the last worklog on this second-worst PPC macintosh possible.

I've been fussing with the cooling of the Turbo 601 as Callan has been having difficulties with his upgraded card. My card was fine - without nubus cards - if ambient temperature is reasonable, say 24 deg C. His is not really stable at room temperature without supplementary cooling. On mine, if the heatsink hits 50 degrees C, things are about to get crashy. At that point die temperature would be 55-60 degrees at most - far below the specified maximum of 85 degrees which it is supposed to be able to maintain stability and timings if running at 100mhz.

There are no specifications available for 110 and 120mhz operation; reading between the lines, it seems like Apple must have been turning the screws on Motorola/IBM to deliver an interim gap-filler while waiting on the 604. This seems to indicate there's truth in the various anecdotes that 601s really struggled to hit those clocks (such as this one). I get the distinct impression that 601v had a hard time meeting specs at 2.5v on a good day; per schematics available for the 8100, 7200, 7500, apple was running the 601v at 2.7v on average and Daystar did the same with the various 601 cards. I suppose now we know why the 110 and 120mhz machines all shipped with peltier coolers!

Given the qualifier above - without nubus cards - I needed to look into supplemental cooling myself since I wanted to run a video card, radius rocket, and ethernet card. All these cards added around another 35 watts worth of heat inside the case. I tried a few approaches with mixed results - small fan/blower on the 601 heatsink, increased PSU airflow, active HSF. The low clearance available really constrained my options. Improved PSU airflow helped somewhat, but the active cooling approaches worked poorly due to most of the airflow going straight into the PSU. Intake fans weren't really a productive option due to the nature of the IIci vents and I'm not about to hack a hole in a vintage case.

In the end the solution ended up being brute force: stick an 80mm fan blowing straight onto the card (and the toasty rocket below) in order to get the heat off the heatsinks and moved out of the case via a moderately upgraded PSU fan. This took temps down by around 7 degrees C off the heatsink over the die and also dramatically reduced the rocket CPU temp. This approach allowed me to give some physical support to the 601 card itself as well. I used a noctua fan as it was to hand and minimized the additional noise.

Files for the brackets are attached: it snaps onto the HDD bracket and HDD caddy. Slightly fiddly to get on and off but does not require removing the HDD bracket for getting at the RAM. Take care to print the bracket with supports enabled and with the tabs on the X-Y axis to allow flexing.



On PSU fans

I was originally using an Astec PSU for testing, however, it was not dealing well with the additional load of the cards. With the benefit of hindsight, it worked well for cooling as it used a NMB 3110nl-04w-b20-d06 fan rated 28 CFM. The replacement PSU is a GE unit with a fan specified for ~ 23 CFM; with the added cards and less airflow it makes sense why I was suddenly having some more thermal difficulties. OK: easy enough, let's see about swapping a new fan in. I ordered a few OEM-grade fans off Mouser. Despite issues with Noctua meeting their specifications previously, I decided to give them a shot as I was able to get one fastest. (Spoiler: I was disappointed)

Measurement methodology was to use a trashbag of known volume and mount the fan in a cardboard bracket taped into the mouth of the bag. The fan intake was blocked then power was applied to allow it to reach operating speed, then the blockage removed and time to inflate measured. While there's certainly some inaccuracy due to the primitive method and timing, I think it's a reasonable approach especially for relative comparisons. This is a fairly optimistic test, with minimal backpressure and no intake resistance. Here's the data.



As compared to the stock fan:

• Noctua was quietest, but underperformed on airflow. I credit Noctua with the best acoustic engineering (wasn't really in doubt) as it was free of overtones.
• The Sunon was fine without being particularly exceptional. Slightly louder.
• The NMB at full speed was a bit too loud to be comfortable mostly due to RPM-related overtones. Reducing the voltage with 22 ohm or 33 ohm resistors dramatically reduced the noise volume and tonality while preserving much of the airflow.
• The delta fan, in true delta fashion, disregarded its specs in both airflow and noise; that blighter moved a lot of air but was far too loud for sensible use. Disqualified!

Takeaway: Setting aside Delta and Noctua - we can see the Sunon, NMB, and Pansonic fans all came in at around 80% of rating, which suggests probable inaccuracy in my measurement method. Delta, for some reason, massively exceeded their airflow and noise rating, but RPM and power draw were accurate. The NMB fan had noticably higher quality fit&finish of all the OEM-grade fans. Noctua dramatically underperformed: excellent quality and just fine for feels-based tinkering or custom PC applications; as you can see, I used it above. But the airflow specs are still bunk. So use care if swapping OEM fans for Noctua if you're trying to go 1:1 off the specs.

Winner was the NMB@9v as it sounds similar to the stock fan while delivering more airflow presumably due to both the smaller motor hub diameter and somewhat higher RPM. I should really compare with some airflow restrictions, but I've turned this into enough of an exercise.

Various notes:

• Overheating CPU is mostly prone to spurious interrupts or mixed mode faults (dc.w $fe07) as indicated by macsbug. This will always happen in early boot if the CPU is too hot.
• System error 25 is heap/stack collision. MTP emergency will do this after about 200 loops of just testing the System board.
• IIci Power on reset period is approximately 200ms, so the PLL reset as described above is completing with plenty of time to spare.
• The 601 card itself uses approximately 20 watts as currently configured. Not for IIsi with their 6a rated PSU!
• @Bolle determined the unpopulated J1-J3 & strap resistors used instead configure for different types of PLCC ROMs.
• I suppose now I know why IIci accelerator cards generally placed the CPU on the left of the card - airflow is best here!
• Goop beneath the 7500 donor CPU was intended for mechanical support, to try to make the ceramic substrate harder to break (@trag)
• Sitting at the Macsbug prompt is by far the biggest heat generator I've found for 601 CPUs. It's brutal! Finder isn't much better. FPU strain might be worse still?
• Asante MC3NB does not play well with the 601: it, or another card, must be installed in slot $E or sad chimes results. It also sporadically prevents (any) chime on cold power on, a soft-reset fixed this. It works fine once booted.
• The LM1085 regulator runs horrifically hot at around 90-100 degrees C. However, this is within spec for the power dissipation (assumed ~6w) and is expected of a linear regulator. Copper planes on the board are used as heatsink.
• Wow, speed doubler really does help a lot with 68k emulation (This is my first experience of early PPCs)

 

[Phipli]

Wow, speed doubler really does help a lot with 68k emulation (This is my first experience of early PPCs)

Yeah, it's a shame we didn't know back when our household computer was an 8100/80!

I got a 518% uplift on my test 6200 (in synthetic benchmarks).