Bussing around with a G3 Beige XPC106 Memory controller upgrade

[Doq]

Honestly, every living PowerPC shouldn't have to be sacrificed for any reason (why the BonusBook is in the Lab and not at an e-cycler).

Now if it was already dead, that's a different story. There's enough dead PowerPCs that fun experiments like these are still very possible.

 

[pete1]

Alright, the community has spoken and I definitely won’t be dismantling my Yikes board. I’ll be on the lookout for a Rev. A G3 B/W board instead.

 

[pete1]

So I got a dead Beige G3 board to play around with. I desoldered the XPC106 chip with a hot air gun (no hot plate) to verify the PLL 0-3 pads on the BGA footprint go to the resistors stated in the schematics, which they do. R49 and R52 are the resistors of interest for 100MHz operation.

I’ll practice putting the XPC106 back on this board before I work on my good board. Which type of solder balls and template should I buy?

 

[LightBulbFun]

I’ll practice putting the XPC106 back on this board before I work on my good board. Which type of solder balls and template should I buy?

for rapid-prototyping as they call it, I would recommend getting a tube of 0.76mm leaded solder balls and a 0.76mm BGA solder stencil, usually they come in in a bag lot of various sizes and shapes, as as long as you get one that has a selection of 0.76mm stencils in there, one will fit

if you want to be super-proper about it, then technically you need to first of all solder paste the chip pads, and reflow 0.89mm 10/90 tin-lead balls onto the chips, then apply paste to the PCB and solder the chip with its special balls onto the PCB, but this is a bit more involved/time consuming etc

and so for testing 0.76mm balls are fine, the only difference is, the chip does sit lower down (so be mindful of that when heatsinks are being mounted etc) and that long term reliability of the solder joints will likely not be as good

 

[pete1]

So I finally got a IR preheater and a 100MHz Grackle from a battery bombed B/W G3 board. The operation to swap the chip went flawlessly. I confirmed stable operation before trying the PLL resistor mod.

So here’s how I did the mod, bodging R52 to +3.3V for a logical 1, and R49 to GND for a logical 0. With PLL2 and 3 jumpers set on the block, that should give us the ‘1000’ setting we need for 100MHz bus operation.

Sadly, it fails to boot at all in this configuration. I spent a couple of hours fiddling and trying different things but it just seems as though this setup is seen as invalid.

My RAM is all PC133 and the CPU is a 350MHz 750L so won’t have a problem with a 100MHz bus.

Which makes me wonder if there’s a bus lookup table in the ROM which might not have an entry for this setting, and causes a hang. After all, we can’t even get the 87.5MHz config to work despite being able to physically set 2.5x35MHz PCI.

I dunno, it’s just a theory, but I feel there’s more at play here. I’m open to try other things if we get some more info on this but for now I am out of ideas.

 

[joevt]

Which makes me wonder if there’s a bus lookup table in the ROM which might not have an entry for this setting, and causes a hang. After all, we can’t even get the 87.5MHz config to work despite being able to physically set 2.5x35MHz PCI.

The DingusPPC discord has this note for Gossamer machines:

The Gossamer HWInit includes the following table of bus and DEC frequencies:

Bus freqency | Decrementer frequency
50000000,    | 12500000
60000000,    | 15000000
66666666,    | 16666666
75000000,    | 18750000
70000000,    | 17500000
78750000,    | 19687500
66820000,    | 16705000
83000000,    | 20750000

There's another note for TNT machines:

The issue I was having with using a non-PPC601 in the DPPC PM7500 (OF 1.0.5) where the timebase wasn't being calculated correctly in Open Firmware was because I was using the bus frequency from Gossamer (66,820,000) instead of 50,000,000.The timing code at 0xFFF03810 uses the VIA timer to time how long the decrementer takes to count down from 0x3FFFF. Then it uses a table at 0xFFF03944 to convert the VIA time to a bus speed.

32840 25,000,000
31580 26,000,000
30410 27,000,000
29320 28,000,000
28310 29,000,000
27360 30,000,000
26480 31,000,000
25650 32,000,000
24880 33,000,000
24630 33,333,333
24140 34,000,000
23450 35,000,000
22800 36,000,000
22180 37,000,000
21600 38,000,000
21050 39,000,000
20520 40,000,000
20020 41,000,000
19540 42,000,000
19090 43,000,000
18650 44,000,000
18240 45,000,000
17840 46,000,000
17460 47,000,000
17100 48,000,000
16750 49,000,000
16410 50,000,000
16090 51,000,000
15780 52,000,000
15480 53,000,000
15200 54,000,000
14920 55,000,000
14650 56,000,000
14400 57,000,000
14150 58,000,000
13910 59,000,000
13680 60,000,000
13450 61,000,000
13230 62,000,000
0 0

