I recently came across that the question if a driver is compatible with DOS 3.3 isn't about the fact if it actually uses IRQs but if it potentially could use IRQs as the driver kernel pulls in the IRQ handler anyway. This is especially suboptimal in the scenario of statically linked drivers where it is concpetually totally clear at link time they use IRQs or not. Apart from that it might make sense to be able to define on a per-target basis if _any_ of the drivers of a certain class uses IRQs. If that isn't the cases the driver kernel for that driver class for that target could omit IRQ handling too. I'm aware that Uz imagined drivers being loaded which weren't known when the program was linked - but I don't see this.
<tag/Interrupts/
There's no <tt/interruptor/ support. Any attempt to use it yields the message
'FAILED TO ALLOC INTERRUPT' on program startup. This implicitly means that
- <tt/a2.stdmou.mou/ and <tt/a2.ssc.ser/ are not functional as they depend on
+ joystick, mouse and RS232 device drivers are not functional as they depend on
interrupts.
</descrip><p>
<tag/Interrupts/
There's no <tt/interruptor/ support. Any attempt to use it yields the message
'Failed to alloc interrupt' on program startup. This implicitly means that
- <tt/a2e.stdmou.mou/ and <tt/a2e.ssc.ser/ are not functional as they depend on
+ joystick, mouse and RS232 device drivers are not functional as they depend on
interrupts.
</descrip><p>
projects / cc65 / commitdiff