gilchrid@herald.usask.ca (Darren Gilchrist) (03/15/90)
We plan to use the AMIGA parallel port for I/O from/to a class project. Since
the project involves the sampling of sound, we would like the sampling circuit
to generate an interrupt request upon the completion of each sampling. Would
someone please answer the following questions.
1. What rate can the parallel port handle I/O?
2. How can one generate an interrupt so each sampling is handled
immediately upon completion?
We will be developing our own software to process the samples and push the
samples through the parallel to an D/A conversion circuit.
Thanks for help provided.valentin@cbmvax.commodore.com (Valentin Pepelea) (03/21/90)
In article <1990Mar14.225744.5617@dvinci.usask.ca> gilchrid@herald.usask.ca (Darren Gilchrist) writes: >We plan to use the AMIGA parallel port for I/O from/to a class project. > > 1. What rate can the parallel port handle I/O? The 1.3 parallel.device can send out or read in about 5000 to 6000 characters per second. (i.e. 50K bits/second in serial terms) Much higer throughput can be achieved by reading or writing the hardware directly. The current parallel device waits for an interrupt from the peripheral before sending out the next character. A program which instead polls the BUSY signal can achieve rates in excess of 100,000 characters per second. > 2. How can one generate an interrupt so each sampling is handled > immediately upon completion? Take a look at the hardware manual. When the *ACK signal is asserted by the peripheral, it generates an ICR interrupt on the Amiga. If you wish to deal with interrupt servers on the Amiga, I suggest you read Carl Sassenrath's Guru's Guide, Meditation #1 - Interrupts. >We will be developing our own software to process the samples and push the >samples through the parallel to an D/A conversion circuit. Busy polling would save you some trouble. Valentin -- The Goddess of democracy? "The tyrants Name: Valentin Pepelea may distroy a statue, but they cannot Phone: (215) 431-9327 kill a god." UseNet: cbmvax!valentin@uunet.uu.net - Ancient Chinese Proverb Claimer: I not Commodore spokesman be
jmeissen@oregon.oacis.org (John Meissen) (03/21/90)
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-