Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!cuae2!gatech!gitpyr!thomps From: thomps@gitpyr.UUCP Newsgroups: comp.os.minix Subject: Re: Which clones *don't* run MINIX Message-ID: <3081@gitpyr.gatech.EDU> Date: Tue, 10-Feb-87 16:41:07 EST Article-I.D.: gitpyr.3081 Posted: Tue Feb 10 16:41:07 1987 Date-Received: Wed, 11-Feb-87 20:40:19 EST References: <275@ihnp3.UUCP> <459@moncol.UUCP> <2529@well.UUCP> <172@axis.UUCP> <1198@husc6.UUCP> Organization: Georgia Institute of Technology Lines: 55 Keywords: MINIX BIOS COMPATIBILITY Summary: sorry I misinterpreted In article <1198@husc6.UUCP>, ddl@husc6.UUCP (Dan Lanciani) writes: > 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. .... > 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. Sorry I misinterpreted what you were trying to say. I think if you will look back at what you wrote you will see that it is not 100% clear that the interrupt was to be passed on to the BIOS after you caught it. > 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. I am not an expert on BIOS so I am perfectly willing to accept that this will work. It certainly sounds like it should. By the way, I have not had any trouble replacing the interrupt in a techical sense (which has nothing to do with whether it is worthwhile to write a new driver) so I would believe catching it and passing it on would not be difficult. It seems a pretty klugey way have doing things however. I suppose choosing whether to do it that way (assuming BIOS is otherwise sufficient to support) multitasking would depend on how important having a nice clean OS is versus how important it is to run on the maximum number of clones. Since one of the primary purposes of MINIX was to be used as a companion to Tannenbaum's book in OS courses this may have taken precedence. Maybe Andy will have a comment on this. -- Ken Thompson (No not that Ken Thompson) Georgia Tech Research Institute Georgia Insitute of Technology, Atlanta Georgia, 30332 ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!thomps