xdg99 possibly not correctly disassembling `vcha` / `vchar` instruction after `FEND`?

[hippietrail]

I've been working on my own GPL disassembler extension for the Ghidra reverse-engineering tool and found an anomaly disassembling a hello world example posted in the atariage forum for me to test on. I use xdg99 as a reference to check that my results match.

Here is xdg99's output:

601d 07   all   >20                  
601e 20                              
601f 87   dclr  @ypt                 
6020 7e                              
6021 08   fmt                        
6022 cb   for   >0c                  
6023 ff   col   >1a                  
6024 1a                              
6025 04   htext 'HELLO'              
6026 48                              
6027 45                              
6028 4c                              
6029 4c                              
602a 4f                              
602b a1   row+  >02                  
602c fb   fend                       
602d 60                              
602e 23                              
602f fb   fend                       
6030 86   clr   @>834a               
6031 4a                              
6032 be   st    >20, @>834b          
6033 4b                              
6034 20                              

And here is RetroGhidra's output:

       601d 07 20                   ALL        >0x20
       601f 87 7e                   DCLR       @>0x837e

       6021 08                      FMT
       6022 cb                      FOR        >0xc
       6023 ff 1a                   COL        >0x1a
       6025 04 48 45 4c 4c 4f       HTEX       0x480x450x4c0x4c0x4f
       602b a1                      ROW+       >0x2
       602c fb                      FEND
       602d 60 23                   VCHAR      >0x1,>'#'
       602f fb                      FEND
       6030 86 4a                   CLR        @>0x834a
       6032 be 4b 20                ST         >0x20,@>0x834b

Notice how at 602c it looks like the FEND instruction uses the three bytes fb 60 23 rather than just fb as would be normal and the 60 and 23 bytes are blank to their right.
After looking through the GPL docs I have I implemented the 6x VCHA instruction which seems correct for that position.

[hippietrail]

Or does FEND actually behave differently when it ends a FOR compared to when it ends a FMT?
"The Graphics Programming Language" by R. A. Green has this on page 81 "E.2 Format Suboperations"

FB FEND >FB {End of FMT}
FB FEND >FB,GGGG {End of FOR}

But on page 38 "9.29 FEND—End of Formatted Screen Write" it specifically says there is no operand:

[label] FEND [comment]

This instruction is a suboperation of the formatted screen write instruction and is only valid after an FMT instruction. The FEND instruction terminates a FOR group if one is active, or the FMT instruction. The instruction has no operands. STATUS is unaffected by this instruction. Although a “label” is allowed, it is illegal to branch to a formatted write suboperation. Example:

FMT Formatted screen write
··· Suboperands
FEND End of formatted write

And this GGGG doesn't occur anywhere else in the book. So now I'm not sure at all...

[endlos99]

First of all, thanks alot for the bug report! It seems that the FOR argument is disassembled incorrectly. It's also a cool project you're doing!

Regarding the FOR-END, this weird address argument does exist, and GROM cartridges containing this statement do execute it. Of course, my disassembly is also wrong.

That's just my first glance, I'll have to look at it again later. Please note, however, I'm going on vacation later this week, and I don't know if I have time before that.

[hippietrail]

I'll keep my eye out for your fix to see if it matched RetroGhidra's output. Let me know if you have a look at my project. I haven't pushed the GPL disassembler yet because I haven't worked out all of the addressing mode binary encodings yet.