• Please review our updated Terms and Rules here

Ruud's diagnostic ROM for IBM PC, XT and compatibles

Ruud said:
An idea just popped up: ...
Click to expand...
A first result: 14 seconds. Much much faster than the first one. And I'm quite sure there is no bug :) No counter (yet) showing the progress.

Edit: hmmm, bummer: first pass goes fine, second pass halts here. That is, I waited at least 60 seconds. And now I am completely flabbergasted. But that's life :)
 
Last edited:
Ruud said:
A first result: 14 seconds. Much much faster than the first one. And I'm quite sure there is no bug :) No counter (yet) showing the progress.

Edit: hmmm, bummer: first pass goes fine, second pass halts here. That is, I waited at least 60 seconds. And now I am completely flabbergasted. But that's life :)
Click to expand...

Interrupts off and not depending on a stack?
Dwight
 
Ruud said:
Shadow Lords idea about using a serial output is very interesting. But then it is up to him to produce the code and afterwards we can see how we can combine my work with his, if he wants to. And I have no objection with him publishing the result under his own name, something like "Shadow Lord's Serial Diagnostic ROM, based on Ruud's Diagnostic ROM". :)
Click to expand...

If Shadow Lord had the technical capabilities to do this it would have already been done ;). Frankly, I am surprised it is not a standard feature in the testing BIOSes (and I don't mean just yours, but Land Mark, UltraX, etc. as well).
 
Ruud said:
Edit: hmmm, bummer: first pass goes fine, second pass halts here. That is, I waited at least 60 seconds. And now I am completely flabbergasted. But that's life :)
Click to expand...
Weird, at home things worked much better: first test goes fine second and later tests need about 35 seconds.

Dwight Elvey said:
Interrupts off and not depending on a stack?
Click to expand...
Just had a look at the source and added a CLI right after the label where the ROM restarts the loop. But unfortunately no change. The test is one big routine with no subroutines, so no stack needed.
And I forgot to mention, So far I only tested with the PCem emulator. Maybe the emulator is to blame but I cannot be sure until I have tested the ROM on real hardware.
 
Shadow Lord said:
If Shadow Lord had the technical capabilities to do this it would have already been done ;)
Click to expand...
I won't promise anything but I will have a look at it.

But I already can tell you on forehand that you will loose the various counters. I need RAM for saving the counters and during the testing of the various ICs the refresh is disabled, which will result in the loss of the information.
 
Ruud said:
I won't promise anything but I will have a look at it.

But I already can tell you on forehand that you will loose the various counters. I need RAM for saving the counters and during the testing of the various ICs the refresh is disabled, which will result in the loss of the information.
Click to expand...

I can live with that! :D I think it would be a nice option to have even with trade offs. If you can't get video going/get some sort of output there is no pint in having a counter that you can't see! Thanks for looking into it.
 
Just a random thought.
Perhaps run some first tests, then display for a 30 seconds. Then clear everything and start fresh with the next set of tests. Or something like that so you do not have to hold the data for later on?
 
My latest ZIP can be found here: www.baltissen.org/zip/diagrom.zip

What are the changes:
- If something goes wrong during the 2 KB test, offending address and the bad bits are shown.
- A complete new test for the rest of the RAM.

Instead of testing just 1 KB at the time I test the whole range in one go. I fill the whole range with a value, wait a bit so the refresh is tested at the same time and then check if the written value is still present. I do this with four different values. Reason: all the bits have to be tested AND the parity has to be tested. Two values, like 55h and 0AAh, won't work as in this case the parity won't change.

So far I have tested things only on the PCem emulator and I tested the main error situations by changes in the code. I will see if I find time to dig up my Taiwanese clone again. If possible, check the bin on an emulator or second best, on a working system so you have an idea how the main change, testing all the RAM, looks like. The advantage of a working system are that you can remove some DRAM modules to see how the Diagnostic ROM behaves when encountering an error.

I'm also working on a text with a detailed explanation the why of certain parts of the ROM how the parts work. During writing this text some more ideas popped up:
- Shadow Lord wants the output over the COM port because he has no MDA or CGA card (or just the monitors?). Anyway, IMHO he has to use a VGA or EGA card then. Although not supported by my ROM, the video RAM still should be accessible. I don't see any reason why it can be used by my ROM for the counters and, a second new idea, as stack.
- Just ocurred: would PCem support a way to see what is outputted to the COM port? I have to check the site and/ or forum.
- I made a dumb calculation error. The MDA card has 4096 bytes of RAM and only 4000 bytes are needed for the screen. I need 25 bytes for my counters and other stuff. This leaves me with still 71 free bytes. Why not use them as a Stack? That would spare me a lot of programming trouble.

