Copper Crash

[rexo12]

Hello, newbie to the forums here


I've been writing programs for/exploring the Amiga OCS and m68k for the last week or so. This is my first time seriously working in assembly, although I've written a tiny bit for ARM and I'm quite confident with the principles of the whole thing. I am working with vasm.



I've been writing a program that is supposed to just loop through a set of images, each with 3 bitplanes, and display them on the screen. This so far works well enough, just moving through a table of pointers to each image and then offsetting within that for each bitplane. I am doing the same thing for palettes. These get written to a copperlist every VBLANK (I think - I haven't been timing).


The problem occurs when trying to change the palette alongside it. For some reason, on about the 2nd image, changing the palette throws an Illegal Instruction guru meditation. In particular I note that this occurs when trying to write $018e0789 over $018e0dba in the copperlist. Looking at the debugger, immediately after writing this long the PC jumps to $F80ED4 (from memory - don't have the debugger immediately on hand). Is this just the routine address for handling crashes or could my code be somehow causing the jump?


So, to clue you in on my program:


I have 2 structures (tables?) with pointers to iterate over:


My bitplane data. This goes to a3 and a4.

struct:
            dc.l       laura1,0

            dc.l       laura2,0

            dc.l       laura3,0

            dc.l       laura4,0

            dc.l       laura5,0

            CNOP       0,4

my palette data. This goes to a0 and a1.

palstruct:  

            dc.l       laura1pal
            dc.l       laura2pal
            dc.l       laura3pal
            dc.l       laura4pal
            dc.l       laura5pal

            CNOP      0,4

and an example of one of the palettes the entries points to:

laura1pal:
            dc.l       $018e0dba
            dc.l       $018c0b87
            dc.l       $018a0976
            dc.l       $01880a64
            dc.l       $01860765
            dc.l       $01840632
            dc.l       $01820433
            dc.l       $01800311

            CNOP       0,4

In the mainloop this code constructs the copperlist once per frame:

; a6 stores our pointer to the copperlist

 ; bitplane 0
            move.l     (a4),d0 ;start of bitplane data 
            move.w     #$00e2,(a6)+                 
            move.w     d0,(a6)+                     
            swap       d0                           
            move.w     #$00e0,(a6)+
            move.w     d0,(a6)+

            add.l      #40,(a4) ;move to next bitplane

  ;bitplane 1
            move.l     (a4),d0
            move.w     #$00e6,(a6)+
            move.w     d0,(a6)+
            swap       d0
            move.w     #$00e4,(a6)+
            move.w     d0,(a6)+

            add.l      #40,(a4)

  ;bitplane 2
            move.l     (a4),d0
            move.w     #$00ea,(a6)+
            move.w     d0,(a6)+
            swap       d0
            move.w     #$00e8,(a6)+
            move.w     d0,(a6)+
  
            move.l      (a1),a0 ;effective address of a1 = laura1pal
            ;this is borked
            move.l     (a0)+,(a6)+ ;a0 points to start of palette, i.e. $018e0dba. Tends to crash here
            move.l     (a0)+,(a6)+ 
            move.l     (a0)+,(a6)+
            move.l     (a0)+,(a6)+
            move.l     (a0)+,(a6)+
            move.l     (a0)+,(a6)+
            move.l     (a0)+,(a6)+
            move.l     (a0),(a6)+


            move.l     #$fffffffe,(a6)+ ;end the list

At the end of the frame we increment our structure pointer registers (a1, a3) by the appropriate amount to go to the next entry in the list. Debugging this has shown it to work and doesn't escape the structure or miss. I keep a value of 4 stored in d4 and decrement every frame too, and reset the pointers to the beginning when it reaches zero.


Typically the first iteration runs fine, when the copperlist is all zeroes. On the 2nd iteration, it seems to crash when trying to write a new value into the $018e colour register. This only happens when I'm changing the data being written, If i hardcoded addresses for the copperlist and wrote the same ones every frame it does not complain at all.

My suspicion is that the copperlist can't be touched while it's executing - only updated between the end of the list and when we move the pointer back into the COP1LCH register during VBLANK. Somehow this may be happening? Although that doesn't match why it doesn't complain when I write the same data every frame.


I really cannot understand why or what is throwing an illegal instruction. I am probably missing something fundamental here, but I don't understand it and I haven't been able to figure it out over the last 2 days of tedious tracing

Thank you, if you guys need more clarity on my code or just want the full dump I'm happy to provide - it's just a bit of a mess at the moment so I wanted to only show the pertinent sections.

[roondar]

You can update the Copperlist whenever you desire, there is no lockout (though if you update the Copper at the wrong time, you may see some display glitches). It should definitely not crash the system*

My hunch is that either A1, A4 or A6 end up pointing to an out-of-bounds address on the second run and that this causes your issue. However, without more code it is hard to be sure.

*) Exception: if you program the Blitter with the Copper, you could end up crashing the system if your timing is off.

