• Please review our updated Terms and Rules here

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

VeryVon said:
When running test 5066 shouldn't we see some RAM refresh on RAS?
Click to expand...
No.

RAM refresh is something that needs to be initiated via code. It's one of the things that the IBM POST does. The RAM refresh mechanism only needs to be initiated if values are to be stored in dynamic RAM, and then those values read back (undamaged) after quite a delay. TEST5066 does not do that, and so there was no need for me to put 'Initialise RAM refresh mechanism' code into TEST5066.

Even the following does not need RAM refresh to be initialised. Why. Because the act of reading address 0 refreshes address 0.
1. Write AA to address 0.
2. Read address 0, verifying that contents are AA.
3. Jump to 2. (2, not 1)
 
VeryVon said:
Should we look into the address multiplexing logic now?
Click to expand...
Yes, because you have an addressing problem,and you are now satisfied that the address bus is fully functional.

VeryVon said:
EDIT: Ok yea, let's go back to [TEST5060]
Click to expand...
Note the following, part of the capture PNG file within TEST5060.ZIP

1704751523011.png
So TEST5060, as written, does not test the address multiplexing.

You need to modify the test motherboard address used from 0 to something that:
- Is still within the bank 0 range of addresses (so you know which bank to put the probes on), and
- Results in a row address that is different to the column address (something that you will see in the capture).

Ideally, a motherboard address that results in ROW=55h, COLUMN=AAh

Then change the address so that the opposite happens: ROW=AAh, COLUMN=55h
 
modem7 said:
You need to modify the test motherboard address used from 0 to something that:
- Is still within the bank 0 range of addresses (so you know which bank to put the probes on), and
- Results in a row address that is different to the column address (something that you will see in the capture).
Click to expand...
I decided to create a diagram - see [here].
 
I setup for 5060 capture. What I noticed is positioning the grabbers on the RAM chips is touchy to get right (now I verify conductivity and check for shorts with the multimeter.)

RAS appears to be stuck high. I verified this with the logic probe. I could have sworn we had activity before.

1704846971345.png
 
VeryVon said:
Ok perfect. If I trace that back, I see a RAS pulse at U81 pin 2, but DACK 0 is always low.
Click to expand...
DACK 0 is part of RAM refresh.
For the RDR ROM, the RAM refresh mechanism does not get initialised completely until step 55 at [here].
For the TEST5060 ROM, the RAM refresh mechanism is never initialised.

There are two types of /RAS:
- Those, where one happens every approx. 15 us, as part of RAM refresh; and
- Those that happen when RAM is read or written - kind of a 'normal' /RAS.

With the TEST5060 ROM in, and the target address being somewhere in bank 0, then you are expecting to see 'normal' /RAS directed to bank 0.
The RAS pulses will pass from pin U65-6 to pin U65-11 when all of the following are true:
- Pin U65-4 (DACK 0) is LOW. (I.e. a DMA refresh cycle in not in progress.); and
- Pin U65-5 (/ RAM ADDR SEL) is LOW. (I.e. Asserted to indicate a motherboard RAM address.); and
- Pin U65-1 (A16) and U65-2 (A17) are both LOW. (I.e. A motherboard RAM address somewhere in bank 0.)
 
Ok so I ran a capture on that chip. Looks like we have a condition that matches passing a pulse, but none is there. I do have a known good LS138 here, I tried the piggy-back technique, but no change.

I measured the resistance between U65-11 and VCC, the resistance is in the mega-ohms.

1704927786112.png
 
Last edited:
VeryVon said:
I do have a known good LS138 here, I tried the piggy-back technique, but no change.
Click to expand...
There are never any guarantees with that technique.
At the time when /RAS is expected, a tug-of-war could be happening on pin 11 between the soldered and piggybacking U65, with the soldered U65 winning the tug-of-war.
 
Ok, the good news is we have RAS now. The bad news is we're back to where we started with the same exact address error in RDR. I'll continue with TEST5060.

1704933668895.png
 
Grabbers re-attached for TEST5060. So far so good with the stock test (shown below.) Now I'm going to modify the 5060 asm to use address 055AAh to test ROW=55h, COLUMN=AAh.

I'm assuming I just have to change line 72:
from: mov dx,0
to: mov dx,55AAh
?

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