I also tried with the original AMI bios but with similar results

Have you got a 5V CPU on a 3.3V board there?

The circuit included the possibility of installing a 5V CPU see JUMPER R17, I removed the regulator and made a bridge between the CPU-VCC and the 5V, the rest of the electronics is 5V

Did you do a full repair of those torn off pads and traces?

Yes i fixed the two trace broken

I count 3, with a lifted pad near marking U4.

Dataset says that is the A21 line. I think you said you connected it?

Are you sure that this is not a multilayer pcb that needs a more... complex... repair for those lifted pads?

You're right, three tracks were broken and they have been repaired.

dataino.it wrote on 2024-10-27, 16:20:

Question: Is the IBM CPU pinout recoverable?

NP - not populated (not soldered in other words).

R18 should be NP because AFAIK Cyrix does not float A20 so there is no need for such connection. R17 depends on what the CPU is. That might be a way for the IBM chip to have a separate voltage reference for I/O pins (like on 3V3 486 chips), but Cyrix chips have all the Vcc pins tied together and no such option.

R16 should be NP as it makes no sense on Cyrix. R15 should be 0 ohm, you might get away putting 100 ohms there as A20 gate signal shouldn't be be fast switching, and that will offer some short circuit protection. A20M# in as permanent input though so 0 ohms should be safe.

R14 should be 0 ohms but this signal should go to the FLUSH# pin, not KEN#. Possibly you can wire both together and just not use KEN# - this will require BIOS too dumb to set it up, so you'll need a DOS util, or a BIOS that allows you to select Cyrix operating mode. Frankly I would expect to have to use the DOS util anyway, and BIOS just to get the CPU to boot properly but perhaps not be set correctly.

R13 and R12 should be NP on Cyrix. Even if BIOS tries to enable KEN# the worst case scenario it will float and the L1 will be sort of randomly used or not during early boot. But there is no need to have KEN# tied to GND, Cyrix can ignore it and you'll just have to set the exclusion zones properly via software.

One last thing, FLUSH# input is optional but it must not float if any software (that means BIOS as well) tries to enable it. You'll get massive performance degradation if it's enabled and pulled low all the time.

I think I was reading that without flush it treats cache as dirty, but it's still 40% faster than cache completely disabled, but when flush is enabled it's 80% faster.

K2's retro workshop on youtube was running into problems with this putting a SLC onto an M396F, I am not sure if he covers it in first vid on topic or later when it won't run Doom in a comparo test. He is a bit vague in his descriptions and you need to watch at 1.5X speed because of slow pacing and pauses.

I am fixing up a couple of Pine PT319A boards with SLC on in the near future, I am hoping they implemented it properly, but have the same SARC chipset dude was saying there was nowhere to hook the flush to, so IDK.

However, a thought occurs with this board, all IBM Microelectronics involved boards I have messed with are picky picky picky with RAM, Red Hill guide mentions this also for I think the IBM SLC2 CPU or DLC3-75 I think referring to a Leopard board. It would suck trying to test RAM on a maybe faulty board without being absolutely sure that RAM works on it.

BitWrangler wrote on 2024-10-28, 16:40:

I think I was reading that without flush it treats cache as dirty, but it's still 40% faster than cache completely disabled, but when flush is enabled it's 80% faster.

Dirty bit exists only on WB cache. WT has a Valid bit and that's it. Flush evicts entire cache by setting all the V bits (in all cache rows) to false. It's fast but not a free operation as it has to go over all the rows, and if that has to be done between each instruction (due to FLUSH# being pulled low and active) it's going to slow down the CPU a lot. But as I've said the input is configurable on Cyrix and inactive after reset, so if the BIOS doesn't do anything with the config registers the system should boot with internal cache disabled by a 4G sized exclusion zone - in other words, excluding the entire memory space from being cacheable.

Since FLUSH# is not edge triggered a slow DMA transaction might cause cache flush a few times but that is not really noticable. The schematic OP posted shows that mobo is already masking fake DMA cycles (that are actually not hidden RAM refresh cycles) with the extra OR gate, that is a much better and faster solution that using BARB flushing. But if FLUSH# input doesn't work well for some reason then BARB is still an option. The only connection that has to be there is the A20 gate status. Without that the workaround config bit must be set (first 64k of each 1MB segment is non-cacheable) and that will affect performance. Some apps get affected more than others. Frankly a better solution might be to apply this only to the HMA rather than each 1MB of RAM via exclusion zone. But it A20 mask signal is available on the mobo it's just best to route that to the CPU, by wires if need be. This makes everything much easier.

KEN# is completly optional thanks to the 4 user definable exclusion zones. On a typical PC you need 2, maybe even 1 if you don't have memory-mapped cards, to get system to work properly. Only some network cards and SCSI controllers would need that, so BIOS might be choosing the safer option but user can override that with DOS util.

The problem with this mobo is there is perhaps some coherency protocol for the mobo cache (if any) that IBM chip uses but Cyrix does not. If the system works when mobo cache is disabled, but not otherwise, that could be the issue.

It was also coming to mind that some of the IBMs had a workaround for exceeding 16MB whereas Cyrix on that footprint don't... though info on these is really scrambled and could have been referring to DX pinout BL3s.

Not sure about IBM, I've never found any proper docs for their chips, but Intel had a 386SL chip. It's basically 386SX and parts of PC chipset integrated into one package, so that it would be easier to implement PC-like hardware with less parts. Cheaper and more reliable. This was meant for industrial use though IIRC - I'm too lazy to find the relevant datasheet now. If memory serves this chip had a different package (more pins) and indeed could address more than 16MiB of memory space because the address lines extented past A23. Not by much though, I think it was just 2 more bits for a max of 64MiB (RAM of memory-mapped devices). Due to package differences it's completly not compatible with existing PC mobos (and possibly the integrated chipset is not 100% identical to IBM PC spec).