• Please review our updated Terms and Rules here

Fixing Five Festive 5150 Boards over the Holidays (BOARD #3 Thread)

Ok wrong heheh. I can see the code will have to look more like TEST5066. During my study I remember seeing physical address generation, offset & segment registers. Will need to revisit that, probably something you pros incorporate automatically :)
 
Capture of 55AA. ROW is 45h (bit 3 out of sequence) and COL is 2Ah (bit 0 out of sequence)

1705023193233.png

Capture of AA55. As expected bits 0 and 3 are out of sequence with the others:

1705023732996.png
 
Last edited:
VeryVon said:
Ran a capture of 55AA. ROW is 45h (bit 3 out of sequence) and COL is 2Ah (bit 0 out of sequence)
Click to expand...
Regarding the first shown capture, showing the portion where AAh is written to address 55AA.

BYW: Your A cursor (ROW) should be slightly to the right, in the area where the data is shown as AAh. Just a technicality. As you can see, it doesn't affect the ROW address seen.

I presume the ROW address is displayed as 45h rather than A2h due to your choice of LA wires. So, yeah, that highlighted 0 in cursor A should be a 1.
 
modem7 said:
I presume the ROW address is displayed as 45h rather than A2h due to your choice of LA wires. So, yeah, that highlighted 0 in cursor A should be a 1.
Click to expand...
Here's what the actual mapping is. I think I have the captures reversed because in the images above the group data format is "Wire MSB -> Data MSB" ... should be "Wire LSB -> Data MSB"?

1705025191704.png
 
VeryVon said:
Here's what the actual mapping is:
Click to expand...
You have used ascending wire numbers on descending address bits.

I have done that myself. There is an option somewhere, where you can get the software to cater for that. Try right-clicking on "-/Address" and seeing what is available.
 
VeryVon said:
This suggests a problem with U62 and/or RN4?
Click to expand...
Yes, although the chances of the resistor network being the problem cause are really really low.

For the ROW address, you are seeing A2, not AA, i.e. bad bit 3 in the ROW address.
Refer to the diagram at [here].
Bit 3 in the ROW address corresponds to A3.
Per the diagram, A3 is routed through U62.
Time to swap out U62.
 
I pulled U62, and two LS158's from the donor board. They all test out OK on the chip tester. Socketed U62 and tried with both donor chips, RDR has same error. Disappointing, but we continue.

p.s. I also verified the resistances across RN4.
 
VeryVon said:
I pulled U62, and two LS158's from the donor board. They all test out OK on the chip tester. Socketed U62 and tried with both donor chips, RDR has same error. Disappointing, but we continue.
p.s. I also verified the resistances across RN4.
Click to expand...
Hmm. I need to have a decent think about this (in amongst other stuff I'm doing). I will probably do my own capture.

While I'm doing that, a couple of suggestions:
- Remove the (known-good) RAM chips from bank 0, and see if that changes the capture.
- For the problem bits, add the 'address bus' version to the capture, i.e. verifying that the source address to U65 is correct. (Yes, you verified the address bus earlier, but is something else going on, e.g. bad code out of TEST ROM.)
 
modem7 said:
Hmm. I need to have a decent think about this (in amongst other stuff I'm doing). I will probably do my own capture.
Click to expand...
I wrote some code, then did a logic analyser capture. All as expected. I have added it all as TEST5067 at [here].

By chance, you didn't accidentally put the bad 74LS158 back in ?
 
Ran capture with TEST5067. Below is what I typically see with RAM in there. I still have to setup a test where I remove the RAM chips. I'm starting to feel like there's something electrically faulty in the ram bank, but close examination under the scope hasn't revealed anything obvious.

p.s. ADDR SEL, A0, A3, A8 & A11 are read directly off U62. I also checked the grounds and power on U62, looks ok.

READ55AA:
TEST5067-READ-55AA.JPG

READAA55:
TEST5067-READ-AA55.JPG
 
Consistently bad MA0 and MA3 outputs out of U62, with good corresponding address bus inputs.
- Known good U62 chip.
- RAM chips removed in case of some strange loading problem for U62.
- RN4 partially checked.
- PCB status unknown.
- Some confidence in power to U62.

Re my "RN4 partially checked." above. You didn't write that you ensured that all resistors were isolated from each other. Ideally, RN4 would be removed from circuit, and a multimeter used to verify that each resistor has infinite resistance (or maybe many megohms) to the other resistors.

So how about you just home in one anomaly, MA0. You have U62 socketed. In a capture, does MA0 behave as expected if you lift the U62 leg connected to MA0, and have the probe on the lifted leg? If so, the problem cause surely has to be something 'downstream' of U62.
 
Agree, good idea to home in on one thing at a time. I lifted leg 4 of U62 and put the MA0 grabber on there. Output looks correct in both cases, except it's inverted. The "noise" in RN3 also looks to have subsided. I can't help but recognize MA0 & MA3 are neighbors on RN4...

1705183977207.png

1705184025431.png
 
Ok, MA0 & MA3 are shorted together somewhere. Looking...

EDIT: most of the routing for these signals takes place on the top of the board. Afraid I might have to remove all the bank 0 sockets to see if it's under there.
 
Last edited:
VeryVon said:
Ok, MA0 & MA3 are shorted together somewhere. Looking...

EDIT: most of the routing for these signals takes place on the top of the board. Afraid I might have to remove all the bank 0 sockets to see if it's under there.
Click to expand...
Presumably, you removed RN4 to see if it was the problem cause.
 
You must log in or register to reply here.
Back
Top