IRQ

[Ed Minchau]

On 5/27/2022 at 10:55 PM, svenvandevelde said:

Ed, may I ask, does the technique to process the VBLANK in the main loop (outside of the interrupt) help with the frame rate? I mean, I notice that during my IRQ processing, that if the CPU time goes beyond the available time to process one frame, then the logic "stutters" and is noticable. When processing the frames in the main loop, this might help, isn't it? because the main loop can just take it's time to paint, while the interrupt will handle the coordinates of the objects to be painted ... hmmm... might consider.

Well, I have a couple of routines that take a really long time. The subroutine that redraws the asteroid if you move or rotate your view takes about 2 million cycles. When it's in the middle of doing its thing it's using both VERA channels and bouncing around in various RAM banks.

I have that subroutine broken up into 22 parts, though I could break it up further if necessary. Each time it's starting a new part of the asteroid to draw, it sets the VERA channels. So, in between each of these 22 (or 44, or whatever I eventually decide) parts, it checks the flag bits set by the IRQ and does whatever (very short) subroutines it needs before returning to the next part of the Draw routine. 

My IRQ just alerts the rest of the program that an event needs to take place, and regular checks of those flags in the rest of the program allows those VERA channels to be switched to different addresses without affecting other subroutines, and without the dance of addresses required if doing things within the interrupt subroutine. 

[svenvandevelde]

So how do you manage to process interrupts at a specific scan line?

[desertfish]

use IRQ_LINE https://github.com/commanderx16/x16-docs/blob/master/VERA Programmer's Reference.md#interrupts

[svenvandevelde]

On 6/12/2022 at 8:39 PM, desertfish said:

use IRQ_LINE https://github.com/commanderx16/x16-docs/blob/master/VERA Programmer's Reference.md#interrupts

My question was meant in reply to Ed comment ... but thanks!

On 6/9/2022 at 5:57 AM, Ed Minchau said:

My IRQ just alerts the rest of the program that an event needs to take place, and regular checks of those flags in the rest of the program allows those VERA channels to be switched to different addresses without affecting other subroutines, and without the dance of addresses required if doing things within the interrupt subroutine

So how do you manage to process interrupts at a specific scan line?

 

[Ed Minchau]

On 6/12/2022 at 8:44 PM, svenvandevelde said:

My question was meant in reply to Ed comment ... but thanks!



So how do you manage to process interrupts at a specific scan line?



 

I don't. I just have things that need to happen at some multiple of 1/60 second instead happen shortly afterwards.  I break long sections of code up into multiple sections ( each should be much less than 1/60 of a second), and then in between those sections call the HandleFlagsAndEvents subroutine, a very short chunk of code that checks for things like the ClockRisingEdge flag (which is set by my IRQ).  If that flag is 1, then any events that need to use the VERA channels or RAM banks are free to do so.  These events need to be very short, such as pushing a 64 byte buffer into the PSG memory.  After events like that are handled, control goes back to the long subroutine.  Ideally HandleFlagsAndEvents is called many times every 1/60 of a second, does almost nothing most of the time and returns quickly.

[Michael Kaiser]

On 5/26/2022 at 6:07 PM, Ed Minchau said:

I'd have the IRQ do as little as possible. For Asteroid Commander it just updates a couple of bytes set aside for flag bits. The main program then checks those bits a couple hundred times a second, each time a major subroutine is finished and at least once for every trip through the main loop.

Just the reverse.  I like to put the screen update in the IRQ and the game logic in main loop.  Furthermore I use ONLY a raster IRQ which starts when the beam goes of the bottom of the screen.  That way I should update the screen between the time the beam leaves the bottom of the screen and it reaches the top of the usable area.  No tearing and no flicker if you do that.

[Ed Minchau]

On 8/3/2022 at 10:00 AM, Michael Kaiser said:

Just the reverse.  I like to put the screen update in the IRQ and the game logic in main loop.  Furthermore I use ONLY a raster IRQ which starts when the beam goes of the bottom of the screen.  That way I should update the screen between the time the beam leaves the bottom of the screen and it reaches the top of the usable area.  No tearing and no flicker if you do that.

I find I'm now using a mixture.  On the video demo I just uploaded, the PCM audio files are loaded within the custom IRQ when the AFLOW flag is set.  The IRQ also keeps track of the number of "ticks" of the VSYNCH, and every fourth tick it sets a flag.  The main program looks for that flag and when it is set loads a video image and pushes it to VERA. This causes it to occasionally miss the signal to load another video frame, so by the end of the demo the audio is slightly ahead of the video.  At least, I think that's what's causing the lag.