English Amiga Board


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

 
 
Thread Tools
Old 04 December 2019, 02:32   #1
Muzza
Registered User

 
Join Date: Sep 2019
Location: Sydney
Posts: 5
Blitter limit

Hi,
I'm an AMIGA ASM newbie, and I've ran into a blitter problem that I can't find any information about.

I'm doing a fairly standard implementation of blitting a tiled map to the display. I can blit around 40 tiles (each 16x16 pixels) with no problem. If I try to blit more (an entire screen worth, so about 320 tiles), it works correctly in FS-UAE, but my actual A1200 just shows a blank screen.

Is there some kind of timing limitation on real hardware where it is possible to overuse the blitter?

I do an OwnBlitter at the start of the code, and a BlitWait before every call to the blitter, plus another BlitWait before the VBlank (not sure if this one is needed?)

My code is based on this tutorial: http://vikke.net/index.php?id=5-horizontal-scroller
I've also compared against the 'ScrollingTricks' tutorials to see if I'm missing anything obvious, but they appear to blit an entire screen of tiles (on the first frame at least), and is generally doing the same thing as I'm trying to do.

Any suggestions on what I might be missing would be appreciated. Thanks!

p.s. please note I'm aware that using the blitter is not always the best solution - at this point I'm just experimenting to learn how it all works.
Muzza is offline  
Old 04 December 2019, 03:59   #2
a/b
Registered User

 
Join Date: Jun 2016
Location: europe
Posts: 174
> Is there some kind of timing limitation on real hardware where it is possible to overuse the blitter?
Nope.

> BlitWait before the VBlank (not sure if this one is needed?)
Not needed.

320 tiles is 20x16 or a 320x256 screen, right? Should be no problem at all. Hard to tell more without seeing the code.
Maybe it's not blitter at all, but copper or init code not doing something properly (since you mentioned A1200 => implies AGA chipset).
a/b is offline  
Old 04 December 2019, 05:54   #3
Muzza
Registered User

 
Join Date: Sep 2019
Location: Sydney
Posts: 5
Thanks for the information. After eliminating the blitter theory, I found the real culprit.
I was not setting the copper list (COP1LCH) until after WaitVB as per the code from the tutorial link I posted above.

From trial and error, I've found if I do lots of work before the first VBlank (i.e. if I draw 320 tiles) and only then set COP1LCH, I get a blank screen on the A1200 (even though it is running the main loop).
If however I set COP1LCH before the workload, it displays correctly. It seems that real hardware wants COP1LCH to be set early.
Muzza is offline  
Old 04 December 2019, 12:10   #4
hooverphonique
ex. demoscener "Bigmama"

 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,044
Quote:
Originally Posted by Muzza View Post
From trial and error, I've found if I do lots of work before the first VBlank (i.e. if I draw 320 tiles) and only then set COP1LCH, I get a blank screen on the A1200 (even though it is running the main loop).
If however I set COP1LCH before the workload, it displays correctly. It seems that real hardware wants COP1LCH to be set early.
This doesn't sound right, I think your problem is not at which exact time you set COP1LC, but something else.


Btw, you mention cop1lcH, but the full 24 bit pointer is COP1LC - are you only setting the upper word?
hooverphonique is offline  
Old 04 December 2019, 18:50   #5
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,620
COP1LC should be set before the Copper list starts to execute, which is directly after VBLANK. However, if you set it late the change will just take effect one frame later. Unless you're continuously swapping two Copper lists around to display two different buffers, it shouldn't really matter.

If you are using two Copper lists then you do indeed need to make sure COP1LC is set prior to VBLANK.

Note that this only applies if you're relying on Copper lists restarting automatically every frame (which is highly likely).
roondar is online now  
Old 04 December 2019, 22:37   #6
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,578
Did you CPU write to COPxJMP after setting COPxLC?

