Re: Parallel port hardware
- From: "petrus" <iemand@xxxxxxxxxxxxx>
- Date: Thu, 4 Oct 2007 19:08:40 +0200
"Jon Slaughter" <Jon_Slaughter@xxxxxxxxxxx> schreef in bericht
news:FsYMi.166$sm6.134@xxxxxxxxxxxxxxxxxxxxxxx
I still want to lay my hands on the original IBM hardware manual. One of
the reasons is that parallel port. Nevertheless I saw several
"compatibel" schematics all with several differences. One thing is clear
to me: The output lines were never meant to do input. I have the
schematic of a printerport that had no inputs but the status lines.
Others had "inputs" on control- and data lines but they were only meant
to read back the status of that outputs. In the old days inputs used to
be SN74LS14 inverting Schmidt triggered buffers, as were the read back
inputs of the control lines. The control line outputs used to be SN7406
inverting open collector buffers. As the control lines are open
collector, you can use their read back inputs for real input when you
drive that control lines high... most of the time. I have a schematic in
front of me in which the read back of the /INIT control is taken from the
input of the SN7406 buffer rather then from its output. So you will never
read back the real status of that printer pin. No need to say it will
fail as an input as well.
I'm not sure. I think the control port was always able to do bidirectional
because it was open collector(of course its true that not all parallel
ports were open collector on the control port but most are)
Guesss you missed the point. That output *is* open collector but the read
back buffer has not been connected to that open collector output. See below.
| |
.-. .-.
| | | |
| | | |
'|' '-'
| |
|\ 06 | |\06 | /INIT
---| >O---+---+---| >O---+------
|/ | |/
|
14/| | |
--------O< |--+ .-.
\| | |
| |
'-'
|\06 |
------------------| >O---+-+----
|/ | other control
|
14/| |
--------O< |---------------+
\|
(created by AACircuit v1.28.6 beta 04/19/05 www.tech-chat.de)
Be aware that it is just one variant of the numerous schematics. Most
printerports I met had all read backs connected to the output pins.
The schematic in the chapter
"Using The Parallel Port to Input 8 Bits"
will fail in this case.
So if you want to stay on the safe side, don't use output pins for input.
If you have to, you will have to check the printerport involved for every
(type of) computer. Once you'll have to do so, it will be worthwile to
check for other properties of the printerport at hand. Almost all but the
oldest computers have printerports that somehow can do bidictional data
transfer. If you have the choice, use EPP ports (or USB :)
Well, I only have one other option and that is to use a status line to
read in the data but then I have to "disengage" the output line from the
data line or use the open collector of the control port to somehow do
it(which is what I was going to do but since I can read the control port
in the first place theres no real reason to use the status line because it
ends up making it slower and I still have to disconnect the output line so
screw everything up).
Right now I'm just trying to program the thing for my computer and I think
I can do it with the control port only but it requires that I know how the
hardware port works and I really have no clue. Of course experimenting
tells me one thing but I'm not sure if I trust myself with it.
Can send you a scan of that printerport schematic I mentioned. Just to give
you an idea about the general appearence of the hardware. As for how to
handle them by the software, you have Beyond Logic. Can't see why it should
be less difficult to use a control line rather then a status line for input.
How many lines of what type do you need anyway? And what for?
Using just the control port for what I want makes it very simple and
"elegant" compared to "hacking" it by mixing the status port and control
port. I guess the only way I'll know if it will work is to try it ;/ I
really hate doing that though cause its pretty risky ;/
I like to use an extra printerport card while experimenting.
Thanks,
Jon
petrus bitbyter
.
- Follow-Ups:
- Re: Parallel port hardware
- From: Jon Slaughter
- Re: Parallel port hardware
- References:
- Parallel port hardware
- From: Jon Slaughter
- Re: Parallel port hardware
- From: petrus bitbyter
- Re: Parallel port hardware
- From: Jon Slaughter
- Parallel port hardware
- Prev by Date: Re: Frequency of batteries
- Next by Date: Re: Which university produces good analog EEs?
- Previous by thread: Re: Parallel port hardware
- Next by thread: Re: Parallel port hardware
- Index(es):
Relevant Pages
|