A.D.A. Amiga Demoscene Archive

  Welcome guest! Please register a new account or log in

  

  

  

log in with SceneID

  

Demos Amiga Demoscene Archive Forum / Coding / strange AGA bug?? please help me!

 

Author Message
TheDarkCoder
Member
#1 - Posted: 23 Nov 2005 11:40
Reply Quote
I have found a strange thing in my startup code which seems to be
a bug of the AGA. I would like that some of you try to see if this happens
also with your code.

I do a simple startup that takes over the system and displays a picture,
like this:


; routine in Supervisor mode, but I don't think it's important

1) disable interrupts & DMA (and save values for restore)

2) prepare a Vertical blank interrupt routine for reloading BPLxPT with
the CPU

3) wait for a specific scanline X in the vertical blank area

4) setup registers BPLCONx, BPLxMOD, DIWSTxx, DDFSTxx with the CPU

5) enable DMA and interrupts

Please note that I don't use the copper at all (I don't even turn on
Copper DMA). Normally the code works preatty well, if the scanline X
that I wait for in step 3 is NOT equal to 1.
If X=1, one of the following happens:

a) a stable picture of trashed memory is displayed (instead of the
picture I want

b) the picture that I want is displayed, but in the very first frame
it is displayed in a wrong position, as if wrong values were written
in DIWSTRT and DIWSTOP; after the first frame the picture is displayed
perfectly

In particular it seems by experiments that it is the writing in any of
DIWSTRT, DIWSTOP, DDFSTRT or DDFSTOP during scanline 1 that produces this
bug. I verified this bug on one A1200 vanilla (020/14), on A4000 with 030/25
and on a A4000T 060/50. On the other hand, I have find no bug at all
on a A2000 with 68000 and standard OCS chipset.

However before saying that this is a hardware bug, I would like to be sure
that it is not a bug in my code!! :-)

So I kindly ask to some brave coder to check if he finds the same with his
own routines. I suggest using as test picture, one with a thin orizontal
line on a clean background: in this way the phenomenon b) can be seen more
easily.

regards
TDC
winden
Member
#2 - Posted: 23 Nov 2005 23:25
Reply Quote
tdc, maybe hardware starts procesing some registers in scanline 1... BTW if you are after minimising setup code, i'd rather make a minimal copperlist which just waits to your last visible scanline and then does a copper interrupt. Then instead of having a vblank triggering on scanline 1, you have a vblank triggering at the first scanline you don't have dma, which helps c2p speed a great deal for example
TheDarkCoder
Member
#3 - Posted: 24 Nov 2005 10:38 - Edited
Reply Quote
I have imagined the same explanation you give, for this (presumed) bug... (note that I count the very first scanline as scanline 0: I don't notice the bug if I wait for scanline 0).

However I really would like that somebody have the patience to try to reproduce the "bug", to be sure I am not doing some mistake...

My question is not related to VBlank syncronization. Usually I set DIWSTxx, DDFSTxx, BPLCONx & other registers only in the inizialization of the demo.
Of course, during vblank time. So, in the very beginning of the demo, I wait for a scanline which is surely into vblank time and then write (once and for all) these registers. Indeed, it is useless to wait, because the jsr WaitTOF which I did, should return to my program during VBlank time,
but to be more sure I decided to wait with my own code too (I don't trust the OS eheh :-). Usually I waited for some other scanline and all was fine.
Then, some days ago I waited for scanline 1 (it's a long and uninteresting story to explain you why) and noticed this strange behaviour. Then I tryied with different startup code and found still the same.
Since I am very curious about chipset and hardware banging issues, I would like to know if it's a real AGA bug (although small and unimportant)
or it's just some nasty bug in my code.

Please, someone try it!! :-)
regards

 

  Please register a new account or log in to comment

  

  

  

 

A.D.A. Amiga Demoscene Archive, Version 3.0