Parallel port hardware
Jon Slaughter
+5
|
4.7 kohm
|
R____|________ TTL input/output
| out
|/
W---|
|\
|
Gnd
I can't seem to find anything that shows how the port is read from and I'm
trying to understand its behavior when reading based on it. The above is
just what I think it probably is but I could be wrong. When reading from
the port W must be 0 and then R follows out. But this isn't quite true
because R seems to latch W to 1 and I have to write W = 0 to allow R to
follow out again.
Basically I'm trying to setup an input and output line into a control port
pin. I read that I have to use all the pins as either input or output but
not mixed? This is probably because I have to reset the pin and I cannot do
them individually? If this is the case then I have to use a status port pin
to read the line when it is working as an input?... which makes it more
complicated.
This is where I'm getting most of my info:
http://www.beyondlogic.org/spp/parallel.htm
and this is specifically where I'm having trouble:
"An external 4.7k resistor can be used to pull the pin high. I wouldn't use
anything lower, just in case you do have an internal pull up resistor, as
the external resistor would act in parallel giving effectively, a lower
value pull up resistor. When in high impedance state the pin on the Parallel
Port is high (+5v). When in this state, your external device can pull the
pin low and have the control port change read a different value. This way
the 4 pins of the Control Port can be used for bi-directional data transfer.
However the Control Port must be set to xxxx0100 to be able to read data,
that is all pins to be +5v at the port so that you can pull it down to GND
(logic 0)."
Not sure why I have to really do all port pins for bi-direction. (Obviously
I can't read and write at the same time but I think I can interleave them to
get what I want)
Any ideas?
Thanks,
Jon
Rich Grise
> Does anyone know how the open collector control port in the SPP is
> ...
> I can't seem to find anything that shows how the port is read from ...
In SPP, it's not. SPP is output-only, except for the status inputs,
of which there are two or three IIRC.
http://www.beyondlogic.org/spp/parallel.htm
Hope This Helps!
Rich
Jon Slaughter
"Rich Grise" <ri...@example.net> wrote in message
news:pan.2007.10.03....@example.net...
Nope, it doesn't ;/ You quoted the link I pasted and obviously didn't read
it.
Try reading it again and maybe you'll realize your wrong.
petrus bitbyter
"Jon Slaughter" <Jon_Sl...@Hotmail.com> schreef in bericht
news:_QMMi.66$LD2...@newssvr17.news.prodigy.net...
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.
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 :)
petrus bitbyter
Jon Slaughter
> 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)
> 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.
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 ;/
Thanks,
Jon
Roger Hamlett
the original 'AT'. Have the BIOS ones for an XT, but can't see the
hardware ones.
However the parallel port, is described in the manual for the video card
(wasn't on the motherboard on these machines). The output lines, use a
74LS374 latch (or 373, on the multi-io cards). The output enable, is
permanently grounded, making the data lines 'output only'. This was the
'SPP' port.
Devices that performed 'input' from these ports, used 'nibble wide' 4
bit transfers, using the four input status lines for the return direction.
The first IBM, to have bidirectional printer pins, was the PS/2. This
doesn't have the automatic latch cycle of the EPP port, or the DMA
abilities of the ECP port, but allowed the main data pins to be read as
well as written. This is the 'bidirectional' port.
Then you have the latter EPP, and ECP ports.
Most chips generating 'modern' printer ports,can be programmed to
emulate the SPP mode, but few emulate the simple bidirectional mode of
the PS/2.
There used to be a standard 'mod' for the old printer cards, of cutting
pin1 on the output driver chip (the output enable line), and connecting
it to a spare latch on an LS174 on the card, allowing the direction to
be switched.
The outputs on the parallel port, were _not_ 'open collector' drives.
Best Wishes
petrus
"Jon Slaughter" <Jon_Sl...@Hotmail.com> schreef in bericht
> >
>> 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
Rich Grise
Oh, silly me! It's the same link!
How can two people read the same thing and get different answers?
I do remember the schematic of the original parallel port from the
IBM PC Technical Reference, and there was no provision for read-back
of the data. I remember this well, because I found it so frustrating
at the time.
Of course, nowadays you've got EPP and ECP, but they're not SPP.
Thanks,
Rich
Rich Grise
> 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 :)
Here's instructions on how to hack a printer port to make it act
bidirectional, from our friend R. Steve Walz:
ftp://ftp.armory.com/pub/user/rstevew/LPT/lptskmtc.asc
The point being, to make the original SPP bidirectional, it has to be
hacked, i.e. you literally have to cut the trace to the OE of the '373
data latch.
Cheers!
Rich
Rich Grise
>
> 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).
>
Jon, please don't panic.
These days, you can go into your BIOS setup and configure your port for
EPP or ECP, and have real, official, bidirectional operation. :-)
I was only sniveling about the use of the term "SPP", which is output-
only, unless the board is hacked; but it's not 1985 any more. )-;
Cheers!
Rich
Jon Slaughter
Well, Supposedly the sepc isn't set in stone and AFAIK all modern SPP's have
bidirectional capabilities on the data and control port. This may be an
artifact of the ECP and EPP modes but since all modern parallel ports have
all 3 then its pretty much a given.
i.e., it doesn't matter in my case because I have it and thats all that
matters at this point. I'm not truely working with some legacy pos from 20
years ago so I have no idea how it compares. It might be the case that those
devices do not have bi-directional capabilities but no modern computer that
has a parallel port uses that exact same hardware. Unfortunately mode
computers now days don't even have a parallel port ;/
Jon Slaughter
Well, I'm not working with an original SPP port. I'm working with a modern
parallel port that has SPP capabilities along with ECP and EPP. I'm not
using the "enhanced" features of ECP and EPP though because they won't work
with my application. The bi-direcitonal'ness of the SPP might just be part
of those other modes though. It doesn't matter though because I'm only
working with my computer(which is very similar to most other modern
computers that have a parallel port) and I know it has bidirectional
capabilities.
Jon Slaughter
>>
>> 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).
>>
>
> Jon, please don't panic.
>
> These days, you can go into your BIOS setup and configure your port for
> EPP or ECP, and have real, official, bidirectional operation. :-)
>
Actually SPP, EPP, and ECP. I use SPP because I cannot use handshaking for
my application. (because it isn't technically designed to work with them...
just like hooking an LED up to the parallel port isn't going to do much with
handshaking)
> I was only sniveling about the use of the term "SPP", which is output-
> only, unless the board is hacked; but it's not 1985 any more. )-;
Maybe. I do not know. I imagine what is going on is that the read
capabilities are probably part of the ECP and EPP modes so maybe technically
SPP doesn't have those capabilities but when its being "Emulated" by a
modern port it does... and thats really all I'm concerned about. (because at
this point I'm only worried about what capabilities my hardware has an not
everything else)
Jon Slaughter
"petrus" <iem...@microsoft.com> wrote in message
news:42ebf$47051e1e$5354d4b6$86...@cache100.multikabel.net...
That would work. Maybe send to alt.binaries?
The only problem is because the PGDx line for the device I'm connecting to
is bi-dir. There are times when it switches into send and sometimes into
recv. If I just connect a status line to the line then then control pin will
need to be disconnected. If not when the device goes into transmitt it will
short out if the control point is low impedence.
i.e.
basically what I have is
Vdd
|
R
|
PGDx ---0-----------+----0--- Control pin
Now if I hook a status pin for reading I have
Vdd
|
R
|
PGDx ---0--+--------+----0--- Control pin
|
|
Status Pin
If PGDx goes to Vdd then status pin reads Vdd but if control pin is low
impedence(i.e., grounded because its open collector) then I have a short. I
figure I can put a resistor inbetween like
Vdd
|
R
|
PGDx ---0--+---R1---+----0--- Control pin
|
|
Status Pin
And then I essentially can limit the current by R1 but I'm not sure how well
this will work.
Just seems easier to use the "bi-dir" capabilities of the control pin in the
first place and not have to worry about using a status pin.
I still have the probably of shorting if the control pin goes low-z so maybe
the status pin is easier.
There is a problem of speed though as if I have to read and write to the
ports to "set them up" then it slows down the transmission speed. Writing or
reading to a port takes about 3us on my computer. If I have to do it, say
3-4 times then I have significantly cut the speed down. I already do it 2-3
times because I have to have a clock that goes twice as fast. This is why if
I do everything on one register I can potentially combine some writes or
reads to maximize speed.
Thanks,
Jon
Andy
chip. It will tell you in detail how to program the parallel port.
<http://www.ite.com.tw/product_info/PC/Brief-IT8712_2.asp>
JosephKK
sci.electronics.design:
Whatever IBM did was functionally very similar to one half an original
Intel 8255 without the ability to read the data port.
Rich Grise
> ...
> Whatever IBM did was functionally very similar to one half an original
> Intel 8255 without the ability to read the data port.
Back in the DOS days, I had a board with a printer port and two
serial ports. They weren't embedded in the MB in those days. Well,
the Chinese chip that they used for the lpt would blow out if you
looked at it funny. I got tired of throwing away otherwise perfectly
good boards, so I got out the trusty ol' IBM tech. ref., and duplicated
their printer port on a daughterboard, which I plugged into the
previous (fragile Chinese) chip socket. Interestingly, I also had
to build a little oscillator, because the clocks for the serial
ports were generated in the Chinese chip - it was pretty simple;
the basic "Clapp" or "Pierce" oscillator (can't remember which it's
called - about three parts), and made an RF choke out of a toothpick
and a couple of resistor leads, hand-wound with about 100 turns of
magnet wire.
It worked for the rest of the life of the computer. :-)
Cheers!
Rich
petrus bitbyter
"Jon Slaughter" <Jon_Sl...@Hotmail.com> schreef in bericht
Placed a printerport schematic on ABSE.
Also see you point for communicating with PGDx. You will need to keep the
printer control line high as long as the PGDx can go into outputmode. If not
you can get a collission and too high a current in the circuit. That old
7406 could sink a lot of current but one cannot know about the modern
integrated printerports. Guess you do not know about the PGDx either. (Guess
it's not open collector as you would not have a problem if it was.) So you
will need that serial resistor for current limiting. Ever saw some type of
electronic collission detection but it is too late to look after it now.
petrus bitbyter
You will need to limit the current somehow because sometimes both outputs
will happen happen to be active at the same time
JosephKK
sci.electronics.design:
Drat, I had misremembered. The less old stuff is nearly like an 8255.
Jon Slaughter
> Placed a printerport schematic on ABSE.
>
> Also see you point for communicating with PGDx. You will need to keep the
> printer control line high as long as the PGDx can go into outputmode. If
> not you can get a collission and too high a current in the circuit. That
> old 7406 could sink a lot of current but one cannot know about the modern
> integrated printerports. Guess you do not know about the PGDx either.
> (Guess it's not open collector as you would not have a problem if it was.)
> So you will need that serial resistor for current limiting. Ever saw some
> type of electronic collission detection but it is too late to look after
> it now.
>
> petrus bitbyter
>
>
>
>
> You will need to limit the current somehow because sometimes both outputs
> will happen happen to be active at the same time
Yes, this is the main problem. Sure I can program it so its high through the
programming but I'd rather not take that chance in general. I'm not quite
sure how to handle this. The problem is with the pic though. I could add a
resistor to limit the current but then it will reduce the voltage. Although
it might not matter to much.
I send an schematic to alt.binaries that shows the idea I'm looking at.
Thanks,
Jon.
petrus bitbyter
"Jon Slaughter" <Jon_Sl...@Hotmail.com> schreef in bericht
Did not find the collission detection but I think the circuit below will
prevent any output to be blown providing the level shift you need at the
same time.
----+-------+-----+--5V
| | | --+---+--2.5V
.-. .-. | | |
| | 10k| | | .-. .-.
| | | | | | | | |
'-'4k7 '-' | 10k| | | |56k
| | | '-' '-'
| | |\| | |
| +---|-\ ___ | | PIC
SPP | | | |-----|___|--+--)---+------
----+-+-----)---|+/ 2k7 | | I/O
control| | |/| | |
| | LM339 | |
| | | | |
| | | /| | |
| | | /+|--+ |
+-----)-----)-------| | |
| | \-|-----+
| | \| |
| | LM339 |
.-. | .-.
| | | | |
10k| | | 10k| |
'-' | '-'
| | |
| | |
------------+-----+----------------+---------
GND
created by Andy´s ASCII-Circuit v1.24.140803 Beta www.tech-chat.de
Any PIC I/O pin I am aware of can sink and source at least 1mA. So the 2k7
resistor being the maximum load will prevent damage from I/O current. At the
same time, the input leakage current on a PIC input pin is in the uA range.
So the 56K will prevent the input to become floating when the output goes
tri-state. Some PICs can activate weak pull ups to do the same.
petrus bitbyter
Gary Tait
news:xZ1Ni.3317$WX3...@newsfe5-win.ntli.net:
> There used to be a standard 'mod' for the old printer cards, of cutting
> pin1 on the output driver chip (the output enable line), and connecting
> it to a spare latch on an LS174 on the card, allowing the direction to
> be switched.
> The outputs on the parallel port, were _not_ 'open collector' drives.
>
> Best Wishes
>
I've done that one before. You use bit 5 on the control line.
I've also made a paralell card into an interface for one of those
MKE/Panasonic/Creative CD-ROM drives.
JosephKK
sci.electronics.design:
>
Tends to get stuck at "0" doesn't it?
petrus bitbyter
"JosephKK" <joseph_...@sbcglobal.net> schreef in bericht
news:xRrOi.5167$4V6....@newssvr14.news.prodigy.net...
You're right, this circuit will not work. I'll have a second look tomorrow
(if I find some time)
petrus bitbyter
petrus bitbyter
"petrus bitbyter" <pieterkral...@enditookhccnet.nl> schreef in
bericht news:470a95a2$0$7076$e4fe...@dreader12.news.xs4all.nl...
----+-------+-----+-5V
| | | +--------------+--2.5V
.-. .-. | | |
| | 10k| | | .-. .-.
| | | | | | | | |
'-'4k7 '-' | | |560k | |56k
| | | '-' '-'
| | |\| | 2k7 |
| +---|-\ | ___ | PIC
SPP | | | |-----+--+-|___|--+--+------
----+-+-----)---|+/ | | I/O
control| | |/| | |
| | LM339 | |
| | | | |
| | | /| | |
| | | /-|--+ |
+-----)-----)---| | | |
| | \+|--)--------+
| | \| | |
| | LM339 | |
.-. | .-. |
| | | | | |
10k| | | | |560k |
'-' | '-' |
| | | |
| | | |
------------+-----+---------+--------+-----
GND
created by Andy´s ASCII-Circuit v1.24.140803 Beta www.tech-chat.de
Modified circuit. This one will work... unless I made another mistake :)
petrus bitbyter
JosephKK
It passed all my checks. I would like to see what happens in SPICE.
I will have to cobble it up, tinker and and see some day.
petrus....@hotmail.com
<pieterkraltlaatdit...@enditookhccnet.nl> wrote:
> "petrus bitbyter" <pieterkraltlaatdit...@enditookhccnet.nl> schreef in
> berichtnews:470a95a2$0$7076$e4fe...@dreader12.news.xs4all.nl...
>
>
>
>
>
>
>
> > "JosephKK" <joseph_barr...@sbcglobal.net> schreef in bericht
> >news:xRrOi.5167$4V6....@newssvr14.news.prodigy.net...
> >> petrus bitbyter pieterkraltlaatdit...@enditookhccnet.nl posted to
> >> sci.electronics.design:
>
> >>> "Jon Slaughter" <Jon_Slaugh...@Hotmail.com> schreef in bericht
>
> - Tekst uit oorspronkelijk bericht weergeven -
Oops, I made a mistake. Connected the PIC I/O pin to GND! Which
connectoin should be removed of course. Like I did in the schematic
above.
petrus bitbyter
petrus bitbyter
Spiced it using LT1011 as I have no model of the LM339. Seems to work ok.
petrus bitbyter