• Please review our updated Terms and Rules here

Five Festive 5150 Boards (BOARD #1 Thread)

TEST5060 & TEST5067 Look good so RAM should be good to go, however RDR now consistently fails all the 8253 timer channels. Even though the 8253 is a solid IC, I had myself convinced it could be faulty. Socketed and swapped out with known good, timers still fail so ruled that out.

I started poking around some more, and found out /XIOW isn't active during the timer tests, it just stays high. At first I was baffled because the schematics say /XIOW & /XIOR go back to U14, but there wasn't any connectivity on the board. So I took a look at the traces, and on these 64-256 type boards they go back to U101:

/XIOR U34-22 -> U101-6
/XIOW U34-23 -> U101-3 (ISSUE HERE)

U101 Doesn't even seem to be documented anywhere, or did I miss it? So I guess I'll be having a look at that IC.

1706415326118.png
 
Replaced U101 and now all RDR 8253 timer channel tests pass. On to the RAM now.

I'm a bit surprised the first 2 KB of RAM always fails after TEST5060 & TEST5067 passed on the LA. Sometimes it crashes RDR as well.

1706465375693.png
 
I thought U12 might be the issue, but after setting up a capture with the LA, it looks fine. Out of ideas at the moment. Board is unstable, 1 out of 3 RDR runs the board crashes at the first 2KB RAM test. Largest address failure I've seen is b.
 
VeryVon said:
Sometimes it crashes RDR as well.
Click to expand...
VeryVon said:
Board is unstable, 1 out of 3 RDR runs the board crashes at the first 2KB RAM test.
Click to expand...
Yes, unstable.

VeryVon said:
I'm a bit surprised the first 2 KB of RAM always fails after TEST5060 & TEST5067 passed on the LA.
Click to expand...
VeryVon said:
I thought U12 might be the issue, but after setting up a capture with the LA
Click to expand...
Here's the problem. Something is intermittent. Not all LA captures are going to capture the instant that something misbehaves. E.g. You could do 100 captures, and not capture it, but do so on the 101'th capture.

Because you are seeing RDR sometimes crash, the problem is somehow related to either: address going from CPU to ROM, or data going from ROM to CPU. And the ROM is under suspicion as well.
 
modem7 said:
ROM is under suspicion
Click to expand...
I created a new RDR ROM, but RAM tests and crashing persist
modem7 said:
problem is somehow related to either: address going from CPU to ROM, or data going from ROM to CPU
Click to expand...
CPU to ROM would be U15 / U16, and ROM to CPU would be U13 correct? If that's the case i'm going to start pulling and replacing those chips one at a time. Seems like 1/3 of the chips on this board are fried anyway :LOL:
 
VeryVon said:
CPU to ROM would be U15 / U16 ...
Click to expand...
Looking at the diagram at [here], I see:

CPU
U7
U9
U10
Control circuitry for U7 and U10
Interference to address bus from anything attached to address bus (including ISA cards)
U15
U16
Control circuitry for U15 and U16
Interference to external address bus from anything attached to external address bus

VeryVon said:
... and ROM to CPU would be U13 correct?
Click to expand...
I'm pretty sure that you can work out similar using the diagram at [here].
 
Sounds good. Glad you have some more ideas because pulled U13, U15 & U16 tonight. They check out ok as far as I can tell.

To check the signals on all these IC's, do you think it's worth trying to develop a custom ROM to reproduce the issue? Something I could run on a working board, and compare signals to the crashing board. I can assist with or attempt the ROM code if you think it's a feasible diagnostic.
 
VeryVon said:
To check the signals on all these IC's, do you think it's worth trying to develop a custom ROM to reproduce the issue? Something I could run on a working board, and compare signals to the crashing board. I can assist with or attempt the ROM code if you think it's a feasible diagnostic.
Click to expand...
I'm not sure what you mean. I cannot create code that makes an intermittent problem not be intermittent.
 
modem7 said:
cannot create code that makes an intermittent problem not be intermittent
Click to expand...
I know what you mean.

Let me expand a little bit on the test. Sometimes RDR doesn't crash, and reports a failure. The test code would simply test RAM address 0000:0000 in a loop. I guess the question is would the loop crash the board. I don't know.

If the board doesn't crash testing address 0000:0000, then I could take a look at the signals vs. a working board.
 
Ok yea, nevermind. I created a version of the ROM that loops testing the first byte of memory, but I don't think its stable enough to get a read of what's going on before it crashes.
 
I'm waiting for the next generation of LA software, the generation that will have 'trigger on random crashes' functionality. :)

Motherboards in this state are a right pain-in-the-butt to fix.

One person that I was helping offline, had some luck with the piggybacking technique, but as we know, that is hit-or-miss.

One thing to check. When there is a crash (as different to RDR halting after encountering RAM failure), see if the 4.77 MHz clock signal is present out of the 8284A.
 
modem7 said:
I'm waiting for the next generation of LA software, the generation that will have 'trigger on random crashes' functionality.
Click to expand...
Sounds like something powered by AI :)

modem7 said:
had some luck with the piggybacking technique
Click to expand...
Good point, easy to do and worth a try

modem7 said:
When there is a crash see if the 4.77 MHz clock signal is present out of the 8284A.
Click to expand...
Will do. I'm leaning towards putting a socket on that chip just to try another and rule out that it's glitching as those so often do fail

p.s. using interrupts is there a way to arrange single-stepping the CPU one instruction or cycle at a time on these boards?
 
VeryVon said:
p.s. using interrupts is there a way to arrange single-stepping the CPU one instruction at a time on these boards?
Click to expand...
I have never investigated single-stepping instructions on PC family motherboards. I have not had the need to. It may require removing the 8088 and in its place, plugging in an 8088 emulator/debugger thing. There is sure to be information about this online.

In early days, to investigate the situation of {IBM POST stopping without error indication, but the SLDR and RDR (early version) passing all tests}, I modified the early part of the IBM POST to output diagnostic codes, and that's where we learned that it was the POST's test of early RAM that was failing (then discovering that SLDR and early-version RDR did not do RAM addressing tests).

But that was a 'permanent' scenario - the problem always occurred at every boot, and occurred at the same location.
 
modem7 said:
I'm waiting for the next generation of LA software, the generation that will have 'trigger on random crashes' functionality. :)
Click to expand...
VeryVon said:
Sounds like something powered by AI :)
Click to expand...
I see that everyone's trying to get onto the AI bandwagon. I bought some suppositories, choosing the brand that had "AI" on the label, only to discover later, that it was a case of misleading advertising. Their "AI" stood for anally induced.
 
Has some fun programming in NASM, displaying bits & test patterns etc (the RDR asm is so well documented, it's practically a tutorial / clinic on how to write code) and I'm going to move on to the final board. Might come back to this one.

1707174614960.png
 
You must log in or register to reply here.
Back
Top