Mail Archives: djgpp/1997/10/03/20:47:32
Obviously the reason to hook interrupts is precisely that you do not
have fast enough drivers. What comes with most languages on most
machines does not give you fast enough access to cooked and uncooked
filesand keystrokes, mouse strokes and buttons, serial and
parallel bytes, printer and CD ROM write bytes; however,the input
and output graphics are not even in the same universe. On a 266 MHz
Pentium running Windows NT, (which is many times faster than my
Heathkit H-89 editor called PI running on a dual Z80 chip, one for
the 64K CPU and one for the screen-keyboard driver), the pop up
editor uses the BIOS keyboard driver, and slows the keyboard
response rate slower than the speed of the 16 year old Z80 PC.
When a human has to wait for a machine needlessly, it is time to
upgrade the device drivers. Part of the problem is that speed is
not usually given as a performance requirement of most device
drivers. But a bigger part of the problem is that the programmers
have extremely high-level APIs which you can beg for them to
grant you slow access to SOFTWARE streams on top of streams,
ultimately on top of the hardware streams of bytes, instead of
direct APIs giving you access to the underlying hardware streams
of bytes. For GUIs, which make computers play like a very slow
video game, it might be okay to slow down access to the I/O
streams. But in realtime systems such as CDROM burners, cool games,
airplane flying, printer timeouts, and audio players, missing
a realtime deadline misses the beat, blotsches the printout,
hardens the landing, lessens the fun of the game, and gives you
a data underrun please start burning your CD all over again.
Mike
- Raw text -