Maker Pro
Maker Pro

Parallel port hardware

J

Jon Slaughter

Jan 1, 1970
0
Does anyone know how the open collector control port in the SPP is

+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
 
P

petrus bitbyter

Jan 1, 1970
0
Jon Slaughter said:
Does anyone know how the open collector control port in the SPP is

+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

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
 
J

Jon Slaughter

Jan 1, 1970
0
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
 
R

Roger Hamlett

Jan 1, 1970
0
petrus said:
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
The oldest 'hardware' IBM motherboard tech-ref, I have, is the one for
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
 
P

petrus

Jan 1, 1970
0
Jon Slaughter said:
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.
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
 
R

Rich Grise

Jan 1, 1970
0
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.

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
 
R

Rich Grise

Jan 1, 1970
0
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
 
R

Rich Grise

Jan 1, 1970
0
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
 
J

Jon Slaughter

Jan 1, 1970
0
Rich Grise said:
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.

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 ;/
 
J

Jon Slaughter

Jan 1, 1970
0
Rich Grise said:
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.

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.
 
J

Jon Slaughter

Jan 1, 1970
0
Rich Grise said:
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)
 
J

Jon Slaughter

Jan 1, 1970
0
petrus said:
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.


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?

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
 
J

JosephKK

Jan 1, 1970
0
petrus bitbyter [email protected] posted to
sci.electronics.design:
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

Whatever IBM did was functionally very similar to one half an original
Intel 8255 without the ability to read the data port.
 
R

Rich Grise

Jan 1, 1970
0
...
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
 
P

petrus bitbyter

Jan 1, 1970
0
Jon Slaughter said:
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


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
 
J

JosephKK

Jan 1, 1970
0
Roger Hamlett [email protected] posted to
sci.electronics.design:
The oldest 'hardware' IBM motherboard tech-ref, I have, is the one
for 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

Drat, I had misremembered. The less old stuff is nearly like an 8255.
 
J

Jon Slaughter

Jan 1, 1970
0
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.
 
Top