Using 66,820,000 for the bus frequency returns a time of 12378 which is below the minimum allowed so you get a zero.Using 50,000,000 for the bus frequency returns a time of 16514 which returns 50,000,000 from the table.I have g_realtime set to false so all the timers (VIA, RTC, TB, etc) are using the original DPPC cycle timing method. I can increase the appearrant speed of the timers by increasing icnt_factor. For my 4GHz Skylake Mac, icnt_factor = 6 makes d# 1000 ms take approximately 1 second. Decreasing icnt_factor to 5 makes that take twice as long. I'm not using the screen in Open Firmware. That may slow it down further.

I don't remember what the problem was. Maybe it didn't startup? I suppose this can be tested with the DingusPPC emulator by changing bus_freq in machinegossamer.cpp.

 

[pete1]

The Gossamer HWInit includes the following table of bus and DEC frequencies:

This strongly seems to suggest that the ROM will only handle one of the bus speeds specified.

How easy would it be to replace one or more of the useless entries with faster ones? Guessing it would work as the length of the ROM would not change but might there be an issue with the checksum? The chips on my ROM are flashable.

 

[joevt]

How easy would it be to replace one or more of the useless entries with faster ones? Guessing it would work as the length of the ROM would not change but might there be an issue with the checksum? The chips on my ROM are flashable.

Of course, you would update the checksum if you change anything that requires the checksum to be updated.
The change can be tested in DingusPPC.
The table probably needs to remain sorted.

