nerd@percival.UUCP (02/10/87)
philip@axis.UUCP >> But, the most important reason (as given in the book) is that the BIOS >> calls do not use interrupts. So, when your shell does a read(), BIOS >> loops on the status bit of the serial line UART (for example), and the >> machine effectively stops for all other processes. ddl@husc6.UUCP > This is plain wrong. The IBM PC keyboard is interrupt-driven. >Int 9 is used, if you are interested. Characters are stored in a FIFO >buffer. The get-a-character call does, indeed, loop waiting for a >character to appear in the FIFO buffer; however, there is a get-status >call which will not hang. Furthermore, it is trivial to catch int 9 >and use it as a cue to ckeck for keyboard activity. The combination >gives you an interrupting keyboard. Nope, sorry, the combination gives you a polled keyboard. As things stand now, if you call the bios to do a read it will sit there and *poll* the FIFO status until it finds that a key has been hit, then it returns with the key's value. Alternately your code could check the FIFO status and loop until something showed up (duplicating the bios' code), you would still be polling the keyboard's queue. While it may be different in words the result is stil that the cpu is doing nothing usefull while waiting for the slowest link in the computing machine (the live-ware). For a device to be usefull in a multi-tasking environment it's driver must take requests for an action (input/output/status check/whatever) and release the cpu to work on other things until the device is ready, then wait for the cpu to come back. What it all comes down to is that it is not suficient for a periferal driver to be interupt driven, the driver also has to be designed to be respectfull of resources that are not its own to alocate (i.e. cpu time). There are several other requierments like reentrancy but that is another subject which I will touch upon some other time when I don't have to go off to work. ddl@husc6.UUCP > I use the BIOS calls a great deal and I have never encountered >problems with the machine being left in an unstable state. Can you give >a specific example? power the machine up, it is inherently in an unstable (unusable) state, that is designed in to ms/pc-dos philip@axis.UUCP >> BIOS/MSDOS/PCDOS and the rest realy are single process machines, >> and in general, no part of them is useful in a 'real' computing >> environment. bravo!!! someone has seen the light. ddl@husc6.UUCP > I use the BIOS in OS for keyboard and disk i/o. It works fine. >It runs on clones because they all emulate the BIOS interface. >I like to think of it as a "'real' computing environment." Well, as >real as you can get on an 8088. ^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ two people have seen the light, we're on a roll now. -- If my employer knew my opinions he would probably look for another engineer. Michael Galassi, Frye Electronics, Tigard, OR ..!{ucbvax,ihnp4,seismo}!tektronix!reed!percival!nerd
ddl@husc6.UUCP (02/13/87)
In article <431@percival.UUCP>, nerd@percival.UUCP (Michael Galassi) writes: > Nope, sorry, the combination gives you a polled keyboard. As things stand > now, if you call the bios to do a read it will sit there and *poll* the FIFO > status until it finds that a key has been hit, then it returns with the > key's value. Alternately your code could check the FIFO status and loop until > something showed up (duplicating the bios' code), you would still be polling > the keyboard's queue. While it may be different in words the result is stil > that the cpu is doing nothing usefull while waiting for the slowest link in > the computing machine (the live-ware). Let me try again, real slow. First intercept INT 9. When it occurs, call the BIOS INT 9 handler. The BIOS will do all the messy key mapping, tell the keyboard that it read the key, send an eoi to the interrupt controller, etc. Now, while STILL AT INTERRUPT TIME, use the BIOS poll function to read a key. If there was something there, hand it to the tty driver and do a destructive read to remove it from the BIOS fifo. Sometimes there will be nothing to read (key-up event). The idea is to use the INT 9 event as a cue to read the keyboard. This is not a polled keyboard. This is an interrupt-driven keyboard. This works. This is how I read the IBM PC keyboard on my multi-tasking operating system. If you want a demonstration then you can either come visit me or buy a copy. Not using the BIOS because you think it is ugly is a matter of taste. This is presumably why MINIX does not use it. Not using the BIOS because you think it can't work is a matter of misunderstanding. Could we please end this silly discussion? > power the machine up, it is inherently in an unstable (unusable) state, > that is designed in to ms/pc-dos Joke? > two people have seen the light, we're on a roll now. Dark destroys the light... Dan Lanciani ddl@harvard.*
grr@cbmvax.UUCP (02/13/87)
In article <1216@husc6.UUCP> ddl@husc6.UUCP (Dan Lanciani) writes: >In article <431@percival.UUCP>, nerd@percival.UUCP (Michael Galassi) writes: COME ON PEOPLE - can't we agree that Andy considered this issue and decided that in his judgment that using the BIOS was contrary to his overall intent! Anybody who has been up to his hips in the BIOS muck can tell you interesting things that can be done, and relate various pitfalls and problems encountred by trying these. The problem is that using the BIOS and various work arounds to make it completly interrupt driven actually obscures the simplicity of using the standard PC hardware. While using the standard BIOS calls would increase portability, trying to go beyond the basics opens the door for all kinds of low-level BIOS incompatiblities that cause other portability problems! It might be useful and fun for someone to make a version of Minix that does use standard BIOS call exclusivly. While crippled, this would be a good tool for starting a port to an alien PC implementation. BTW, as far as multi-user, interrupt driven concerns - have you ever noticed how the interrupt driven keyboard driver implements control/num-lock to "stop scrolling" - true elegance 8-) -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
braun@m10ux.UUCP (02/13/87)
ddl@harvard writes: > Let me try again, real slow. First intercept INT 9. When it >occurs, call the BIOS INT 9 handler. The BIOS will do all the messy >key mapping, tell the keyboard that it read the key, send an eoi to >the interrupt controller, etc. Now, while STILL AT INTERRUPT TIME, use >the BIOS poll function to read a key. If there was something there, hand >it to the tty driver and do a destructive read to remove it from the BIOS >fifo. Sometimes there will be nothing to read (key-up event). The idea >is to use the INT 9 event as a cue to read the keyboard. > This is not a polled keyboard. This is an interrupt-driven keyboard. >This works. This is how I read the IBM PC keyboard on my multi-tasking >operating system. If you want a demonstration then you can either come >visit me or buy a copy. > Not using the BIOS because you think it is ugly is a matter of >taste. This is presumably why MINIX does not use it. Not using the >BIOS because you think it can't work is a matter of misunderstanding. >Could we please end this silly discussion? The keyboard is the easy one. How is disk I/O done in an interrupt-driven fashion with the BIOS? -- Doug Braun AT+T Bell Labs, Murray Hill, NJ m10ux!braun 210 582-7039