-
Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.
Beige G3 onboard cache
- Thread starter stynx
- Start date
So far i have only realized that the Gossamer cache Slot is for 512K modules only. There are some lines that are tied together on the Gossamer while the data sheet of the MPC106CDG66 states that these must be separately switched to use the full 1Mb of cache.
Also, Apple has seemingly tied some unused pins to ground while others are tied to 3.3V
Im a bit tired at the moment and need to sleep a bit to have a clear mind.
Also, Apple has seemingly tied some unused pins to ground while others are tied to 3.3V
Im a bit tired at the moment and need to sleep a bit to have a clear mind.
I have seen, and copied somewhere, a picture of the G3 beige board with the slot in place, and a cache inserted.
What cpu were you using when you booted up?
A G3 with its cache, or a cacheless 604e. Accordingt to at least one other intrepid explorer, he ran a 604e ibm 333hmz 604. Though he did say it was taller than the G3 and the heat sink couldn’t clamp down. Saw the pics he posted. Looked neat. But perhaps a 604 would be best for you to try in this case.
I used a G3 and a 604e3 333MHz both times the cache module blew smoke while the computer itself kept working. I came to the conclusion that the specific cache module is not 100% compatible but an older 512K module might work. Sadly, that IBM/Motorola 512K module is unobtainable. IBM might have used it in the RS6000 7248/43p
Looks like it does support 1MB modules, you need to change some pull-up resistors depending on the module that’s installed.
Of course the specific one you tried (that I also have) could still be incompatible.
The bank-address lines (BAA) are tied together as are the ADSC lines. This means that only one bank can be accessed or rather both banks are addressed at the same time.
This will result in a bus-conflict with 1Mb modules which have 2 64bit wide banks.
Gossamer:
Cache module:
Apple accesses the cache-module completely different than it is ment to be accessed.
CNTEN0 and CNTEN1 are tied together as are CWE4 and CWE5, CG0 and CG1, ADS0 and ADS1.
CWE0 - CWE3, CWE6 and CWE7 are left floating.
Apple most likely did a completely different addressing scheme of the cache chips than used on the cache module.
The cache chips would have to be arranged in 32bit bank interleaved fashion with L2SCLK(0) and L2SCLK(1) acting as the hi/lo-word select.. or maybe the cache banks are 64bit-only wide with four 16bit or two 32bit chips each, only differentiated by the L2SCLK(1/0) chip-select?
EDIT: L2SCLK0 and L2SCLK1 are also tied together.
Either way, the cache module is not remotely usable without modifications.
CNTEN0 and CNTEN1 are tied together as are CWE4 and CWE5, CG0 and CG1, ADS0 and ADS1.
CWE0 - CWE3, CWE6 and CWE7 are left floating.
Apple most likely did a completely different addressing scheme of the cache chips than used on the cache module.
EDIT: L2SCLK0 and L2SCLK1 are also tied together.
Either way, the cache module is not remotely usable without modifications.
I have bought some IBM L2 cache modules (1MiB) 75H5463.
The way that module is accessed is a bit more similar to the way Apple has implemented it.
The big differences:
CWE3 -> NC
DP3 -> GND
CWE2 -> NC
DP2 -> GND
CWE1 -> NC
DP1 -> GND
CWE0 -> NC
DP0 -> GND
CWE7 -> NC
DP7 -> GND
CWE6 -> NC
DP6 -> GND
CWE5 -> DWE
DP5 -> GND
CWE4 -> DWE
DP4 -> GND
CLK3 -> GND
COE0 -> DOE
CLK4 -> GND
COE1 -> DOE
CLK0 -> L2SCLK
CLK1 -> L2SCLK
CLK2 -> L2SCLK(2)
CLK3 -> GND
CLK4 -> GND
CWE0-CWE7: Byte enable lines for each byte of the 64bit data-bus.
Apple has not implemented a decode logic on the mainboard but the IBM cache module has them exposed to the cache bus.
CWE5 and CWE4 are attached but are tied together on the G3 mainboard. The other lines are not connected.
This would result in only one chip (on each bank) being capable to be written to.
-> The CWE-lines have to be tied together on the cache module.
DP0-DP7: The data parity lines are tied to ground on the G3 mainboard. This may cause problems since it would connect the parity lines directly to ground on a read-cycle. This may cause excessive load on the output.
-> Cut the DP-line on the cache module since Apple does not use them.
COE0, COE1: Chip output enable: both are tied to data output enable (DOE).
CLK0-CLK4: The G3 mainboard has only CLK0 and CLK1 tied to the system clock. CLK2 is tied to the tag-ram. The cache module uses CLK0 and CLK1 on bank 0 while it uses CLK3 and CLK4 on bank 1.
-> Tie all CLK-lines together.
The individual banks (0,1) are selected by address line A12 using the chip-enable and inverted chip-enable on the cache-chips. This means that the 1MiB of cache can be addresses by using the output-enable and write-enable signals while the cache is always active. The cache module has a LC86A (quadruple 2-input exclusive OR) where the Standby line and A12 a routed, most likely to facilitate disabling the cache, using standby like a CS-line.
This is all my personal opinion based on looking and measuring traces and using the Motorola and Apple schematics. There are no IBM cache-schematics, sadly. I have modified an IBM cache module and might try it in the G3 in the future. Im a bit hesitant since the last time the unmodified Motorola module blew smoke
The way that module is accessed is a bit more similar to the way Apple has implemented it.
The big differences:
CWE3 -> NC
DP3 -> GND
CWE2 -> NC
DP2 -> GND
CWE1 -> NC
DP1 -> GND
CWE0 -> NC
DP0 -> GND
CWE7 -> NC
DP7 -> GND
CWE6 -> NC
DP6 -> GND
CWE5 -> DWE
DP5 -> GND
CWE4 -> DWE
DP4 -> GND
CLK3 -> GND
COE0 -> DOE
CLK4 -> GND
COE1 -> DOE
CLK0 -> L2SCLK
CLK1 -> L2SCLK
CLK2 -> L2SCLK(2)
CLK3 -> GND
CLK4 -> GND
CWE0-CWE7: Byte enable lines for each byte of the 64bit data-bus.
Apple has not implemented a decode logic on the mainboard but the IBM cache module has them exposed to the cache bus.
CWE5 and CWE4 are attached but are tied together on the G3 mainboard. The other lines are not connected.
This would result in only one chip (on each bank) being capable to be written to.
-> The CWE-lines have to be tied together on the cache module.
DP0-DP7: The data parity lines are tied to ground on the G3 mainboard. This may cause problems since it would connect the parity lines directly to ground on a read-cycle. This may cause excessive load on the output.
-> Cut the DP-line on the cache module since Apple does not use them.
COE0, COE1: Chip output enable: both are tied to data output enable (DOE).
CLK0-CLK4: The G3 mainboard has only CLK0 and CLK1 tied to the system clock. CLK2 is tied to the tag-ram. The cache module uses CLK0 and CLK1 on bank 0 while it uses CLK3 and CLK4 on bank 1.
-> Tie all CLK-lines together.
The individual banks (0,1) are selected by address line A12 using the chip-enable and inverted chip-enable on the cache-chips. This means that the 1MiB of cache can be addresses by using the output-enable and write-enable signals while the cache is always active. The cache module has a LC86A (quadruple 2-input exclusive OR) where the Standby line and A12 a routed, most likely to facilitate disabling the cache, using standby like a CS-line.
This is all my personal opinion based on looking and measuring traces and using the Motorola and Apple schematics. There are no IBM cache-schematics, sadly. I have modified an IBM cache module and might try it in the G3 in the future. Im a bit hesitant since the last time the unmodified Motorola module blew smoke
Another difference:
PD0 and PD1 are connected to 3.3V on the G3 while they are connected to GND and 3.3V through a 100 Ohm resistor on the cache module.
The module got very warm in that area since 3.3V was connected to GND through that 100 Ohm resistor and vice versa. I therefore disconnected PD0 and PD1 on the cache module.
I switched the resistors for PD2 and PD3 around since IBM seems to have implemented the cache-size detection differently.
The G3 will now chime and sit there while the tag-ram on the cache module gets hot.
I will have to test this setup with a 604e3-375 ZIF CPU module once i get another one delivered. I have a 375MHz CPU module but that is installed on a ZIF-carrier card for the 7/8/9x00 PCI Powermacs. I doubt that this mod will be successful since i have no idea how Apple had intended the L2 cache socket to be used. On top of that, it may be completely switched off in rom or maybe even on the Board itself with no possibility to enable it from the Mac OS. Especially the ROM will have a routine to disable any L2 when a G3 with cache is installed.
I have also bought a 128MiB 3.3V EDO module. This does not fit into the SD-Ram socket... though i have read that the 3.3V DRAM modules should fit....
-Jonas
PD0 and PD1 are connected to 3.3V on the G3 while they are connected to GND and 3.3V through a 100 Ohm resistor on the cache module.
The module got very warm in that area since 3.3V was connected to GND through that 100 Ohm resistor and vice versa. I therefore disconnected PD0 and PD1 on the cache module.
I switched the resistors for PD2 and PD3 around since IBM seems to have implemented the cache-size detection differently.
The G3 will now chime and sit there while the tag-ram on the cache module gets hot.
I will have to test this setup with a 604e3-375 ZIF CPU module once i get another one delivered. I have a 375MHz CPU module but that is installed on a ZIF-carrier card for the 7/8/9x00 PCI Powermacs. I doubt that this mod will be successful since i have no idea how Apple had intended the L2 cache socket to be used. On top of that, it may be completely switched off in rom or maybe even on the Board itself with no possibility to enable it from the Mac OS. Especially the ROM will have a routine to disable any L2 when a G3 with cache is installed.
I have also bought a 128MiB 3.3V EDO module. This does not fit into the SD-Ram socket... though i have read that the 3.3V DRAM modules should fit....
-Jonas
Similar threads
