Ok, this is beyond stupid. going as simple as possible, only outputting first two bytes:

POST card shows:
66|F0

YaY progress!
F0 was my marker to see if its executing at all. Still no clue why does it hang after one byte 😐
66 should be AA.
lets try 2 bytes at a time
Should be AA 55, and on second one 5A A5.

POST card for "one and two" shows:
66|04

POST card for "three and four" shows:
d0|F7

what the actual
66 04 d0 F7
AA 55 5A A5
~50% bits in common, might as well be random 🙁

one more try with delay loops, in theory there should be ~1 second delay two times between changing numbers

POST card shows F0|12

looks like your POST doesnt like it when I output two times in a row without sufficient delay
lets try something I saw in another bios, dummy output "out 0E1h, AX" to a non existent port as a delay

POST card shows:

0F|12 initially
and
F0|0F a few seconds later

woohoo, I finally managed to tame your post card 😀 at least partially, there should be '34' there after ~2x longer delay tho
fingers crossed this one cycles properly, im still not sure how long the delay is on real hardware, so give it a minute if it doesnt cycle

EDIT: wait, we are executing from ROM, there is no ROM in RAM, there is no RAM, and ROM is set as uncacheable, and Im not sure about L1 cache (should be enabled?) you said "few seconds" and this was barely 65K cycles delay. I think I miscalculated badly 😀 irl hardware is a LOT slower, 86box doesnt emulate slowness of eprom, making another one brb

edit2: done, ~20000 cycles delay, if its executing from bios with no caching thats gonna be .. hmm still too fast? at least this time you should see movement

I have had to temporarily remove the motherboard from the testbed. I will pick this up again after SXL2 testing is complete.

I fully understand, its a lot of effing around and not a lot of results

With the SXL2 testing wrapping up, I've made space for the Asus PCI/I-P54TP4 motherboard again. Getting pipelined burst SRAM working on this board isn't looking promising.

Upon running t15i0302 delay 5000.7z, I see a repeating series of numbers:
83 | 02
10 | FF
E8 | 72
00 | 69
-repeats indefinitely-

Now I need to remember what was my code doing in the first place 😀 but repeating same string of numbers is a good sign. How fast are they changing?

edit: found it, this is the code being executed

1_F000:E22A				   mov	   dx, 80h
2_F000:E22D				   mov	   ax, 1000h
3_F000:E230				   mov	   es, ax

setup

1_F000:E232
2_F000:E232 loc_FE232:
3_F000:E232
4_F000:E232				   xor	   di, di
5_F000:E234				   loop	   loc_FE232

quick loop just in case

1_F000:E236				   mov	   ax, 0F00Fh
2_F000:E239				   mov	   es:[di], ax
3_F000:E23C				   wbinvd

write F00F to beginning of test area and flushing cache, after that cache is empty and first two bytes of ram should contain F00F

1_F000:E23E loc_FE23E:
2_F000:E23E				   mov	   ax, es:[di]
3_F000:E241				   out	   dx, al
4_F000:E242				   out	   0E1h, ax
5_F000:E244				   xchg	   ah, al
6_F000:E246				   out	   dx, al

read back two bytes and push to diag card, this should read F00F on the card on first loop

1_F000:E247				   out	   0E1h, ax
2_F000:E249				   mov	   cx, 5000h
3_F000:E24C loc_FE24C:
4_F000:E24C				   loop	   loc_FE24C

only 20000 cycles of delay

1_F000:E24E				   add	   di, 2
2_F000:E251				   cmp	   di, 10h
3_F000:E254				   jb	   short loc_FE23E

repeat until 16 bytes, then reset back to 0

1_F000:E256				   mov	   cx, 5000h
2_F000:E259				   jmp	   short loc_FE232

feipoa wrote on 2022-12-17, 02:25:

83 | 02 10 | FF E8 | 72 00 | 69 -repeats indefinitely- […]
Show full quote

83 | 02
10 | FF
E8 | 72
00 | 69
-repeats indefinitely-

bad:
- I dont see any F00F in there
no foof means writes to cache arent saved in cache
- it repeats every 8 bytes instead of 16
8 bytes = 64bits just like Pentium bus/cache width, means it did try to flush cache, but no cache chip was being activated at the moment of reading and it kept reading same garbage maybe from empty memory bus? is the output always the same even if you power down for couple of minutes?

The values shown on the POST card change approximately every 1 second.

Yes, I tried powering up/down 3 times in total and the output was consistent, as shown above.

We may be at a stand still. I did manage to find a later version of this board, the ASUS P/I-P55TP4XEG. It is based on the same 430FX chipset, has DIP Async SRAM sockets and a COAST slot. There is one jumper on the board that selects between ASYNC and COAST-PB SRAM, so when it arrives, I will see what this jumper is doing. Most likely it is doing something we've already tried, but sometimes I get pleasantly surprised.

worst case scenario you can stick desoldered coast module in new board and trace pin by pin how cache chips are connected to chipset

feipoa wrote on 2022-12-17, 10:23:

The values shown on the POST card change approximately every 1 second.

20000 cycles per second? so the cpu must be running with L1 disabled, still that seems really slow 😮

Let's see how my motivation is at that point. I may even upgrade my socket 5 setup to that of the socket 7 ASUS P/I-P55TP4XEG. After all, it can take 512 KB PBSRAM rather than just 256K.

I have received my Asus P/I-P55TP4XEG v2.4. Attached is the manual.

So far, I've only had time to map out where JP16 goes.

JP16
1-2 = Async SRAM
2-3 = Pipeline Burst

Pin 1 = COAST slot pin 91 = pipeline burst SRAM module pin 86 = OE#

Pin 2 = DIP32 sockets pin 24 = OE#

Pin 3 = 4.7K pull-up to 5 V

Good board. I had this one once.

Cheers,

I attempted to mimic the jumper setting, JP16, from the Asus P/I-P55TP4XEG v2.4 onto the Asus PCI/I-P54TP4 using a 4.7 K-ohm resistor, but it didn't help the issue with the non-functional pipeline burst cache.

I have since desoldered the UMC pipeline burst SRAM from the Asus PCI/I-P54TP4 and removed all other modifications made with regard to PB SRAM. I gave up this effort and am now using the Asus P/I-P55TP4XEG v2.4 with a 512K PB SRAM COAST module in my K5-200 build.

I had really wanted a full length AT socket 5 board for my K5-200 build with PB SRAM, but I've settled for a socket 7 board instead. Perhaps someone else with another 430FX and PB SRAM solder pads can report their findings here.

Off topic:
I also owned the P54TP4 back in the days with 512kb non PB cache plus EDO. and all benches were indeed faster with L2 disabled. Especially when running bus at 80MHz. Never understood why.

Anyway fantastic engineering here so far. Good luck with the new board.