A.D.A. Amiga Demoscene Archive

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

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

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