LOADXTRT.COM results unreadable on cards with CGA snow
MobyGamer opened this issue · 3 comments
Because LOADXTRT runs completely from the video card, on cards that exhibit "snow", the amount of snow generated renders the test nearly unusable:
There is a split-second where the test "walks back" an on-screen pointer and that allows the results to be visible for a fraction of a second. After a few tries, I managed to capture that on video so that the test results could be read, but that isn't ideal.
I'd like to request that LOADXTRT.COM be modified so that, between passes, the program will pause execution in some way so that the results can be read on cards that suffer from CGA snow. Because any code running out of video RAM causes snow, and because the PIT and IRQ0 are guaranteed to be initialized prior to running LOADXTRT.COM, my suggestion is to use a sequence of 72 HLTs in a row to pause for roughly 4 seconds (72 x 18.2Hz ticks). This will run the least amount of code possible to produce the wait.
That's a pretty impressive amount of snow. I was certainly aware that running out of VRAM would cause a something of a blizzard on snowy CGA cards. But I understand different cards have different amounts of snow, and I hadn't really thought much about users wanting to run the DOS version with a CGA card. It was more for enabling use on EGA/VGA which have no snow, though I guess for most people it's more convenient than burning a ROM, and so tempting to use even on CGA.
Your idea of halting and waiting for the timer interrupt is interesting. As currently written, the tests are run with interrupts disabled (cli), because the RAM test immediately clobbers the interrupt vector table and the timer ISR that DOS provided (and of course because it doesn't assume DOS has ever been loaded). I wonder if there's a mode of the PIC or the interrupt mask that would wake the CPU from its HLT without dispatching to an interrupt routine, but I doubt it.
Failing that, I'd have to at least reinstate the timer interrupt vector and reimplement the interrupt service routine. The ISR running from VRAM would still make some snow 18 times per second, but it may be at least better than what you are experiencing. If that's still too snowy, the only solution I can see would be copying the delay function into the first 2K of RAM right above the IVT, and pointing the vector to that copy, so the CPU doesn't access VRAM during the pause.
It should be mentioned as well that all of this requires the first 2K of RAM to be error-free. But then, if someone's running LOADXTRT.COM on a system with RAM errors (especially page errors) in the first bank, all bets are basically off anyway, and they should really find a way to run from ROM as originally designed.
Currently, LOADXTRT.COM literally contains a bit-exact copy of the ROM (the assembly source just slurps in the compiled ROM file), copies it into VRAM, and starts it using an entry point that skips the hardware initialization. After that it doesn't know or care that it is running from VRAM instead of ROM. It would be possible to have some different setup specific to running in DOS, but as you can see it seems to be a bit more involved than just adding a delay.
All cards that have snow have the same amount of show as depicted in the photo; it's very all or nothing. However, if LOADXTRT is only meant for EGA/VGA systems, then a simple answer is "use the boot rom if you want less snow", and I can accept that. I just didn't have a way to use an eeprom on the system being tested. (By the way, it did find a marginal fault, so the test was helpful :-)
I didn't realize LOADXTRT clobbered the interrupt table, but in hindsight, of course it does, so unless you want to temporarily restore INT08 for the time it has to wait, that won't work.
You can mark this issue as "nice to have" but not in any way a priority. Just note for the future that there are a few clone systems out in the wild that suffer from CGA snow and also can't take a custom eeprom.
I do think that if we're able to make the option ROM behavior more robust, that could help in this situation. For instance, popping the ROM in a slot on, say, an 8-bit network card or one of the modern ISA ROM cards could for many people give a chance to launch the ROM.
In the case of CGA, where there is no video BIOS to initialize, there would be less reliance on the RAM before this ROM, running as an option ROM, has a chance to get started. If at some point I have some time to try to get the keyboard polling working properly at option ROM init time without using RAM/stack, that should further reduce the reliance on RAM in this scenario.
Thanks for your engagement and feedback on this project, Jim.