Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!OMNIGATE.CLARKSON.EDU!ahd
From: ahd@OMNIGATE.CLARKSON.EDU (Drew Derbyshire)
Newsgroups: comp.sys.zenith.z100
Subject: Re:  Re: Re: help for a BIOS function call
Message-ID: <8902150111.AA15595@ucbvax.Berkeley.EDU>
Date: 15 Feb 89 01:03:34 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 20

Cindy,

You got problems.  :-)  I would suggest writing a device driver that
polls every (how often?) and queues it internally.  Then you can write
to the stuff to the screen at a lower priority than the queueing.
Another question is, are you using the BIOS or direct MTR-100 calls for
output?  You may be able to speed the screen output up that way.

Also, how do you poll for keyboard input?  There is an interrupt you can
call to report if you had keyboard or aux input since that last
interupt, this may be lower overhead than the noraml BIOS call to poll.
The interrupt is 58H, it returns flags for devices that had interrupts
in AX.

Kermit handles up to (but not including) 9600 baud that way, using the
BIOS for I/O to the AUX port and direct monitor calls for output.


If you can do a device driver, or find an existing one, interfacing to
existing programs might be alot easier and thus faster in the long run.