Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!interlan!backman
From: backman@interlan.UUCP
Newsgroups: comp.sys.ibm.pc
Subject: Re: Interrupt handlers on the AT, need help
Message-ID: <120@interlan.UUCP>
Date: Wed, 25-Feb-87 07:59:23 EST
Article-I.D.: interlan.120
Posted: Wed Feb 25 07:59:23 1987
Date-Received: Fri, 27-Feb-87 21:41:35 EST
References: <2142@pur-phy.UUCP> <757@bucsb.bu.edu.UUCP>
Reply-To: backman@interlan.UUCP (1014-Larry Backman)
Organization: MICOM-Interlan, Boxborough, MA
Lines: 69

>In article <2142@pur-phy.UUCP> dub@pur-phy.UUCP (Dwight) writes:
>>	I would like to be able to use a hardware interrupt
>>(like IRQ5) to signal our IBM PC-AT to perform an
>>interrupt handling routine
>>	Is there anyone out thar who has written some
>>software to handle interrupts already that can help
>>me out?
>
>I'm interested in anything anyone knows about handling interrupts in
>just about any language except BASIC.  Specifically, I need info on
>the COM interrupts -- what needs to be done to get a routine to handle
>I/O through COM interrupts?  Help?


	I have written at least half a dozen DOS interrupt handlers, mostly
	communication oriented.  A few years ago, I went through the
		"I'll do it all in C" phase of programming. I got over it
	and went back to writing interrupt handlers in assembly.  My current
	approach uses Microsoft Macro Assembler Version 4.0 and Microsoft C,
	Version 4.0.  A brief description of an interrupt handler follows:

	I place a vector to an assembly interrupt handler in the BIOS vector
	table.  This assembly handler is real simple, it keeps  interrupts off
	long enough to save all registers, place the Microsoft C DS into DS
	and replace the stack with one of my own with SS the same as DS.

	At this point, my environment is set up so that I can call a C routine.
	Before turning on interrupts I capture whatever I need from the 
	interrupt routine and shove it somewhere safe in my Microsoft DS.  
	For instance if I'm in a NETBIOS POST routine I shove ES:BX onto
	a queue that can be accessed in C. If I'm doing synchronous comms., 
	I grab some Z8530 registers and put them on queues, if I'm doing
	Ethernet I save some 82586 info.  End result... I've got an environ-
	ment that is C compatable set up, I've got my interrupt information
	in a safe place that can be accessed from C.  At this point I can
	turn on interrupts, perform the EOI to the 8259 and call a C routine
	to do the interrupt handling.

	My C routine can now process the data captured by the interrupt. If
	its a NETBIOS NCB, get the pointer to the NCB from the queue that it
	has been saved on, and access the fields within the NCB.  This C routine
	is running on a non-interrupt basis, since we have issued an end of
	interrupt and re-enabled interrupts.

	When the C routine is finished, it returns to the assembly handler which
	restores all registers and does the IRET.  This architecture is based
	on a fast interrupt handler setting up and environment that a slower
	interrupt consumer can user.  The handler (assembler) does the hardware
	housekeeping, while the consumer (C) does the actual data processing.

	Warning - this architecture works provided you protect against 
	re-entrancy, a second interrupt occuring before the first is completely
	processed.  This can be easily handled through semaphores and queues.

	Yes I know that this is not real portable, nor will it be ADOS
	 compatable. However, it allows me the control needed to capture and
	process real-time interrupts safely without fear of missing a critical
	interrupt.  When Microsoft comes out with a means to handle an interrupt
	through signals to C code (ADOS?) I will be the first to change, until
	then assembly sems th safst way.


						Larry Backman
						Micom - Interlan
						617-263-9929 x291

						ulowell	
						mit-eddie  !interlan!backman
						ihnp4