🚀 go-pugleaf

On Thu, 21 Jun 2001 00:05:08 -0500, agreenb@uab.NOSPAM.edu (Adam
Greenberg) wrote:

>Ok, I wrote a program about 2 years ago that will poll the "busy" pin on 
>the parallel port.  It's accepting a TTL pulse and waits for a change in 
>status value before doing something.  It was compiled as 16-bit on a 
>laptop running Win98.  We got a new laptop and I tried moving the 
>executable over and it didn't work (after intalling all the necessary 
>16-bit dlls into Win/Sys directory).  Then I tried recompiling and that 
>didn't work.  So, I downgraded the new laptop to Win98 and that didn't 
>work either.  I am using the interrupt function in vbasm.dll to gain 
>access to the port.  It seems to be able to read from the port once and 
>then (although the TTL value changes) the value read doesn't change the 
>way it used to.  Anyone know why this would not work on a new laptop?  
>Also, in the BIOS I noticed that there are the following options for the 
>"mode" of parallel port:  output only, bi-directional, EPP, and ECP.  
>Anyone know which of these is best for what I'm doing?  Unfortunately, I 

Was it set to Output only?  I'd first try bidirectional.  I've long
since forgotten what EPP and ECP stand for, but I'd try those next.
Pretty sure when the output only mode is set, that the parallel port
doesn't care if there is a busy or not.




>don't have access to the old laptop anymore so I can't look up the BIOS 
>settings on that one, but I'm sure they were standard settings (whatever 
>those are).  Here's the snippet of code that calls the busy pin:
>
>Global Const IntNum = &H17
>
>'power the device by turning on data lines
>InRegs.AX = &H7
>InRegs.DX = &H0
>Call vbRealModeIntX(IntNum, InRegs, OutRegs)
>'Status Request Parameters
>InRegs.AX = &H2000
>InRegs.DX = &H0
>TriggStat = OutRegs.AX
>
>'Read from the port
>Call vbRealModeIntX(IntNum, InRegs, OutRegs)
>TriggStat = OutRegs.AX
>Text1.Text = TriggStat
>
>Maybe my addresses are off for the new machine?  I never really 
>understood how those worked (I lifted them from something else I saw and 
>they just worked).  Thanks for any and all help.
>-Adam

What I see your program doing is using INT17H (Printer Driver Entry Point)
to handle the printer stuff. You're turning on bits 0, 1 and 2 with the
first call and the second call is reading the "Out Of Paper" pin on the
parallel port.  Assuming that the InRegs.xx stay the same, that's the pin
that you're sensing for the signal.
Things that you need to do is to insure that the parallel port has pullups
on the output lines that will drive the outside electronics properly
(dongles, etc. tend to use some of the output lines as power supply lines!)
or you will have problems there.
I might note that the link between the hardware and what the software can do
is becoming more tenous with each rendition of windoz and you may want to
see what it takes to actually start dealing with the hardware through the
windoz services rather than walking roughshod over the windoz restrictions.
--
Bob May
Remember that computers do exactly what you tell them to do, not what you
think you told them to do.

"Adam Greenberg" <agreenb@uab.NOSPAM.edu> schreef in bericht
news:agreenb-2106010005080001@dsl-64-34-93-149.telocity.com...

> Global Const IntNum = &H17
>
> 'power the device by turning on data lines
> InRegs.AX = &H7
> InRegs.DX = &H0
> Call vbRealModeIntX(IntNum, InRegs, OutRegs)
> 'Status Request Parameters
> InRegs.AX = &H2000 <------------------------------------------ &H0200
> InRegs.DX = &H0
> TriggStat = OutRegs.AX
>
> 'Read from the port
> Call vbRealModeIntX(IntNum, InRegs, OutRegs)
> TriggStat = OutRegs.AX
> Text1.Text = TriggStat
>

And if you change the value of InRegs.AX to &H0200 as indicated above?

Regards, Theo Meester.

That's not a valid pin.

--
Bob May
Remember that computers do exactly what you tell them to do, not what you
think you told them to do.