majestyk wrote on 2026-07-11, 15:25:

It came complete with the memory card

ooooh, can you post pictures of the mem card? 😮

majestyk wrote on 2026-07-11, 15:25:

Here´s a picture of my own 386SX

looks pretty

majestyk wrote on 2026-07-11, 15:25:

permanently lit "FRAME" LED.

frame is for PCI side of POST card, blinking shows transactions happening, probably wired directly to FRAME# pin (active low)

majestyk wrote on 2026-07-11, 15:25:

Any ideas welcome!

any activity on the bios chip address pins after reset?

Memory card (partly populated):

There´s NO activity at address / data lines of the BIOS chips.

I added a 16MHz oscillator as "Osc1", so I can see _all_ signals on this mainboard with my old 20 MHz scope 😉

As for the LED - I just checked with another ISA mainboard (same chipset) and it´s also constantly lit while everything is working.

Make sure to reseat all seated chips, and/or clean the sockets with a toothbrush + isopropyl alcohol, and the isa slots. Oxidisation can completely disconnect the signals (reduce signal integrity to stop the device working).

Some boards needs at least an IDE controller connected, but no video card. It should beep without a video card.

majestyk wrote on 2026-07-12, 05:07:

Memory card (partly populated):

The attachment ECS_386SX_MemC.JPG is no longer available

did you happen to take picture of the back too? ;p

majestyk wrote on 2026-07-12, 05:07:

There´s NO activity at address / data lines of the BIOS chips.

Looking at NEAT datasheet now. It has an error on first page ... 245 buffer drawn between S-bus data and M-bus address 😐 Bad C&T, bad!

ROM data pins are wired to MD0-15 ram databus, looking at reverse picture of the pcb from retroweb this is confirmed by ram chip .. hmmm which one is it? M12? M19? M18? third from the bottom closest to bios... this ram chips pin 2 (Data IO) connects directly to EPROM HI U28 pin 11 (data out 0) and also connects to 245 buffer and also goes somewhere under U8 near 82C215.

On the other hand I can trace 386SX CPU QFP100 pin 1 (D0) connecting to 82C215 pin 24 (D0).

In general it all goes thru 82C215 as it has both D0-15 CPU-bus and MD0-15 M-bus. This is the crucial chip between CPU and BIOS. 82C215 pin 77 (MD0) can be traced to ... pin 14 (Dout) of top most parity ram chip 41c256??? that doesnt seem right ?? what do you know, another datasheet error. Later on pin 77 is described as MP0 not MD0, WTF C&T. Real MDO is pin 61, cant trace this one as it goes under the chip, but MD8 goes right to ram chips so can pretty much confirm.

Intel 386 pinout
- Deunan "IBM chips have the pinout 100% identical to 386SX " Re: 386SX pin-compatible upgrades
- pinout of a normal TI486SXLC QFP100 package Re: Upgrading a 386SX - some advice! or http://bitsavers.informatik.uni-stuttgart.de/ … rence_Guide.pdf page 6-2

TLDR:
1 confirm CPU is getting healthy reset pin 33
2 confirm CPU is getting healthy clock pin 15, R216
3 put scope on CPU Address pins 18 and 51-76. Check if CPU is trying to drive Address FFFF:FFF0. First 7 Address lines (18 51-56) should go high then low while pin 58 should remain high.

Picture of the Memory Card´s back added.

Here´s what I traced so far (found the error, too):

There´s one strange observation:
All inputs and outputs of the buffer U202 that bridges system bus data lines and memory data lines are on constant high level except "A6 <-> B6" (SD01) which is low on both gates.
So I removed this 245 buffer suspecting it might have a broken pullk-up, but without the chip B6 goes high while A6 stays low (all other Ax stay high). I removed the RAM chips using this data line and the BIOS chip using it (the LOW one), but this has no effect. 82C215 is also hooked to the memory data lines, but I have tested with a known working one. What else could fail to pull up or falsly pull down just this data line?

majestyk wrote on 2026-07-11, 15:25:

I also replaced the CPU and tried both with onboard memory and with the memory card.
Any ideas welcome!

Forget the mobo for now, make sure the CPU is working. I mean it's unlikely you got a bad replacement but there are different failure points.

First check (using datasheet and pinout) that all the required power pins are indeed connected. Soldering aside you might have a broken trace or via somewhere. These chips require all pins to be powered, it's not just for current capacity, the chip might simply not have internal power rails. That costs metal masks. So it's more like islands that are connected to power via the many power pins. Check both VCC and GND, preferably with ohm meter on unpowered mobo (and disconnected from PSU) to save yourself from accidents like shorting I/O pin to VCC or GND with a slip of the probe tip.