[a/b]

Any particular reason you're adding 40 to (a4) (permanent change) and simply not to d0 (temporary change), so you also don't have to reload (a4) all the time?
Other than that, can't see anything wrong...

[Galahad/FLT]

Those add.l #40,(a4) your code states its to shift to next bitplane, but actually that size would be to start of next horizontal line in the same bitplane.

Assuming the following

Width equ 320
Height equ 200
Bitplanes equ 3


Calculation for size of bitplane is:

(Width/8)*Height

Your 40 is derived from Width/8 which is one horizontal line

Are you resetting at to the start everytime you rebuild the copperlist?

[Asman]

@rexo12

Are you sure that copperlist and images are stored in CHIP memory ?

[rexo12]

My suspicion is also that my pointer registers are going out of bounds somewhere but so far i haven't been able to catch any of them in the act. Is it possible that the copper is reaching the end of the list before I have written the $fffffffe wait instruction? Thus taking in zeroes or garbage data as instructions. That said, the size of the list never changes so that wait instruction should still be present from the last frame. Again, this crash only happens when updating the palette.



Actually no reason I've been incrementing a4, could just swap d0 back around and continue to use that. (Or otherwise write to the high word i guess?). Saves me an address register!

The images are ILBMs. - I'm skipping the header and just hand-coding palettes etc because I don't want to tackle the code to parse it (yet) - my understanding is that each bitplane is interleaved by raster line? So bitplane 1 at 0, bitplane 2 at 40, bitplane 3 at 80 and then let the BPLMOD registers do their thing (These are set to 80). This works exactly fine for static images.

I am resetting a6 (my copperlist pointer) to the beginning of the list every VBLANK.

I have a section directive that should be putting all of the relevant data into chipram. Does vasm have any syntax requirements for sections or should it just work like any other directive (and not a label)?

 Section ChipRAM,Data_c

Just reran the program and I get something new - Illegal Address Access.

 ################################################################################.
#                               Software Failure!                              #.
#                           Task : 0x00C03ED8 - laura                          #.
#                  Error: 0x80000003 - Illegal address access                  #.
################################################################################.
PC   : 0x0002EBB9.
Module laura Segment 1 - unknown - (0x000199E8) Offset 0x000151D1.
CPU context:.
D0: 5CD00003 00000003 0080012F 00C2436C.
D4: 00000002 00000000 00000000 00C2436C.
A0: 0002EBB9 0003CD54 00C047C0 0003CD44.
A4: 0003CD44 00F9070C 0003CD78 00C65BB0.
SR:     2CD1.
PC: 0002EBB9.
SegTracker: laura.
Hunk 1, Offset $000151CD, SegList $00309ADD.
.
Stack trace:.
0x00000000 Address not found.
################################################################################.
  D0 00E013F0   D1 00E01450   D2 0000002F   D3 00E7EE22 
  D4 00000030   D5 00E01441   D6 00C00000   D7 0001FFF8 
  A0 00F02C7E   A1 00E01441   A2 00E0D776   A3 00C000DC 
  A4 00FFDFAC   A5 0003FFE8   A6 00C00020   A7 0003FF00 
USP  00C65BB0 ISP  0003FF00 
T=00 S=1 M=0 X=0 N=1 Z=0 V=0 C=1 IMASK=4 STP=0
Prefetch 4afc (ILLEGAL) 0c52 (CMP) Chip latch 00E01450
00FE8678 0c52 4afc                CMP.W #$4afc,(A2) [001c]
Next PC: 00fe867c

note that the PC is at $02EBB9. This is the value in a0 and is just a pointer to the 3rd palette list:

 

0002EBB9 018E 0789 018C 0767 018A 0555 0188 0457  
0002EBC9 0186 0534 0184 0236 0182 0234 0180 0111  
0002EBD9 0000 00C0