Then a remark regarding testing the ROM using PCem. I already mentioned the fact that the second and further runs run as twice as slow as the original run. When testing things, most of the time I turn off the sound so that I don't bother anyone with the beeping. Now the sound was on and even the initial beep took twice as much time but at the same frequency. So far I have no explanation.

Have fun!
 
Last edited:
Ruud said:
- Shadow Lord wants the output over the COM port because he has no MDA or CGA card (or just the monitors?). Anyway, IMHO he has to use a VGA or EGA card then. Although not supported by my ROM, the video RAM still should be accessible. I don't see any reason why it can be used by my ROM for the counters and, a second new idea, as stack.
Click to expand...

Yes, any color card will present memory at b800h so a common VGA ISA card should work (if it's the variety that works in an 8-bit slot).
 
Hi Ruud!

I think the .bin file in the updated zip is still the old version? I compiled a fresh one from the source and burned to a ROM. I then was able to do a few test runs on some known good working 5150 motherboards:

PC 256k motherboard:
DSC00459.jpg

PC 64k motherboard:
DSC00461.jpg

Sorry for the blurry pics from the $1000 camera... BUT, you will notice that the ram tests show all bits failing, and the rom checksums fail. Both boards are good boards w/ basic roms installed, no problems. The ram test passes fine when I run in PCEM, but on the hardware it shows this. The test seems to run quickly as expected! Also to note, the first version of the rom had the same behavior showing all ram bits as bad.

Everything else seems to run OK for these simple test runs on known good hardware. Now I need to go break some boards so I can test it on bad hardware ;) Thanks Ruud!
 
AND, one more test run on a 256k XT 5160 motherboard:
DSC00462.jpg

Rom checksums pass on the XT board, but the RAM bits still show as failed.
 
Ruud said:
- Shadow Lord wants the output over the COM port because he has no MDA or CGA card (or just the monitors?). Anyway, IMHO he has to use a VGA or EGA card then. Although not supported by my ROM, the video RAM still should be accessible. I don't see any reason why it can be used by my ROM for the counters and, a second new idea, as stack.
- Just ocurred: would PCem support a way to see what is outputted to the COM port? I have to check the site and/ or forum.
Click to expand...

Hi,

Except that is not why I requested it. In my latest "bang my head against the wall episode" I was trying to track to see why my G2K 80386SX wouldn't boot. The system had a the original VGA card in it that had been working without issues since the computer came out of the factory. However, I was no longer getting any output on the screen at all - just a long tone out of the speaker. I tried another (known good) VGA card and that one only worked intermittently and in the incorrect video modes. I have a set of UltraX diagnostic BIOSes and even with these in place I could not get an output from the video card. Turned out the problem was occurring before video was even being initialized so having had MDA, CGA, EGA, or VGA card in there would not have helped me see anything on the screen. This kind of situation is mainly why I am asking for the serial/terminal out as well as the already hypothesized missing/lacking proper video card/monitor or non-working video card (although I guess if it POSTs you get the beep and know the computer is good).
 
Ruud said:
I won't promise anything but I will have a look at it.

But I already can tell you on forehand that you will loose the various counters. I need RAM for saving the counters and during the testing of the various ICs the refresh is disabled, which will result in the loss of the information.
Click to expand...

You realize that if you access your needed data, at least, every 2 msecs you'll be refreshing it. Even if your running some other test, as long as you read your needed data, periodically, you can run your test without loosing data and have the refresh turned off. You do need to choose your memory location as you need to know if your are doing Row or Col refresh, if you are specifically doing a RAM test for retention. You might be refreshing location you were intending to test for retention.
Dwight
 
I uploaded the 2019-07-23 version and the 2019-03-10 version with names that should make clear what is what. Both versions is including the source codes for NASM. So if it doesn't work for you for whatever reason feel free to change and compile it.
I'm sorry but I'm busy with a renovation and things that affect hardware is a no-no at this moment.
 
Ruud said:
I uploaded the 2019-07-23 version and the 2019-03-10 version with names that should make clear what is what. Both versions is including the source codes for NASM. So if it doesn't work for you for whatever reason feel free to change and compile it.
I'm sorry but I'm busy with a renovation and things that affect hardware is a no-no at this moment.
Click to expand...
Hello @Ruud
thank you, ok, I will try the source code, can you share please your script that compile the source code and then copy the compiled file to the emulator?
 
Last edited:
You must log in or register to reply here.
Back
Top