| Wayne, David, and community, When the interrupt occurs, it is necessary to save any registers used by the interrupt service routine. Regarding the saving of these registers, there are two techniques for this context save. The first one is to simply push the context registers onto thew caller's stack and pop them when you are done. Since we don't know the size and location of the callers stack, this can be problematic. The second technique involves the use of a private stack on entry and switch back before the end of the ISR. This generally works in a system where the interrupts are not reenabled until the end of the ISR. Currently, it is undefined whether we will allow nested interrupts. When an ISR is entered, the time between the disablement of the interrupt system and it's subsequent re-enablement is a guarded region and constitutes a latency period for all other interrupts that may be pending. In the case of some devices, it is necessary to servicer them immediately to prevent data loss. For this reason it is desirable to allow nested interrupts. I can see a likely scenario where we would want to use nested interrupts. The PS/2 mouse and keyboard ports must be serviced on time, especially necessary if we are bit banging/grabbing in order to receive serial presented information. Nested interrupts are a little tricky, but can be used to provide dramatic results. I am hoping that the interrupt scema will take this into account. A case in point being the implementation of MPM-80 the performance of which depends heavily on the use of nested interrupts to support mass storage access (may include floppies and communication channels such as UART's. A typical technique is to keep an interrupt count in memory that is incremented on entry and decremented on exit. The 8259A programmable interrupt controller has priority dispatching modes, although I usually use it in "round robin" mode. Also please note that when using the 8259A interrupt controller, failure to clear all interrupt causes before exiting is penalized by subsequent failure of the interrupt system as the 8259A will not accept future interrupts. An easy example of this would be the collision of the timer interrupt with other real-time devices such as a floppy drive which requires the incoming data to be read immediately. Hence there is a genuine difference between David's proof of concept interrupt example and a more realistic fully functional system with up to eight interrupt sources (using the 8259A interrupt controller, including the pesky IR7 default interrupt (also known as the vacuum cleaner interrupt because it just happens when the environment is noisy, and it must be handed immediately as indicated in the Intel documentation. Because of all these factors, a robust interrupt system capable of handling nested interrupts requires a sophisticated ISR whose size will easily exceed the last page of the CBIOS space. Because of this I see a requirement for the entire ISR and supporting routines to be in the alternate bank. There is of course the issue of user callbacks to ISR extensions existing in the base banks of the TPA space. Nested interrupts are a challenge to test and certify as correct and safe. I really look forward to discussing the HBIOS's support for interrupts, as this groundwork is critical for the more challenging port to MP/M-80 using the HBIOS for all hardware related tasks. Respectfully, Douglas Goodall On Sep 18, 2012, at 6:39 AM, Wayne Warthen <wwar...@gmail.com> wrote: Hi David, |