English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 27 November 2017, 15:18   #1
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,883
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...
phx is offline  
Old 27 November 2017, 15:24   #2
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,629
Read INTREQR to check what kind of level 3 interrupt was triggered (copper, blitter, vertical blank) and acknowledge them accordingly.
StingRay is offline  
Old 27 November 2017, 15:52   #3
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,883
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.

Last edited by phx; 27 November 2017 at 16:04. Reason: Clarification
phx is offline  
Old 27 November 2017, 16:14   #4
ross
Defendit numerus

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 3,247
Quote:
Originally Posted by phx View Post
Hmm? Are you saying that Copper, Blitter and Vertb interrupts can interrupt each other?

That would be easy...
No, StingRay refer to something different (a who required IRQ check).

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)

Last edited by ross; 27 November 2017 at 16:24. Reason: []
ross is offline  
Old 27 November 2017, 16:52   #5
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,883
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.
phx is offline  
Old 27 November 2017, 16:55   #6
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 48
Posts: 4,256
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.
meynaf is offline  
Old 27 November 2017, 17:00   #7
a/b
Registered User

 
Join Date: Jun 2016
Location: europe
Posts: 377
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
  beq.b NotBlitter
  move.w #$0040,$dff09c
; start another blit here
NotBlitter:
  btst #5,$dff01e
  beq.b NotVBL
  move.w #$0020,$dff09c
; your main VBL code here
NotVBL:
  rte
a/b is offline  
Old 27 November 2017, 17:12   #8
ross
Defendit numerus

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 3,247
Quote:
Originally Posted by meynaf View Post
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.
Interesting.. but a little dangerous.

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

Last edited by ross; 27 November 2017 at 17:24.
ross is offline  
Old 27 November 2017, 17:22   #9
Kalms
Registered User
 
Join Date: Nov 2006
Location: Stockholm, Sweden
Posts: 228
Quote:
Originally Posted by a/b View Post
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
  beq.b NotBlitter
  move.w #$0040,$dff09c
; start another blit here
NotBlitter:
  btst #5,$dff01e
  beq.b NotVBL
  move.w #$0020,$dff09c
; your main VBL code here
NotVBL:
  rte
You also need to change the IPL bits in SR. It's very fiddly, most other solutions (like moving heavy processing out of the VERTB handler) are better choices.
Kalms is offline  
Old 27 November 2017, 17:55   #10
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 48
Posts: 4,256
Quote:
Originally Posted by ross View Post
Interesting.. but a little dangerous.

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.
Of course only the low priority stuff has to be put out of the vbl handler. This is, as Kalms said, moving heavy processing out of the vbl.
meynaf is offline  
Old 27 November 2017, 18:16   #11
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,883
Indeed, I quite like the soft-int solution. Will think about it.
Thanks for your comments!
phx is offline  
Old 27 November 2017, 20:43   #12
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 243
Quote:
Originally Posted by phx View Post
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.
This method will take lots of rastertime as your interrupt handler has to be executed for every blit. Only the rte command needs alone 20 cycles to be executed on the MC68000. This is only efficient, if you have few big blits in a queue. If possible, use the copper with a double buffered list to wait for the blitter instead. While waiting, the copper is off bus and could also feed the blitter faster than the CPU does. The only time critical thing would be updating the copperlist by the CPU with new values for the copper move commands. And if the amount of blits changes, you could initialize a copperlist for the maximum of blits and jump into this list with COP2LC/COPJMP2 at the end and step backwards blit by blit. So only the parts of the copperlist will be excuted which were initialized by the CPU.

Quote:
Originally Posted by phx View Post
I really would like to have both: run my program in VERTB and use Blitter interrupts...
Does your main routine needs to run in supervisor mode? If not, you could also wait for the VBI by hand checking the INTREQR register and execute your main routine in user mode. So it would be no problem to interrupt it by a level3 blitter-finish-interrupt.
dissident is offline  
Old 27 November 2017, 21:55   #13
ross
Defendit numerus

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 3,247
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.

Last edited by ross; 27 November 2017 at 22:08. Reason: []
ross is offline  
Old 27 November 2017, 23:28   #14
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,883
Quote:
Originally Posted by dissident View Post
This method will take lots of rastertime as your interrupt handler has to be executed for every blit. Only the rte command needs alone 20 cycles to be executed on the MC68000.
Yes. And the interrupt processing will also need more than 40 cycles, IIRC. I am not totally convinced myself that it will turn out as hoped, but the alternative is to waste all these cycles by waiting for the Blitter. There is not much else to do, as all data to feed the Blitter was already generated earlier.

