Parallel port hardware

In SPP, it's not. SPP is output-only, except for the status inputs, of which there are two or three IIRC.

Hope This Helps! Rich

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.

"Jon Slaughter" schreef in bericht news:_QMMi.66$ snipped-for-privacy@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

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)

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

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

Best Wishes

"Jon Slaughter" schreef in bericht news:FsYMi.166$ snipped-for-privacy@nlpi069.nbdc.sbc.com...

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

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?

I like to use an extra printerport card while experimenting.

petrus bitbyter

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

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

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

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

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.

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)

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)

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

Thanks, Jon

Try reading the data sheet of the commonly used ITE IT8712F Super I/O chip. It will tell you in detail how to program the parallel port.

petrus bitbyter snipped-for-privacy@enditookhccnet.nl posted to 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.

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

"Jon Slaughter" schreef in bericht news:gZbNi.1084$ snipped-for-privacy@newssvr27.news.prodigy.net...

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

petrus bitbyter

You will need to limit the current somehow because sometimes both outputs will happen happen to be active at the same time

Roger Hamlett snipped-for-privacy@ttelmahdemon.co.uk posted to sci.electronics.design:

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

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.