Ruud's Diagnostic ROM

[modem7]

"this clone motherboard" looks like a Juko ST4R, ...

I have it listed [here] in the 'Motherboard: Unbranded XT clone (CPU: V20 @ 12 MHz)' entry. A variation has 1 MB of RAM fitted.

I have that board and ran into that problem as well.

It seems to me that the RAM tests of RDR are taking longer than expected to execute. It might be that there's a wait state happening for RAM access. That could be a distraction.

But the Supersoft/Landmark Diagnostic ROM (SLDR) passes the INT0 test, and when I compare the source code of INT0 test in RDR to that in SLDR, the same timeouts are used. So that it where I need to focus my research: why is it passing in SLDR. Low priority.

 

[modem7]

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

Available at minuszerodegrees.net

Bug fix #1:

Symptom: The first few bytes sent to the serial port sometimes displayed as strange characters on the serial terminal.

Enhancement #1

Background: During certain RAM tests, an address is shown in the bottom right corner of the screen, in two different formats. E.g. "04800:0000 = 48000"
Enhancement: I added a third format, which is the address as a KB figure. E.g. "04800:0000 = 48000 = 288 KB"

 

[modem7]

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

Available at minuszerodegrees.net

Enhancement #1

When a critical error is encountered, the diagnostic sends a hash to COM1 before the CPU is halted.
Per the example shown at [here].

 

[modem7]

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

Available at minuszerodegrees.net

Bug fix #1

Version 4.0 introduced the following problem.

If the IBM made MDA card ('IBM Monochrome Display and Printer Adapter') is used:
• No output to screen.
• No short-long-short sequence of beeps at start-up.
• Serial output reveals that the diagnostic starts, but stops after checkpoint 00 is issued.
• If the IBM MDA card is removed, the diagnostic does not stop at checkpoint 00.
• A third party MDA card of mine does not show this symptom.

Bug found to be in versions 4.0 through 4.7

Bug fixed. Current version is now 4.8

 

[Ruud]

And what was the problem? AFAIR I always used a third party MDA card so I never encountered the bug.

I just checked my old sources and outputting 00 is the first thing RDR does at a reset, after executing CLI. So I really, really wonder.

 

[modem7]

I just checked my old sources and outputting 00 is the first thing RDR does at a reset, after executing CLI. So I really, really wonder.

But those are old source code. Per [here], since version 3.3, RDR has outputted checkpoint 33h as the first step. And in the current version, 4.8, there is a new first step.

And what was the problem? AFAIR I always used a third party MDA card so I never encountered the bug.

Even if you were using an IBM MDA card at the time, you would not have experienced the problem, because the bug was introduced in version 4 of RDR.

As for the fix, see post #36 at [here]. After writing that, I realised that there is more to the timing of where the '1 to CRT control port' code is put, i.e. version 3.9 does not have the problem, and 3.9 sends 33h to the IBM MDA's parallel port before the 6845 controller chip's data registers get populated. And it doesn't sound right to me that the IBM MDA's parallel port would be in scope of the '1 to CRT control port before other interaction with the card' requirement. More research required (out of curiosity).

BTW. The 'PC System Programming' book refers to the requirement, but unlike IBM's documentation, does not imply that it needs to be the first step in the card's initialisation.

 

[Ruud]

Thank you for the explanation!

 

[modem7]

Thank you for the explanation!

I did observe that the IBM CGA card was unaffected.

I see in the Supersoft/Landmark Diagnostic ROM (SLDR) code, that the '1 to CRT control port before population of 6845 controller chips data registers' is done for both MDA and CGA. For CGA, is that the SLDR author 'playing safe'? Perhaps I will do the same in the next version of RDR (I like to play safe.)