A.D.A. Amiga Demoscene Archive

Hello, guess what ?
I'm trying some genuine aga copperlist and I have that old bug, sometimes,
some unwanted vertical sprite band happens. I remember it was a common bugs, but
I don't remember how to get rid of this.
I don't find what is missing in my bplconx registers...
I set 16 words at sprpt ($120) to 0... I have some "copper compiler" so I can not directly post the whole thing, except that template copper from the blueberry startup that I use at the very beginning

dc.l $008e2c81,$00902cc1
dc.l $00920038,$009400d0
dc.l $01001200,$01020000,$01060000,$010c0011
dc.l $01080000,$010a0000
dc.l $01800abc,$01820123
dc.l $01fc0000
dc.l $fffffffe




I have absolutely no experience in sprites at the moment...

Isn't that what you sometimes get if you disable sprite dma outside of vblank?

It makes sense, I was doing that when I had the bug

I also have a sprite surprise.

I have a series of 64-pixel 16 color aga sprites drawing an overlay which distorts sometimes for still unknown reason. I've verified the sprite control words are the same as what the system is creating. So I believe the data structure for the sprite is correctly set up.

I set the sprite pointers in the Vblank interrupt (added by AddIntServer() ).

It can look like something is writing into the sprite pointers from another location.

Is it possible to put a watchpoint on the sprite registers using FS-UAE's debugger? Also.. how to launch/use this debugger?

Turning off sprite-dam while setting the pointers seems to improve stability. Now the distortion is limited to the sprite being visible and not at certain frames.

apparently sprite DMA channel should never be closed in dmacon. Worked for me.

@krabob : if it works for you it should work for me too right?

I'm now at a point where the distortion is affected by:
- a certain amount of cpu load in the audio interrupt
- moving the mouse pointer

So what I'm thinking is that the audio interrupt is happening during the vertical blank period at certain times. Could it be an interrupt, interrupting another interrupt ? intception?

Also reading Krabob's new post where he says moving the mouse can take 70 rasters.. maybe it is related aswell? I don't know how intuition reads the mouse exactly.

Seems that if I made the work in the vblank interrupt really short. The artefacts disappear. Thus solving the problem on this emulator atleast. The previous vblank was positioning sprites and setting bitplane and sprite pointers. Now the positioning code got moved out. not sure what was so heavy about that? Maybe a look at the disassembly will show why.

Interestingly, Frequent tested on the real thing and there was no sprite distortion even before I slimmed down the code in the interrupt.

As I understand, after some tests:

Intuition listen inputs and frequently updates its copperlist when you move the mouse (coding blitter with direct access has write pointer trashed when moving mouse with intuition screens, which prooves it touches copjump.)

With just LoadView(NULL) , intuition completely stop to touch hardware address I think, but is still listening inputs and lives on.Even With Forbid(), its interupts are working, that's why most startup does #$7fff, intena

But I think "sprite surprise" is more due to Bus noise in certain conditions:

From OCS sources, it is said that 16 words at $dff000+$120 should be set to 0 to clear sprites.
If I set that in my copper with sprite DMA off, sprite surprise would appear a lot. Makes sense, because disabling sprites on a DMA level may disable the ability to turn them off, and may upset the bus.

loaderror, maybe what you're doing is: having sprite DMA on, but no 0 at $120 or not all 16 words ? Which would be another case for sprite-surprise ?

Or maybe there's a magic aga bit to switch somewhere.

My theory;
Audio Interrupt (Priority 4) have higher priority than Vertical Blank Interrupt (Priority 3), which means that if you do a lot of stuff inside the Audio Interrupt, the Vertical Blank will happen outside the Vertical Blank area, maybe thats why?
Also OS Mouse Handling is in Vertical Blank, and maybe it's dead slow, so your added Vertical Blank Interrupt happens outside the Vertical Blank area?

That seems like a reasonable explanation. I was thinking about something like this,but I thought vblank had higher priority than audio. I was thinking Priority 1 = first priority, priority = 2 second priority etc. but if its the other way around it makes sense.

Maybe I can check intreq in the audio interrupt whether vblank is going on. Then skip the audio copy loop in there (which just copies 512 bytes ) and rather defer this copy to the end of the vblank interrupt. *guitar solo montage*

Either that or do the audio copy in vertical blank (after updating critical things like sprites & bitplane pointers), look at Kalms ADPCM player (not using audio interrupt) or check Blueberry's thread where the discusses audio timing and updating the audio in vertical blank (http://ada.untergrund.net/?p=boardthread&id=267)

Yes, higher number have higher priority, e.g. level 7 (priority 7) is the highest interrupt and locks everything, a interrupt that only can be triggered by shorten some pins on the CPU.

That sounds better! I may even be able to look at my own 4k player. I'm experiencing a bit of deja vu here now. I think the last version of Psylteflesk also did all the audio work in the vblank interrupt.

Got rid of my sprite surpris now. When exiting, I restored cop1lch using View->LOFCprList->start thinking this was the toplevel copper in system. However I stumbled upon GfxBase->copinit and when writing this to cop1lch the full system display is restored including valid sprite pointers.

I always open a "dummy" intuition screen (1 bitplane), before i start banning LoadView(NULL) and creating my own copperlist. Then i just have to close that screen on exit, and the OS will solve everything.

That again sounds like a more proper way to do things :)