• Please review our updated Terms and Rules here

Ruud's Diagnostic ROM

( I have only looked at parts of the source code for the SuperSoft/Landmark ROM. I wonder what it is doing video wise. And for that matter, where it stores variables, and when does it start using the variables. )
It initializes both MDA and CGA. I completely skipped looking at the EGA part. It writes text, etc. to both screens. And it does not use variables. This sound weird but it doesn't. Then what about the various counters? The only thing it does is to increase them, or not. And it is doing that by reading the ASCII values out from the existing video memory, increase the number, and write that number back as ASCII again. It also will read nonsense from the not existing video memory, calculate a absurd number and write it back to that not existing memory and nobody will see it.
Hmmm, never thought about this: what about placing a MDA and CGA in a computer?

Do you have my disassembly of the Landmark ROM?
 
I replaced the processor but it didn't change anything.
But yesterday I received a package with a batch of SN74LS244N chips and I replaced U14 again.
The situation has improved significantly :)
TEST6077 returns only 11
Ruud's Diagnostic ROM starts and stops at Check first 2 KB of RAM. Displays code 2A AA

I'm not going to give up :)
 
I replaced the processor but it didn't change anything.
But yesterday I received a package with a batch of SN74LS244N chips and I replaced U14 again.
The situation has improved significantly :)
TEST6077 returns only 11
That is very good news.

Ruud's Diagnostic ROM starts and stops at Check first 2 KB of RAM.
We are back to where we were at post #44 - a failure of the test of the first 2K of RAM.
What bits are showing as faulty ([example]) ?
And below that, the address-at-fault will be displayed. What is it ?

Displays code 2A AA
Not important. Per the list at [here], on the parallel/LPT reader device, the 2A means that the test of the first 2K of RAM started, and the AA means that the test failed. We already know that from what is appearing on-screen.
 
Hmmm, never thought about this: what about placing a MDA and CGA in a computer?
No, because I cannot see any benefit.

Do you have my disassembly of the Landmark ROM?
No. I used a commenting disassembler (Sourcer) to create a list file. That was enough for me to see the bits that I wanted to see.

If I may suggest: maybe It is better to initialize both boards and to display anything in the first one-time part and to continue in the loop with that board whose memory you found.
It sounds like the way to go. I will put some thought into it.
Yes, I definitely think that is the way to go. And it means that the pre-loop tests of the CPU, and RDR checksum, can go.

Something else to consider is removing the dependence on video RAM for variable storage. The check of the first 2 KB of RAM could be made thorough, i.e. data + address + refresh, and if that test passes, part of the 2 KB used for variables and the stack. That will be an enabler for no-MDA-CGA-video-card operation (e.g. for those who do not have that type of video card), but such operation would require enhancement of the codes sent to the parallel/LPT reader, e.g. for a RAM error, the bit pattern and address.
 
All 8 bits are marked with X and the parity bit is marked with 0
Failure address: 0 KB (00000)
Of interest, back at post #19, the 'Check first 2 KB of RAM' test was passing, and the failure was the 'Testing RAM - Address' one.
But now, you are seeing a failure that affects the RAM subsystem.

I am assuming that you have RAM bank 0 populated, and the bank 0 chips are in the correct orientation, and the other banks are not populated.

This will not be a RAM refresh problem.

You have a logic probe, but not a logic analyser.

After Ruud's diagnostic ROM displays the error, using your logic probe, do you see activity on:
- the eight address pins (A0 through A7);
- the /RAS pin.

1695713371347.png
 
After Ruud's diagnostic ROM displays the error, using your logic probe, do you see activity on:
- the eight address pins (A0 through A7);
- the /RAS pin.
A0 – High
A2 – High
A1 - Pulse
A7 - Pulse
A5 - Pulse
A4 - High
A3 - Pulse
A6 - High
RAS - Pulse
 
After Ruud's diagnostic ROM displays the error, using your logic probe, do you see activity on:
- the eight address pins (A0 through A7);
- the /RAS pin.
A0 – High
A2 – High
A1 - Pulse
A7 - Pulse
A5 - Pulse
A4 - High
A3 - Pulse
A6 - High
RAS - Pulse
There is a problem. All address pins should show activity. Why? Because the RAM refresh mechanism is still running in the background.

Half have no activity: A0 A2 A4 A6
If you look at the partial circuit diagram below, those four are from chip U39.

1696475913960.png
 
I replaced the U39 chip with other chips but it didn't change anything
 
I replaced the U39 chip with other chips but it didn't change anything
And the replacement chip was tested elsewhere to prove functionally ?
Are you positive about your soldering ?

Refer to the diagram in the previous post. Let's pick one of the failing address lines, A2:

After the 'Check first 2 KB of RAM' test fails, we expect the A2 pin on the bank 0 chips to be active. You do not see activity. That pin connects, via resistor network RN3, to the Y2 pin of U39.

U39, a 74LS158, contains four switches.
The Y2 pin is part of switch #2:
- Switch #2 output is pin 2Y.
- Switch #2 inputs are pins 2A and 2B and S.
- The S pin controls whether it is pin 2A or 2B that goes to pin 2Y (inverted on the way).
- The G pin is grounded, and so U39 is permanently enabled.

