|
DOS/32 Advanced DOS Extender has quite a complex scheme of passing the hardware interrupts (IRQs) down to the real mode. The problem with these interrupts, is that by default the master PIC (Programmable Interrupt Controller) is mapped at software interrupts INT 08-0Fh, which are reserved on Intel's processors for the CPU exceptions. Whenever an interrupt handlers installed for INTs 08-0Fh are executed, they must first check if the interrupt was a processor exception, or a hardware interrupt. This is done automatically by the DOS/32 Advanced, which will use interrupt buffering technique to separate the hardware interrupts from the exceptions, and you do not have to worry about it when writing your interrupt handlers. What you should know about IRQ handlers, is that when you read/install an IRQ handler using ADPMI functions 0204h/0205h it will be read/written into a special buffer inside ADPMI kernel instead of IDT. The ADPMI will always receive interrupts INT 08-0Fh first, examine them and send them to the proper interrupt handlers, either IRQ or Exception handlers. This is accomplished as fast as possible, but there will always be a short delay before your IRQ handler is executed. The overall system performance are not degraded since the delay time is so short, that few (if any) devices are capable of sending the second IRQ before the first one is processed. The ADPMI supports the first 16 exceptions, except 0Ch - Stack fault. The exceptions 10h - Coprocessor Error, 11h - Alignment Check Error and 12h - Machine Check Error are not supported either and no exception handler will be installed for them. Please note, that even DOS/4GW DOS Extender does not handle the exception 0Ch properly, since it must be handled through a Task Gate because the state of the stack is unknown when the exception handler is executed.
Whenever an exception occurs, DOS/32 Advanced will take the following actions:
Below is shown an example of a report generated by the DOS Extender on an exception:
The unrelocated crash address will show where in your program the error had occurred. If you are using WATCOM C/C++ to create your applications, you may want to create a map file when linking the program. In the map file the linker will show all the subroutines that are declared as public, and their respective unrelocated addresses. The first number (before the colon) is the number of the Object in which the error had occurred, followed by an unrelocated address of the function/variable. HINT: use SUNSYS Debugger with the program which contains error, press the '4' key on the main keyboard to show the unrelocated addresses. Use the ENTER key to enter the address of the faulting instruction that was reported by DOS/32 Advanced (do not forget the '.' before the address to indicate that it is an unrelocated address) and debug the code.
When you install a protected mode IRQ handler, the DOS Extender will automatically install a special real mode IRQ callback, which will send the IRQ occurred in the real mode to a protected mode interrupt handler. Unlike DOS/4GW which supports this technique only for the first eight IRQs (IRQs 0-7 = INTs 08-0Fh), DOS/32 Advanced will install real mode IRQ callbacks for all 16 hardware interrupts (IRQ 0-7, IRQ 8-15 = INT 08-0Fh, INT 70-77h). Further more DOS/32 Advanced is capable of trapping the software interrupts that have been issued to emulate IRQs in protected mode. DOS/32 Advanced supports PICs remapped to other interrupt vectors than the default INTs 00-0Fh and 70-77h. In fact, when the PICs are remapped by the system (only VCPI servers can remap PICs), the IRQs will be processed slightly faster, since there will be no need in testing them against the exceptions and no interrupt buffering will be used. Though, DOS/32 Advanced will never remap the PICs itself.
All Rights Reserved |