QuickBasic Cafe Forum

I've read several forums and they all seem to agree on the way to output data to the parallel port, using OUT. Makes sense.

The question, then, is: why doesn't this work?

956 = output port on an IBM laptop.

d%=inp(956)
print d%
o%=118 : out 956,o%
d=inp(956) : print d%
o%=23 : out 956,o%
d%=inp(956) : print d%

I should get <unknown>, 118, 23. Right?

Well, when running under XP, I get <unknown>, <same unknown>, 23 on the first run. On all subsequent executions, I'll get 23, 23, 23.

If I run the same code in DOS, I get 255, 255, 255 every time.

Either way, it's just odd. I need to input from the parallel port for my current project, but I'm wondering why this isn't working. I even read through the QB manual, and the instructions couldn't be simpler.

(This is using QB 3.0. Maybe I should try 4.5?)

Thx.

R. Barr

Definitely use QB4.5

You must be the last (only) person who even has a copy of 3.0

(I talk - and I only use QB 1.0 - The version supplied free by Microsoft with my Windows-NT system)

Mac

OK, I downloaded 4.5. Haven't played with it much yet, but it looks like it has quite a number of new features to explore & play with. The HELP is built-in now! I'll still keep my manual -- all 8 pounds of it, or whatever it weighs...

Anyway -- apart from the mistake in line 4 (there should be d% instead of just d), the program yields the same result. If I run the program maybe ten times in a row, I'll actually get the '118' I expect as the 2nd line of output.

WTH?

It's an unfortunate fact of QuickBasic that when running in any of the NT systems the ports are not direcly accessible even when running in the Command Shell (often called Dos but it isn't). There's a good read here http://www.beyondlogic.org/porttalk/porttalk.htm

Another possible workaround is here http://qbasic.com/classic/files/qbserial.zip

I have not tried either of the above workarounds, I have a working Win 98se system for port work.

Good luck

[/url]

Not really having much luck here. To avoid any NT complications, I'm using a DOS 6.22 boot disk, running in strictly DOS, and adjusted the code like this:

defint d,o

DOG:
CLS
d% = INP(956) : PRINT d%
o% = 118 : OUT 956,o%
d% = INP(956) : PRINT d%
o% = 23 : OUT 956,o%
d% = INP(956): PRINT d%
END

All I can get for output is three x 256.

256
256
256

I get the same results when looking at 957, and that's the problem; that's the status port, which is where I intend to read my input. All it tells me is 256 x 3, again.

Who knows? I'm going to try this on a desktop machine, as soon as I figure out where its LPT1 lives.

Thanks for the suggestions.

I think your calculation of 956 being the port address is incorrect. 956 is possibly being written to by the system thereby returning decimal 255 every time. I changed the port address to 888, a more familiar one, and ran your code in the QB IDE under Win ME without problem. Here's the code I used:
The screen output is:
234
118
23

BTW when programming ports I have found it much easier to name the port, then if the port number must be changed there's just one change to make - such as:
And you can save a bit of coding by not using o%= or d%= --

OUT outport%,25
PRINT INP(outport%)

will work just as well.

Just a thought....

Valerie wrote:I think your calculation of 956 being the port address is incorrect. 956 is possibly being written to by the system thereby returning decimal 255 every time.

Actually the 956 is correct, normal for an IBM Thinkpad. I can go into Device Manager and examine LPT1, and the resources listed are 03BC-03BE, which is 956 decimal.

I went into it and altered the configuration to set the LPT1 port to 888. If I cut and paste your exact code, I'll get 234, 234, 234 every time. It obviously executes the first OUT, and it seems to ignore any OUT statements afterward. There's no doubt the program hits those lines of code, since it also executes the INP and PRINT.

I think it has something to do with this being a laptop. (Maybe...). All I want to do, in the long run, is read the status bit, which would be 888+1 (or 956+1), when I discovered that the OUT isn't doing anything after the first encounter of it.

Weird.

Robertbarr wrote:Actually the 956 is correct, normal for an IBM Thinkpad. I can go into Device Manager and examine LPT1, and the resources listed are 03BC-03BE, which is 956 decimal.

You are, of course, correct about the 956 port address. I should have done a bit more research before jumping in with both feet Apologies.

I haven't come up with a solution to your problem but still looking.

V...

Aha! Results.

I used a DOS 6.22 diskette, booted into DOS and used Valerie's code, and it worked just like it was supposed to.

I modified it a bit:

defint d,o,p,x
portid=966

DOG:
CLS
d% = INP(portid) : PRINT d%
print "*" inp (portid)
out portid,118
print INP(portid)

for x=1 to 221
OUT portid,x
print INP(portid);
next
END

This spits out 1 - 221, as one would expect. The odd thing is, it changes the screen color. Different upper limit values will leave the screen different colors (which means it's doing it for each x, but just too rapidly for me to notice). Kind of suggests that it's not the parallel port I'm writing to!

When I change portid to 888, I get nothing but 256 for output, so that can't be the right port ID either.

Next step is to introduce some +5 to a few of the Status bits, to see if I can read them by a similar approach. This should be child's play, but it keeps acting weird.

Great news about port 966, did you try 956?.

I've so far had success with Win.ME and bombed with W2k/pro, XP Home, XP Pro. Haven't been able to devote a lot of time to this gem of a problem but will shortly try barebones Dos 7.1 (yes, Wengier Wu's version) and Win.98se.

Pity tho', I've not got any IBM hardware (implying IBM bios) to try it on.

Congrats on your find.

Valerie wrote:Great news about port 966, did you try 956?.

D'oh! Maybe that explains the screen color weirdness. Yes, it's a typo, and it's in the code. So when I 'try' 956, I'm back to where I was.

The more I read about this, the more confusing it gets...

I'll be happy if I can just find a way to read into VB the presence or absence of +5. So if I put +5 WRT ground on pin 11 (the 'Busy' bit #7 of the Status Port), read the port and AND the result with 128, I should get 128. If I remove the +5 and repeat, I should get zero.

I think I'll start a fresh post and explain what I'm up to...

Success at last!

I found some documentation on the control register, and use pins 12 and 14; they have to be pulled low with a resistor to ground. I've experiemented, and found that the highest resistance I can use is right around 1.4k ohms.

This presents just a minor problem: instead of just taking +5 from the sensor to use as an input signal, I now have to switch the pin to ground via a resistor. Solution? Reed switch. One for the start beam, and one for the finish. Adds about $7 to the project cost, and it's a little heavy-handed, but I'm ready for a solution to this! I'm sure there's a less expensive, more elegant way to do this, but -- so what.

Since the reed switches should take about the same amount of time to actuate, there should be no influence on the timing.

It was a real relief to FINALLY watch a number on the screen change values when I provide and remove continuity. (... without destroying the parallel port on an IBM laptop...) I t only took me half a week!

I just wanted to say 'thanks' to everyone who offered suggestions.