English Amiga Board


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

 
 
Thread Tools
Old 02 June 2019, 16:23   #1
Yragael
Registered User

 
Join Date: Jun 2017
Location: Paris
Posts: 51
Puzzling: Blitter line drawing faster on second execution

Hi guys,

A most puzzling problem to me, that you surely will solve in a blink.

Here is the code of a little program that just draws 20 times the same line with the Blitter in a loop.

But first, run WinUAE. Use a standard A500 1.3 512Kb Chip / 512Kb Fast configuration and boot the ADF. By standard, I mean a perfect emulation. When the prompt appears, type "desireONE" and press Enter. Watch the red part and the number in the bottom left : 139. Press the mouse button to exit the program, and type "desireONE" and press Enter again. The red part is smaller and the number reads 116.

So the problem is: why does the program run faster the second time (and times forward)?

The ZIP includes the code.

Notice that the problem won't occur if you assemble in ASM-One. You have to run the program from the disk to notice it.

Thanks for your help!
Attached Files
File Type: zip desireONEDebug.zip (318.5 KB, 21 views)
Yragael is offline  
Old 02 June 2019, 16:38   #2
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,136
I didn't test but most logical reason would be blitter nasty bit being cleared first and set later.
Toni Wilen is offline  
Old 02 June 2019, 17:04   #3
Yragael
Registered User

 
Join Date: Jun 2017
Location: Paris
Posts: 51
Quote:
Originally Posted by Toni Wilen View Post
I didn't test but most logical reason would be blitter nasty bit being cleared first and set later.

Doesn't sound like the explanation. This bit is cleared at the beginning:


move.w #$07FF,DMACON(a5)


and later not set:


move.w #$83C0,DMACON(a5) ;DMAEN=1, BPLEN=1, COPEN=1, BLTEN=1


Notice that the problem occurs only when drawing lines with the Blitter.
Yragael is offline  
Old 02 June 2019, 17:31   #4
a/b
Registered User

 
Join Date: Jun 2016
Location: europe
Posts: 119
intena:
- first run: blitter interrupt enabled
- consequent runs: blitter interrupt disabled
a/b is offline  
Old 02 June 2019, 18:13   #5
Yragael
Registered User

 
Join Date: Jun 2017
Location: Paris
Posts: 51
Unhappy

Quote:
Originally Posted by a/b View Post
intena:
- first run: blitter interrupt enabled
- consequent runs: blitter interrupt disabled

Where? First run and second run seem the same to me, bit BLIT never being set in INTENA:


move.w INTENAR(a5),intena
move.w #$7FFF,INTENA(a5)
move.w INTREQR(a5),intreq
move.w #$7FFF,INTREQ(a5)
...

move.w #$E000,INTENA(a5) ;For the tune player

...

(main program)
...
move.w #$7FFF,INTENA(a5)
move.w #$7FFF,INTREQ(a5)
move.w intreq,d0
bset #15,d0
move.w d0,INTREQ(a5)
move.w intena,d0
bset #15,d0
move.w d0,INTENA(a5)

New: I just made some new tests, and the problem is related to waiting the Blitter to finish (I thought that it occured when the Blitter was drawing lines and not copying data, because I was drawing lines in a loop, which meant waiting for the Blitter to finish several times, and not copying data in a loop).

Last edited by Yragael; 02 June 2019 at 18:25. Reason: Adding a comment about waiting for the Blitter
Yragael is offline  
Old 02 June 2019, 18:51   #6
a/b
Registered User

 
Join Date: Jun 2016
Location: europe
Posts: 119
Using Winuae, A500 68000 0.5/0.5 OCS max compatibility etc. Press shift+f12 for debugger (custom registers in the topright-ish corner).
- first run: INTENA 6040 (master+external+blitter enabled), INTREQ 0028 (0040 blitter bit is being cleared by interrupt handler)
- after that: INTENA 6000 (master+external enabled), INTREQ 0068 (0040 blitter bit remains set, since the interrupt is disabled and is not clearing it)
Reset Amiga and repeat, the same thing (6040/0028 first run, 6000/0068 after that).
Didn't check the code, this is just what I noticed in debugger. So it seems to me that each finished blit is triggering an interrupt, which does nothing harmful, and is slowing the code down.
Maybe, maybe not. Try explicitely disabling blitter interrupt and see what happens.
a/b is offline  
Old 02 June 2019, 19:26   #7
Yragael
Registered User

 
Join Date: Jun 2017
Location: Paris
Posts: 51
Quote:
Originally Posted by a/b View Post
Using Winuae, A500 68000 0.5/0.5 OCS max compatibility etc. Press shift+f12 for debugger (custom registers in the topright-ish corner).
- first run: INTENA 6040 (master+external+blitter enabled), INTREQ 0028 (0040 blitter bit is being cleared by interrupt handler)
- after that: INTENA 6000 (master+external enabled), INTREQ 0068 (0040 blitter bit remains set, since the interrupt is disabled and is not clearing it)
Reset Amiga and repeat, the same thing (6040/0028 first run, 6000/0068 after that).
Didn't check the code, this is just what I noticed in debugger. So it seems to me that each finished blit is triggering an interrupt, which does nothing harmful, and is slowing the code down.
Maybe, maybe not. Try explicitely disabling blitter interrupt and see what happens.
Thanks. Indeed, the problem is related to this instruction:

