A89: Invalid opcodes (was Re: Addressing)

[Prev][Next][Index][Thread]

A89: Invalid opcodes (was Re: Addressing)


> Taking the advice of Johan, I changed the mulu.l to mulu.w.  That caused a
> lovely crash complete with grayscale static.  (Which I suppose was better
> than a blank screen and an address error.)  I then tried the optimized
code
> he was kind enough to include.  It caused the same lovely crash.  Any
ideas?

Repeat after me:

MULU.L IS NOT A VALID 68000 OPCODE
MULU.L IS NOT A VALID 68000 OPCODE
MULU.L IS NOT A VALID 68000 OPCODE
MULU.L IS NOT A VALID 68000 OPCODE
MULU.L IS NOT A VALID 68000 OPCODE

and add this for good measure:

DIVU.L IS NOT A VALID 68000 OPCODE
DIVU.L IS NOT A VALID 68000 OPCODE
DIVU.L IS NOT A VALID 68000 OPCODE
DIVU.L IS NOT A VALID 68000 OPCODE
DIVU.L IS NOT A VALID 68000 OPCODE

Ditto for muls.l and divs.l.  Rinse, Lather, and Repeat as Desired.

The 68000 can only handle division and multiplication of words (with
division returning the quotient in the lower word and remainder in the upper
word).  A68k - which sucks royally - allows other lengths, as they are
present in higher-end versions of the chips (such as the 68040), but they're
not on the 89's 68000.  They'll crash with an illegal opcode error and leave
you baffled for months, just like me.

> choose:
>     ; in:   d0.w=x
>     ;   d1.w=y
>     ;   d2.w=picture number (0=first)
>     ;
>     lea Pic0(pc),a0
>     lsl.w   #3,d2
>     add.w   d2,a0
>     add.w   d2,d2
>     add.w   d2,a0

to keep a running commentary, we're adding a total of 8 + 16 = 24 times
picture number to a0, correct?  Your pictures are each 24 bytes?  Not the
most common number, so I might as well check.  And the "add.w d2,d2" is
better off as another "lsl.w #1,d2"

>     moveq   #-1,d3

That's the same as #%11111111

>     move.l  graphlib::plane0,a1

Technically, you should use (graphlib::plane0) - with the parentheses.  But
since a68k doesn't care I won't get into the specifications of indirect
addressing notation here.  It doesn't affect the program's execution at all.

>     lea graphlib::put_sprite_mask,a2
>     jsr (a2)

An original optimization (since you use it twice) - I like it a lot, I
should use it myself - but not one that I would try if the routine doesn't
work yet =)

>     lea 12(a0),a0

So we're not pointing to the sprite 12*(d2+1)?  Are you sure you want this
AND what you have above?

>     move.l  graphlib::plane1,a1
>     jmp (a2)

I can assume that you've got (graphlib::choosescreen) set to 1?

This looks like it should compile and run fine as long as those little
things I noted aren't logic errors - are you sure that this is the buggy
part of your code, not something surrounding it?  Are you sure that the
input values are correct?

Why not try isolating this portion of the code and testing it by itself
once?  And you're sure that the data it points to is in the proper graphlib
sprite format?

    -Scott
Follow-Ups: References: