irq 5 chaining(parallel.port)

[randomnumber]

i am trying to interface a device using the parallel port.. there are external sensors on the outside and when they sense something,, they should invoke irq5 by changing the acknowlege bit of the status register changes from 1 to 0. the resident irq changes the data register to 04h. Thus the isr for the irq is working perfectly.

but i need to chain the irq to another memory resident ISR.. i have tried the following code but it doesn't work. Afta running the program, changing the ackwoldge bit doesn't change anything know.. the previous procedure is certainly removed but the new one doesn't seem to work.. :( i have tried changing to irq 7 but its stil doesn't work..

ps: i have already bypassed xp restriction on direct hardware referencing..

[BogdanOntanu]

Your program is not so big and because of this it does not need to be an attachement.

Again your program does use int 21h hance it belongs in the DOS sub-forums.

And you might dream that you have bypasses XP direct hardware access protection but you did not.

XP will emulate an environment for old DOS applications and you might think that you have direct hardware access like that but you do not have it.

Instead XP will monitor and emulate a few well known hardware access cases in order to allow older but "still useful" applications to run. IF your application tried to perform an action that XP is not aware or does not agree with then your application will (most likely) silently fail.

I suggest you try this kind of direct hardware access in "pure" DOS mode ... ie run it in a machine booted in MS-DOS or FreeDOS and NOT in a console window in XP.

Additionally you can use an virtual machine like Virtual PC or VMWare or VirtualBox that runs DOS as a guest OS in XP.

The int 21 and int 27 are too old and "obsolete" for me to remember what they do anymore... a few comments on your code would have helped ....

However  I did notice the folowinf issues:

1) that you do not acknowledge the IRQ to the IRQ controller inside your ISR and this might prevent the next IRQ from firing.
2)You also "pushf" and do not "popf" ...
3) 0Dh in AL in int 21h means irq 13 and not irq 5 or irq 7 .... are you sure you want to "hook" the parallel port :P ?

Here is what you have in that zip ... for others to see:

Code Select Expand


.model small

.stack
.code

start:

jmp load_prog

testISR proc far
push dx
push ax
pushf

mov dx,0378h
mov al,0bch
out dx,al

pop ax
pop dx

iret
testISR endp

load_prog proc near
mov dx,offset testISR
mov ax,250Dh
int 21h
     
      mov dx,offset load_prog
      int 27h
load_prog endp
end start


[MichaelW]

AFAIK running under the NT versions of Windows you cannot use a TSR. One method that will work, under these versions of Windows as well as under DOS, is to make the handler a part of the DOS EXE that installs and uninstalls the handler. The attachment contains an example that hooks interrupt 8 / IRQ 0.

[randomnumber]

\\bodganontanu i am using this to reference the parallel port isr location.

http://www.htl-steyr.ac.at/~morg/pcinfo/hardware/interrupts/inte6l0w.htm Thus by choice for 0D for irq5 and 0F for irq7
is this the rite way?

are you sure you want to "hook" the parallel port

  ? i need to execute a task depending on my external inputs to the para port. The inputs are constantly changing.  I can easily make a prog that monitors continuously the parallel port but i will need a fast processor and its not guaranteed that my intended task will be executed since the inputs may change b4 the comp reads them.. but why i believe the interrupt will serve me better..

\\michaelw

AFAIK running under the NT versions of Windows you cannot use a TSR

as i understand it. the new procedure should be in memory at all times in order for the irq to do the intended task. if YOUR program exits, it WON'T use the new isr.. .. right? so i should find a way to make the program loop continously until a sentinel is supplied?

[BogdanOntanu]

\\bodganontanu i am using this to reference the parallel port isr location.

http://www.htl-steyr.ac.at/~morg/pcinfo/hardware/interrupts/inte6l0w.htm Thus by choice for 0D for irq5 and 0F for irq7
is this the rite way?

I do not know if it is the "rite" way but it does look like the correct way.
Sorry for missleading but this stuff is so very old and I have made an error.

