Here's another side project of mine - a tool for viewing/editing the state of the parallel port pins.
Full source included - but you will need to download "WinIO", and copy the binary files (DLL, SYS) into the same folder as the project executable. I didn't implement code for the 64bit version but the 64bit functions are there too.

Does your parallel port support bidirectional mode (using data pins as inputs instead of outputs) ?
If so, does the data you place in D0-D7 survive a switch to bidirectional mode and back again?
Try my application and find out :)

Note that this is a POLLED version.

And now, some questions from me :)


#1 - I learned that I was able to find the current hardware address of the LPT1 port (usually 378h) can be found always at physical address 0408h ... Is there any way to determine for sure which IRQ is associated with the port?

#2 - Usually the IRQ associated with parallel port is 7. No microsoft operating systems use this IRQ for anything that I am aware of, although I read a vague mention of it being assigned to other devices. Is it safe to hook int 7 with an ISR?
Attachments:
Posted on 2010-06-17 06:02:09 by Homer

I found that (on this machine) in bidirectional mode, the data pins (D0-D7) all go HIGH.
This means that the interface circuit needs to be able to "sink" enough voltage to produce a zero - we get a one even when nothing is connected. So we need to "pull down" the voltage - thus the term "pull-down resistor".

If we found that the data pins produced a zero when not connected to anything, we would need to "pull up" the voltage to make a one... thus we would need a "pull-up resistor".

What is the difference between a pull-down resistor, a pull-up resistor, and a 'normal' resistor - and why do we need a resistor at all?
Posted on 2010-06-18 02:36:39 by Homer

#2 - Usually the IRQ associated with parallel port is 7. No microsoft operating systems use this IRQ for anything that I am aware of, although I read a vague mention of it being assigned to other devices. Is it safe to hook int 7 with an ISR?


Many moons ago, Creative assigned irq 7 to its SoundBlasters by default. They later changed this to irq 5.
So yes, there is empirical evidence of other hardware using irq 7.
Posted on 2010-06-18 08:31:23 by Scali
As you say - many moons ago.
And this seems to be only the case for some machines which have NO parallel port (some few laptops).
Yes, Creative did advise people to manually configure IRQ7 for use with soundblaster, but they could have used any unused interrupt (I think irq 9 is deliberately left vacant for such a reason).

Anyway - for parallel port work with custom interface hardware and software, I won't have other devices plugged in to the parallel port (no daisy chain), and I will know that if I ever have an IRQ conflict, its probably a "misconfigured" soundcard causing it.

So I think I am "pretty safe" to go ahead and hook this interrupt via IDT hooking from a device driver.
In fact, I already found one example of a port access DLL which *does* provide such a functionality, allowing the user to write a userland callback function that the Driver will call in response to IRQ 7's falling edge.
Apparently it's been written as a filter that attaches to Microsoft's default PARPORT.SYS driver...
The author notes that we must tie the !ERROR pin to Earth, otherwise the default driver will cause chaos for about one minute by trying to "ping" a printer that does not exist - we'll tell it theres no printer, and it will shut up and leave us alone. So - we lose the use of the error line, but we gain the use of the interrupt line - definitely a good trade.
However I would suggest that it would be safer to do so via a 4k7 resistor, just incase the parallel port has no current protection on its inputs, as can be the case in some cheap ones.

Warning that without having made said modification, this driver will bluescreen you.
http://www.scienceprog.com/xdrv-driver-for-lpt-with-interrupt-service-routine/

Now - I don't think I really need this special driver if I write my own IDT hooking code - I already have a function that lets me read/write to anywhere in physical memory, and I know about using SIDT to gain the physical address of the IDT. But this driver already has the "userland ISR" function, I may just get lazy and use it as it stands.

Many happy interruptions :)
Posted on 2010-06-19 21:12:25 by Homer

What is the difference between a pull-down resistor, a pull-up resistor, and a 'normal' resistor - and why do we need a resistor at all?

With common digital circuits, an input wire can have three states: high, low, and floating. Floating inputs can be at any voltage level, including any value between "high" and "low". The pullup and pulldown resistors are normal resistors wired to eliminate floating inputs.

Pullup and pulldown resistors have two uses.

1) They force unconnected inputs to a known high/low state.
2) They allow specially designed outputs to be wired together, without logic gates, to feed a single input.
Posted on 2010-06-19 21:54:16 by tenkey

As you say - many moons ago.
And this seems to be only the case for some machines which have NO parallel port (some few laptops).
Yes, Creative did advise people to manually configure IRQ7 for use with soundblaster, but they could have used any unused interrupt (I think irq 9 is deliberately left vacant for such a reason).