There is hardware bug that can do copper pointer to blitter pointer copy (which get quite nasty if it is D channel pointer) if blitter is active, copper is waiting and CPU writes to COPxJMP.
Toni Wilen is offline  
Old 04 December 2019, 22:49   #7
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 717
@Toni
I am just curious - Is there an asm example with such hardware bug ? Also, is it possible to reproduce such hardware bug in WinUAE ?
Asman is offline  
Old 05 December 2019, 01:04   #8
Muzza
Registered User

 
Join Date: Sep 2019
Location: Sydney
Posts: 5
To answer the above:

I am setting a long on COP1LH, so I believe that is correct.
I'm not touching COPxJM.
In this example I'm using only a single copper list.


I've simplified the code, with a line at the top you can uncomment to see working vs not-working on real HW. Perhaps someone can spot whether I'm doing something else wrong.

Example code here
Muzza is offline  
Old 05 December 2019, 02:32   #9
a/b
Registered User

 
Join Date: Jun 2016
Location: europe
Posts: 174
You are not terminating the copper list you generate (with e.g. move.l #$fffffffe,(a6)+) just before the 'working' #ifdef.
a/b is offline  
Old 05 December 2019, 02:37   #10
Muzza
Registered User

 
Join Date: Sep 2019
Location: Sydney
Posts: 5
Quote:
Originally Posted by a/b View Post
You are not terminating the copper list you generate (with e.g. move.l #$fffffffe,(a6)+) just before the 'working' #ifdef.

You're right. I was doing it in the original, I trimmed it by mistake.
I've added it back but the original problem remains.
Muzza is offline  
Old 05 December 2019, 05:57   #11
a/b
Registered User

 
Join Date: Jun 2016
Location: europe
Posts: 174
Don't have access to real hardware at the moment... Probably not the reason, but it's a problem. You're doing this:
- init empty view (LoadView(), ...)
- Forbid() to disable multitasking
- bang BPLCON0, ..., DDFSTOP with cpu
- disable interrupts (bang INTENA)
You should disable interrupts before changing display registers in case VBL interrupt happens and overwrites them. If you are not using interrupts yourself, a simple move.w #$4000,$dff09a (and $c000 before exit) will suffice. Or use exec's Disable()/Enable() instead.

Also, consider using a copper list to initialize all those custom registers (and palette as well). Related info: http://eab.abime.net/showthread.php?...30#post1362030
You don't have to use two of them. If you set all the registers via copper list every frame it's generally safer and easier to debug. Once you have it working, you can start optimizing (moving stuff out of main copper list).
a/b is offline  
Old 05 December 2019, 16:25   #12
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,578
Don't assume you can safely update custom registers if system copper list is active (even if you executed LoadView(NULL)). System copperlist can still update some registers. At least stop the copper or switch to dummy empty copper list first. This can cause really difficult to debug random bugs that depend on timing/CPU speed etc..

Quote:
Originally Posted by Asman View Post
@Toni
I am just curious - Is there an asm example with such hardware bug ? Also, is it possible to reproduce such hardware bug in WinUAE ?
Details here: http://eab.abime.net/showpost.php?p=...&postcount=237 (because it depends on CPU cycle usage, it is currently impossible to emulate if 68020+. UAE will still log warning message if three main conditions are true)
Toni Wilen is offline  
Old 06 December 2019, 00:07   #13
Muzza
Registered User

 
Join Date: Sep 2019
Location: Sydney
Posts: 5
Thanks for the advice. It seems I have an explanation now.

Setting my own copperlist early results in it working on real HW because it stops the system copperlist from overwriting registers I have set. An alternative fix would be as a/b suggests, setting the registers in the copperlist to ensure they are correct when the frame begins.
Muzza 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
Immediate Blitter & Wait for Blitter... volvo_0ne support.WinUAE 29 10 December 2018 18:56
Is DF3: really the limit? Anakirob support.Hardware 1 09 February 2017 14:41
Blitter busy flag with blitter DMA off? NorthWay Coders. Asm / Hardware 9 23 February 2014 22:05
to the limit baby Tolismlf Nostalgia & memories 17 17 January 2005 13:03
OS 3.x Partition/HD Limit? jmmijo support.Hardware 3 11 January 2002 18:38

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 01:04.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.09497 seconds with 15 queries