Re: [Freemint-discuss] Disassembly of TOS 1.00 with Ghidra

[Vincent R. <vin...@fr...>]

On 08/01/2025 at 07:38, Thorsten Otto via Freemint-discuss wrote:
> Yes, i did similar for AES. There is no direct function ptr table, but once 
> the crysbind function was identified, you can look at its disassembly, and 
> compare that to the source.

Ah, indeed. That makes sense.

But crysbind() was one of the latest functions I found before stopping. I 
even found it after I bundled the current GAR file, so its label is not 
present in the disassembly. I only put it to internals.md. So currently, I 
need to do 'G' fe54d6 to find it.

Of course, crysbind() is crippled with Line-F calls, so it's a pain to 
disassemble. But by using 'D' (standard disassembly) and '$' 
(AddLineFReference script) it becomes rather easy. Then functions can be 
directly renamed with 'L' from crysbind() disassembly, and you're done. 
Unfortunately this can't be done from the decompiled source, due to the 
Line-F issue.

> Yes, of course. But i have to do some checks first. I am using a variant of 
> the 68000 processor definition that is not part of the ghidra source, don't 
> know how well that works if someone else imports the GAR file.

Ah. Yes, this has to be checked.
But it seems that processor definitions are only used in read-only mode, to 
display a nice disassembly and of course produce the dynamic decompilation. 
So I'm quite optimistic, custom processor definitions shouldn't cause 
trouble. But this has to be tried.

> You can open the symbol table window, select all labels, then right-click 
> and export them to a CSV file. But there seems to be no (automatic) way to 
> import them again (maybe using the ImportSymbolsScript). My current version 
> is attached if you want to have a look.

Ah, it's nice. I will have a look.

> Yes, i know them. But they are for importing TOS binaries, that does not 
> help for the ROMs.

There is also this script:
https://github.com/czietz/ghidraScripts_for_Atari/blob/master/ImportAtariTOSROM.py

It does the initial memory setup, then it *does* load symbols from an 
external file.

I haven't tried it, though.

>>To replace a Line-F instruction with "dw" (a.k.a dc.w) by pressing 'T' 
>>and assigning the type "word".
> 
> Yes but there is currently one major problem: if you do that, the decompiler 
> will no longer stop at that instruction.

No, this doesn't happen for me.
In the decompilation window (the C one), I get:

/* WARNING: Bad instruction - Truncating control flow here */
halt_baddata();

It seems that the disassembly and decompilation window are completely 
different stuff. My '$' macro only acts on the disassembly window, this has 
no effect to the decompilation (alas).

You may have different results due to your custom 68000 definition.

Note that most "F" opcodes are invalid, so this stops the decompilation. But 
if you managed to convince Ghidra that they are instructions (not data), 
then sure, the result would be different.

Another case would be Line-F opcodes which are valid FPU instructions. I 
haven't checked that case.

> But it does not find the function return statement either, so it will
> continue to the end of the ROM (or if it runs into some other data that
> cannot be disassembled). That takes ages.

Again, I don't encounter this behaviour on standard Ghidra, because 
"halt_baddata()" happens as soon as a Line-F opcode is found.

> I've also tried to match the linefcalls, but without much success yet. See 
> https://github.com/NationalSecurityAgency/ghidra/pull/7126#issuecomment-2572492219
> Maybe you want to try that if your are more familiar with ghidra.

Fine. I will have a look.
Note that my '$' script is just a workaround to ease browsing of the 
disassembly.
Of course, the right solution would be what you tried in that Issue: 
properly implement Line-F opcodes as instructions. Theoretically, they 
should just act like "jsr" and "rts". But convincing Ghidra to do that is 
another story.

-- 
Vincent Rivière