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

[Ruud]

In other words, don't worry if your diag rom doesn't work on drastically-different clones.

I don't worry at all. I know it is more or less XT incompatible but what really really surprised me is that the test stopped at the third run. Still have to give the whole thing a good look but being human I have only one time line and in that time line not so much free time

 

[alecv]

Ruud Read a Private Mail please.

I'm trying to repair a dead XT clone (taiwanese XL-7 motherboard). I've replaced dead 2x74LS245 and one 74LS273 (a latch on hi addresses between CPU and ISA slot).
It starts your Test ROM but _hangs_ very early on the diagnostic Point 4. Seems it does something weird between Point 4 and Point 5 (Video initialization).
My video is a CGA clone (RY-3301, it works on the another good XL-7 clone board with the same Diagnostic ROM).
So motheroard can read end execute ROM and can output to diagnostic LED.

I have no idea how it could hangs, there is linear video initialization code there.

 

[Ruud]

Sorry, I often forget to check the PM. Will do that this evening.

 

[Shadow Lord]

Ruud,

Thank you for the superb work. I was wondering can you add serial video output to your code? What I mean by this is in a system w/o working video or noncompatible video one would connect a terminal to the serial port and be able to see the output that would normalky go to the screen? Thank you.

 

[Ruud]

Ruud Read a Private Mail please.

- please name a source file with name containing version i.e. diagrom-2019-03-05.zip I already have at least two 'diagrom.zip' files...
In this way you can see there is a new version. OK, I'll do that.

- There is no Version: header on the screen
I don't now when I added that but there is one now.

- CGA has only 16Kb of memory. I saw in comments: you are considering CGA has 32K. It's wrong.
Indeed that is wrong. But I only test the screen memory so no harm is done.

- DIP Switch on this XT displayed incorrectly. This XT clone has very generic schematic of the 8255 PIO.
I cannot check it now. In the past I used an Unitron board that did not have the standard dip switch settings. In the mean time I located some some Taiwanese clones. I will use one of them ASAP to test the DiagROM.

- I'm testing mb w/o keyboard and FDD. It hangs too long trying to read from non-existent floppy controller. (BIOS just reported about FDC absesnse)
I saw in your movie what you meant. I'll change the ROM so it won't try to read the floppy when the FDC test fails.

- After test it restarts too quickly! I can't read right half of screen.
Your movie shows that the screen is completely cleared and that is not supposed to happen at all. Could it be possible you are running a very old, may be even the first version? That was just to show what the idea was and a lot of things weren't working correctly.

- Test pass count not incremented
That should work. So I again think you are running the first version.

I found two bugs in the mean time:
- I forgot to remove some comment that disabled a loop. This loop is needed to test the refresh. But when it is present, the checking of the RAM takes "ages". So be prepared that the new ROM will be quite a bit slower, Sorry.
- I only tested the ROM with a MDA card. I just tested the ROM with the PCem emulator and saw that in CGA mode the dip switches aren't displayed at all. Weird, I'm sure it did so in the past. So back to the drawing board. (displaying something incorrectly is something else than not at all, IMHO)

I'll notify you all when I have a new version. Please give some days, I have a privat life and family as well.

 

[Ruud]

Thank you for the superb work.

Thank you very much!

I was wondering can you add serial video output to your code?

No, and I have three reasons for it:
- I'm not creating things just to please others. I created this ROM because I had a need for it and the Landmark ROM was not good enough IMHO. Your request is not in my interest and having not that much free time, I have to say no. But I hope to retire in about seven years. If you still need this feature, please ask me
- I output codes to various I/O ports, including LPT1. The outputted code should show you what the ROM is doing or where it stopped.
- You probably noticed the various counters. They are not stored in RAM because that is cleared and tested every time. Landmark kept track of the counters by reading and upgrading the numbers on the screen. I partly stole this idea: I use the video memory outside the actual screen memory. That means I have 96 bytes for storing the counters. When using the serial output, I think I can forget about the counters.

