Under 6.1 RTP a ported 4.25 app that writes values to ports on x86 machines
can’t be made to work, at least when trying to write to port 0x378. The
program includes the call to ThreadCtl(_NTO_TCTL_IO,0), includes hw/inout.h
and replaces outb() with out8(). Since devc-par runs during startup I’ve
even added a “slay devc-par” to a rc.local script. Despite this, nothing
seems to affect the data lines on the parallel port. Does devc-par do
anything that would interfere with using the parallel port and if so how can
I disable the enumeration sequence from loading devc-par at startup?
Thanks.
Yes, I guys from company, got a problem using this port, something
like ECP… it appears works a little bit different…
Harry Qualls wrote:
Under 6.1 RTP a ported 4.25 app that writes values to ports on x86 machines
can’t be made to work, at least when trying to write to port 0x378. The
program includes the call to ThreadCtl(_NTO_TCTL_IO,0), includes hw/inout.h
and replaces outb() with out8(). Since devc-par runs during startup I’ve
even added a “slay devc-par” to a rc.local script. Despite this, nothing
seems to affect the data lines on the parallel port. Does devc-par do
anything that would interfere with using the parallel port and if so how can
I disable the enumeration sequence from loading devc-par at startup?
Thanks.
\
My problem disappeared after I reconfigured the port in the BIOS to standard
(SPP) from ECP/EPP. This setting (EPP) did not affect the my test program
when running under 4.25 so I suspect that devc-par does some detection on
the port and configures it to behave differently. Or else Dev.par is
excluded from the sysinit file (some Dev.pars sigsegv’d on some of our
equipment). In any event, the SPP setting does the trick.
“Claudio Cardozo” <cazo@bol.com.br> wrote in message
news:3CDA87ED.6040502@bol.com.br…
Yes, I guys from company, got a problem using this port, something
like ECP… it appears works a little bit different…
Harry Qualls wrote:
Under 6.1 RTP a ported 4.25 app that writes values to ports on x86
machines
can’t be made to work, at least when trying to write to port 0x378. The
program includes the call to ThreadCtl(_NTO_TCTL_IO,0), includes
hw/inout.h
and replaces outb() with out8(). Since devc-par runs during startup I’ve
even added a “slay devc-par” to a rc.local script. Despite this, nothing
seems to affect the data lines on the parallel port. Does devc-par do
anything that would interfere with using the parallel port and if so how
can
I disable the enumeration sequence from loading devc-par at startup?
Thanks.
\