Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
I've just looked into it and they actually aren't pin-compatible, got that one wrong... It's actually the KT133 and KT133A that are pin-compatible. :rolleyes2: The KT133(a) got additional pins in preperation for stuff like onboard graphics. (KM133) They also have a single address bus for the...
Thx for looking it up! These boardviews are indeed very nice to see how the boards are strapped. The strapping options/pins between the KX133 and KT133 boards seem to be same, only difference is that they're strapped differently. It's really nice that they are also available through the dimm...
The pull-down resistor value is a lot higher than the signal impedance, so it shouldn't infer with the actual signal.
The chipset got some other strappings as well on different address lines so it's designed in such a way that the pull up/down resistors don't infer with the dram signals.
One more thing... The KX133 seems to have a hardware strapping pin for the SysPushPull parameter. By using a pull-up (1) or pull-down (0) resistor the strapping can be adjusted. The pp/od parameter is strapped to the MAA4 pin of the SD-RAM interface so it's accessible through the ram slots...
Although i technically don't really have time for this... I've started to invest some time into getting familiar with VHDL, the programming language for FPGA's. Also dug into the AMD datasheets again to freshen up some memory about the whole ROMSIP transfer procedure. The ROMSIP is transferred...
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...
Yeah that's correct. My plan was to overclock it to ~400MHz, this would give a maximum sync error of 1/4 clock cycle, unfortunately even the most simple programs need 2 to 3 clock cycles to read the input pin, forward it to the output pin and loop back to reading the input pin. This gives an...
Well, i've received the Raspberry Pi Pico's but i don't think i can sync them (reliable) to the clock signal of the CPU which will mess up the timing of the SIP transfer. My next option will be the use of a CPLD (a simple form of an FPGA) but this is something that will take some time. Progress...
I tried the internal romsip on the Socket-A Gigabyte board and it seems to behave exactly like the adapter. Nothing happens.... The Slot-A Thunderbird sillicon should be the same but it also uses the older BGA Slot-A package. I don't know how AMD managed to make it work in open-drain mode...
I've tried multiple CPU's although most of the testing work has been done with a ceramic Duron 800. But i've also tested the adapter with different known-working Thunderbird, Palomino and Thoroughbred chips. I also double checked the FID settings, which is adjustable via dipswitches on the...
Alright, i've given up on the open-drain operation. Everything seems to be configured correctly and all the clock signals look good. The initialization is also successfull, the problem now is that the CPU just won't drive it's data pins. It doesn't even try to communicate. Maybe the Socket-A...
At 60mhz bandwidth you may still be seeing enough at 100mhz to decode the SIP, although i'm not familiar with analog scopes. What's unfortunate is that none of the Slot-A boards use an external ROMSIP. This was actually a feature for debugging in the chipset which Gigabyte just exploited to make...
Perfect! :d That's what i was guessing all along, that Gigabyte was using the external SIP to enable the PP bit. It should be 0 with the internal ROMSIP.
I have added the missing bit to the SIP streams to my original post, the last bit was missing on both. The SIP's have been measured with a D800AUT1C CPU, which is a Duron 800 with an 8x multiplier.
@Tzk
The stream is synchronised to the CPU PLL clock which is indeed the FSB clock of 100MHz, so...