One thing to check is the "Serial Test Manager" which is also mentioned in the DingusPPC discord. It will check the checksums of the ROM.
I only know about the checksum for the first 3 MB of the ROM. There's other checksum(s) checked by the "Serial Test Manager".
I'm not sure how to enter the "Serial Test Manager". I think you need to press a button (NMI, emmo?) during or before startup? If there's a problem, then there should be a crash sound during startup and the "Serial Test Manager" is automatically entered (a prompt ;# is output to modem serial port where you can send commands - enter ? for help).

 

[pete1]

The table probably needs to remain sorted.

It’s not sorted? I see a couple of entries out of order.

One thing I thought is that the entry for 100MHz would have an extra digit, although perhaps that doesn’t matter when dealing with hex code. We could anyway start with 87500000 to begin with. (edit: it doesn’t matter - 87,500,000 (0x053EC600) and 100,000,000 (0x05F5E100) both fit within the same 32-bit (4-byte) space in the ROM.)

I might have a play with DingusPPC if it would help to establish proof of concept.

 

[joevt]

It’s not sorted? I see a couple of entries out of order.

Yes, there's two versions of grackle that are considered in the code so there's more than one table. I believe Gossamer and Yosemite have the same grackle revision (0x40 in PCI config register at offset 8) so they both should use the same table.

    this->class_rev   = 0x06000040;

The list is not sorted because the code is not using a timing loop to choose the bus frequency like TNT did. It uses 3 bits of the Gossamer system register to select from 8 timing info entries.

    BUS_SPEED_POS   = 1,         // bus speed code, see below
    BUS_SPEED_MASK  = 0x0E,

    // configure the Gossamer system register
    uint16_t sys_reg = FDC_TYPE_SWIM3 | BURST_ROM_TRUE
                        | (0x3F << PCI_A_PRSNT_POS) // pull up all PRSNT bits
                        | (1 << PCM_PID_POS) // CPU/Cache speed ratio = 2:1
                        | AIO_PRSNT_FALSE // this machine is not All-in-one
                        | (BUS_FREQ_66P82 << BUS_SPEED_POS) // set bus frequency
                        | UNKNOWN_BIT_0; // pull up bit 0

// Gossamer bus speed frequency codes
enum : uint8_t {
    BUS_FREQ_75P00A = 0, // 75.00 MHz
    BUS_FREQ_70P00  = 1, // 70.00 MHz
    BUS_FREQ_78P75  = 2, // 78.75 MHz
    BUS_FREQ_TRI    = 3, // clock output tristated
    BUS_FREQ_75P00B = 4, // 75.00 MHz
    BUS_FREQ_60P00  = 5, // 60.00 MHz
    BUS_FREQ_66P82  = 6, // 66.82 MHz
    BUS_FREQ_83P00  = 7, // 83.00 MHz
};

Each timing info entry is 18 32-bit numbers which is 72 = 0x48 bytes for each entry.
The first number is bus frequency. The second number is timebase or decrementer clock frequency. One of the remaining 16 numbers is selected using the 4-bit CPU PLL which determines the CPU speed.

@Powermax posted his disassembly of the Gossamer HWInit routine in the DingusPPC discord.
There is a section "Initialize ROM timing" which also may need to be considered.

What have you changed?
Do you know what the system register and the PLL are set to?
Is there a setting not described here that you have set?

 

[joevt]

This thread has followup posts at https://68kmla.org/bb/index.php?threads/croissantkings-conquests.46708/post-558292

 

[PowerPC74]

So I finally got a IR preheater and a 100MHz Grackle from a battery bombed B/W G3 board. The operation to swap the chip went flawlessly. I confirmed stable operation before trying the PLL resistor mod.

View attachment 2496940

So here’s how I did the mod, bodging R52 to +3.3V for a logical 1, and R49 to GND for a logical 0. With PLL2 and 3 jumpers set on the block, that should give us the ‘1000’ setting we need for 100MHz bus operation.

View attachment 2496944

Sadly, it fails to boot at all in this configuration. I spent a couple of hours fiddling and trying different things but it just seems as though this setup is seen as invalid.

My RAM is all PC133 and the CPU is a 350MHz 750L so won’t have a problem with a 100MHz bus.

Which makes me wonder if there’s a bus lookup table in the ROM which might not have an entry for this setting, and causes a hang. After all, we can’t even get the 87.5MHz config to work despite being able to physically set 2.5x35MHz PCI.

I dunno, it’s just a theory, but I feel there’s more at play here. I’m open to try other things if we get some more info on this but for now I am out of ideas.

I think one of the FFO's could just be replaced setting the PCI bus to 66MHz, I think the XPC100 should do 133MHz.

It's just a matter of the PCI Bus built-in PCI devices and if you get too much clock jitter at 66.666MHz

 

[pete1]

I think one of the FFO's could just be replaced setting the PCI bus to 66MHz, I think the XPC100 should do 133MHz.

It's just a matter of the PCI Bus built-in PCI devices and if you get too much clock jitter at 66.666MHz

This doesn’t sound realistic to me - it’s way too far in excess of what the hardware was designed for. Bear in mind that most 66MHz Grackles won’t even run stable at 83MHz.

A step by step approach is needed and I think getting it to boot with an 87.5MHz bus (35MHz PCi) would be an interesting target.

Significant hurdles include the SC608 clock generator with its fixed presets, and the ROM code which may block unknown frequencies.

I need to better understand the relationship between the clock generator and the Grackle chip in terms of how the bus frequency is being generated. I’m not clear if the clock generator is doing it or if the Grackle is doing it, but I suspect the former.

 

[PowerPC74]

This doesn’t sound realistic to me - it’s way too far in excess of what the hardware was designed for. Bear in mind that most 66MHz Grackles won’t even run stable at 83MHz.

A step by step approach is needed and I think getting it to boot with an 87.5MHz bus (35MHz PCi) would be an interesting target.

Significant hurdles include the SC608 clock generator with its fixed presets, and the ROM code which may block unknown frequencies.

I need to better understand the relationship between the clock generator and the Grackle chip in terms of how the bus frequency is being generated. I’m not clear if the clock generator is doing it or if the Grackle is doing it, but I suspect the former.

Doesn't the clock generator relay on a Fixed Frequency Oscillator?

Maybe I'm wrong, but the correct FFO would run the PCI BUS at 66MHz and the rom tables would not be wise to it. If the system bus is 66MHz with 33Mhz PCI then it's 133MHz with 66MHz PCI.

XPC100's can run at 133Mhz, it's been done on G3 B&W, and other Old World Macs have been clocked to 66Mhz PCI, it can cause issues with mac-io, but issues don't mean it won't run.

The Rage II chip and VRAM may also be an issue, but it's not like they can't be removed.

If Mac-io can handle the 66MHz PCI, even with some issues, then we maybe golden, if it can't without major issues, then back the clock down, and we are no worse off than we were before.

If the point is speed, and the point is always speed, then the simple math is 133MHz is faster than 100MHz and the Beige needs the PCI BUS performance of 66MHz.

Of course another issue is OS X calculation of the timebase would be all wrong, and that has been an issue before with Sawtooths and Gig-E machines overclocked to 133Mhz Bus.

 

[pete1]

Doesn't the clock generator relay on a Fixed Frequency Oscillator?

Yes, it does. TBH I didn’t know what you meant when you said FFO in your previous reply.

Maybe I'm wrong, but the correct FFO would run the PCI BUS at 66MHz and the rom tables would not be wise to it. If the system bus is 66MHz with 33Mhz PCI then it's 133MHz with 66MHz PCI.

It would need to be a FFO that’s 2x the exisiting 14.31818 MHz part so a 26.63636 part. They do exist, so not an issue in that respect.

Why do you think the ROM tables would not be wise to it? How does the ROM check on this?

XPC100's can run at 133Mhz, it's been done on G3 B&W, and other Old World Macs have been clocked to 66Mhz PCI, it can cause issues with mac-io, but issues don't mean it won't run.

It would depend on the specific XPC106 - some might be stable at that speed while others might not be. A heatsink would probably help.

Which old world Macs have been clocked to a 66MHz PCI bus? Do you have a link to the discussion on that? This is very interesting.

The Rage II chip and VRAM may also be an issue, but it's not like they can't be removed.

I suspect they would be. Doesn’t the Heathrow chip use the PCI clock as well? Things like Ethernet, SCSI and IDE would break. I guess you could add in PCI cards for all those things but then would they be compatible?

I’ve read that 33MHz PCI cards start to malfunction above 36MHz so in my mind 66MHz seems bonkers (unless the card was designed for it, such as the Rage 128 that came with the Blue and White G3).

If Mac-io can handle the 66MHz PCI, even with some issues, then we maybe golden, if it can't without major issues, then back the clock down, and we are no worse off than we were before.

Right. Not much to lose and easy to test.

If the point is speed, and the point is always speed, then the simple math is 133MHz is faster than 100MHz and the Beige needs the PCI BUS performance of 66MHz.

We’re coming at this from different angles (which is fine!). I like to unlock the hidden potential in hardware, but not at the cost of breaking loads of stuff. The 100MHz bus mod originally aimed for in this thread is appealing to me as it would keep PCI at 33MHz.

However, your proposal - if it gets round the ROM block - is interesting in terms of what we could learn from it.

Of course another issue is OS X calculation of the timebase would be all wrong, and that has been an issue before with Sawtooths and Gig-E machines overclocked to 133Mhz Bus.

Maybe we cross that bridge when we come to it. Can the code be edited?

 

[pete1]

If Mac-io can handle the 66MHz PCI,

I just realised that Mac-io refers to the Heathrow.

The Paddington chip in the Yosemite is pin compatible so could be transplanted. (Edit: just checked and the Paddington is on the slow side of the PCI bridge)

 

[PowerPC74]

Which old world Macs have been clocked to a 66MHz PCI bus?

Insane Otaku Productions

 

[pete1]

I socketed the reference crystal and fitted a 15MHz part to see what would happen. It boots and reports a 87.3MHz bus as it should:

This tells us that the ROM does not check the actual speed of the bus, just the preset selected in the clock generator. Obviously the clock generator doesn’t know about the reference crystal being swapped out. This is confirmed by ASP which still reports a 83.3MHz bus.

The time base seems OK.

The onboard video is left shifted and dimmer, because the Rage Pro uses the reference crystal as well (buffered through the clock generator). A PCI card would not be affected.

 

[PowerPC74]

I socketed the reference crystal and fitted a 15MHz part to see what would happen. It boots and reports a 87.3MHz bus as it should:

View attachment 2501337

This tells us that the ROM does not check the actual speed of the bus, just the preset selected in the clock generator. Obviously the clock generator doesn’t know about the reference crystal being swapped out. This is confirmed by ASP which still reports a 83.3MHz bus.

The time base seems OK.

The onboard video is left shifted and dimmer, because the Rage Pro uses the reference crystal as well (buffered through the clock generator). A PCI card would not be affected.

That's not moving the timebase much, did you plan to try and push it out more?

Sadly the Beige G3 seems to not use the pci-proble-list variable, or we could skip probing of the Rage II chip as we know this is going to be an issue @26.63636MHz.

The only report I could find of someone pushing the XPC100 in a B&W to 133MHz was not a good one, but maybe 60MHz PCI and 120MHz Bus might work.

 

[pete1]

That's not moving the timebase much, did you plan to try and push it out more?

Sadly the Beige G3 seems to not use the pci-proble-list variable, or we could skip probing of the Rage II chip as we know this is going to be an issue @26.63636MHz.

The only report I could find of someone pushing the XPC100 in a B&W to 133MHz was not a good one, but maybe 60MHz PCI and 120MHz Bus might work.

I plan to try a 16MHz oscillator next which would give a 93MHz bus.

VCC could be lifted on the Rage Pro so it is disabled.

I have two spare B/W boards now so I may try the 133MHz bus mod on those.

 

[joevt]

Sadly the Beige G3 seems to not use the pci-proble-list variable, or we could skip probing of the Rage II chip as we know this is going to be an issue @26.63636MHz.

Any of the PCI enumeration code in Open Firmware can be patched.
See this example where we change the probe order on a Power Mac 6500/TAM
https://68kmla.org/bb/index.php?threads/the-great-gazelle-pci-hack-thread-part-2.38360/post-467825

 

[pete1]

Running into an issue with a 16MHz oscillator.

With 1 DIMM installed, it gets me a 93.1MHz bus - the expected speed - but if I put in 2 or 3 DIMMs it drops down to 91.2MHz or 89.3MHz respectively.

Seems there are signal integrity issues trying to drive multiple sticks of RAM at 90MHz or above. I’m impressed it can automatically drop the bus speed, but a bit surprised I’m running into a ceiling already.

 

[pc297]

Speaking of the 83.3 MHz fsb setting, does anyone know if the 1GHz sonnet encore g4 zif will run at all with this bus frequency (and if it will change the multiplier from 15 to 12 automatically)?

 

[LightBulbFun]

Speaking of the 83.3 MHz fsb setting, does anyone know if the 1GHz sonnet encore g4 zif will run at all with this bus frequency (and if it will change the multiplier from 15 to 12 automatically)?

from what I have seen it does not, there is actually someone on this forum who used this to his advantage to overclock his by running his beige at 75Mhz FSB he got his clocked to 1.125Ghz


@pete1 very interesting findings, I have a feeling the clock dropping with more DIMM's is perhaps not intentional, but maybe a loading thing somehow slowing the clock down? or maybe the software miss-reporting? I did notice that on my early Uninorth machines, Gauge Pro would sometimes take a little time to "settle down"

https://forums.macrumors.com/threads/making-a-g4-pismo-upgrade-at-home.2019269/?post=24334163#post-24334163

I dont recall seeing this happen on any pre-uninorth machine with gauge pro but I do wonder if it might be something like that happening here, so I wonder if its worth letting it sit for a few minutes and opening and closing gauge pro throughout to see if things change or not?

 

[pete1]

I dropped in a nice little socket that makes swapping crystals a breeze.

I received a 17.734MHz crystal, which is the next step up from 16MHz, as 17MHz crystals don't seem to be available.

The absolute best bus speed I have been able to attain is 94.7MHz as reported by Gauge Pro, with just one stick of RAM. Adding in more sticks brings the bus speed down as previously (to 89-91MHz or thereabouts).

Changing the reference crystal should scale things up linearly, so I would expect a bus speed of 103MHz. As before, I'm hitting some kind of ceiling.

Still, it's not far off the 100MHz mark I'm aiming for and I've seen no instability or weirdness despite PCI running at almost 38MHz.

@pete1 very interesting findings, I have a feeling the clock dropping with more DIMM's is perhaps not intentional, but maybe a loading thing somehow slowing the clock down? or maybe the software miss-reporting? I did notice that on my early Uninorth machines, Gauge Pro would sometimes take a little time to "settle down"

I'm pretty sure it's the first one – excessive PLL load causing the clocks to sag. Gauge Pro does seem to settle down as you previously observed on another machine. But removing RAM affects the bus speed a lot more conspicuously.

I wonder whether bumping the clock generator's voltage slightly might help.