On 31.08.2022 0:33, Louis Ohland wrote:

Oh, hows about using the single row sockets to pump up the N to a POD? Instead of removing the 17x17 and dropping in a 19x19 socket?

You could probably do that if you are careful with the alignment. The connection won't be as reliable if you use a normal female pin-header (i believe the CPU pins are slightly thinner).

I wanna replace the LIF on one of my "N"s with the old-school
"overdrive" ZIFs that were used on the Olivetti M6 planar, for example.
Mainly because these early sockets are more compact. I don't think a
regular ZIF would fit with its bulky lever base.

But more importantly, I need to get back to figuring out what makes the
"N" barf with anything but the DX2. Even with a regular 486DX-33 that
should be 100% compatible with the DX2-33/66 (externally). It either
executes POST for a bit and then loses the plot (even before the first
SDL checkpoint) or sometimes just sits there after reset.

One thing that comes to mind is the BIST execution time - that's one
aspect where the two differ. Of course there are probably other
undocumented differences too.

Eh, we will get there...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Oh, hows about using the single row sockets to pump up the N to a POD?
Instead of removing the 17x17 and dropping in a 19x19 socket?

Tomas Slavotinek wrote:

On 30.08.2022 22:44, Shane Benting wrote:

On Monday, August 29, 2022 at 5:18:46 PM UTC-7, Tomas Slavotinek wrote:

All this also reminded me of the AMD K6 experiment I've done some time
ago. It failed on one of the tests that were now identified to use the
JTAG interface.

I don't have the code fully reversed but looks like they are doing an
awful lot of bitbanging there. TCK is pulsed from the code with no
explicit SW delay. So, now I wonder whether there really was a critical
communication failure on the local/system bus or if this was just a
timing issue on the JTAG bus because of the CPU's ability to execute the >>> loops significantly faster... (sure, we are limited by the timing of the >>> local and system buses - 60/66 and 40 MHz, but JTAG from this era is
usually clocked even lower - 10-20 MHz maybe? The TCK signal goes
through a PAL, so it's possible that they are doing some synchronization >>> there, but idk... will have to probulate it with a logic analyzer.

But don't get your hopes up. It's quite likely that there will be more
problems down the road with the K6 if we push it past the JTAG tests.
But it makes me curious. I'll definitely revisit this at some point and
try bypassing the tests...

Tomas,

Which K6 did you try? I've been meaning to test out an Evergreen
Spectra I recently acquired on one of my Ys. I was hopeful that since
it offloaded the power to a separate connector that it wouldn't
require the same level of modifications that the Overdrives do.

-Shane

I believe it was a regular K6-266 (non -II/-III) with the PowerLeap
PL-ProMMX Plus interposer (v4.0 IIRC). This interposer (and the mounted
CPU) is also powered directly from the PSU and has a local switching regulator. It takes care of the clock multiplier pins too, so no bodge
wires are needed. The Evergreen one should be similar in this aspect.

There are however other problems with the later Socket 5/7 CPUs.

The non-MMX P54C Pentium chips had 3.3V I/O and core, but the clock
input was still 5 V-tolerant (to make board conversion easier/cheaper).
So, to nobody's surprise, the "Y" platform uses IBM's own 5 V clock
driver - the same one as on the "P" and "Q" boards. The clock signal
goes directly to the CPU (unlike the other non-C5/C8 input signals that
*ARE* level-shifted on "Y"). Pentium MMX (P55C) not only introduced the
split voltage design but also dropped support for the legacy 5 V clock.
Most interposers probably don't level-shift the clock. This won't damage
the chip, despite it being beyond the absolute maximum voltage, but it
may compromise the clock integrity.

Further, the P5 and P54C chips can be configured to a C5/C8 mode (the
cache chipset used on all T4 complexes). This modifies the driving
capability of certain pins IIRC. At least some of the P55C MMX chips
still have this capability, but most if not all of them were not tested
in this configuration by Intel. That's another potential problem...

The former issue is fixable, and if that's what causes the incompatibility/instability with some faster CPUs, then we should be
able to get them working.

The latter may be more difficult to solve... but I'll have to go over
the manuals again to see what exactly the C5/C8 mode modifies.

Later Socket 5/7 CPUs were designed with the "modern" PCI chipsets in
mind, so there very well may be other incompatibilities too (tighter
timings, etc.).

I plan to do more CPU experiments but first I wanna understand the T4 architecture better - down to a component level including the 74xx glue.
I'm almost there, but not quite... And the JTAG discovery will help me
crack the few remaining early POST bits too. (I had to delay all this exciting stuff because of other more important things..)

The C5/C8 cache set is actually relatively fast - especially for its
time. But you can fit only so much into 256K. We are ultimately limited
by the relatively slow RAM subsystem (interleaved 64-bit 70 ns non-EDO)
and slow I/O bus (Micro Channel) where the best we can do is <40 MB/s sequential from/to the complex - comparable to early PCI implementations (Neptune). So at some point, the benefits of a fast CPU core flatten out
in practical applications, as it has to spend a lot of time waiting for data/instructions... The fast internal L2 cache of the K6-III(+) chips
might mask the memory bottleneck a bit, but it's still only 256K...

Anyway, please let us know how your experiments go. It's always good to
have more data!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)