🚀 go-pugleaf

g-man@flowzone.EBay.Sun.COM (Luis Navarro) writes:

>I am trying to write a Windows 3.0 application that uses an assembly
>level interrupt handler to handle MIDI (musical instrument digital 
>interface) input/output and am having some serious problems with the
>data interfacing.  Please read on if you are familar with all or any of 
>the following as they relate to windows programming:

>	1. MIDI 
>	2. interrupt handlers
>	3. assembly level routines communicating with Windows C code

>The following are some more details regarding what I'm trying to do, as
>well as the problems I'm experiencing:

>I have obtained some C/assembly code originally written for interrupt
>driven MIDI communcations in DOS.  The assembly level stuff consists of
>the interrupt handler (an interrupt is generated for every MIDI byte that
>arrives at the MIDI interface) and the data i/o.  The C code uses the
>assembly routines to do the rest.  Now I am trying to use this assembly
>code in a relative simple windows program and am having some great 
>difficulties.

>My main objective is to modify the already existing assembly/C code so
>that the interrupt handler will post a windows message (encapsulating the
>current MIDI data byte in the message).  How does one go about doing this?

You can use the PostMessage() function.  Actually, PostMessage is the ONLY
Windows function that you can call while you are processing your interrupt
(due to the fact that Windows is non-reentrant).  

Depending on the frequency of calls to PostMessage(), you may run into 
problems filling up the application queue.  The default message queue can
only hold something like 8 messages in it.  You can increase the size
of the queue using SetMessageQueue() - be sure to do this before your
application creates any Windows.  Even increasing the size may not be enough.
In my application, I had to introduce my own specialized queueing functions
that my ISR calls.  The queueing functions then post one message to the
windows queue to indicate data in the 'other' queue (the queueing functions
use a flag to indicate whether or not the message has been posted).


>Furthermore, the interrupt handler appears to work in real mode, but not in 
>standard or 386 as if the data buffer (created and declared in the assembly
>code) was empty or if interrupts suddenly weren't being generated at all. 
>Any ideas, advice, or general pointers would be greatly appreciated.

What interrupt are you using?  My app is successfully trapping the timer
interrupt (IRQ0 or Int 8h), but (as you state) in standard or 386 enhanced
mode I was not seeing interrupts on IRQ2 (Int 0Ah) which is a shared 
interrupt with the second 8259 P.I.C. chip.  While I haven't gotten around to 
asking Microsoft, I suspect that Windows is treating this interrupt specially.


Other tidbits that you may already know about:
    1) Be sure to put your ISR code in a DLL with FIXED code and data
       segments.
    2) You probably want to also call GlobalPageLock for the code and data
       segments.
    3) If your hardware uses memory-mapped or shared memory at a fixed
       segment address (say D000:0000 for example), then be sure to convert
       the real mode segment into a protected mode selector.  You can use
       the DPMI service Int 31h to do this.

>--Luis (g-man@EBay.Sun.COM)

Enjoy,

Tom

-- 
Tom Hjellming
Software Consultant
Analysts International Corp. (AiC)
Schaumburg, IL