• Please review our updated Terms and Rules here

Memory Test Programming

cr1901

Veteran Member
Joined
Dec 28, 2011
Messages
817
Location
NJ
Hello everyone, I'm here again to ask what's probably a question with a simple answer :D!

I decided to run my 5150 today to check its health after a month or so of disuse, since I haven't been able to give it the love it deserves. Everything checks out (and the RTC hasn't lost nearly any time at all in the past 2 months o.0;), but while I was running CHECKIT's memory test, something dawned on me...

CHECKIT gives you the option to test all regions of conventional memory, and allocates a buffer to store data so MS-DOS data structures, device drivers and the IVT are not overwritten. I can understand moving the data back to it's correct location immediately after testing locations, but I don't understand how such a program can deal with hardware interrupts. I thought overwriting the IVT implies that all interrupts must be disabled, including (especially) the system timer. However I have a TSR screensaver which hooks the system timer, and it works properly even during the memory test (which takes longer than 10 minutes, the delay before the screensaver activates).

What I expect to work (disable interrupts) and what does work (interrupts are not disabled) contradict each other. Am I understanding this right, or am I missing something? On that note, how would I go about programming a memory test (psuedocode?) without completely trashing MS-DOS?
 
Last edited:
I can think of several approaches to this. One is to disable and test the interrupts one by one, re-enabling them after testing.

Or, one can disable all interrupts, then poll for an interrupt request and perform the appropriate long CALL.

Or, one can relocate the IVT to a different area (recall that the device only controls the bottom 3 bits of the generated INT instruction, the remainder of the 8 bit interrupt number is controlled by 8259 programming.

Take your pick.
 
The third one, though overkill, seems appealing if only as an exercise in programming the raw hardware... however, if my routine calls a software interrupt (say, a call to DOS or the Hard Disk Services, as an example- I know that's a bad idea, but just for the sake of illustration) while testing the non-hardware interrupts in the IVT, this will still cause DOS to die a painful death, correct? Additionally, the 8088 always looks for the IVT in the first kB of memory, if I remember correctly...
 
I'm thinking at this point that the memory test code might only affect interrupt 9, just to keep the timer events kosher (and by inference, interrupt 1C). It could be that this is the only interrupt service that's preserved. That would certainly simplify the job--and account for your screen saver being operational.
 
I can't believe I never replied to this- I guess I'm forgetful in my old age lmao!

I'm going to assume you meant Interrupt 8h? Interrupt 9h is the keyboard :p.

Interrupt 9h might also be preserved, because the test can be interrupted by pressing ESC, though CHECKIT might not respond immediately...
 
If I were writing such a test, I'd just mask everything disabled in the hardware PIC, CLI just for good measure, do my testing, then STI and put back whatever the PIC had configured before I started. Seems pretty straightforward, with the exception of making sure that all memory tests read/wrote at least 256 consecutive bytes so that DRAM stays refreshed (since you're disabling the DRAM refresh mechanism when you mask off everything in the PIC).

Yes, you'd lose some seconds/minutes in the DOS date/time, and maybe if you had a device that needed routine wakeup (mouse, network) it might die, but overall the system would run just fine. (And you're supposed to run utils like CheckIT on a clean boot anyway, so if that happens it's kind-of your fault)
 
Disabling the PIC won't disable DRAM refresh - only the PIT (timer 1) and DMA are needed for refresh to work.
 
Back
Top