Path: grendel.demon.co.uk!jes
From: jes AT grendel DOT demon DOT co DOT uk (Jim Segrave)
Reply-To: jes AT grendel DOT demon DOT co DOT uk
To: djgpp AT sun DOT clarkson DOT edu
Subject: Re: Installable ISRs
References: <714523621snx AT essence DOT demon DOT co DOT uk>
Date: Mon, 24 Aug 92 12:39:27  GMT
Organization: None
Lines: 31

I would like to modify go32 to add the ability to load an a.out file
which would contain code for interrupt driven serial I/O. It would be
nicer (from my point of view) not to directly bind the ISR code into
the go32 executable, but rather to find the ISR code from a command
line parameter and have it load that. Ideaaly, go32 would then invoke
the ISRT code's main, which could then call back (perhaps through an
int21/ah=ff function) to specify what interrupt(s) it wants to handle
and where the entry points for the interrupt code are. go32 would then
'lock down' the pages used for this code and carry on with normal
application loading. An app could communicate with the ISR code through
absolute addresses using shared memory or somehow extending the int 21h
ah=ff interface.
The main problem I see in all this is that the system command might have
some not-so-good results, but there may be other problems.Has anyone
done anything like this already? Am I overlooking some major flaw in
doing this sort of thing?

One of the purposes I hope to achieve with this weirdness is to port a
verson of ka9q to djgcc with the serial I/O running in protected mode.
At the moment, if you have a PC running a memory manager, it is
virtually impossible to get reliable comms at 38400 baud without a 16550
UART. However there are many machines - laptops - which can not be
fitted with a 16550. If the serial code was run in protected mode, the
UART could be virtualised and BIOS and DOS routines which disable
interrupts could be prevented from locking the UART out.
Any comments, suggestions, dissuasion from my own foolishness, etc.
gratefully accepted.

--
Jim Segrave