Path: utzoo!attcan!uunet!ginosko!gem.mps.ohio-state.edu!csd4.csd.uwm.edu!mailrus!ames!oliveb!pyramid!lll-winken!scooter!neoucom!wtm
From: wtm@neoucom.UUCP (Bill Mayhew)
Newsgroups: sci.electronics
Subject: Conflicting IBM PC/AT IRQ 4
Keywords: probably makes no difference
Message-ID: <1701@neoucom.UUCP>
Date: 17 Aug 89 18:05:04 GMT
Organization: Northeastern Ohio Universities College of Medicine
Lines: 46

Normally, IRQ4 is the COM1: interrupt.  On most (all?) clone
machines, IRQ4 corresponds to INT 0CH.  Provided the interrupt
controller is set up to allow IRQ4 to be serviced, the CPU will
execute whatever code is pointed to by the vector at 0000:0030.  In
all of the clone machines I have access to, the BIOS initialization
points that vector to an innocuous routine in RAM at 0070:04xx,
where xx varies slightly from one machine to another.

I have three PCs in my office here.  I wrote the following program
to call INT OCH spuriously:

MAIN	PROC	FAR
	MOV	BX, 10		;CALL IT 10 TIMES
L1:	INT	OCH
	DEC	BX
	JNZ	L1
	MOV	AH,4CH		;DOS EXIT FUNC. REQUEST
	INT	21H		;CALL DOS
	ENDP
END

I assembled and ran the above on an AT&T 6300, rev 1.43 BIOS, an
Epson Equity III with Kyocera BIOS, and a Tandy 1400LT portable
with Phoenix BIOS 2.5.  The 6300 issued, "Illegal interrupt 04h at
0070:042D" to the console 10 times.  The Epson and Tandy did
nothing other than return to the DOS prompt.  Just for the record,
the AT&T also has a modem as COM2: and a two port board as COM3:
and COM4:, with COM1: and COM4: sharing IRQ 4.  Of course, the
internal COM1: UART maps at 3F8-3FFH, while COM4: is at 2F0-2F7H.

I presume that the clone machine being discussed in the original
usenet article must have had two cards accidentally mapped in as
COM1:.  Unless a telecom program were running, any IRQ4s should
have simply mapped to the DOS handler, exiting inocuously.  If the
cards had different addresses, the card with the ports at 3F8-3FFH
would have been the one serviced.  If two cards had the same port
addresses too, there could have been a case of bus contention.

That the conflict could have trashed a hard drive seems like a
rather remote possibility.  Who knows though, there are some clone
machines out there with very poorly written BIOSes ... perhaps, the
clone BIOS simply didn't bother to install a handler at power-up
and any IRQ 4 resulted in ramdom code being executed?....


Bill		(wtm@neoucom.edu   or   wtm@impulse.UUCP)