Interrupts (IRQ)

Note:

The emulator's version of FLEX is not at this point configured to respond to an IRQ, so you must turn off interrupts when FLEX or a FLEX utility command is running unless you have defined a service that will not be disturbed by operations within FLEX and the various utility commands FLEX runs. Remember that some UC's destroy memory in the $C100 area, and others run in low user memory. I would suggest using the higher areas for your IRQ service if you want it to be safe, or using the FLEX memend info & controls to move the end of memory down past your service. However, not all FLEX commands properly pay attention to memend! For this reason, I again suggest using high memory if you expect your IRQ service to run concurrently with FLEX. The $E800-$F37F range is ideal.

The interrupt rate may be set via the Execute/IRQ Timing menu item, which specifies how many 6809 instructions are to go by (multiplied by 20) before an interrupt is generated.

The interrupt capability is not based upon a timer, as Windows 95 offers only a timer with a minimum interval of 55 ms and an interval granularity of 55 ms. The "count of instructions" interrupt mechanism that is implemented for the emulator offers an effective granularity of 20 instructions, or about 100 microseconds for a 1 Mhz equivalent machine.

There's a catch, though (isn't there always?). Because the emulator runs faster or slower depending on the speed of the host computer, the settings for a particular interrupt rate will vary across machines. For instance, the game RB that I supply as a graphics demonstration was designed around a 16.66 ms interrupt. I've provided a default interrupt rate (1200*) that approximates this for my 133 Mhz Micron Pentium. On your machine, the game will almost certainly run too fast, or too slow - and you'll need to adjust the interrupt rate accordingly. You can get "in the ballpark" just by using a ratio between my CPU speed and yours; for instance, if you have a P166, then the ratio of 166/133=1.25 applies, and so your setting would be 1.25*1200=1497.

The application is not multithreaded for the emulation code, so multiple processors shouldn't affect the timing. MMX CPUs likewise shouldn't affect it a great deal as the emulation deals almost exclusively with 8 and 16 bit data items under a large memory model.

What will affect the timing are differences in memory architecture, cache mechanisms, available memory, and for operations that use graphics or large amounts of text manipulation, the display adaptor. If you're looking for a particular interrupt rate, you should be able to get close but you'll have to create a test program, determine the approximate number of instructions per second your machine runs the emulation at, and use that number to set the Execute/IRQ Timing value accordingly.

There is a hidden benefit here, and that is that with an interrupt rate like this, as the emulation slows down due to system factors, the interrupt rate slows in exact proportion, so your program won't be overrun (or at least, it's no more likely to do so that it would be in a real machine.

The Interrupt Mechanism

A very serious consequence of this is that you cannot vary the IRQ rate under program control. If newer versions of Windows 95 (98?) have better timer controls available that allow a more precise emulation of the VIAs, I'll almost certainly modify the emulator IRQ handling to reflect that. I believe that in most every case, a "real" interrupt rate is preferable to what we have now.

The following table describes the various actions available to your programs to control IRQ interrupts:

There are two VIA's. VIA 1 is at $E030-$E03F, VIA 2 is at $E040-$E04F.

Note:

The emulation of the 6522 VIAs is only complete to the degree required for the interrupt and graphics emulations to function.

Below are minimal interrupt service routines. To use them, follow this procedure:

1. Call I_INIT
2. Call I_ON
   • Interrupts begin now, I_SVC is called regularly. Go about your business in the main program until you are ready to stop interrupt servicing.
   • In sections of your code where you can't be disturbed, mask the interrupt by setting the "I" bit in the 6809's CC register. In that case, remember to unmask the interrupts again when its ok to do so.
3. Call I_OFF. You can now change the interrupt service routines, if needed, or you can turn them back on by calling I_ON. Note that it is generally not sufficient to just mask the I bit in the condition codes; before returning to FLEX, call I_OFF. You don't want FLEX to jump into your custom IRQ service, generally speaking. The exception to that is, of course, things like print spooling (which I've not yet implemented).

PSYIRQ EQU  $F3F8
VIA2   EQU  $E040
IERG   EQU  $E
T2CL   EQU  $8
IN_BIT EQU  $10
IY_MSK EQU  255-IN_BIT

I_INIT PSHS D          SAVE REGS USED
       LDD #I_SVC      POINT TO INTERRUPT SERVICE
       STD >PSYIRQ     INSTALL VECTOR TO PSYMON
       PULS D,PC       RETURN TO CALLER, REGS INTACT

I_ON   PSHS A          SAVE REGS USED
       LDA  #%11000000 TURN ON IS B7=1, T2 FLAG IS B6
       STA  >VIA2+IERG HIT VIA, TURN T2 INTERRUPTS ON
       ANDCC #IY_MSK   ALLOW IRQ'S
       PULS A,PC       RESTORE & EXIT

I_OFF  PSHS A          SAVE REGS USED
       ORCC #IN_BIT    DISALLOW IRQ'S
       LDA  #%01000000 TURN OFF IS B7=0, T2 FLAG IS B6
       STA  >VIA2+IERG HIT VIA, TURN T2 INTERRUPTS OFF
       LDA  >VIA2+T2CL MAKE SURE LAST POTENTIAL IRQ IS ACK'ED
       PULS A,PC       RESTORE & RETURN

*
* REMEMBER: THE IRQ INTERRUPT STACKS EVERYTHING, SO YOU'LL
*           NEED TO ALWAYS HAVE ROOM FOR ALL THE CPU
*           REGISTERS ON THE STACK WHEN USING IRQ SERVICING,
*           PLUS ANY REGISTERS YOU SAVE LOCALLY ON THE STACK
*           WITHIN THE IRQ SERVICE.
*
I_SVC  LDA  >VIA2+T2CL "ACK" INTERRUPT & DROP T2 IRQ FLAG
*
* HERE IS WHERE YOU INSERT YOUR CUSTOM INTERRUPT CODE
*
       RTI             RETURN FROM IRQ SERVICE