Does the PC location mean that somehow we've jumped to this address? I never make any jumps to address registers in my program.

Otherwise, inspecting the memory each address register points to shows that it's all as expected...

As before, we make it 2 iterations in before it crashes (i.e. we crash on frame 3). In particular, it crashes at exactly this instruction:

 

            move.l      (a1),a0

-->       move.l      (a0)+,(a6)+ ;[018e0211] over the top of [018e0bbb] causes crash.
            move.l     (a0)+,(a6)+ 
            move.l     (a0)+,(a6)+
            move.l     (a0)+,(a6)+
            move.l     (a0)+,(a6)+
            move.l     (a0)+,(a6)+
            move.l     (a0)+,(a6)+

dumps of the full copperlists at each frame before the crash.

a6 copperlist at first frame:
0003CD60 00E2 99F0 00E0 0001 00E6 9A18 00E4 0001 ;3cd60 is the start  
0003CD70 00EA 9A40 00E8 0001 018E 0DBA 018C 0B87  
0003CD80 018A 0976 0188 0A64 0186 0765 0184 0632  
0003CD90 0182 0433 0180 0311 FFFF FFFE 0000 0000


a6 copperlist at 2nd frame:
0003CD60 00E2 5C80 00E0 0003 00E6 5CA8 00E4 0003  
0003CD70 00EA 5CD0 00E8 0003 018E 0BBB 018C 0B77  
0003CD80 018A 0888 0188 0855 0186 0644 0184 0722  
0003CD90 0182 0433 0180 0211 FFFF FFFE 0000 0000

In my tests, this only happens when i try to update the palette. Keeping the bitplane pointer static and incrementing the palette crashes, using a static palette and updating the bitplanes is fine, keeping both static is also fine. However my palette pointers.. point to the correct place.

very confusing.

Find attached my full code.

[a/b]

;;            add.l      #16,a3                       ; move to next image pointer
            addq.l      #8,a3                       ; move to next image pointer

a3 and a4 point to struct, 8 bytes per image (not 16).
Reason for the crash: a0 and/or a1 are odd (68000/010 cant access words/longwords on odd addresses). You probably overwrite something in palstruct because you are overstepping struct.

[rexo12]

good catch, thank you. Although 8 byte steps still seem to crash.. I also can't seem to change my structure so that it doesn't pad with 0's either.

My structure looks like this in memory - It should be 8 bytes to each next pointer.

0003CD24 0001 99F0 0000 0000 0002 0A94 0000 0000  <--- addresses to images.
0003CD34 0002 7B38 0000 0000 0002 EBDC 0000 0000  
0003CD44 0003 5C80 0000 0000 0002 0A74 0002 7B18  <--- 020a74 is start of palstruct
0003CD54 0002 EBB9 0003 5C60 0003 CD04 0FFF FFFE

I tried messing with my counter in d4 and I notice that it's always crashing regardless of the value I give it. If it's 0, the check should always be resetting the pointers to the top, and so it shouldn't have any opportunity to move too far. Perhaps there's something wrong with my logic there?

This even address thing may be the problem however as I'm not sure i fully understand it. If i'm understanding you, a3/a4 are overstepping into palstruct and writing an odd value (due to overflow or whatever), that is then being accessed by a0/a1/copper, and causing a crash?

[Falcon]

Two things I have noticed so far:

- No CNOP to align "laura3pal" - looking at the memory dump of "palstruct", the third entry is an odd address (0002 EBB9)
- The longword in the initial copperlist needs to be changed to "$FFFFFFFE" (you're missing one "F")

Not sure how your PC ended up at 0002EBB9, still working on that one. I'd love to see how this turns out - please let us know!

[Galahad/FLT]

Just out of interest, any of your iff files odd sized?

[rexo12]

Of course 2EBB9 is odd! Oops.

Good question regarding images. Bash/ll claims they're all exactly 24001 Bytes, which would be odd sized.

I will update you if I make any progress - Had other things on my plate this last week. In advance, I would like to thank everyone for their help so far

[rexo12]

Hello. I never figured out what was going wrong - however I did essentially the same thing again in another project (double/triple indirect pointers) and it worked absolutely fine. I expect there was something I was missing with odd/even alignments, or just the alignment in general.

Thank you for your help.