VB and realtime interrupts

02-21-2002, 04:18 AM
Does anyone knows how process interrupts in real time using Visual Basic?

02-21-2002, 04:24 AM
Uh, what kind of interupts do you mean? Hardware interupts?

02-21-2002, 05:13 AM
Yes, hardware interrupt, and/or not only. I think for game programming and i/o data sampling (i.e. a/d sampling) a reliable real-time interrupt could be very useful, for playing sound, get data from joysticks, moves sprites smoothly and so on... There are some controls (like the timer control in VB) that invoke timer events but the are always delayed by windows if the o.s. has others things to do with higher priority so i'm asking if someone knows a way to have a REAL-time interrupt software or using an hardware to stimulate the event of an accurate timer...
I.E. in the old Commodore 64 it has 3 interrupts RESET/NMI and IRQ, with IRQ you was able to manage everything with high accuracy. Obviously the interrupt task must be very quick and small.

02-25-2002, 03:20 PM
The most basic interrupt is the Int(0) or the Timer Interrupt. This will ALWAYS give you an accurate reading. Here's a good example of how to use it VB. http://www.mcselec.com/an12.htm

02-25-2002, 03:31 PM
You can't use hardware interrupts from VB.
You could screw up the complete windows enviroment with it, don't forget it's a not a single task OS like on the C64.

02-25-2002, 03:32 PM
The code in the link is NOT visual basic code.

02-25-2002, 03:41 PM
Just checked. It is not VB it is BASCOM (maybe).
In BC7 (Microsoft Basic Compiler 7) a full set of instruction allows to manage hardware and software interrupts. It is not so in VB, i'm understanding due to the o.s. architecture. BUT: when you use mscomm.ocx you have a buffer of the serial com. This mean that a special task is always awake to get quickly data incoming from the serial uart (hardware), this mean that an OCX very quick can be built to perform hardware task. The clock that generates the increase of TIMER function, that give back the value of milliseconds elapsed from the midnight must be generated by the hardware, i would like to discover if there is a way to intercept this interrupt to generate a fast and reliable interrupt task to use generally in all kind of VB programs.

02-25-2002, 03:58 PM
There are two types of interrupts as you know, hardware and software. Hardware interrupts cannot be intercepted or "chained". Software interrupts can. There is a difference between between a standard function call and an interrupt call. When a standard (local) call is made to a subroutine the caller "pushes" all variables onto the local stack buffer and the subroutine is responsible for returning the stack to it's pre-call state. An interrupt routine has to do 3 things.

1) Perform it's function (of course)
2) Call the interrupt's previous handle (so everybody else who has "chained" to it can get their processing in
3) Clear the stack to pre-call state.

ALL interrupt code MUST be in assembly. It doesn't strictly require assembly, but you need very quick code here.

Everything I just mentioned is beyond the scope of VB. It doesn't allow access to the local stack, or support pointers.

Intel puts another block in front of you by it's seperation of stacks. Your interrupt's previous handle must be called, but in order to do that you have to store the previous address. It would then be stored in the "data stack". You cannot call an address from the data stack. You may only do that from the "code stack". There is a work-around but it's rather involved. If you want to know about just let me know. But for the sake of time and space I'll leave it out for now.

But it would make an interesting challenge, wouldn't it?

02-27-2002, 06:06 AM
I appologize, I gave a bit of incorrect information. You CAN chain to hardware inrerrupts, but only through PIC (Programmable Interrupt Controller). It's the method used to do low-level sound and multimedia control. By low-level I mean actually talking to the hardware.

When talking about software interrupts you note them as INT 0 INT 1, ect... When talking about hardware interrupts you use IRQ 0, IRQ 1, ect...

02-28-2002, 05:25 PM
Remember that the only time you'd even need this sort of control is if you were writing a device driver. The whole point of device drivers is that the application programs do not need to know how to access the hardware. They all work through the API and windows (though the device drivers) talks to the hardware.

If you are trying to write a device driver then for God's sake don't do it in VB. C or assembler would be better suited. If you are coding an application (a game perhaps then use the API. THe waveIn* and waveOut* function handle sound, the joy* functions do joystick input and there are many functions for timing events.

EZ Archive Ads Plugin for vBulletin Copyright 2006 Computer Help Forum