Power Mac 7500-9600 Bus Speed Overclocking

[trag]

Excellent work, @obsolete . I don't seem to be getting notifications for new posts, for some reason. I guess 3 years isn't that long to miss a thread...

It would be interesting to build a custom cache.... Fast SRAM chips down to 2.5 ns are (or were) available... TAG RAM is always the issue, but IIRC, one can make TAG RAM with SRAM and a comparator. Need a fast Comparator though.

Another interesting possibility would be to get some of the brilliant software guys to probe HammerHead address space with the CLKID pins set to different values.

 

[obsolete]

Excellent work, @obsolete . I don't seem to be getting notifications for new posts, for some reason. I guess 3 years isn't that long to miss a thread...

Thanks @trag! I was hoping you would see this eventually. Since I posted last November, you are not even 6 months late

It would be interesting to build a custom cache.... Fast SRAM chips down to 2.5 ns are (or were) available... TAG RAM is always the issue, but IIRC, one can make TAG RAM with SRAM and a comparator. Need a fast Comparator though.

I've looked at swapping faster SRAM chips onto Apple cache DIMMs and seeing whether the TAG chips can keep up at 60MHz, but do you know whether the chips must be 5V tolerant on the I/O pins? These machines are from a weird transitional period between 5V and 3.3V. If 5V tolerance is required, that really limits the options.

I have a pair of 256KB modules that resemble D03 on @Fizzbinn's TD Wiki page: https://tinkerdifferent.com/resources/ppc-macintosh-l2-cache-modules.19/ (including the empty chip footprints on the back). One has Micron MT58LC32K32B2LG-11 chips (11ns) and the other has MT58LC32K32B2LG-9 chips (9ns). I know the -9s work up to 55MHz at least.

In the 1994 Micron SRAM Databook (warning, big PDF), MT58LC32K32B2 and MT58LC32K32C4 (and their 36-bit counterparts) specifically list "5V-tolerant I/O" as a feature. By the 1999 Micron Memory Databook, the datasheets for MT58LC32K32B4, MT58LC32K32C6, and MT58LC32K32D9 (and their 36-bit counterparts) all omit the statement about 5V tolerance. It looks like Apple used MT58LC32K32D7 on DIMM D05 on Fizzbinn's wiki page, so that might be an option.

Another interesting possibility would be to get some of the brilliant software guys to probe HammerHead address space with the CLKID pins set to different values.

Are you suggesting that the hardware CLKID straps could be overridden in software then? Or are you trying to understand which other Hammerhead register values get changed by CLKID?

 

[obsolete]

I was able to dig up a datasheet for MT58LC32K36D7 and it is in fact 5V-tolerant. That lends credence to the theory that 5V I/O compatibility is required.

 

[joevt]

Hammerhead ERS documents all the registers doesn't it?
https://tinkerdifferent.com/threads/apple-network-server-macos-based-roms-found.4756/post-41404
Write a utility to dump the values to see how the CPU slot pins affect them (if it does at all)?
Use DingusPPC emulator to follow the ExceptionTable and HWInit code during boot?
The RAM test code is commented in Diagnostics.s.
https://68kmla.org/bb/threads/skipping-the-startup-memory-test.50699/post-571099

 

[trag]

but do you know whether the chips must be 5V tolerant on the I/O pins?

I expect so. I think the way it ends up working is that the host sends 5V level signals and the chips must tolerate that. The chips send back 3.3V level signals, but the "high" logic level is high enough to register as high to the 5V logic.

Are you suggesting that the hardware CLKID straps could be overridden in software then? Or are you trying to understand which other Hammerhead register values get changed by CLKID?

Both. But I don't know. The NewerTech hardware guy said he had a utility for adjusting timing by changing Hammerhead register values, plural. Suggests more than one set of values and that it was by writing registers in Hammerhead. But I'm making a lot of stew out of one potato.

 

[trag]

Hammerhead ERS documents all the registers doesn't it?
https://tinkerdifferent.com/threads/apple-network-server-macos-based-roms-found.4756/post-41404

Thankyou. I've been wanting that documentation for something like 20 years. Any idea how it found it's way into the wild, and are the other documents listed as "further reading" available? Now going down a rabbit hole....

Already seeing that Hammerhead does indeed have 5 Bus Grant/Request/DBG lines available, suggesting possibility of connecting four Bandits, unless some of those are needed for the memory data path controllers. Need to check schematic.

The ANS Developer Note, as just a sort of aside, mentions the possibility of up to four Bandits in the architecture.

