1st Anniversary of Lazy Bones

This text is written on 28th of April 1994,
1st Anniversary of Lazy Bones
GOOD NEWS, BAD NEWS

0. Who am I?

My name is Coyote and I'm from Lazy Bones. Yes, a Scene member!

1. What is this text about?

Well I have discovered some undocumented features of Amiga
hardware. I have an Amiga 500 with ECS Agnus and standard Denise, but one
of these discoveries I checked on ECS Denise and it behaved the same as on
the standard one.

Both features I found out almost a year ago, but I haven't spread
the word about it 'cause I thought that someone has already reported these,
should I say bugs, and I didn't want to bore you. Well, after a short
period of searching and inquiring about that kind of information I
concluded that there is possibility that noone has noticed Amiga's strange
behavior. So here are the good and the bad news.

2. Good news :)

I discovered this after my search through copper lists on AGA
machine for a proper way of setting colors from 24 bit palette. At that
time I had no knowledge about AGA registers and when I saw that some
registers are among unused registers on standard Amiga I was overcomed with
feeling that there are some 'weird' graphics modes or whatsoever, even on
my standard Denise.

Well, I was right ! :D

Before I start explaining what I've discovered I must say some
facts. This discovery happened in may 1993 with simple filling Denise
registers and watching the results. It is tested on ECS Denise and it
works fine.

Finaly, here it is:

When you fill register $dff100 with value which has the number of
bitplanes specified as 7 (lo-res) something strange is going on. On screen
you will notice only 4 bitplanes but further checking has revealed to me
that there are still some differences from usual 4 bitplane mode.

When 7 bitplanes are 'opened' color index is 6 bit wide. (It would
be better to say 5 bit wide with halfbright enabled.) First 4 bits of color
index is fetched from BPL1DAT-BPL4DAT ($110 through $116) registers which
are filled through DMA channels. 5th and 6th bit of color index is taken
from BPL5DAT and BPL6DAT which are NOT disturbed by DMA. In other words,
you can put in, i.e. BPL5DAT value $aaaa and you will get at odd pixels on
screen color which is indexed as $10 trough $1f. (Same is with BPL6DAT,
value $aaaa would give you halfbright odd pixels.)

The benefit of this is accesing of all colors ($00-$1f) without
loosing speed of copper. Okay, okay, this is maybe not so worth to use
except in 4x4 pixel 4096 color rotators where you can now have 31 instead
30 colors for columns. Now, you may ask why is my 4096 color rotator in
"B2" (Lazy Bones) using columns of color $01-$0f and non DMA sprites for
columns of color $11-1f. That was before I was sure that this 'trick' with
7 bitplanes will work on ECS Denise.

3. Bad news :(

This information already know some my friends. I told one of them
to put it on some BBS but I don't know if he did it.

Prepare yourself to hear some unpleasant bug !

This Amiga bug gave me almost whole day of debugging while I was
coding B2. When I explain you how I got in chance to discover it you will
say that I should not code that way, but...

I almost always start copper (or change copper lists) with
strobing. I know that its enough to fill COP1LC, and copper will in next
frame execute requested list, but I like to start copper list IN frame, not
in a frame before.

Well, in one routine everything was going fine for some time but
then something disturbed copper list. I found out that blitter was writing
over my copper list, and spend quite a time debugging.

Finaly I concluded that blitter is changing its destination address
in the middle of the 'blitting'. But I always properly wait for one blit
to end before I start another. What it could be ?

As I mentioned before I strobed copper in vertical blank interrupt
to change the screens. Because my routine was longer then 1 frame I put it
in main program and I worked with 3 screens. When I finished one screen I
set my own 'request flag' to tell to interrupt routine that it's time to
change screen. Right after setting flag I started blitter to clear the 3rd
screen. While blitter was bussy vb interrupt happened and routine had
strobed copper to another list.

BLITTER THEN CHANGED ITS DESTINATION ADDRESS TO ADDRESS WHICH WAS
IN COP1LC !!!!!

I tested this only on few Amigas with Fat Agnus,so I do not know
does Agnus on Amiga 1.2 also have this bug.

Hey, you guys with Amiga 1200, try this program... I would really
want to know does the new Amiga act the same.

Fortunatly, this bug is not always active.

If you are interested look at following program, and read the text
after it.


run:
lea $dff000,a5
move.w #$7fff,$9a(a5) ;disable interrupts
move.w #$7fff,$96(a5) ;disable DMA channels

move.l #copper_list,$80(a5)
move.w #$0000,$88(a5)
move.w #$82c0,$96(a5) ;cop and blt DMA enabled

move.l #$01f00000,$40(a5) ;D = A
move.l #$ffffffff,$44(a5)
move.l #$0000,$64(a5)
move.l #blitter,$54(a5)
move.w #$c0de,$74(a5) ;BLTADAT = $c0de
move.w #$1000,$58(a5) ;fill $1000 words

REPT 100
move.w #$0000,$88(a5)
ENDR
bltwait:
btst #$06,$002(a5)
bne.s bltwait
illegal ;****ENABLE RESCUE IN YOUR ASSEMBLER****

org $50000
copper_list:
dc.w $ffff,$fffe
; dc.w $0088,$0000 ;read the text below for explanation

blk.w $fffc,0

org $60000
blitter:
blk.w $1000,0

REM
This is proof for those who does not believe it !!

Put your copper list in some free memory (you can open a chip
section for it, if you like clean programming).

Put $fffffffe in copper list as first instruction. If you start
the blitter to fill some location with i.e. $c0de and then strobe copper a
few times you will notice that blitter did not move its data where it
should have.

The data is transferred in copper list ! Look at the location
which blitter was supposed to cover with $c0de... Interesting, isn't it ?

Well this happened when copper was executing wait instruction,
blitter was running, and we were strobing copper.

If we put the first instruction to be move ($00880000 - this will
also insure that copper will execute only this move on and on), nothing
strange will happen.

You will now say:"How can this be ? Blitter is running, copper is
strobing itself, and everything is alright."

Well, there is nothing wrong because copper is in move instruction.
When I first tried to prove to myself this "copper-blitter" bug I put $baba
in BLTADAT ("baba" is grandma in croatian) and of course, blitter filled
wrong location. After some time I realized that blitter did not took the
address from COP1LC 100 times in spite the fact that I put 100 copper
strobes in my program. (If it did, there would be transfered just few
words, because blitter BLTDPT would be changed to copper list many times.)

Then I made a long copper list consisting only of move
instructions, and blitter did not make a mistake.

This also explained how all those programs with copper loops and
blitter scrolls can work. Strobing copper is dangerous only in case that
copper is in wait instruction, and when copper is strobing itself it's
obvious that copper is executing move...

What happens when you use more than one blitter channel ? Well,
experiment a little !

ENDREM


4. My address

If you want to contact me for any reason you can write to following
address :

Bojan Urosevic (Coyote/Lazy Bones)
Dapci 218A
43240 Cazma
CROATIA

Or you can reach my nearest modem-friend at e-mail address:

dalibor...@120.hrfido.fesb.hr

...and he will print and forward message to me!

I hope that I helped at least one coder to debug his masterpiece !!

Happy coding !! ;)