Good News and Bad News (copper-blitter)
Kristijan Zibreg
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:
...and he will print and forward message to me!
I hope that I helped at least one coder to debug his masterpiece !!
Happy coding !! ;)
David Jameson
(Origninally posted to comp.sys.amiga.misc)
In a previous article, kzi...@public.srce.hr (Kristijan Zibreg) says:
[...]
[code deleted]
> 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 !
I've also discovered this bug -- I posted a message about it a few months
back, but didn't get much response...I only heard from one other person
who had discovered it. I ran my own test program on an A500, A1200 and A4000,
and the bug happened on all these machines.
As well as happening when you strobe the copper while the blitter is running,
it also seems to happen if you enable copper DMA while the blitter is
running.
Luckily this bug is pretty easy to work around -- you just need to make sure
that you never mess around with the copper while the blitter is running.
Franchetti Paolo 357826/IF
it ? When I use a wait instr which masks off vertical pos to wait the end
of a generic line, I put $e2 as horiz pos and the copper seems to halt for
a while, messing the screen.
I found that I must put a smaller value than $e2, depending on the cases,
and the copper waits till the pos I specify, so I don't know how to wait
till the end of line.
Bye
Paolo
Dan Thies
: I found a strange behaviour in the copper, is there anyone else who noticed
A quick test gave me the same result.
Just curious if any of these "bugs" (heck, let's call 'em features, the
amiga needs all the PR it can get) shows up when using OS routines, or if
they are only happening when you bang the hardware? I never hit the
hardware directly myself, but it seems that there are bound to be a few
little rough edges. After all, it's unlikely that the C= folks ever
tried every possible number stuffed into every possible register.
Dan
--
rt...@cyberspace.com
Rune Skaarsmoen
[ ... ]
: little rough edges. After all, it's unlikely that the C= folks ever
: tried every possible number stuffed into every possible register.
Heh, much like the Intel people 8^)
Rune.
Ralf
This is correct operation. There is no horizontal position $e2. $e1
_is_ the last horizontal position on the screen. If the horizontal position
cannot be reached, then the wait isn't satisfied - this is how the C_END
macro is implemented as a wait for horizontal position $ff.
For instance, if you want to wait until some position>256 lines, then
you do $ffff,$ffe1 then do your normal wait. AFAIK, position $e1 _will_ always
give the right results if you're waiting for the end of the line.
____ ____ _ _ ____ __
_\__ \ _\__ \ / \ / \\__/ Ranulf Doswell ///
/ \_/ /_ / \_/ \ / / / /___ ///
\ __ \\ __ \\ \ _\ \\_/ ra...@dcs.warwick.ac.uk __ ///
\ \ \ \\ \ \ \\ \__/ \\ \ \\\///
\_/ \_/ \_/ \_/ \______/ \_/ http://www.csv.warwick.ac.uk/~mauer/ \XX/
Jani Vaarala
: Franchetti Paolo 357826/IF (mc6...@esse11.dei.unipd.it) wrote:
: : I found a strange behaviour in the copper, is there anyone else who noticed
: : it ? When I use a wait instr which masks off vertical pos to wait the end
: : of a generic line, I put $e2 as horiz pos and the copper seems to halt for
: : a while, messing the screen.
: : I found that I must put a smaller value than $e2, depending on the cases,
: : and the copper waits till the pos I specify, so I don't know how to wait
: : till the end of line.
do you mean you use it for ex. like this:
dc.w $2CE2,$FFFE ?
if you do this, it's totally wrong ... the last bit of the
first word does *not* belong to horiz.pos wait ..
You should wait for ex.
dc.w $2CE1 or $2CE3 ..
is $E1/3 possible to wait ? I use in my copperlists
$FFDF,$FFFE as PAL-wait (wait during which copper actually
jumps to next line ...)
-------------------------------------------------
---- Jani "Flame / Pygmy Projects" Vaarala ----
--- Amiga ftpadmin of x2ftp.oulu.fi ---
-- C= computers since 1982 --
------------------------------------------
Matthew Waters
Strange feeling of deja vous...
This 'bug' was discussed at some length by Dave Jameson (Dave, I've lost
your email address!) a while ago. I believe it happens on *all* amigas
and is a real pain. We also spent a lot of time debugging before
discovering what was going wrong.
Still, nothing is perfect.
Matthew
Mat...@mattwms.demon.co.uk
Spencer Shanson
Matthew Waters <Mat...@mattwms.demon.co.uk> wrote:
>Dan Thies (rt...@cyberspace.com) wrote:
>: Franchetti Paolo 357826/IF (mc6...@esse11.dei.unipd.it) wrote:
>: : I found a strange behaviour in the copper, is there anyone else who noticed
>: : it ? When I use a wait instr which masks off vertical pos to wait the end
>: : of a generic line, I put $e2 as horiz pos and the copper seems to halt for
>: : a while, messing the screen.
>: : I found that I must put a smaller value than $e2, depending on the cases,
>: : and the copper waits till the pos I specify, so I don't know how to wait
>: : till the end of line.
If you're on an NTSC or PAL display, then you are waiting for a
horizontal position that will never occur. I can't remember exactly
what will happen in this case, but I suspect the copper will actually
execute the next instruction at the beginning of the next line, not
the end of the current line which I presume is what you wanted. And if
you are overscanned to the left, then the copper may not have enough
time to execute all the instructions you need. And if your screen has
has too many bitmaps, or you are in the old ECS 1x mode, you will have
less copper cycles to use. Also, if you are on line 255, the vertical
counter will wrap around to line 0 and you have another set of cases
to worry about. etc etc. Do you see a pattern forming?
Trust me, MrgCop() was a bear to get right, and I'm sure there are
still some cases that MrgCop() gets wrong.
> >Matthew >Mat...@mattwms.demon.co.uk
--
Spencer Shanson - 3DO System Software Weenie
Email: spe...@3do.com | "Work is the scourge of
All opinions expressed are my own, and do | the drinking class"
not (necessarily) represent those of 3DO. | - Oscar Wilde
Franchetti Paolo 357826/IF
I did that instruction with the copper because I actually wanted to execute instrucions at the beginning
of each line without specifying which line I was in.These was the only way I think,quoted from Hardware
Manual.There is no DMA problem because Copper waits correctly for the right pos if it is smaller than
$e2.This value was taken from HM as the last pos to wait for,and actually the smallest closest pos,$e0,
is NOT the end of line.
Paolo Franchetti
A
Spencer Shanson
Dr. Peter Kittel <pet...@combo.ganesha.com> wrote:
>In article <3gup39$b...@badger.3do.com> spe...@3do.com (Spencer Shanson) writes:
>>
>>Trust me, MrgCop() was a bear to get right, and I'm sure there are
>>still some cases that MrgCop() gets wrong.
>
>with simple MoveScreen() since AA, as opposed to nice working on
>OCS and ECS? On AA, it's unavoidably jumpy. I already tried WaitTOF()
>at any place I could think of, but to no avail. Is this at all a
>known problem, and if yes, is there a fix?
Maybe. Most of the MrgCop() code is the same though; the differences are
where special AA conditions were "shoe-horned" in, especially in the
calculations where the inter-screen gap straddles line 256
>>shudder<<.
>
>--
>Best Regards, Dr. Peter Kittel //
>Private Site in Frankfurt, Germany \X/ Email to: pet...@combo.ganesha.com
>Now ex-employee of Commodore, Class of '95.