On the bright side: the sources are free so feel free to add this feature yourself. I don't mind helping you in some way if needed.

 

[alecv]

Ruud thank you for support.

Unfotunately my XT-clone motherboard is faulty. It hangs forever when I/O card trying to use IOCHRDY ISA signal.
My CGA card has slow DRAM so it uses IOCHRDY. Hence it hangs trying to clear video memory (between codepoints 4 and 5).
ADDRESS=B000h, DATA=20h, MEMW=Active

Motherboard does not hangs w/o CGA card. This CGA card works OK in the similar motherboard.
It's hardware fault. not a Test BIOS fault.

Schematic:
http://ixbt.photo/?id=photo:874739
seems DD44, DD32

 

[Ruud]

RuudIt hangs forever when I/O card trying to use IOCHRDY ISA signal. My CGA card has slow DRAM so it uses IOCHRDY. Hence it hangs trying to clear video memory (between codepoints 4 and 5).
...
Motherboard does not hangs w/o CGA card.

If a card sets IOCHRDY, the same card should also release it. In 1986 a friend and I built a card to measure EEG signals with a PC and we needed a delay. We used a 74LS393 counter that set IOCHRDY and released it after 8 clock cycles. For one or another reason your CGA card does not release IOCHRDY.

This CGA card works OK in the similar motherboard.

IMHO "similar" does not mean "the same". But it still sounds quite weird.

Schematic:

Unfortunately the image is too dense. Not understanding Russian and not having my wife at hand right now, I don't know if there is a link to download a better picture. And I also have no idea what you mean with DD44 and DD32 (ID of ICs, coordinates?).

I can advise you to use another (type of) video card but I think you would have if you had one.

 

[alecv]

Ruud Don't bother! I'm just telling it's not a (your) software problem!

Both my motherboards (semi-dead and working) are XL-7 Turbo, rather popular (and clonable ) Taiwanese Turbo XT.
Later Bulgarian Pravetz computer plant also have been producing this motherboard clone too.
Hence this board was popular in post-USSR Russia till early 1990-th.
You can find Hi-resolution schematic link below the image (see a 4704 x 3055 digits)
This schematic 99.5% matches original XL-7 Turbo and may be considered as clone-of-clone...
DD44 is a U44, a IC number.
Sorry for russian IC types we have to live in "bilingual" electronic environment here.
i.e. K555LA3 == 74LS00

Anyway, this hardware problem is not detectable by any sort of BIOS...

 

[Ruud]

Ruud Don't bother! I'm just telling it's not a (your) software problem!

I'm sorry if I raised that suspicion but I already understood that.

 

[Ruud]

OK, as I already mentioned in another thread I ran into bug in the memory test. In short: not all memory was tested. In fact, what ever value I chose, only 97 bytes were tested.

I corrected that error and ran into another weird thing: during the first run in PCem about 2 KB par second were tested. During the second it is only 1 KB/sec and I have no explanation for the change in speed (yet). FYI: I write a block of memory (CX = size) with a value, run a loop where CX = zero to make sure the DRAM must have been refreshed several times, and then check the value of each byet in the block against the original value.

Looking at the code I also noticed another thing: I use the values AAh and 55h to test the DRAM. Using only these values means I'm not changing the parity during the whole test. And that is not good IMHO. FYI: Landmark also only uses 55h and AAh. If I want a change of parity during the tests, it means I have to use at least four values like 00h, 54h, FFh and ABh. And that means that the test takes even longer.

Comments on this are more than welcome!

 

[Ruud]

An idea just popped up: until now I'm testing the memory in chunks of 1 KB. Why? It looks nice to see the progress of the counter, just like the memory test of various PCs. But I have this built in waiting for the refresh for every chunk of memory I test. The idea is:
- First test how much memory is present by testing the byte at 640 KB -1, 512 KB -1, 256 KB - 1, etc. until 16 KB -1. This is done with using four values and without waiting for the refresh or testing for parity.
- Fill and read the whole range with 00h and FFh for setting the parity DRAMs and then enable parity.
- Now fill the whole range wit a test value and wait a bit. Then check the range against the written value plus do a parity check.
IMHO this is much faster than the original test because we now wait only one times 'a bit' instead of 640 times. And because of this we can afford to wait a bit longer so that we can be absolutely sure that if we read the correct value, the refresh does work.

Please shoot

 

[chris_nh]

Hi Ruud, did you receive my message about the bug fix in dochecksum routine?

 

[Trixter]

- Now fill the whole range wit a test value and wait a bit. Then check the range against the written value plus do a parity check.

I'm not sure waiting is necessary; by the time you fill all of known RAM with test values, if there was a problem (stuck bits, DRAM refresh not working, etc.) it should be apparent by the time you get back to the beginning to read the test values... Unless you have one of the units with very high-quality DRAM that takes seconds to fade, in which case I would make a separate test for seeing if DRAM refresh is working. Having refresh testing being part of the memory testing makes the memory test take way too long.

Will you be open-sourcing your code any time soon, such as putting it on github and being receptive to contributions? I know you wrote earlier "This is just a free-time hobby" but it makes it much easier to contribute bugfixes, etc. when that structure is in place. There are many things I'd like to contribute (replacing speed-sensitive delays with universal ones, for example), but peacemeal comments in a forum makes it difficult.

 

[Shadow Lord]

On the bright side: the sources are free so feel free to add this feature yourself. I don't mind helping you in some way if needed.

Will you be open-sourcing your code any time soon, such as putting it on github and being receptive to contributions? I know you wrote earlier "This is just a free-time hobby" but it makes it much easier to contribute bugfixes, etc. when that structure is in place. There are many things I'd like to contribute (replacing speed-sensitive delays with universal ones, for example), but peacemeal comments in a forum makes it difficult.

I thought his code was already open source?

 

[Trixter]

Ruud has graciously made his code public, but if multiple people start sending him patches, all not working off the same codebase, it leads to trouble (and work) on his end. Online repos like github let people all work on their own features and later submit them for Ruud's approval with less issues at merge time.

 

[Shadow Lord]

Ruud has graciously made his code public, but if multiple people start sending him patches, all not working off the same codebase, it leads to trouble (and work) on his end. Online repos like github let people all work on their own features and later submit them for Ruud's approval with less issues at merge time.

I see what you mean. Well if others with more talent then I are making changes I still would love to see a serial terminal output for the ROM for when you can't get video to come up or you don't have the appropriate video card. :D

 

[Dwight Elvey]

If there is an issue with the refresh, it is good to wait. It is a typical test of DRAM. It is even a typical test for static RAM( but for a different problem ).
Dwight

 

[Ruud]

Hi Ruud, did you receive my message about the bug fix in dochecksum routine?

Sorry, I sometimes completely forget to check my PM box. I already answered your PMs.

For you and the others: I don't mind you emailing me regarding the Diagnostic ROM using my email address that you can find on my site.

 

[Ruud]

Hallo allemaal,

Will you be open-sourcing your code any time soon, such as putting it on github and being receptive to contributions?

I have tried to put another project on Github but it didn't work the way I liked it. And it took a lot of time to handle things, and I don't have that much free time. So I decided to keep things in my own hand. Bug-fixes are always welcome. Other ideas are welcome as well, like Trixter's "replacing speed-sensitive delays with universal ones". But it will take time to implement them. Using Github would not change things IMHO: it would still take time to sort out things and to approve (or reject) them.

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".

FYI: I'll have holidays within two weeks time and then I have some decent time to check everything in peace. But send your ideas, code, bug-fixes and comments on forehand because I'm going to my parents-in-law in Poland and they don't have internet. But this also means I cannot check things on real hardware.

I hope to hear from you