Make sure the clock actually reaches the CPU. What did you replace it with, the Intel on the photo? In that case make sure the clock (keep in mind 386 takes in CLK2, so twice what the actual clock is) is at least some 8MHz. Intel's 386 are CMOS but dynamic design, you'd need an AMD or Intel L-type low power chip for static. Also keep in mind these CPUs have a (very simple) self-check microcode that executes after reset so if you are trying to capture bus activity with logic analyzer or scope then reset input is not a good trigger. There will be a delay, I can't remember the details but say 65k clock cycles?

PQFP CPUs have FLT# input, make sure it's not grounded. This mobo doesn't have an extra CPU socket so no jumper for it but there might be a short somewhere.
A permanent high state on HOLD input would basically do the same as FLT#, the CPU releases the bus. But at least this would be indicated with HLDA being driven high by CPU (unlike FLT# which tristates everything).

You might still need a scope with some clever triggering if everything looks good, to check if the adddress lines (low bits A1-A8) toggle at all after reset, and if there is any activity on D/C# and M/IO# outputs. If none and everything else is good (clock present with good levels, no FLT/HOLD or RESET/INTR), and no excessive ripple on the power pins, then I would suspect the CPU is toast. Even if a replacement. But be sure you are capturing the activity (or lack of) because invalid instructions fetches can put the CPU in hang or HALT state and then it will appear dead. It might be only brief activity before that happens. In theory the chipest should detect some hangs like triple faults and reset the CPU but that might be broken so don't count on it.

afaik u202 is 573 not 245, you mean 245 U20?

>on constant high level

most likely everything is pulled high with resistor networks
I think RP1 is pulling D0-7 on S-bus
RP2 is pulling all the special signals like MEMR MEMW SMEMR SMEMW IOW IOR and for some reason pin7 of U38 245?

>except "A6 <-> B6" (SD01) which is low on both gates.

D1 on the CPU side is pulled by huge ass resistor R200 so cant really tell which way its being pulled

still I dont think thats your problem since you said you dont see any activity on BIOS address lines (just after reset), even crazy sticky data bus would make cpu execute some garbage - 7Fh is 'jnle' opcode so CPU would be just keep jumping around (in theory if 211 lets CPU just run wild)

Thanks for your support!

1. The replacement CPU (the one in the picture) came from a working mainboard.
2. clock signal at CLK2 is present (about 0.2Vpp)

With my scope in DC mode:
- reset goes up for about half a second, then stays low
- INTR goes up immediately and stays high
- A1 and A2 go up and then low just like reset
- A3 - A8 go up and stay high

So far I wasn´t able to watch any signal activity at the address lines at all. (At lest without external triggering)
I´m now going to double check all the solderings and traces to/from the CPU.

majestyk wrote on 2026-07-13, 06:32:

2. clock signal at CLK2 is present (about 0.2Vpp)

0.2? As in, there is only 0.2V difference between L and H levels? In that case find the gate that's driving the CPU input and replace it. CLK2 must have a full TTL swing at the very least, the closer to 0V for L and 5V for H the better.

CLK2 is often amplified/driven by F-class 74' chip, might be gates or one of the drivers in '244 or '245. These F chip do get weak and die and that's how it usually looks like - there is a signal but not in spec.

Looks like the Y-amps of my scope have aged faster than the buffers on the mainboard. After switching to the 2nd channel the amplitudes are five times larger. To make sure I compared to two working 386SX boards - same CLK2 amplitude.

5x higher would still be only 1Vp-p but considering it's a 20MHz scope you are probably getting a lot of attenuation already, so if another mobo shows the same signal and works I'd focus on other things. Just make sure the mid-point of the signal is also within TTL specs - as an example, a 2Vp-p between 3V and 5V might seem like a strong signal but will not properly drive digital inputs. Some inputs require much better than TTL specs, Z80 clock input was infamous for needing a very high H level to operate properly.

Anyway, A3 should also go low after reset but perhaps it's the issue I've mentioned, the CPU first goes into self-test so the bus is not properly driven yet. That scope, is it digital or analog? Digital one would be preferable here as it can trigger one-shot and keep displaying the captured data, analog will just blink the screen faster than your eye can see. Although, depending on the scope, if it at least shows it went from run/once to stop then you know it triggered. That itself can be useful but keeping in mind that during reset weird things can be presented to the bus.

With your setup it'd probably be best to focus on FLT# and HOLD first, make sure these have correct states: FLT# high or tri-stated, not L anyway, and HOLD must be low. You've checked INTR and it's H, not good but then again something might be requesting interrupt. The good news is x86 exits reset with interrupts disabled so it'll be ignored. But make sure NMI is L and not H as that one can't be masked by CPU.

If FLT,HOLD and NMI are OK then check ADS# on pin 16 for any activity. Use it as trigger perhaps if you can't see it toggling otherwise. ADS# must go low for any valid bus cycle so it not toggling means CPU is not doing any bus cycles at all.

