Re: How to debug inside the BIOS and/or interrupt?
- From: Ed Beroset <spamtrap@xxxxxxxxxx>
- Date: Sat, 07 Jul 2007 15:21:44 GMT
Jim Leonard wrote:
How can I debug this sort of thing? I've tried to break the operation
of the program when it hangs in both D86 and Turbo Debugger, but being
on the 8088 there's no hardware virtualization and the machine does
not respond to my keypress. How did people debug interrupt handlers,
BIOS functions, etc. "back in the day"?
I'm not sure I can help with your specific code problem but if the program works when you read only one chunk of data at a time from disk, but locks up after a while if you read multiple chunks, then probably one of two things is happening -- some memory is being corrupted (you mentioned a shared memory allocation piece) or an interrupt is taking too long somewhere. If you have an oscilloscope, one nice way to debug interrupt problems on such hardware is to modify your interrupt routine so that it toggles a pin that you can look at with a 'scope. When I did such stuff, the printer port was often most convenient. Set a line "high" when you enter the interrupt and set it "low" when leaving. Then you can look at a 'scope trace on that pin to see exactly how long the interrupt takes. Extending that, you can have multiple pins and multiple interrupts.
Another technique is to do something like a C "assert." The way that works in C is that you write something like "assert (count <= MAX_COUNT);" and that line of code will then verify that the expression is true. If it is, then the code proceeds as normal. If it isn't, then in the traditional C model it would execute a macro which writes the name of the source file and the line number and calls the abort() function. That's usually not wise to attempt within an interrupt but you can simulate such a thing by doing something like writing to a fixed, preallocated error log in memory, or to a hardware register. Again you might find the printer port convenient for this, or if you have at least an EGA compatible display on your hardware, you can do things like change the background color of the screen by writing to the overcan register (naturally this assumes you have a CRT and not an LCD). If you just have one or two asserts, you can write to the keyboard's LED register and change, say, the NUMLOCK and CAPSLOCK LEDs. Another hardware-oriented technique, common among BIOS writers some years ago, was to send hex byte to i/o port 80h. A plug-in hardware card then decoded that address and displayed the hex byte on two 7-segment LED displays on the card. If you happen to have such a card (they were often sold as "BIOS diagnostic cards" in the 80's and 90's) or could get one or build one, that's a convenient method. Unlike the parallel port address, which requires that you load the dx register with the address of the port and then do an out dx,al instruction, the 80h address can be used in one step as out 80h, al, saving a few bytes, a few cycles, and most importantly, the need to preserve and restore the dx register.
So to put this together, let's say that you want to assure that the DMA is never already in progress when IRQ 2 starts being serviced. You can write a little code to check for that condition at the start of the interrupt, and if it is true, change the background color of the display to red. When the machine locks up, just check the color of the screen. If it's the normal black color, you'll know that your "assert" didn't fire and you need to hunt elsewhere. If it's red, you'll have found your culprit and you can dig deeper to figure out why and what to do about it.
Hope that helps.
Ed
.
- Follow-Ups:
- Re: How to debug inside the BIOS and/or interrupt?
- From: Jim Leonard
- Re: How to debug inside the BIOS and/or interrupt?
- Prev by Date: Re: *** When 4G DRAM installed ...***
- Next by Date: 64bit operations efficiency...
- Previous by thread: Re: *** When 4G DRAM installed ...***
- Next by thread: Re: How to debug inside the BIOS and/or interrupt?
- Index(es):
Relevant Pages
|