The problem I see is where would Interrupts (handled by Grand Central) come from for the additional slots, and, of course, the Mac ROM would need to be made aware of the additional slots, I think.

Given that Bandit and its arbiter are demonstrated on ANS to support at least 6 PCI devices, this suggests that one could go crazy and build a machine with 24 PCI slots. I'm not sure why you would want to, but maybe it could be done.

 

[trag]

With the help of Tiny Turbo, I was able to push my 7600 to the promised land of 60MHz bus speed.

The table in my previous post implies the existence of a CLKID setting of 7, which should result in the most latency and allow the fastest bus speed. To give that a try, I removed R51, so that none of the three CLKID resistors on my CPU card were populated. Gauge Pro showed a small decrease in Memory Performance, which I think confirms the increased latency:

With the CLKID setting of 7 confirmed working, I was able to interleave the 32MB EDO sticks, a configuration that consistently crashed at 60MHz with CLKID = 6! The memory performance increase of interleaving more than makes up for the increased latency:


Also, the fastest L2 cache I have is 9ns, and it also cannot be used at 60MHz. The RAM and cache limitations make this a pretty impractical experiment, but now I can say I did it.

From teh Hammerhead document that joevt referenced:




Not quite sure how this corresponds to the CLK ID pins but I'm sure the relationship is there somehow...

And this is interesting:

 

[Phipli]

From teh Hammerhead document that joevt referenced:

View attachment 99028


Not quite sure how this corresponds to the CLK ID pins but I'm sure the relationship is there somehow...

And this is interesting:

View attachment 99029



View attachment 99030

The difficult bit is that you need to have safe timings for the speed the whole time, so if you use an extension to adjust the timings for a stable 60MHz, you'll have to make it to the extension without crashing.

Obviously a custom ROM would solve that issue. But this is what stopped me just making an extension to adjust the timings.

Note the clock speed register is read only so you can't overwrite it like you can with the LC 475.

 

[trag]

The difficult bit is that you need to have safe timings for the speed the whole time, so if you use an extension to adjust the timings for a stable 60MHz, you'll have to make it to the extension without crashing.

Obviously a custom ROM would solve that issue. But this is what stopped me just making an extension to adjust the timings.

Note the clock speed register is read only so you can't overwrite it like you can with the LC 475.

By "clock speed register" do you mean the "CPU Speed" register? If so, and I have not read the entire Hammerhead document, but does the register actually do anything? It looks to me like it is a method for hardware to record a speed/state request at start up, and then must depend on software to read the setting in "CPU Speed" at start up and then set the various timing registers appropriately.

As usual, I could be wildly wrong....

 

[joevt]

Any idea how it found it's way into the wild, and are the other documents listed as "further reading" available? Now going down a rabbit hole....

Not sure where they come from. By "further reading", do you mean the "Related Documents" section of the HammerHead ERS?

TNT System ERS - don't know
TNT Control/Kaos ASIC ERS - don't know
TNT Bandit ASIC ERS - yes
Grand Central ASIC ERS - yes
djMEMC and MEMCjr ASIC ERS - don't know
MacRISC Architecture Document - don't know
Apple RISC Bus - don't know

Already seeing that Hammerhead does indeed have 5 Bus Grant/Request/DBG lines available, suggesting possibility of connecting four Bandits, unless some of those are needed for the memory data path controllers. Need to check schematic.

The ANS Developer Note, as just a sort of aside, mentions the possibility of up to four Bandits in the architecture.

8500 has Chaos (vci0) at position 0 and Bandit (pci1) at position 1.
9500 has Bandit (pci1) and Bandit (pci2) at positions 1 and 2.
I haven't seen anything using position 3 (pci3).
position 0: F0000000
position 1: F2000000
position 2: F4000000
position 3: F6000000
Platinum or PSX or Hammerhead is at F8000000.
F9000000 to FEFFFFFF is PCI bus space for 6 NuBus slots.
FF000000 to FFFFFFFF allows for 16 MB of ROM.

The problem I see is where would Interrupts (handled by Grand Central) come from for the additional slots, and, of course, the Mac ROM would need to be made aware of the additional slots, I think.

Grand Central has 11 external interrupt pins. PCI devices can share interrupts.
An nvramrc script can be used to probe additional slots.
The more difficult part is having grant/request pairs for each slot.
Of course, there's always the method of using a PCI bridge to add more slots.

Given that Bandit and its arbiter are demonstrated on ANS to support at least 6 PCI devices, this suggests that one could go crazy and build a machine with 24 PCI slots. I'm not sure why you would want to, but maybe it could be done.

