• Please review our updated Terms and Rules here

Ruud's Diagnostic ROM

I have released a new version of Ruud's Diagnostic ROM. It is now at version 4.2

Available at minuszerodegrees.net

Enhancement #1:

Most (not all) checkpoints are sent to the serial port at 3F8h. More information about that is at [here].

Enhancement #2:

If a RAM test fails, the shown breakdown of failing bits now has the following to the right: "<----- May or may not be RAM chips."

Removing something that was misleading

Now, if a RAM test fails, the parity bit is not shown unless the parity bit is determined to be at fault.
( That determination can only be made when all data bits are functional. )
 
I have released a new version of Ruud's Diagnostic ROM. It is now at version 4.3

Available at minuszerodegrees.net

Enhancement #1:

If you do not have a MDA video card nor CGA video card, Rudd's Diagnostic ROM will look for 4 KB of RAM at address A0000 (640 KB), and if found, use that for variables and the stack.
Additional information on this enhancement is in the 'Requirements' section of [here].

Enhancement #2:

All (not some, like in version 4.2) checkpoints are sent to the serial port at 3F8h, providing that you meet one of the the 'MDA video card or CGA video card or RAM at XXXXX, requirements.
 
@modem7

Happy New Year and thanks for the work you’re doing on Ruud’s Diagnostic ROM.

You might remember my misadventures from here:

Turns out that all those weird RAM problems were caused by a faulty 8284.

Anyway, I have to report a “bug” - I keep having the IRQ0 issue - the test passes without issue in the Landmark ROM but always fails in RDR. What might be causing this difference in behaviour? The board seems to work fine.

Thank you for your time.

Pics attached:
 

Attachments

  • IMG_2360.jpeg
    IMG_2360.jpeg
    483.6 KB · Views: 16
  • IMG_2361.jpeg
    IMG_2361.jpeg
    409.3 KB · Views: 16
jbenam said:
Happy New Year and thanks for the work you’re doing on Ruud’s Diagnostic ROM.
Click to expand...
Thanks, and Happy New Year to you to.

jbenam said:
Anyway, I have to report a “bug” - I keep having the IRQ0 issue - the test passes without issue in the Landmark ROM but always fails in RDR. What might be causing this difference in behaviour? The board seems to work fine.
Click to expand...
Coincidentally, a few weeks ago, I started to see this exact behaviour as well.

At the time, the 'sometimes misbehaves' clone MDA card I was using had become unusable. I switched to my Mini G7 card ([photo]). That's when the symptom appeared. Later, I changed a couple of chips on my clone MDA card, returned to using that, and lo and behold, symptom gone. Put the Mini G7 back in, symptom appears.

A week or so ago, I added the 'Mini G7' symptom to the 'Known bugs' section of the pages at [here].

My present hypothesis is that the controller chip on the Mini G7 is using some of the 'unused' video RAM for its own purposes, RAM that Ruud’s Diagnostic ROM (RDR) uses for variables and for a stack. Where the Supersoft/Landmark Diagnostic ROM (SLDR) differs, is that the equivalent test uses a byte in bank 0 as the interrupt indicator.

I should get back into investigating that. For example, the first experiment would be to modify the 'Checking interrupt IRQ0' test in RDR to have the identical code that SLDR uses.

What video card are you using?
 
modem7 said:
Thanks, and Happy New Year to you to.


Coincidentally, a few weeks ago, I started to see this exact behaviour as well.

At the time, the 'sometimes misbehaves' clone MDA card I was using had become unusable. I switched to my Mini G7 card ([photo]). That's when the symptom appeared. Later, I changed a couple of chips on my clone MDA card, returned to using that, and lo and behold, symptom gone. Put the Mini G7 back in, symptom appears.

A week or so ago, I added the 'Mini G7' symptom to the 'Known bugs' section of the pages at [here].

My present hypothesis is that the controller chip on the Mini G7 is using some of the 'unused' video RAM for its own purposes, RAM that Ruud’s Diagnostic ROM (RDR) uses for variables and for a stack. Where the Supersoft/Landmark Diagnostic ROM (SLDR) differs, is that the equivalent test uses a byte in bank 0 as the interrupt indicator.

I should get back into investigating that. For example, the first experiment would be to modify the 'Checking interrupt IRQ0' test in RDR to have the identical code that SLDR uses.

What video card are you using?
Click to expand...
I think my craptastic CGA clone card is based on the same “all in one” CGA chip. I use the one on the right - the left one produces a sync signal but no image.

I would also love to understand what the heck the jumpers do (I made the one on the right work by moving them blindly around), I wonder if you might know if there are docs for these cards flying around?

EDIT: I have now tested with my ATI Graphics Solution SR (which has somehow started churning out a purple image, and that's why it's out of the 8088 right now) and the same thing happens.
 

Attachments

  • IMG_2374.jpeg
    IMG_2374.jpeg
    451.1 KB · Views: 10
Last edited:
jbenam said:
I think my craptastic CGA clone card is based on the same “all in one” CGA chip. I use the one on the right - the left one produces a sync signal but no image.
Click to expand...
Yep. Looks pretty much like the same card to me. I'm guessing that the maker of the large chip included a 'suggested PCB layout' in the chip's data sheet.

jbenam said:
I would also love to understand what the heck the jumpers do (I made the one on the right work by moving them blindly around), I wonder if you might know if there are docs for these cards flying around?
Click to expand...
The 'Users Operation Manual' for my Mini G7 card is at [here].
( The Mini G7 can be configured for MDA, Hercules, and CGA. )

jbenam said:
EDIT: I have now tested with my ATI Graphics Solution SR (which has somehow started churning out a purple image, and that's why it's out of the 8088 right now) and the same thing happens.
Click to expand...
Hmm.
 