I swapped the old CPU back in - no change.

Pins 27 - 31 are NC (Intel 386SX) so the FLT pin has no electrical connection.
HOLD is low, NMI is low, ADS# is constantly high.
A1, A2 AND A3 are going low after reset.

My scope is an analog veteran 😉

majestyk wrote on 2026-07-13, 11:24:

I swapped the old CPU back in - no change.

If it doesn't bother you then I'm not going to nitpick, IMHO though the less work needed the better. But it's your project, just keep in mind that these PCBs are old and sooner or later something is going to delaminate, even if you control the temperatures properly.

majestyk wrote on 2026-07-13, 11:24:

Pins 27 - 31 are NC (Intel 386SX) so the FLT pin has no electrical connection.

Pin 28 is defined in the datasheet but NC is correct because it has internal pull-up. IIRC the datasheet even suggests it be left unconnected if not used.

majestyk wrote on 2026-07-13, 11:24:

HOLD is low, NMI is low, ADS# is constantly high.
A1, A2 AND A3 are going low after reset.

So that is correct, except ADS#, but...

majestyk wrote on 2026-07-13, 11:24:

My scope is an analog veteran 😉

... I'm also considering this to be instrumentation issue. It could be both your scope and the mobo being faulty TBF. What I'm saying is I like analog scopes too but they do have their limitations and this job is much better suited for a digital scope. Rather than going in circles over this consider a new purchase - these days 2ch 100MHz scopes with reasonable 0.5-1Gs/s are pretty cheap. That with a basic 10:1 probe is going to make such projects much simpler. Think about it.

So here's another angle but with your scope it might not be possible to easily verify this: For the CPU to actually do anything useful it must get READY# from the chipset to terminate the bus cycle. If the chipset is kaput and READY# is held high all the time then the CPU will just forever stall on the first bus cycle. If I'm reading the datasheet right the ADS# will not stay low, it'll pulse once and then the CPU will wait for READY#. Your scope might easily miss that single pulse so it will look like the CPU is not doing anything.

However I think the bus signals should stay asserted in that case so I would expect D/C# and W/R# lines to be low, as that would be the first code fetch attempt. So probe these two lines after reset and we'll go from there.

Does the board have at least 4.8v?, given all the shorted tantalums.

Tested any other RAM? Any other BIOS'?

Some day I´m going to acquire some RIGOL digiscope - even the 200 MHz ones are priced moderate.
D/C# jumps high for half a second then stays low.
W/R# stays low all the time.
I have tested the 4 chipset chips in another mainboard and they were working fine.
______________________

Tantalums are fine, since they are new (see 1st post)
Tried both with onboard RAM AND the memory card (see 1st post) Just the two near the FPU socket are old, but they have no connection to any supply voltage.
The ECS BIOS works fine in another mainboard with the exactly same configuration / chipset and in return the other mainboard´s BIOS makes no difference on the ECS.

majestyk wrote on 2026-07-13, 14:05:

D/C# jumps high for half a second then stays low.
W/R# stays low all the time.

Jumps? As in toggles once or switches L-H a lot but stops after that half a second? Neither should happen unless chipset terminates the bus transaction with READY# going L. Which should then cause the CPU to pulse ADS# again because 386 has no internal cache so it must be fetching code all the time.

Since you see no activity on ADS# it's inconsistent - IMHO you've reached the limit of what your scope can show you and this is a problem that requires knowing more than than bits and pieces to see the whole picture. You need equipment that would show you pulses (~1 clock cycle long) on ADS# and READY# lines.

majestyk wrote on 2026-07-13, 14:05:

I have tested the 4 chipset chips in another mainboard and they were working fine.

Could be the PCB then. In general if the chipset works then these early fetch cycles should translate directly to BIOS ROM reads and you see no activity on BIOS chips, correct? The BIOS is slow so the chipset will introduce enough wait cycles on CPU for you to see at least address or control lines toggling on the ROMs even with that scope of yours.

A missing address line connection between CPU and chipset could be the cause. Especially A23 but on these mobos the lower address lines are often also decoded. In that case the BIOS ROM access is not detected and CPU receives some random data from the floating bus, or 0xFFs maybe, which will quickly turn into GPF -> DF -> triple fault and CPU shutdown. And the chipset might be too stupid to do a reset in that case so it all just freezes. That entire sequence would generate only a handful of bus transactions in a burst so it's easy to miss.

Scope is really poor tool for the job because ideally you want to see at least a couple of signals and their relations.
Nothing beats LA, even the $5 Cypress CY7C68013A kind (limited to 24MHz). https://github.com/gusmanb/logicanalyzer is another cheap option, requires $5 pico and optional buffers. Ideally something like $70 Sipeed SLogic16U3

I hate guessing games, and prefer to see what is actually happening with my own eyes.