Right. The first Bandit of ANS has 6 devices. The second Bandit has 4 devices.
For the 9500, each bandit has 3 devices.
(Ignoring the Bandit PCI device @B for all four of those Bandits).

 

[trag]

Not sure where they come from. By "further reading", do you mean the "Related Documents" section of the HammerHead ERS?

TNT System ERS - don't know
TNT Control/Kaos ASIC ERS - don't know
TNT Bandit ASIC ERS - yes
Grand Central ASIC ERS - yes
djMEMC and MEMCjr ASIC ERS - don't know
MacRISC Architecture Document - don't know
Apple RISC Bus - don't know

Requesting the TNT Bandit and Grand Central documents if you have them, please.

8500 has Chaos (vci0) at position 0 and Bandit (pci1) at position 1.
9500 has Bandit (pci1) and Bandit (pci2) at positions 1 and 2.
I haven't seen anything using position 3 (pci3).
position 0: F0000000
position 1: F2000000
position 2: F4000000
position 3: F6000000
Platinum or PSX or Hammerhead is at F8000000.
F9000000 to FEFFFFFF is PCI bus space for 6 NuBus slots.
FF000000 to FFFFFFFF allows for 16 MB of ROM.

Seems possible to put Bandits at positions 0 and 3 provided no Chaos is present.

Interesting that 16 MB of ROM is possible, though finding compact high density 5V Flash is a pain.

Grand Central has 11 external interrupt pins. PCI devices can share interrupts.
An nvramrc script can be used to probe additional slots.
The more difficult part is having grant/request pairs for each slot.

Bandit provides the Grant/Request pairs. Actually, the PCI Arbiter chip 343S0182-1 (28 pin PLCC) provides the Grant/Request pairs. Everywhere you see a Bandit (343S0020) installed you'll find a 343S0182 nearby. But each additional Bandit provides the Bus/Grant pairs for the PCI slots.

The trick is having additional Grant/Request sets for each Bandit on the ARBus. It looks like Hammerhead has 5 sets and the CPU is only using one set. So how fixed are those notes in the Hammerhead document about certain sets being for Chaos or for a Secondary CPU. Could they be repurposed to a Bandit?

Are the drivers for Mac PCI devices written properly to share interrupts, given that Apple provided every slot with its own unique interrupt?

Of course, there's always the method of using a PCI bridge to add more slots.

Given the behavior of the S900, I'm not a fan of PCI-PCI bridges on the PowerSurge architecture. Something doesn't handle bridges properly. Install a multi-function PCI card behind a PCI-PCI Bridge on a PowerSurge machine and the machine will lock up during boot up. I've tried this with all four ROMs and with four different models of PCI-PCI Bridge.

Right. The first Bandit of ANS has 6 devices. The second Bandit has 4 devices.
For the 9500, each bandit has 3 devices.
(Ignoring the Bandit PCI device @B for all four of those Bandits).

Nitpick: On the 9500, Bandit 1 has four devices. Grand Central counts as a PCI device.

 

[Phipli]

By "clock speed register" do you mean the "CPU Speed" register? If so, and I have not read the entire Hammerhead document, but does the register actually do anything? It looks to me like it is a method for hardware to record a speed/state request at start up, and then must depend on software to read the setting in "CPU Speed" at start up and then set the various timing registers appropriately.

As usual, I could be wildly wrong....

Yeah, "CPUSpd".

It's possibly a register representation of the state of the physical pins. It does do something - it makes them readable from software, but you can't do anything to  it.

On the LC 475 you're able to use register writes to control the clock generator and set the bus speed. There is no reason to expect it here, I was just saying it is a shame.

The timings for things like RAM and ROM can be set through.

 

[trag]

Yeah, "CPUSpd".

It's possibly a register representation of the state of the physical pins. It does do something - it makes them readable from software, but you can't do anything to  it.

On the LC 475 you're able to use register writes to control the clock generator and set the bus speed. There is no reason to expect it here, I was just saying it is a shame.

The timings for things like RAM and ROM can be set through.

Right. Yes. Bus speed on the PowerSurge architecture (TNT/Tsunami) is completely controlled by the physical oscillator located on the CPU card. There's no way (that I can see) for influence to work it's way across the motherboard/CPU card interface to affect any circuitry on the CPU card, even if the CPU card had an adjustable clock (which some do).

The ANS also originates the bus speed with the oscillator on the CPU card, although the ANS distributes the Clocks to the various motherboard components rather differently.