Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!husc6!ddl
From: ddl@husc6.UUCP
Newsgroups: comp.os.minix
Subject: Re: Which clones *don't* run MINIX
Message-ID: <1198@husc6.UUCP>
Date: Tue, 10-Feb-87 04:01:45 EST
Article-I.D.: husc6.1198
Posted: Tue Feb 10 04:01:45 1987
Date-Received: Wed, 11-Feb-87 05:50:06 EST
References: <275@ihnp3.UUCP> <459@moncol.UUCP> <2529@well.UUCP> <172@axis.UUCP> <3071@gitpyr.gatech.EDU>
Organization: Harvard University, Cambridge MA
Lines: 47
Keywords: MINIX BIOS COMPATIBILITY

In article <3071@gitpyr.gatech.EDU>, thomps@gitpyr.gatech.EDU (Ken Thompson) writes:
> I believe Dan, Phil and Andy T. are talking about the same thing
> here. The keyboard interrupt is supplied by the hardware and has
> nothing to do with BIOS. What BIOS supplies is a keyboard driver
> or interrupt handler which catches the interrupt and places the
> code for the depressed key in the keyboard buffer. BIOS provides
> calls to get information out of the buffer, find out if anything
> is in it etc. However, if I catch the int 9 directly from the
> hardware (as Dan suggests) and use my own interrupt handling routine or driver
> and am no longer using BIOS. I am sure that this is what MINIX's
> keyboard driver does. Dan's argument really says that the BIOS is does
> not do the kind of interrupt I/O that a multitasking operating system
> needs because if we let the BIOS keyboard driver handle the keyboard
> interrupt, the process waiting for the character will never know
> its there unless it checks explicitly. Therefore, the BIOS driver must
> be replaced with another one that will signal the OS when a character
> arrives.

	No, that's not what I said at all.  Please don't rewrite me...
The idea is to catch INT 9 and then PASS IT ON to the BIOS.  Next, using
this as a hint that there might be something to read from the keyboard,
invoke the non-blocking read character/status call and (possibly) the
destructive read call until the buffer is drained.  This has many advantages.
The standard BIOS calls are used.  The BIOS takes care of all character
encoding, shift keys, etc...  Your operating system is isolated from
the hardware and thus runs on many (partly incompatible) clones.  Some
clones that don't use INT 9 are so thoughtful as to simulate one every
time a key is struck, so this still works!  The net effect is completely
indistinguishable from an interrupt-driven keyboard.  In fact, it is
an interrupt-driven keyboard.
	The confusion seems to stem from not differentiating between
the BIOS interrupt service routine (which does just what you want; shoves
characters into a buffer) and the BIOS user-level calls which don't
do quite what you want but can be trivially coerced to do so.  Or maybe
it isn't clear how easy it is to intercept an interrupt rather than
replace it.  Take my word for it, it is much easier.  Just not having
to worry about sending the eoi to the interrupt controller improves
portability considerably.
	Now before you tell me this won't work, note that it is not
a theoretical argument; this is the way I do keyboard I/[O] in OS.
Also note that I am not praising the BIOS code; I hate it just as much
as the next guy.  But the thought of writing n different keyboard
drivers for n different clones when a much simpler approach would work
was very persuasive.

					Dan Lanciani
					ddl@harvard.*