No, it has nothing to do with laptops or machines with no parallel port. The early SoundBlasters were ISA cards. They had jumpers to set irq and things, but by default it was set to irq 7. Anyone who stuck such a card in their PC (99% of them having a parallel port), would use irq 7 by default. In fact, various games are even hardcoded to use only irq 7 on a SoundBlaster.
Posted on 2010-06-20 03:10:18 by Scali
Fair enough.... still not sounding like a problem - at least not for me, there will be no games on that dedicated machine.
I've been doing a bit of digging around - ok I lied - I've spent the entire weekend SCOURING the internet, trawling through forums, just trying to find ONE example of a device driver which registers an ISR to the parport.sys driver "the right way" rather than using some hack. And I found just ONE example.. and the author mentions in the comments that it doesn't seem to actually DO anything on his test machine - disturbing. The example I found was a driver written for an application which used the parallel port to transfer data to and from CBM (commodore) devices, most recently edited it seems in 2006 (so not too old)... new enough anyway.

Well, I now have sourcecode for writing such a driver, I've read all the relevant docs over at MSDN, I will try it out.
And if it does not work, I've already downloaded a copy of Ubuntu.
I will not spend another weekend hitting my head against the wall.

But I do hope I can get it to work on Windows - I even took the time to learn how to register unlicensed drivers on Win7, and I don't use Win7.

I have almost zero experience writing kernel mode drivers, so I expect to be asking for a little help at some stage.
Posted on 2010-06-21 01:35:53 by Homer
Don't know if this helps, but IRQ 7 is notorious for issuing spurious interrupts.

There are some theories and workarounds on this page.
Posted on 2010-06-21 13:01:46 by SpooK

That was a really interesting read - especially his 'probable causes'.

He mentions that the interrupt is firing, even though theres nothing connected to the parallel port. He notes that one possible cause is "floating inputs" - but fails to realize that they are floating BECAUSE they are not connected to anything :P
But then later he says that updating his kernel seems to have improved the issue.

I have seen this problem before, where a friend had been shorting out parallel port input pins to earth, he damaged his PIO controller's outputs to his physical parallel port, some inputs were just dead, others would 'flutter'.
But you should need the "IRQ Enable" pin active, and the "ACK" pin fluttering to cause interrupts.
The interrupt controller should ignore ACK unless IRQ Enable is enabled...

Very interesting is the specifications of the 8259A PIC chip - are these still being used in modern motherboards?
It states that if an IRQ is not acknowledged by the cpu in an acceptable amount of time, the Master PIC will issue an IRQ7, which will be fed down through any cascaded Slave PICs... I assume this ends up being translated into something other than IRQ7, but it is a disturbing note. It could explain why an update of his linux kernel greatly reduced the problem... I would suspect the IO subsystem / port driver were taking too long.

More disturbing is that eventually he opted to use Serial port (apparently just to generate the desired control interrupts).
It seems weird to me that the serial and parallel controllers would still be separate chips after all these years.



Posted on 2010-06-22 00:06:45 by Homer
Not sure. My guess is that the 8259A design was preserved, even within the Southbridge/LPC, though I would imagine it is generally disabled in favor of the APIC by most modern operating systems.

Found that even Wikipedia has a section on 8259A and spurious interrupts, interesting indeed.
Posted on 2010-06-22 00:33:37 by SpooK
It's looking and sounding like a poor parallel port implementation to me.
The author does not state whether the port is card-based or native to the motherboard, nor specify make nor model.
I have found plenty of references to "bad parallel port hardware implementations" so we can't blame Intel.
Microsoft are actually in the clear this time,  because this occurred on a Linux (2.4?) box.

Anyway, I am going to go out on a limb and state that this is not likely to be the typical case.
I need to hold on to some hope!
There ARE commercial drivers which claim to be able to watch IRQ7, but I hear about people missing counts, and I wonder if (A) they used a IDT hack incorrectly on a multi-cpu system, or (B) They're just polling the ACK and IRQ Enable pins, and catching as many positives as they can, EMULATING interrupt handling.

There seems to be very little evidence on the ground that anyone has done anything in this area in years.
Am I alone?
Posted on 2010-06-22 04:09:32 by Homer

There seems to be very little evidence on the ground that anyone has done anything in this area in years.
Am I alone?


Last time I dealt with this is on a 486, and I simply disabled IRQ 7 :lol:
Posted on 2010-06-22 11:44:36 by SpooK
Well yea, the last few computers of mine don't have a parallel port at all.
Posted on 2010-06-22 13:00:14 by Scali

Well yea, the last few computers of mine don't have a parallel port at all.

Man, all I have is USB 2.0, USB 3.0, Firewire and E-SATA ^^ I remember having a PC with 1 serial port about 3 years ago. I can't recall how long it has been since the last time I had a PC with a parallel port ^^'
Posted on 2010-06-22 16:43:44 by ti_mo_n