Parallel Port Interfacing

[burhanmz]

hello all.
this is my first post here..
i need a bit of help with interfacing  parallel port

i am blinking 8 leds, one at a time. please check my code and tell me, whts wrong with it.. because i'm not getting the desired out put
*********************************************************************************************************
STSEG SEGMENT STACK 'STACK'
DB 64 DUP(?)
STSEG ENDS

DTSEG SEGMENT

DTSEG ENDS

CDSEG    SEGMENT
   MAIN PROC
   ASSUME  CS : CDSEG, DS : DTSEG, SS : STSEG
   MOV AX,DTSEG
   MOV DS,AX
   
   mov ah,1
   mov dx,0
   int 17h           ; initialize parallel port
   
   
   MOV AL,01H
   MOV CX,0AH        ; loop 10 times
   
ORDER:   PUSH CX
   MOV DX,03BCH        ;the port address i checked from debug, that responds to my leds
   OUT  DX,AL
   CALL DELAY
   CALL DELAY
   SHL  AL,1

   MOV  DL,'*'              ; print an * after every (hopefully ) successful 'out' to port
   MOV  AH,02H
   INT  21H

   MOV  DL,0AH       ;enter/change line
   MOV  AH,02H       
   INT  21H
   
   POP  CX      
   LOOP ORDER
   JCXZ EXIT
   


DELAY:    MOV  CX,0EFFFH                      ; a 2.8 sec delay function/ routine thats called after and 'out'
OUTER:   PUSH CX
   MOV  CX,0FFFFH
INNER:   LOOP INNER
   POP  CX
   LOOP OUTER
   RET


EXIT:    MOV AH,4CH
   INT 21H


MAIN    ENDP
CDSEG    ENDS
   END MAIN
********************************************************************************************************
i am using dos under windows xp.. and from debug mode, i can write data to port 03bc, only problem is, when  i enter this
-o 03bc 00           ;assuming all leds were ON
                          ; after a 5 second delay all leds turn off
why is there such a long delay to execute a direct command
my system specs
windows xp pro sp3 constantly updated
Ram 3GB DDR2
Processor 2.8GHz dual core intel


my connections with parallel ports
pins 1, 10 to 25 > all grounded through external power supply
pins 2 to 9   connected to leds through a IC, ULN 2803 (invert buffers)

here is a circuit pic

[BogdanOntanu]

Windows does NOT allow proggrams to have direct access to ports.
Only drivers (signed in VISTA) have this privilege in Protected OSes like Windows and Linux/ Unix.

Hence you either:
1) Write a Windows kernel driver (pretty hard)
2) Use an already made one that gives you access to your ports (for example GiveIO)
3) Test your application in pure DOS (not in a DOS box window in Windows)

When running old 16 bits programm sin a DOS box window then Windows will EMULATE some (but not all) of the commands when it "feels like it" and IF "it feels like it". The ideea is to allow older programs to run BUT if you do something new then Windows might not agree with you.

You might experience delays or simply abnormal behavior with old 16bit DOS program in Windows. The ideea is clear: if you have an old programm that used to work then you can give it a try, or if you use the exact same INT's that the old programs used then again you might have a chance.

BUT if you write something new... then forget about it or use DOS!

About your code:

On a fast first glance you use AL to output to the port BUT AL will be changed by the code below it (INTs) hence you should save it somehow.

Also in your circuit diagram you did not write the names of the pins hence we can not verify if your connection (esp the handshaking on the parallel port) are OK.

[MichaelW]

burhanmz,

I agree with Bogdan that it would be best to test your program under DOS (or Windows 9x) first.

I see a potential problem with your port address. Running under DOS, and probably under Windows 9x (don't recall), the BIOS data that you see in DEBUG is the actual BIOS data, but under Windows 2000/XP it's not. For example, running under Windows 2000 on my system DEBUG shows:

0040:0000  F8 03 F8 02 E8 03 E8 02-BC 03 78 03 78 02 C0 9F

When the system actually has only one serial port with the base address 3F8h and one parallel port with the base address 378h. I think the additional address, or perhaps all of the address, are for 'virtual' ports. I'm not sure that using the actual port address will correct any problems, and if Windows is using the port it may cause Windows to block the access and/or complain, but I think it's worth a try.

Since you are using the BIOS to initialize the parallel port, why not use the BIOS to send your data?

I think you should consider replacing your processor-dependent delay loop with one based on the system timer. The BIOS maintains a count of the timer ticks since midnight in the BIOS data area at offset 6Ch. It's fairly easy to create a programmable delay based on the least significant word of this count. Basically, you capture the count, add some appropriate number of ticks (one thick = 1/18.2s or ~55ms) to the captured value, and then loop waiting for the count to reach the new value. I have doubts that the parallel port access will work correctly under Windows, but at least under Windows 2000 this timing method will.

[FORTRANS]

Hi,

   Two small comments:  You are pulling to ground some output pins.
Probably not a good idea, check the parallel port pinouts.  A 64 byte
stack is too small on some systems.  My windows 2000 box requires
more than 256 bytes if I change video modes.  That caused a program
that worked on other another of my computers to crash.  A discussion
on a usenet group recommended > 512 bytes.

   I agree with MichaelW's comments about the delay routine.  Using
the system timer is fairly easy.

Regards,

Steve N.

[dedndave]

pins 18-25 are grounds - 2-8 are data - you don't need to connect any of the other pins
no resistor values are given - but should be 390 ohm or so
you do need to have access to the ports - it will work easier in win95/98 where that was allowed
and - if the led is only on for a millisecond, don't expect to see it

[vanjast]

Have a look over here..
http://www.hardwarebook.info/Parallel_(PC)

From this site   http://www.hardwarebook.info/
:8)

[dedndave]

to run the LEDs, he won't need any handshaking

[vanjast]

Grounding the O/P HS lines will cause 'shorts', eventually destroying the driver chip.
And he must make sure that the HS signals are set to their correct various states to make sure the BIOS/Driver does not see the incorrect Port state or his code will not work.
:wink

[dedndave]

i think he's lucky on that one - lol
if i remember correctly, they are open-collector outputs - lol
it has been several years since i designed anything to connect to a parallel port

[vanjast]

I'm not sure about Open collector as the original 8255 chip wasn't OC.
It might have changed, but probably not as the parallel port is not a multidevice port.
It's also a long time since I've bothered to look at it too.
:bg

[dedndave]

the chips' outputs were never tied directly to the port
back then, they used npn transistors - i am sure that has all changed now and they are CMOS
the collector of these transistors had a pull-up resistor
that way, they could be wire-or'ed as they called it
several outputs could be wired together - if any of them were low (any on), it was low
if none of them were low (all off), it was high

[vanjast]

Did a quick recap..
burhanmz might find this usefull

http://www.beyondlogic.org/spp/parallel.htm
http://logix4u.net/Legacy_Ports/Parallel_Port/A_tutorial_on_Parallel_port_Interfacing.html
http://www.epanorama.net/circuits/parallel_output.html
:8)