Blitter interrupt during VERTB interrupt
In an unnamed project I have a queue with several 16x16 tiles to blit (each node has bitmap and tile image address). I thought about processing the queue with Blitter interrupts, so I am free to run any code I like while the Blitter is busy.
The problem: My main program is running in a VERTB interrupt, and I am probably confused. Both are level 3 interrupts, so the Blitter can never interrupt my program, right? Does it make sense to change the interrupt mask with "MOVE #$2200,SR" during my VERTB interrupt to allow new level 3 interrupts again? I really would like to have both: run my program in VERTB and use Blitter interrupts... |
Read INTREQR to check what kind of level 3 interrupt was triggered (copper, blitter, vertical blank) and acknowledge them accordingly.
|
Hmm? Are you saying that Copper, Blitter and Vertb interrupts can interrupt each other?
That would be easy... To clarify: I want several Blitter interrupts to be processed WHILE the VERTB interrupt handling is still running. |
Quote:
The only way to get a same level IRQ is as you say, but you have to clean INTREQ VERTB first to avoid immediate re-trigger. Or poll BLIT bit at some time in your VBL routine.. (not so good). EDIT: and warning, the following VERTB can trigger :) (so better some semaphore in code) |
Ahh, ok! Thanks. Makes sense.
The following VERTB should not interrupt me, otherwise my game engine is too slow and I have to optimize it. ;) |
I think the best way to achieve this is to trigger a SoftInt (which is level 1) at the start of the vertical blank interrupt, then do the job in that new int.
Then this work can be interrupted by a level 3 interrupt and you have no risk of reentrancy. How exactly this is done, depends if your code is OS friendly or not. |
VBL won't interrupt Blitter handler and vice versa. You'll need one handler and then check INTREQR bits and clear them appropriately, as pointed out above.
Something like: Code:
btst #6,$dff01e |
Quote:
If your "new VBL Level 1" is interrupted immediately by a blitter storm, and you needed to make some init before some raster position, you can have bad video glitch. EDIT: indeed these are only theoretical speculations, if the BLIT or VBL IRQ drivers are slow then there is something wrong in code :D |
Quote:
|
Quote:
|
Indeed, I quite like the soft-int solution. Will think about it.
Thanks for your comments! |
Quote:
Quote:
|
Hi dissident! Good ideas in your post but .. how to make them coexist real-time copper video effects with blitter register write that copper should do in "random" moments?
Create a (slow) copper list that already contains all possible blitter register writes in every lines? [EDIT: yes, you can insert a simple COPxLC/COPJMPx pair, but then you need to limit your CMOVEs to defined quantity to not disrupt CWAIT code when you are back in the original list] And there also the question of double writes to "slow bus".. first write to chip ram to fill copper list, then from copper to registers. phx is not talking about a demo in which you manage the limitations you are subjected to, but a game where you have to make switches of various colors each line, modify BPLxPT, multiplexing sprite or who know :) I'm not against this method, but I think that is useful for CWAIT (with BFD=0) in vertical video blank period only. And then in that case COP2LC/COPJMP2 idea is applicable. I vaguely remember that i've debugged something similar. |
Quote:
How many cycles will pass, when blitting a 16x16 tile with 5 planes and mask? All DMA channels used. Quote:
Quote:
Quote:
|
Quote:
Well, there are actually several reasons for this choice. But too OT, maybe for another thread ;) |
There is not much gained by running CPU and blitter simultaneously if blitter cycle sequence does not have any idle cycles (which are always available for the CPU. Don't waste them!). In no-idle-cycle case CPU is immediately (technically after 2 or 3 cycles) blocked until blitter finishes.
IMHO it is practically only useful when clearing (every other blitter cycle is idle cycle) or D=A filling (every 3rd cycle is idle cycle). All other common channel combinations don't have idle cycles. Only exception is if code is running in real fast ram. (or blitter nasty not set but why would you do that in a demo or game?) |
Quote:
For OCS, assuming the steady registers are already initialized and the A&B-pointers point to the repeated bar/mask pattern (8 colours) in memory which are increased after every blit automatically, this could look like this: The CPU only changes the $xxxx positions, the display starts at $2C and is visible within the positions $81-$1C1, the blit and the BPLxPT updates are done in the horizontal blank area. Code:
DC.W $0040,$xxxx ;BLTCON0 Quote:
Quote:
Quote:
|
Quote:
Quote:
Code:
8*16*5*2 BTW: Why do you use all channels? I suppose these are your blits to copy objects in to a background picture. Quote:
COP2LC-jump-pos already initialized by the CPU. The CPU only changes $xxxx. Code:
cop1 Quote:
Quote:
Code:
DC.W $2C01,$7FFE ;Wait y-pos & pseudo waitblit |
Toni is certainly right. This discouraged me so much that I reverted all my Blitter interrupt code last night. So I will just set Blitter to Nasty and copy all masked tiles.
|
Quote:
Thanks for the examples with the Copper blits. I have to think about it. Maybe there will even be enough room after the last sprite-multiplexing in the middle of the screen (for a parallax effect). There shouldn't be much copper activity until end of frame. |
All times are GMT +2. The time now is 21:39. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.