Sphere478 wrote on 2022-05-24, 04:44:

This is a investigation thread continuing a conversation that started here: Re: Socket 5/7/SS7 (Processor) Tweaker […]
Show full quote

This is a investigation thread continuing a conversation that started here:
Re: Socket 5/7/SS7 (Processor) Tweaker

The thought and Idea has come up many times, including myself, but I don’t know if anyone has ever investigated it in a long winded research thread.

I need to understand better the relationship between the bus and the clock pin, the flexibility of various elements to operate at different clocks and even asynchronous (drifting) clock relationships. Is the cpu truly divorced from the bus? Or does it need to stay synchronized in some way? And would such a device break that?

I’ve been under the impression that if these are out of sync the whole setup would fall apart. But I don’t know for sure. Does anyone else have thoughts or knowledge on this?

Some background: socket 5/7/SS7 uses a processor internal multipler/divider that is inside the cpu its self. So that obviously isn’t able to be modified as it is internal, but maybe it’s able to be put in series with another device that is external to the cpu.

I would like to know that too. I don't have a lot of time right now, but it has been part of my plans to do some kind of "bubba" mod to try this out, on some Socket 7 board i don't care too much about. As far as sync goes, it must not be too complicated, since multipliers started to allow CPU's to clock "X times" the speed of the bus. The CLK pin is input only, and AFAIK only serves the purpose of being a base to calculate the CPU frequency. Since my Pentiums and Pentium MMX's have the ability to run at low clocks, like 14Mhz for instance, i don't think clocking low will be a problem. The question here is: how the system will behave with a higher FSB vs CPU clock. Theoretically the CPU will become the bottleneck, being slower than the bus it can never saturate the memory I/O for instance.

I think in theory even with different frequencies, if the duty cycle is the same and in sync there won't be any issues. The way i wanted to try this would be feeding 25MHz from a TTL OSCI to the CLK pin, severing the trace that comes from the PLL to the CPU.

If you are correct that we simply need to divorce and re supply the clock pin then it may be possible to just install a clock generator on a interposer

Not actually a hard thing to do..

The fastest way to test this is probably to de solder the clock pin on a pentium mmx and run a boge wire from it to the reference or kb clock on the clock gen. And boom, your fsb goes from 50/66mhz to 14 mhz

I propose you try that and report back, if it works we can proceed.

Sphere478 wrote on 2022-05-24, 06:21:

The fastest way to test this is probably to de solder the clock pin on a pentium mmx and run a boge wire from it to the reference or kb clock on the clock gen. And boom, your fsb goes from 50/66mhz to 14 mhz

You can't just run a bodge wire into the reference clock. The 14.318Mhz crystal does not provide TTL output. That's why you need the PLL to take this signal and convert it to several TTL outputs. PLL's must always generate at least one 24MHz TTL clock which is usually going to the Super I/O chip. I guess i could try that at least.

Also i don't know if the pin can be desoldered. But i have a few PPGA Pentium MMX's that i can at least use to try this out. Now i just need some time.

carlostex wrote on 2022-05-26, 00:25:

Sphere478 wrote on 2022-05-24, 06:21:

The fastest way to test this is probably to de solder the clock pin on a pentium mmx and run a boge wire from it to the reference or kb clock on the clock gen. And boom, your fsb goes from 50/66mhz to 14 mhz

You can't just run a bodge wire into the reference clock. The 14.318Mhz crystal does not provide TTL output. That's why you need the PLL to take this signal and convert it to several TTL outputs. PLL's must always generate at least one 24MHz TTL clock which is usually going to the Super I/O chip. I guess i could try that at least.

Also i don't know if the pin can be desoldered. But i have a few PPGA Pentium MMX's that i can at least use to try this out. Now i just need some time.

I said run it to the clock gen not to the crystal. We said the same thing I think.

Anyway, there is usually a 12 or 14mhz clock for the kb clock on the clock gen chip (pll)

You could use a coaxal cable maybe btw. Like a wifi cable? Help insulate from interference. Ground the jacket, use the core for the signal

I’m reasonably sure you can desolder a plastic pentium pin. It goes through to the top

Honestly, I kinda doubt any of this will work, but may as well try it, for science!!!

Sphere478 wrote on 2022-05-26, 00:28:

