🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.os.msdos.programmer
Article #1049

Re: Parallel port I/O (mostly O : -)

#1049
From: Ralf Brown
Date: Thu, 20 Aug 1992 04:32
38 lines
2825 bytes
In article <1992Aug19.135359.24909@bas-a.bcc.ac.uk> nino@mph.sm.ucl.ac.uk (Nino Margetic) writes:
}I know that there is also a way to access the LPT port directly thru the
}in/out commands and its 3 I/O registers. Are there any advantages (in
}terms of speed) in using interrupt driven parralel I/O, as compared to
}INT17 BIOS service as I have used it - if there is, how much, and is
}it doable in C?? I can just about read assembler, but that's about it.

Writing directly to the ports can be an order of magnitude faster than doing
separate interrupt calls to check the status and actually write the character.
However, you probably will not be able to get reliable interrupt-driven
operation because (a) a majority of parallel ports don't reliable generate
the IRQ, and (b) the standard IRQ7 is also triggered whenever the interrupt
controller gets an interrupt request which is deasserted before the CPU
responds to the request.

}The speed of the application is crucial - I need to send as many bytes
}thru the LPT port as possible (order of 1e6). N.B. does anyone know the
}approximate number of bytes per second that can be sent thru the LPT port
}via INT17 and/or interrupt driven parallel I/O??

Maximum speed depends on the CPU speed and the speed of the device at the
other end of the parallel cable.  For example, if the other end is an
Epson FX80, the timing specifications for the strobe/ACK sequence set a
limit of about 75,000 characters per second.  Connecting a pair of 386/33s,
a data rate of 300,000 characters per second sounds feasible using tight
loops (you'd never be able to get near that speed in interrupt-driven
operation due to the overhead of handling an interrupt).

I've managed to pump nearly 2400 characters per second to said FX80 using
30% of the CPU cycles on a 4.77MHz 8088 (over one-third of that 30% was
the overhead of handling 2400 clock interrupts per second).  All parallel
port I/O was done using direct port accesses.

-- 
Internet: RALF+@CS.CMU.EDU   |The University would disclaim this if it knew...
FIDO: Ralf Brown 1:129/26.1  |
BIT: RALF%CS.CMU.EDU@CARNEGIE|"Success has a simple formula: do your best,
AT&Tnet: (412)268-3053 school| and people may like it."   -- Sam Ewing
Technical Details
Message-ID: <Bt9Ly4.7sD.2@cs.cmu.edu>
Path: arc1-ca.pugleaf.net!sparky!uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!rpi!uwm.edu!ogicse!das-news.harvard.edu!cantaloupe.srv.cs.cmu.edu!ralf
References: <1992Aug19.135359.24909@bas-a.bcc.ac.uk>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!rpi!uwm.edu!ogicse!das-news.harvard.edu!cantaloupe.srv.cs.cmu.edu!ralf
From: ralf+@cs.cmu.edu (Ralf Brown)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Parallel port I/O (mostly O : -)
Message-ID: <Bt9Ly4.7sD.2@cs.cmu.edu>
Date: 20 Aug 92 04:32:27 GMT
Article-I.D.: cs.Bt9Ly4.7sD.2
References: <1992Aug19.135359.24909@bas-a.bcc.ac.uk>
Sender: news@cs.cmu.edu (Usenet News System)
Organization: School of Computer Science, Carnegie Mellon
Lines: 38
Nntp-Posting-Host: b.gp.cs.cmu.edu