How many cycles will pass, when blitting a 16x16 tile with 5 planes and mask? All DMA channels used.

Quote:
If possible, use the copper with a double buffered list to wait for the blitter instead.
I agree that this might be faster, but also extremely more complex to manage. I can have any number of tiles in the queue, at different times during the frame.


Quote:
Does your main routine needs to run in supervisor mode? If not, you could also wait for the VBI by hand checking the INTREQR register and execute your main routine in user mode.
I would really prefer when the game engine, which renders the frames, runs in an interrupt, triggered by VERTB. This way I have a kind of multitasking and let the "main program" do tasks which are not VERTB-synced, like reading data from the disk.


Quote:
Originally Posted by ross View Post
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
Indeed, there will be multiplexed sprites, color changes and scrolling.
phx is offline  
Old 28 November 2017, 00:39   #15
ross
Defendit numerus

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 3,247
Quote:
Originally Posted by phx View Post
I would really prefer when the game engine, which renders the frames, runs in an interrupt, triggered by VERTB. This way I have a kind of multitasking and let the "main program" do tasks which are not VERTB-synced, like reading data from the disk.
Coincidence.. just a couple of days ago I was thinking a very very similar system for asynchronous load and unpacking from floppy, with a running main prog. not from user mode but from level 1 IRQ.
Well, there are actually several reasons for this choice.
But too OT, maybe for another thread
ross is offline  
Old 28 November 2017, 15:57   #16
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 24,737
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?)
Toni Wilen is offline  
Old 29 November 2017, 17:17   #17
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 243
Quote:
Originally Posted by ross View Post
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]
Hi ross, it depends on the size of the blit to be done in a scanline. A coexist of real time copper effects with for example vertical rasterbars (Kefrens/Alcatraz-Bars) is possible. Just check my copper-demo http://www.pouet.net/prod.php?which=65627 . I combined there the rasterbars with a sheared effect by a bitplane shift and a vertical colourscroll line per line. For this routine I didn't need any COPJMPs as it is clear that every visible scanline there will be a blit.

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
  DC.W $0042,$xxxx ;BLTCON1
  DC.W $0048,$xxxx ;BLTCPTH
  DC.W $004a,$xxxx ;BLTCPTL
  DC.W $0054,$xxxx ;BLTDPTH
  DC.W $0056,$xxxx ;BLTDPTL
  DC.W $2bd3,$fffe  ;WAIT $D2,$2B
  DC.W $0058,(3*1*64)+(32/16);BLTSIZE  
  DC.W $2be1,$fffe  ;WAIT $E0,$2B
  DC.W $00e2,$0040 ;BPL1PTH
  DC.W $00ea,$nnnn ;BPL1PTL
  DC.W $00f2,$0040 ;BPL2PTH
  DC.W $00e6,$nnnn ;BPL2PTL
  DC.W $00ee,$0040 ;BPL3PTH
  DC.W $00f6,$nnnn ;BPL3PTL
  DC.W $0102,$xxxx ;BPLCON1
  DC.W $0180,$xxxx ;COLOR00
  DC.W $0001;$0000 ;Pseudo blitter finished (OCS A1000/2000A bug)
  DC.W $0001;$0000 ;The real blitter wait
  DC.W $0040,$xxxx ;BLTCON0
  DC.W $0042,$xxxx ;BLTCON1
  DC.W $0042,$xxxx ;BLTCON1
  DC.W $0048,$xxxx ;BLTCPTH
  DC.W $004a,$xxxx ;BLTCPTL
  DC.W $0054,$xxxx ;BLTDPTH
  DC.W $0056,$xxxx ;BLTDPTL
  DC.W $2bd3,$fffe  ;WAIT $D2,$2C
  ...


Quote:
Originally Posted by ross View Post
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.
It makes no difference. If you use the blitter finished interrupt, you also have to store the data for the blits in a buffer (which could be in FAST memory), read it and write the data to the blitter registers in the blitter interrupt routine.

Quote:
Originally Posted by ross View Post
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 understand. My first assumption was a vertical or horizontal fullscreen textscroll with 16x16 pixel characters. This routine could be also used to display a landscape created of different tiles.