I said run it to the clock gen not to the crystal. We said the same thing I think. […]
Show full quote

I said run it to the clock gen not to the crystal. We said the same thing I think.

Anyway, there is usually a 12 or 14mhz clock for the kb clock on the clock gen chip (pll)

You could use a coaxal cable maybe btw. Like a wifi cable? Help insulate from interference. Ground the jacket, use the core for the signal

I’m reasonably sure you can desolder a plastic pentium pin. It goes through to the top

Honestly, I kinda doubt any of this will work, but may as well try it, for science!!!

There is a 14.318Mhz fixed signal which is usually used for at least the ISA bus. The keyboard controller on Pentium machines, at least, use 24MHz fed into the Super I/O CLK input pin. There's also a 48MHz signal for USB, but this is not really useful. No point in running the CPU at 96MHz.

This leaves us with 2 useful TTL signals coming from the PLL, the 14.318MHz which will yield a 28.6Mhz clock min frequency for the CPU and a 24MHz one. These ones could be indeed really useful. With some tweaking, namely by disabling Branch prediction and V Pipeline (which 386 and 486's never had), i assume that at least 486DX-40, 486DX-66 and 486DX-100 performance levels should be achievable. Disabling everything should allow for 386SX levels.

I'm not sure it will work either but doesn't really hurt to try. And if it works the slowdown will be really smooth, since the PCI and ISA buses won't be touched.

i have a feeling we are making some assumptions here that won't pan out but I'm onboard with investigating and trying. I just won't be doing it on my hardware 🤣 I eagerly await your attempt! :p

will any kind of pcb help with the attempt? I could maybe throw something together real quick. but just removing the pin and replacing it with a coax lead seems like a good approach from a physical design standpoint.

if it works somehow then our next step would be to see if it works using a non synced signal. Maybe use the signal from another mobo to test that. (bonding the grounds would prob be in order)

And if all that somehow manages to work, we just build a clock gen circuit on a interposer and intercept the pin.

Sphere478 wrote on 2022-05-26, 03:15:

i have a feeling we are making some assumptions here that won't pan out but I'm onboard with investigating and trying. I just wo […]
Show full quote

i have a feeling we are making some assumptions here that won't pan out but I'm onboard with investigating and trying. I just won't be doing it on my hardware 🤣 I eagerly await your attempt! :p

will any kind of pcb help with the attempt? I could maybe throw something together real quick. but just removing the pin and replacing it with a coax lead seems like a good approach from a physical design standpoint.

if it works somehow then our next step would be to see if it works using a non synced signal. Maybe use the signal from another mobo to test that. (bonding the grounds would prob be in order)

And if all that somehow manages to work, we just build a clock gen circuit on a interposer and intercept the pin.

For a non synced signal i can just use a TTL Oscillator. One of those rectangular can ones. In fact, like i said before, i used a 24MHz one to mod my board. My super I/O always receives the clock from that external TTL oscillator so that if i use the 7MHz FSB setting the keyboard and floppy don't stop working. Works fine there.

carlostex wrote on 2022-05-26, 03:23:

Sphere478 wrote on 2022-05-26, 03:15:

i have a feeling we are making some assumptions here that won't pan out but I'm onboard with investigating and trying. I just wo […]
Show full quote

i have a feeling we are making some assumptions here that won't pan out but I'm onboard with investigating and trying. I just won't be doing it on my hardware 🤣 I eagerly await your attempt! :p

will any kind of pcb help with the attempt? I could maybe throw something together real quick. but just removing the pin and replacing it with a coax lead seems like a good approach from a physical design standpoint.

if it works somehow then our next step would be to see if it works using a non synced signal. Maybe use the signal from another mobo to test that. (bonding the grounds would prob be in order)

And if all that somehow manages to work, we just build a clock gen circuit on a interposer and intercept the pin.

For a non synced signal i can just use a TTL Oscillator. One of those rectangular can ones. In fact, like i said before, i used a 24MHz one to mod my board. My super I/O always receives the clock from that external TTL oscillator so that if i use the 7MHz FSB setting the keyboard and floppy don't stop working. Works fine there.

Re: New clock gen for tyan s1564d

here is a interesting read also

https://youtu.be/odcH80wiiPs

If the processor can indeed be driven separately a device like this could possibly be used for driving it.

Very interested to hear the result of your test

Thank you for linking my Video.
Now if you try to just drive the CPU clock form an external clock... well this will never work. And there are many problems with that.
The bus is sampled based on this clock. So all devices connected to the bus (CPU, Chipset, etc) should have exactly the same clock signal as an input.

Now in a totally theoretical level it is possible with extra circuit there to resync the bus, however this is challenging to do and will add wait states.
There is probably also a mid-road solution were you use a pll to exactly double the clock, this should be generated from the normal clock input.
In this case again you need to process correctly some signals (handshaking) but in general not all + no extra delays on the bus.

So long story sort, doing this in a simple way this is impossible. With some simplifications it is possible, but hard to do even for me. I might try in the future.

galanopu wrote on 2022-06-15, 13:56:

Thank you for linking my Video. Now if you try to just drive the CPU clock form an external clock... well this will never work. […]
Show full quote

Thank you for linking my Video.
Now if you try to just drive the CPU clock form an external clock... well this will never work. And there are many problems with that.
The bus is sampled based on this clock. So all devices connected to the bus (CPU, Chipset, etc) should have exactly the same clock signal as an input.

Now in a totally theoretical level it is possible with extra circuit there to resync the bus, however this is challenging to do and will add wait states.
There is probably also a mid-road solution were you use a pll to exactly double the clock, this should be generated from the normal clock input.
In this case again you need to process correctly some signals (handshaking) but in general not all + no extra delays on the bus.

So long story sort, doing this in a simple way this is impossible. With some simplifications it is possible, but hard to do even for me. I might try in the future.

Okay, if you think it is possible maybe we can collaborate. if you give me a circuit I can incorporate it into a Tweaker and we can release it together as a collaborative effort.

galanopu wrote on 2022-06-15, 13:56:

Thank you for linking my Video. Now if you try to just drive the CPU clock form an external clock... well this will never work. […]
Show full quote

Thank you for linking my Video.
Now if you try to just drive the CPU clock form an external clock... well this will never work. And there are many problems with that.
The bus is sampled based on this clock. So all devices connected to the bus (CPU, Chipset, etc) should have exactly the same clock signal as an input.

Now in a totally theoretical level it is possible with extra circuit there to resync the bus, however this is challenging to do and will add wait states.
There is probably also a mid-road solution were you use a pll to exactly double the clock, this should be generated from the normal clock input.
In this case again you need to process correctly some signals (handshaking) but in general not all + no extra delays on the bus.

So long story sort, doing this in a simple way this is impossible. With some simplifications it is possible, but hard to do even for me. I might try in the future.

Thanks for your input. The idea here was to have the CPU running at a lower clock, for instance "2 X 25Mhz" for a total of 50MHz while keeping the rest of the system at 50MHz. This would help something like a Pentium MMX to have a more natural speed down without the cache disabling penalty hit.

Lowering the whole FSB itself brings other kinds of problems with PLL's that have very low test settings. Usually PCI bus drops to stupidly low levels bringing the whole VGA speed down to unusable levels or a keyboard clock so low that it stops working. Floppy drive won´t work anymore too. I was able to counter this by using a 24MHz TTL oscillator and feed the Super I/O chip with it all the time. But still the low PCI bus just wrecks everything. I wonder if i could do the same to the PCI bus and just feed it 33MHz directly. But in any case my PLL does not offer any FSB options lower than 50MHz other than the 7Mhz FSB test setting.

So yeah not easy to do. Again thank you so much for your input. Love your Youtube channel.

Thank you for liking my channel 😀

I see your point here.
Slowing down and Pentium is something that I have in mind and it is possible.
Now going for the clock divider approach is actually the had way to do this.
I have something better and easier in mind that I want to try.

Now aside from that... on my 486 under-clocking video I had a PCI VGA card with a bus at 5Mhz (maybe lower).
This was working fine. You can also use an ISA vga card that can also work with very low bus speeds.
The real problem with socket 5/7 is the rest of the reference frequencies as you said.
In the future I will have an Any_Clk variant for systems like that.
A bit hard to say for now how well this will work.

Re: Some (failed) experiments with external 386 clock doubling