[weblacky]

As I mentioned in a previous post, technically the chips appeared to be correct but on a lot of sites they're labeled as PS/2 SIMMs and not just SIMMs. Now this could just be an older jargon but from my understanding there was in fact a PS/2 SIMM standard and the only thing I found odd was if you look back at the data sheets that I gave the data lines are not in the same order that the JEDEC standard prefers. They're grouped in the same correct areas. And it has the correct presence detect lines on it to convey speed and type. But a lot of of the pins are addressed/labelled with different A# or D# numbers than the JEDEC generic SIMM pin out.

I don't know if this actually matters or not given the fact that it has to read through those same pins if the internal organization of the memory is different I don't know why that would matter to the host machine. But that was the only weird thing I found about the memory. Otherwise both sets are in fact parity and are in fact FPM supporting 70 ns.

I mean it would be great if you could find a new set of four modules to break the stalemate here given that both sets are basically from the same family and so they're actually very much like each other except for their densities.

Also it would've been able to start the TFTP transfer without having a valid MAC address on the embedded NIC because else ARP and IP allocation and everything else wouldn't have worked. So I don't believe that the RTC isn't working at this point given that the PROM actually comes up.

I'm still wanting to know the results of that network experiment though you just said it didn't work but I don't know what that means. Does that mean you got exactly the same result where it started the transfer and then ended prematurely? Did you use a crossover cable and did you adjust your window system to manually match the 10Mb speed?