Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
hippietrail opened this issue Oct 6, 2024 · 4 comments

Comments

@hippietrail
Copy link

hippietrail commented Oct 6, 2024

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
Copy link
Author

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...

@hippietrail hippietrail changed the title xdg99 not correctly disassembling vcha / vchar instruction xdg99 possibly not correctly disassembling vcha / vchar instruction after FEND? Oct 8, 2024
@endlos99
Copy link
Owner

endlos99 commented Oct 8, 2024

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
Copy link
Author

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.

@hippietrail
Copy link
Author

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.

I think I called this wrong. As my disassembly gets more complete I understand things better. It now seems to me that the same opcode is used for FEND to end both FMT and FOR but that it takes an operand only when it ends a FOR. Do you know if this is documented?

By the way, I'm also having some trouble decoding the operand format for MOVE. I know the regular operand format encoding is documented but unless I'm missing something the MOVE variant doesn't seem to be.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants