What happens when you have "no luck"? What OS? Are you the same "nobody" who's trying to do this in Linux? I *think* that under "real dos", you'd have actual access to the hardware. Under "vm86/dos" or Win9x, the ports are emulated - usually it should work the same as "real" access... with exceptions... the IDE controller, for example, seems to be "off limits". I understand NT-based Windows blocks access to ports entirely, the way around it is to write a "vxd" (virtual device driver) - maybe other options(?). Under Linux, access is blocked, but you can get permission with sys_ioperm or sys_iopl. I mentioned this to the "linux nobody", and (s)he responded with a reference to a LRMI library - sounds interesting, but I don't know anything about it. I suppose you'd use it like any other library(?)...
If I were trying to learn port programming, I think I'd start out in "real dos" - booting from floppy if all else fails - just to eliminate any "complications". But assuming we've got access, one way or another, I think there's more to it than just writing to 378h (or wherever - that's most likely, I think). I think I'd first read the status port (at 379h - or "base + 1"), and check to see if we're "selected" and not "busy" or "out of paper"... maybe we can check just the "no error" bit(?). Then write our data to 378h. Then, I think we have to "strobe" bit 0 of the control port (37Ah or "base + 2") before we can expect to see our data appear on the pins.
Then there's the question of what's attached to this parallel port. I doubt if a modern printer will do anything sensible if you just start throwing ascii at it - I suspect there's some "setup" required. I used to be able to get what I wanted out of a 9-pin dot-matrix, to a degree, but I imagine it's more complicated these days! The printer manual would help... some... probably...
If it's something else... a cable to another computer, perhaps, the receiving end might have some responsibilities like sending an ACK(?). The "linux nobody" mentioned that the value remained 0FFh... If this was determined by means of an LED readout (as opposed to simply reading the port - 0FFh is what I see when I try to read the IDE controller from win98, for example), that would be ideal. Unless I'm mistaken, there are plans for such a device in the old AoA16 "lab manual" available at Webster - probably easily found other places, too. If someone had the ambition to build such a device... Failing that, I'd at least display every byte I read back... But I lack confidence in what I might read back from an OS that might be "emulating" things...
You can get the basic info on the ports from Ralf Brown's Interrupt List ("ports.lst", not "interrup.lst", of course). I imagine a google for "parallel port FAQ" would turn up more than you want to know. Maybe if you show us what's not working, somebody can spot something...
Best,
Frank