move.w #$E000,INTENA(a5)

The problem does not occur if I remove it.

But this is most strange, because this instruction is required to enable the lvl 6 interrupt for the music player, and does not touch the lvl 3 interrupt BLT finished bit, which has been cleared before:

move.w INTENAR(a5),intena
move.w #$7FFF,INTENA(a5)
move.w INTREQR(a5),intreq
move.w #$7FFF,INTREQ(a5)
move.w DMACONR(a5),dmacon

Last edited by Yragael; 02 June 2019 at 19:26. Reason: Too many blank lines
Yragael is offline  
Old 02 June 2019, 19:46   #8
Yragael
Registered User

 
Join Date: Jun 2017
Location: Paris
Posts: 51
Nailed!

Quote:
Originally Posted by a/b View Post
Using Winuae, A500 68000 0.5/0.5 OCS max compatibility etc. Press shift+f12 for debugger (custom registers in the topright-ish corner).
- first run: INTENA 6040 (master+external+blitter enabled), INTREQ 0028 (0040 blitter bit is being cleared by interrupt handler)
- after that: INTENA 6000 (master+external enabled), INTREQ 0068 (0040 blitter bit remains set, since the interrupt is disabled and is not clearing it)
Reset Amiga and repeat, the same thing (6040/0028 first run, 6000/0068 after that).
Didn't check the code, this is just what I noticed in debugger. So it seems to me that each finished blit is triggering an interrupt, which does nothing harmful, and is slowing the code down.
Maybe, maybe not. Try explicitely disabling blitter interrupt and see what happens.

Ok. Thanks to your help, I noticed that I was preventing the music routine to run as a lvl 6 interrupt handler, but still restoring the lvl 6 interrupt. So I was not removing the system lvl 6 interrupt handler, and I presume it was restoring the BLT finished interrupt someway.
Yragael is offline  
Old 02 June 2019, 21:02   #9
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,024
I didn't check the code but I think this happens: you left the IRQ6 active w/o changing system vector ($78),
so at some point in time irq handler in ROM call some code (in the graphics.library) that changes INTENA, setting the blitter IRQ3.
TOD ALARM is involved (it's it who triggers the call..) It's a situation that I remember getting caught but I don't remember anything else
So at the end of one of your blitting an IRQ3 start and a ROM routine (in gfx.lib) is executed (because now INTENA is changed).

Why only the first time? Probably the trigger situation is canceled by the first call.

[EDIT] FOUND!
http://eab.abime.net/showthread.php?t=91412
http://eab.abime.net/showpost.php?p=...2&postcount=24

Last edited by ross; 02 June 2019 at 21:14.
ross is offline  
Old 02 June 2019, 22:25   #10
Yragael
Registered User

 
Join Date: Jun 2017
Location: Paris
Posts: 51
Quote:
Originally Posted by ross View Post
I didn't check the code but I think this happens: you left the IRQ6 active w/o changing system vector ($78),
so at some point in time irq handler in ROM call some code (in the graphics.library) that changes INTENA, setting the blitter IRQ3.
TOD ALARM is involved (it's it who triggers the call..) It's a situation that I remember getting caught but I don't remember anything else
So at the end of one of your blitting an IRQ3 start and a ROM routine (in gfx.lib) is executed (because now INTENA is changed).

Why only the first time? Probably the trigger situation is canceled by the first call.

[EDIT] FOUND!
http://eab.abime.net/showthread.php?t=91412
http://eab.abime.net/showpost.php?p=...2&postcount=24

Yep, and thanks for the references. This is the explanation to the previous conclusion. Lesson to remember for metal coders: we never cut the system enough!
Yragael is offline  
Old 02 June 2019, 22:52   #11
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,301
Curse Commodore for putting in an OS without giving a kill switch command
roondar 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
When is the 68k processor faster then the blitter at copying memory redblade Coders. Asm / Hardware 20 08 May 2019 22:57
Blitter line-drawing mode? E-Penguin Coders. Blitz Basic 2 13 April 2019 21:37
Blitter: clean-up line drawing and fill mode idle cycles. ross Coders. Asm / Hardware 9 12 May 2018 22:32
Blitter line drawing: nothing happens Crank Coders. General 21 25 April 2018 21:43
Drawing a line... Lonewolf10 Coders. Tutorials 24 06 September 2011 00:46

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 17:33.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.07617 seconds with 16 queries