I can not confirm it but I guess that for DOS your documentation is right.

... but i will need a fast processor and its not guaranteed that my intended task will be executed since the inputs may change b4 the comp reads them..

Generally speaking for real time tasks using an hardware IRQ's is better ... BUT I doubt that this is the case for running an emulated old 16 bits task under XP.

My guess is that the XP OS will handle the IRQ first with all the protected mode drivers stack and IRP's and only then it will eventually call the corresponding INT vector in your emulated 16 bits DOS task ....only much later.... and with unpredictable slowdowns from time to time ....

Because of this even if you use and IRQ (in 16 bits under windows XP) your program will still loose input bits changes if enough stress  is added ....

[redskull]

To offer an alternative solution, you can pick up a PIC microcontroller with the loose change in your couch, which (by design) is much suited to interfacing with external sensors.  For a few cents more, you can get a USB version, and interface it to a PC "the right way".  IMHO, trying to kludge your way through this using NTVDM is more trouble than its worth.

-r

[japheth]

Hi,

as BogdanOntanu has mentioned, your ISR isn't correct. It should look like this:

Code Select Expand


testISR proc far
push dx
push ax

mov dx,0378h
mov al,0bch
out dx,al

mov al,20h
out 20h,al

pop ax
pop dx

iret
testISR endp


Also, you must take care to setup register DS correctly if your program isn't in DOS COM format:

Code Select Expand


push ds
push cs
pop ds
mov dx,offset testISR
mov ax,250Dh
int 21h
pop ds


Generally, I'd say your code should work fast enough in NTVDM. With todays fast cpus it doesn't matter at all whether there is an additional "emulation" level between your code and the legacy parallel/serial hardware.

[MichaelW]

as i understand it. the new procedure should be in memory at all times in order for the irq to do the intended task. if YOUR program exits, it WON'T use the new isr.. .. right? so i should find a way to make the program loop continously until a sentinel is supplied?

The handler would continue to work as long as the program is running. My example simply waits for a key press to occur when it has the keyboard input focus, but it could be coded to wait for practically any event or combination of events. And running under Windows, it should be possible to keep the CPU utilization of the wait loop close to zero by inserting a call to the MS-DOS Idle Call function.

Before you get too deep into this, I think you should run some tests to determine if Windows will allow you to control the parallel port from a DOS program. I recall having problems controlling a serial port from a DOS program running under Windows. And also a problem determining which of the four serial ports shown in the BIOS data area was the "real" port, on a system that had only one. And I recall that the BIOS data area also showed three parallel ports, on a system that had only one.

[randomnumber]

okay... i have officially given  up on irq7 and irq5... they simply don't work.. when u try chaining with another isr.. why? is that a hardware of a software problem? i haven't tried on another computer model..  i have used the irq8 readin 55ms the paraport.. i have just done my 1st test runs an its all thumbs up.. its pretty good with memory.. i also tried the loop program which overloads processor n wasting most tyme doing nothing.. 


\\redskull

To offer an alternative solution, you can pick up a PIC microcontroller

am just starting up with a plc from tomorrow..  i bliv its realy a better solution..

:thumbu :U thks every one.. :cheekygreen:

[MichaelW]

i have officially given up on irq7 and irq5... they simply don't work

I assume that you have some device attached that is asserting the interrupt request pin. One reason for them not working may be that they are disabled at the interrupt controller. Another reason may be that the interrupt request is disabled at the parallel port. The attachment contains an app that reads OCW1 for both of the interrupt controllers and displays the enabled/disabled status for each of the IRQs, and the status of the parallel port interrupt enable for the three most common port addresses. Note that I did not attempt to determine what printer ports are actually present.

[randomnumber]

\\MichaelW

okay.. 2 issues
even when the irq is disabled from the paraport changing, the acknowledge bit of the status port changes the data register to 04h. my assumption is that this is the previous irq. but i don't know why its working when it shouldn't.

after enabling the irq from control register, changing the irq know doesn't do anything.. it surely replaces the other isr but it just doesn't work.