Quote:
Originally Posted by ross View Post
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.
Yes, this is a good idea as in the vertical blank area no bitplane DMA interrupts the blitter DMA.
dissident is offline  
Old 29 November 2017, 17:57   #18
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 243
Quote:
Originally Posted by phx View Post
Yes. And the interrupt processing will also need more than 40 cycles, IIRC. I am not totally convinced myself that it will turn out as hoped, but the alternative is to waste all these cycles by waiting for the Blitter. There is not much else to do, as all data to feed the Blitter was already generated earlier.
This is the same method you need waiting with the copper for the blitter. Your buffer mentioned above with all the blitter data is the copperlist.

Quote:
Originally Posted by phx View Post
How many cycles will pass, when blitting a 16x16 tile with 5 planes and mask? All DMA channels used.
As the HRM says http://amigadev.elowar.com/read/ADCD.../node012A.html we could calculate it this way:

Code:
    8*16*5*2
t= ---------- =180,55 microseconds
      7.09
But this is only a theoretical value as bitplane DMA could steal some cycles and maybe slows the blitter down.

BTW: Why do you use all channels? I suppose these are your blits to copy objects in to a background picture.

Quote:
Originally Posted by phx View Post
I agree that this might be faster, but also extremely more complex to manage. I can have any number of tiles in the queue, at different times during the frame.
Generally it is not so complex as you can see here: http://www.pouet.net/prod.php?which=71971 I used this method for the line blits for the Triple-Glenz and for the Vector-Balls copy blits. You just count the blits you need and calculate the copper jump-adress at the end. It behaves like a stack-pointer logic.

COP2LC-jump-pos already initialized by the CPU. The CPU only changes $xxxx.

Code:
cop1
  ...
  DC.W $008A,$0000 ;Jump to copperlist2


cop2
  ...
  DC.W $0001,$0000 <- Entry for second blit
  DC.W $0001,$0000
  DC.W $0040,$xxxx
  ....
  DC.W $0058,$xxxx

  DC.W $0001,$0000 <- Entry for first blit
  DC.W $0001,$0000
  DC.W $0040,$xxxx
  ....
  DC.W $0058,$xxxx

  DC.W $FFFF,$FFFE <- Entry for no blit
Quote:
Originally Posted by phx View Post
I would really prefer when the game engine, which renders the frames, runs in an interrupt, triggered by VERTB. This way I have a kind of multitasking and let the "main program" do tasks which are not VERTB-synced, like reading data from the disk.
Okay, for this case this it is the best method using the VBI generating a level1-interrupt like meynaf already suggested.

Quote:
Originally Posted by phx View Post
Indeed, there will be multiplexed sprites, color changes and scrolling.
So you could only do small blits for example every second line without any COPJMP:

Code:
  DC.W $2C01,$7FFE ;Wait y-pos & pseudo waitblit
  DC.W $0180,$xxxx
  DC.W $0001,$0000
  DC.W $0040,$xxxx
  ....
  DC.W $01FE,$0000 ;Changed to $0058,$xxxx if blit is used / needed

  DC.W $2D01,$FFFE
  DC.W $0180,$xxxx

  DC.W $2E01,$7FFE
  DC.W $0180,$xxxx
  DC.W $0001,$0000
  DC.W $0040,$xxxx
  ....
  DC.W $01FE,$0000 ;Changed to $0058,$xxxx if blit is used / needed
dissident is offline  
Old 29 November 2017, 18:03   #19
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,883
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.
phx is offline  
Old 29 November 2017, 18:30   #20
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,883
Quote:
Originally Posted by dissident View Post
BTW: Why do you use all channels? I suppose these are your blits to copy objects in to a background picture.
Foreground tile animations, and foreground tiles which have to be redrawn because BOBs moved behind them, or because of background tile animation.

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.
phx is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Q: Copper Interrupt Herpes Coders. Asm / Hardware 3 25 April 2016 13:31
Trigger level 7 interrupt geir support.FS-UAE 2 15 August 2015 22:45
Interrupt 7 BigT support.WinUAE 2 07 September 2013 22:25
level 7 interrupt on A600 xc8 Hardware mods 1 26 October 2008 14:53
Level 7 interrupt Kintaro support.WinUAE 1 21 January 2004 17:31

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 08:44.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.18687 seconds with 13 queries