Step 1.
Is the Y2 pin of U39 active? If active, there is a problem between the Y2 pin and the A2 pin of the bank 0 RAM chips. If inactive, go to step 2.

Step 2.
{Y2 pin of U39 is inactive.}
The 2A and 2B pins of U39 are both expected to be active.
If both active, either U39 is faulty, or the G pin of U39 has lost its grounding, or there is no +5V getting to U39, or a combination of those.

( Note that the state of the S pin is irrelevant, because both 2A and 2B are expected to be active - one of those two will be switched through to Y2. )
 
Hi,
I also have a serious problem with my 5150 board, 16-64k version. As you know, it's the rare first version but I don't have any spare parts.
My PC was running idle in DOS when suddenly PARITY CHECK 1 appeared on the screen and the system hung. After reboot there was no response at all, no beep and nothing on the screen. At this time I had a RAM expansion card installed, so I had full 640kB available that ran quite stable until then.
I removed all cards but the Hercules card and set the jumpers to "only bank 0 populated", 16k. I replaced the BIOS with Ruud's Diagnostic ROM 4.0 and that at least brought the monitor to live again. The tests passed until "Testing RAM - Address FAILED". Failure at address: 15 KB (exactly 03FBC). After that I removed all other RAM chips, no difference. I reseated several chips without any difference.
I checked some, but not all address lines with an oscilloscope and at least on all that I tested I got some signals. I'm afraid I'm not very good in electronics.
Could you please advise what I can test next?
Thanks a lot!
 

Attachments

  • IMG_20231023_180553.jpg
    IMG_20231023_180553.jpg
    1.8 MB · Views: 13
Why don't you start a new thread?
I think it would be beneficial.
Yes, I don't know why people think that they need to 'hijack' a thread in order to get attention. This thread has now been hijacked twice.

I wonder if the mods have tools to rectify the situation. (I.e. select the post then choose 'Create new thread', specifying target forum and thread title. Notification of moved post to post author.)

Could you please advise what I can test next?
Based on all that you wrote, I suspect that one of the RAM chips in bank 0 has failed (failed in a way that affects addressing, not data). Of course, a right pain on an IBM 5150 motherboard, because all chips in bank 0 are soldered in. Are you in a position to remove all chips in bank 0, put in IC sockets, then plug in a new set of RAM chips (e.g. those from the other banks) ?

I will look into enhancing the 'Testing RAM - Address' test in Ruud's Diagnostic ROM, with the aim to provide additional information that may assist identification of which RAM chip (assumption: faulty RAM chip) is at fault.

I'm afraid I'm not very good in electronics.
If that includes soldering, then perhaps wait until I enhance Ruud's Diagnostic ROM.

( I am presently enhancing Ruud's Diagnostic ROM by adding a 'Testing RAM - Slow refresh' test - code added, testing outstanding. )
 
I have released a new version of Ruud's Diagnostic ROM. It is now at version 4.1

Available at minuszerodegrees.net

Enhancement #1:

I added a new test: 'TESTING RAM - SLOW REFRESH'.
This is the same as the slow refresh test in the Supersoft/Landmark Diagnostic ROM (SLDR).
The slow refresh test seems to be a bit of a: Show any RAM chip 'weaklings' (weak at holding charge). Within spec, but they could be a problem cause.

Enhancement #2:

If the 'TESTING RAM - ADDRESS' test fails, in addition to the failing address, also now displayed is the bit error pattern.
The bit error pattern is expected to reveal the faulty RAM chip, as confirmed by limited testing by me.
Presently, the bit error pattern is shown as a hex number, but I will probably later change the presentation to that shown by the main RAM test.
Example of presentation in version 4.1:

Failure at address: 15 KB (exactly 03F7C [hex])
Bit error pattern: 08 (hex)


80 = bit 7
40 = bit 6
20 = bit 5
10 = bit 4
08 = bit 3
04 = bit 2
02 = bit 1
01 = bit 0
 
Last edited:
I'm afraid I'm not very good in electronics.
If that includes soldering, then perhaps wait until I enhance Ruud's Diagnostic ROM.
Per my previous post, if you use the new version (4.1) of Ruud's Diagnostic ROM, a bit error pattern will now be shown.
If the bit error pattern is not one of the following eight bytes, let me know.

80 = bit 7
40 = bit 6
20 = bit 5
10 = bit 4
08 = bit 3
04 = bit 2
02 = bit 1
01 = bit 0

( You may even see a word, e.g. 02F4 )
 
Hi,
Yes, I don't know why people think that they need to 'hijack' a thread in order to get attention. This thread has now been hijacked twice.
I'm sorry interrupted the old thread. Since I googled for the error message and this thread was the only related thing that I found I thought it would be appropriate. I apologize if I was wrong.

Thank you for investigating on this issue. I will download the new ROM and test it like you said. If I need any further help I will start a new thread.
Best regards
 
Thank you for investigating on this issue. I will download the new ROM and test it like you said. If I need any further help I will start a new thread.
Okay. If you see one of those eight bytes, then it is sure to be a RAM chip that failed. Anything else would suggest a different cause.

I have added the motherboard failure to the list at [here].
 
Back
Top