@auto660 so you want to replicate this adapter as I understand?
One thing to remind is that KT133 boards don't support A-XP so maybe this difference is what is preventing you from booting. Another thing is that Thunderbird CPUs were late and not all boards and BIOS versions might support them. So it's best to check TB support for Slot A and use TB socket A CPU. And even then they have different steppings AFAIR.
Just found this thread, looks very nice.
Anhang anzeigen 906817
It's been a while since i've been active here on the forums. Just didn't have the time and motivation to continue with the project, so it's been mostly stored away now in the hardware stash. But essentially i'm trying to replicate this adapter. But from the ground up using my own design, since this picture is the only documented thing left of all the Slot-A adapters that might have existed. As for the current state of this project...
The CPU gets initialized, the ROMSIP is transferred and (if i remember correctly) it's even confirmed by the CPU to the board that it was received/initialized successfully. All the clock signals and power-good signals seem to be there as well, with good signal quality/integrity. So that shouldn't be the problem, it's actually really nice that this part is good since signal integrity can be a b*tch to get right at these clockspeeds. I've also acquired a high-speed oscilloscope during this project which really helps with debugging stuff and checking if the signal waveforms look alright.
The main problem now is that the socket A CPU's won't start the data-communication bus in Open-Drain mode. Even the databus clock signals aren't activated, total silence on the bus traces. I've tried this with AMD751 based boards as well as with VIA KX133 based boards. With and without modded bioses. CPU-wise i've tried thunderbirds, durons, Thoroughbreds and Bartons. I've even put a Geode in there to check if the embedded stuff is a bit more willing to communicate via open-drain. But that was a no-go as well.
There is one motherboard though that uses the AMD751 Slot-A chipset while supporting Socket-A cpu's, with a modded bios it even works with the later Barton cores. I did some debugging work on that board and found out that it uses a customized ROMSIP to initialize the CPU in Push-Pull mode. In order to get the AMD751 chipset to initialize the CPU in Push-Pull mode, they've put the chipset permanently in debug-mode. This debug-mode allows the chipset to read a custom ROMSIP from an external EEPROM. So the board is using an external EEPROM to provide the correct ROMSIP to the CPU in order to make it work.
This motherboard (The Gigabyte GA-7IXE4, based on their Slot-A 7IXE variant) has an unpopulated jumper that makes the boards switch between the external and internal ROMSIP. I've added the jumper and switched between the ROMSIP's. The result was kinda expected, it will only boot with the external ROMSIP. The internal ROMSIP is a no-boot and gives the exact same behaviour as with the Slot-A adapter on a Slot-A board.
The high-speed oscilloscope came in very handy to see how the board and CPU behaves with both ROMSIP's. After scoping both the internal and external ROMSIP package we were able to decode them here on the forum. And this confirmed our assumptions. The external ROMSIP initialized the CPU in Push-Pull mode which works flawlessly. The internal ROMSIP on the other hand, initialized the CPU in Open-Drain mode which doesn't work. So here we have the reason why Gigabyte went through the trouble of putting the chipset in debug-mode and adding an external EEPROM. They probably had a whole stash of these chipsets left laying around when Socket-A was the hot new thing, so they went out of their way to still get a profit on them.
The next step would be to modify the ROMSIP such that the CPU is initialized in Push-Pull mode and see if the CPU tries to communicate. Unfortunately, both the AMD and VIA chipsets have a hardcoded ROMSIP that can't be changed. Putting the chipset in debug-mode and adding an EEPROM would require extensive mods to the motherboard and would be nearly impossible, especially without any further documentation about this debug-mode. It also defeats the use-case of this adapter and would only work on AMD based boards, not the VIA ones.
This brings us to the current state of the project. The only realistic solution to this would be to
throw away the adapters and start a more viable project. uhh... i mean go on and find a way to initialize the CPU in push-pull mode without extensive mods to the motherboard. The only way to make this happen is to intercept the ROMSIP package and either modify or completely replace it. This will be a difficult task since it's a high speed signal (100MHz) and is timing sensitive in correlation with the incoming 100MHz PLL clock to the CPU.
So i've been looking for a solution. Back when Socket A launched, it would've been nearly impossible to make this happen in a price-competitive way, and with approval of AMD. Fortunately, we've advanced almost 25 years with technology and that approval of AMD is not really a thing anymore for the Slot/Socket A hardware. (I think/hope) It's also more of a gimmick, so price-competitiveness isn't too big of a thing now.
My first try was with the Raspberry Pi Pico (RP2040), unfortunately it seems like it's really struggling to make signals at a rate of 100MHz and it would be nearly impossible to time the signal correctly in correlation with the 100MHz PLL clocksignal. Fail.
My second try will be to use a FPGA that supports this kind of speeds and makes use of an external clock-input, so it can be driven by the 100MHz clock signal and keep near-perfect timing. Luckily these kind of FPGA's have become cheaply available throughout these 25 years so that would be an option worth to try. It even supports higher clockspeeds, and since it would be coupled to the CPU PLL clock, FSB/bus overclocking should stay possible from a theoretical standpoint. Actually, i've already ordered an FPGA board a while ago that's been sitting in the stash here for a while now.
Unfortunately i don't have time (yet) to try and make it work with the FPGA. But it's still something i want to do in the coming year. So the project isn't dead (yet), but it's gonna take some time to make the next big step.
I also want to thank everyone who helped here for their help to make this project happen.
Parallel habe ich mir ein paar alte Sticks zum Üben aus dem Container gezogen
biosbude.de
hwbot.org