modem7 said:
I should get back into investigating that. For example, the first experiment would be to modify the 'Checking interrupt IRQ0' test in RDR to have the identical code that SLDR uses.
Click to expand...
I modified RDR 4.3, the ISR recorder now being stored in low motherboard RAM, instead of in the 'unused' portion of MDA/CGA video RAM. That is valid because all use of the ISR recorder happens after low motherboard RAM has been tested.

Now, the 'Checking interrupt IRQ0' test no longer fails when I use my Mini G7 video card.

I have DM'ed the modified RDR 4.3 to you. The version shows as '4.4 test'. Does that fix the problem for you as well ?
 
modem7 said:
I modified RDR 4.3, the ISR recorder now being stored in low motherboard RAM, instead of in the 'unused' portion of MDA/CGA video RAM. That is valid because all use of the ISR recorder happens after low motherboard RAM has been tested.

Now, the 'Checking interrupt IRQ0' test no longer fails when I use my Mini G7 video card.

I have DM'ed the modified RDR 4.3 to you. The version shows as '4.4 test'. Does that fix the problem for you as well ?
Click to expand...
Thank you for sending me the test version - just tried it, my EPROM took something like one hour to fully erase.

Seems like 4.4 did the trick - it failed twice, but on most passes it has worked well.

Actually I can see that the 8253 test failed once or twice as well so it might have something to do with that?
 
jbenam said:
my EPROM took something like one hour to fully erase.
Click to expand...
Make sure the window is perfectly clean when erasing, It could be your Eraser, Getting old ??, Have you tried another Eprom ?
 
jbenam said:
Seems like 4.4 did the trick - it failed twice, but on most passes it has worked well.
Actually I can see that the 8253 test failed once or twice as well so it might have something to do with that?
Click to expand...
Do you see the same behaviour when you de-turbo the clone motherboard to 4.77 MHz operation ?
 
Malc said:
Make sure the window is perfectly clean when erasing, It could be your Eraser, Getting old ??, Have you tried another Eprom ?
Click to expand...
I usually clean the window before erasing - 99.99% of the EPROM actually erased in 5 minutes or so, but there was a stuck byte (EF) which took another 55 :-D

modem7 said:
Do you see the same behaviour when you de-turbo the clone motherboard to 4.77 MHz operation ?
Click to expand...
So it turns out I had a partially borked 8288. After changing it everything went smoothly (did 20 rounds and only got the IRQ0 error once) but… it didn’t end there. I usually switch back and forth between Anonymous’ XT Turbo Bios (the one on phatcode.net) and GLaBIOS (pretty nice!) and I found out that the floppy drive didn’t read anything at all under the Anonymous XT Turbo BIOS, while it worked fine under GLaBIOS but only in 4.77MHz mode, while in turbo it gave the same issue as the other BIOS.

But I *could* remember it working, and why would it work under a BIOS and not on the other one? So I started looking on Vcfed and found a post by Ruud that advised checking the 8237. After swapping it, Anonymous’ XT Turbo BIOS started trying to boot the drive (but failed in turbo mode, while it kinda worked in 4.77MHz) and the drive also started working fine in turbo mode under GLaBIOS, which was something it didn’t before.

So, if I had a partially broken 8237, why didn’t anything show up in RDR’s? Some weird edge case?
 
I have released a new version of Ruud's Diagnostic ROM. It is now at version 4.5

Available at minuszerodegrees.net

Bug fix #1:

I had introduced a bug in version 4.4 - the addresses shown in the bottom-right corner were incorrect.

{ 'Check addresses shown in the bottom-right corner' now added to my RDR test list. }

Bug fix #2:

At some point in the past, I had introduced a bug that affected the ability of RDR to reset the keyboard on certain PC and XT clones (e.g. Amstrad PC1640).

Bug fix #3:

Affected the Amstrad PC1640 (but not the IBM 5150 nor 5160). When I made bug fix #2, it was discovered that if the 'keyboard reset' test passed, the 'stuck key' test was then skipped (showing as 'N/A').

Fixed by using a RAM location, not the CPU's BP register, to hold the flag that indicates whether or not the 'keyboard reset' test passed.
An 8086 peculiarity, or bug, or what ???
 
modem7 said:
Fixed by using a RAM location, not the CPU's BP register, to hold the flag that indicates whether or not the 'keyboard reset' test passed.
An 8086 peculiarity, or bug, or what ???
Click to expand...
The INT 10h of some BIOSes doesn't handle register BP well i.e. it is not saved before and thus not restored after being used by the interrupt. Source: I don't know anymore. But it is reliable because I ran into this problem as well.
 
Ruud said:
The INT 10h of some BIOSes doesn't handle register BP well i.e. it is not saved before and thus not restored after being used by the interrupt. Source: I don't know anymore. But it is reliable because I ran into this problem as well.
Click to expand...
But when the RDR ROM is in, the motherboard's BIOS ROM is out.
 
I recently added a 'PC and XT clones' option to the web page at [here]. (A page refresh in your web browser may be required.)

In the web page that the option displays, there is a 'Limitation: Clone compatibility' section, and that section contains a link to a 'Some known compatibility/compatibility' table. That table shows that I own two clone motherboards where RDR version 4.5 is not working as expected, but the Supersoft/Landmark Diagnostic ROM is. So, some investigation is required of me.
 
"this clone motherboard" looks like a Juko ST4R, mentioned here at Vogons. I have that board and ran into that problem as well. I laid it apart for more research although the PC that contained the board worked well. But couldn't find the time/not important enough.
 
You must log in or register to reply here.
Back
Top