Currently no version of GFA-Basic runs on the FireBee. GBE also fails. I have no plans to fix this.

Its a bit technical, but I'll try to explain it. As you know the Coldfire is not 100% 68k compatible. Certain opcodes are not supported or handled differently. The CFLib manages to solve quite a lot of these issues, but there are a couple of instructions it cannot fix. One of them happens to be move.b to or from the stack (a7). My guess is it cannot be trapped. Anyway, the 680x0 chips keep the stack even. If you push a byte, it pads it with a 0. The ColdFire on the other hand pushes just a byte and you end up with a stack on an odd address.

There's two common occurrences in GFA where this instruction is used. One is to temporarily null terminate a string (prep for some OS call), so the result is the stack is odd at the moment an OS function is called. I don't really know if that is good or bad. Something tells me its a bad idea, because at the time the OS was written, the stack was assumed to be even. Maybe some one else knows?

Something like this:

lea     0(a1,d1.w),a0 ;locate end of string
move.b  (a0),-(a7)    ;save end char addr (stack goes odd at this point on the ColdFire)
pea     (a0)          ;save char addr
clr.b   (a0)          ;null terminated string
pea     (a1)          ;string addr
move.w  d7,-(a7)      ;op code
trap    #@gemdos
addq.l  #6,a7         ;fix stack
movea.l (a7)+,a0      ;restore end char addr
move.b  (a7)+,(a0)    ;restore end char

The other occurrence is used to decode words on an odd address (within the token stream). This is where GFA buggers. To make matters worse the original author of GFA exploited this instruction. He expects the processor to pad the byte to a word, which has the side effect of shifting it left 8 bits if he reads it back with move.w (sp)+. This goes completely wrong on the ColdFire and GFA crashes. There's 158 occurrence of move.b to the stack in the original editor alone.

Something like this:

decode_index:  moveq  #0,d0         ;clr
               cmpi.b #$f0,(a5)+    ;check index size
               bcs.s  .1_byte_index ;  byte?  yes...
               move.b (a5)+,-(sp)   ;upper byte (a5=token stream, might be on an odd address)
               move.w (sp)+,d0      ;now its shifted left 8 bits
.1_byte_index: move.b (a5)+,d0      ;move lower byte into place (index decoded)

The majority of these are what I just described. The entire GFA package contains 231 occurrences. The linker is the only component that likely works as is.