WIDE
4THE ECS FUCKUP


From  now  on, this mag also 2runs on 2.0 1machines.  It was quite simple why it
wasn't compatible till now...  I had to change 1 (yes, ONE) assembler command!

Lots  of  people  didn't leave me alone because SH didn't run on 2.0.  I could
only  answer:   I  don't  know,  there is no extra cheat in it.  Now I had the
opportunity to try it on a 2.0 Amiga, so I could easily find the 'bug' (around
in  7.0018790042 minutes).  Do you know what was the problem?  I wouldn't find
it out in my weirdest dreams...  3The Copper didn't start.1

The  reason  of it was that in the begginning of the code I stop every DMA and
IRQ, and turn the system off.  Then later on I start the IRQs and DMAs I need.
Of  course  the  Copper-DMA,  too.   Then on normal or fatter Agnus the Copper
started,  but  on  the ECS I even had to kick it in the ass (clr.w $dff088 for
Copper1  and  clr.w  $dff08a  for Copper2), so this was the 2"BIG BUG"1.  So who
codes  on 1.3 and would like to start his Copper on 2.0 should not forget this
little  kick!   Because  if  you  forget to do this with the first Copper, the
second will never ever start, this is a bit 2strange 1from the ECS.
Our  3Aabsolute!  demo1 could run on 2.0, but the same copper start routine I've
used  in  SH  did not run, so I didn't understand why did the 'first same' run
while  the  'second  same'  didn't.   There  is another 2surprise1 here!  In the
beginning  of  SH's code I have a NULL-OP Copper where I only start the Copper
DMA, and it doesn't start even after the 'extra kick'?!  I was really confused
and  didn't  understand  why can't I only start the Copper & Bitplane DMA if I
want  to  (I  could  easily  do  it  on the 1.3), so the 3ECS fucked me 1to this
routine:
                                                           @IPgotchu
	move.w	#$7fff,$dff096          ;all dma off
	.
	.
	.
	move.l	#coplst,$dff080		;set copper address
	move.w	#$8180,$dff096          ;just copper & bitplane dma on
	clr.w	$dff088                 ;restart copper 1

I don't know why can't I, but suppose I want to show a picture, and I list the
needed  things  in  the  Copperlist,  and I don't need anything else, then the
above  mentioned  routine seems to be good, but it isn't!!  The ECS just can't
take that I don't need any other DMAs...  3it needs this:1

	move.w	#$87d0,$dff096		;all dma on, except sprite and audio

Then  later  I  can  turn  off  all  the  others, but all will be active for a
moment...    Nice,  isn't  it?   The  2third  ECS  fuckup1  which  I  discovered
Absolute!ly accidentally:

coplst	dc.w	$008e,$7200,$0090,$dfff,$0092,$0038,$0094,$00d0
	dc.w	$0102,$0000,$0104,$0000,$0108,$0000
	dc.w	$00e0,pic>>16,$00e2,pic&$ffff           @IPgotcha
	dc.w	$0180,$0000,$0182,$0111
	dc.w	$0100,$1200
	dc.w	$ffff,$fffe

This  copper wants a picture to be seen from rasterline $72 to $df...  but not
on  the  ECS!  The problem is at chipregisters $8e and $90.  It doesn't know a
picture  starting  at  horiz.   $00  ending at $ff.  It needs 2real things1 like
this:

	coplst	dc.w	$008e,$722811,$0090,$df2c11,$0092,$0038,$0094,$00d0
	...

I  can  understand  this, it's like the 1.2 vs.  1.3 problem.  I think lots of
people  have seen a demo running on 1.2 but not on 1.3.  The problem there was
with the DDFSTRT ($dff092) and with the DDFSTOP ($dff094).  Usually 1.2 coders
opened an 3overscan1 picture like this:

	coplst	dc.w	$008e,$7281,$0090,$dfc1,$0092,$002301,$0094,$002e01
	...

But  it wasn't rare that someone wrote a bigger number than $e0, and it was no
problem  as  the  1.2  limited  it,  but the fatter Agnus didn't limit it, but
fucked up the picture, the sound, the blitter (linedrawing, etc.)...  But it's
not  a problem as almost everyone codes on 1.3, and can test his proggy, so it
will run on 1.2, too.

Anyway,  it  is  a  little  bit  weird  that 31.3 code runs on 1.2 and 2.0 code
(without  spec.   extras.)  runs  on  1.3!?1   I think this is not the 2backward
compatibility!1   Because  it  would be that older proggys run on newer Amigas!
3Commodore  fucked  it  a  bit1  when  they  didn't really check the 4 registers
mentioned  above, and later they repaired it, but now older stuffs sucks.  The
newer  registers  of the ECS were done normally, they 2didn't work1 on the older
registers  (THANX  GOD!), but created new ones (except those $dff08e & $dff090
they have modified2!!!1).

4Conclusion:


These  (in)compatibility  problems  are 3 not 1 only  the  3coders fault,1 but the
hardware's,  too.  Because if I use a register and that works on my machine, I
can  really  expect the manufacturers not to modify it!  But if one thinks for
the  future  and uses realistic numbers (but I don't know why the pic from $00
to $ff is not real?) then his stuff will be compatible! (probably!)

Let's  see  an extreme example 2(for not coders):1  Suppose that a company finds
out  that  the  3bits1 should not have 2 3(0-yes, 1-no)1 but 3 3(0 yes, 1-not sure,
2-no)1 positions, then all existing programs will fuck up, and every coder will
end up in special house for insane people...
@IPadtR\