Xref: utzoo comp.sys.amiga:52439 comp.sys.amiga.hardware:711 comp.sys.amiga.tech:10657
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!ogicse!oregon!jmeissen
From: jmeissen@oregon.oacis.org (John Meissen)
Newsgroups: comp.sys.amiga,comp.sys.amiga.hardware,comp.sys.amiga.tech
Subject: Re: Questions regarding the AMIGA parallel port
Message-ID: <429@oregon.oacis.org>
Date: 20 Mar 90 23:25:00 GMT
References: <1990Mar14.225744.5617@dvinci.usask.ca> <10279@cbmvax.commodore.com>
Followup-To: comp.sys.amiga
Distribution: na
Organization: Oregon Advanced Computing Research, Beaverton, OR
Lines: 26


Along the lines of directly polling the parallel port, I had a similar
need, and as you say, was able to improve throughput from 5-6K bytes
per second to about 50K. I did the pooling from within the interrupt
handler, letting the remote read of the first character prime the
transfer. I also timed the loop to avoid too much system impact.

The problem I ran across was that reading the ICR also reset the bit
associated with the keyboard. I never found a successful way of 
putting it back, so although my transfers ran much faster, I occassionally
lost a keyboard transition if I tried to type while it was happening.

Now I discussed this at much length with Carl, and he thought it
should be possible to put it back via one of the ICR routines (SetICR()
maybe, I don't have my source handy). I never really got it to work.
The logic was to poll the ICR and stay in the loop as long as port
activity happened within a certain amount of time. If too long elapsed
it would leave and wait for the next interrupt to pull us back in.
If, during this loop, something other than the port bit was set, then
the code would fall out of the loop, try to put the other bit(s) back,
and exit to let the system handle it(them). The problem was (if I recall)
that I never detected the next parallel port operation until a keyboard
interrupt pulled me back into the main vector routine.
 
Should this logic work?
john-