
The unique thing about rg-dis is its deep knowledge of Atari hardware. It understands the full memory map of the machine; all the hardware registers, system vectors and operating system variables. It has full understanding of all the GEMDOS, BIOS and XBIOS calls. It knows all about AES and VDI and their data structures.
With this knowledge, it can annotate all operating system calls; input arguments and outputs.
And as it also understands assembly language, it can track how registers are stored and loaded, and assign contextually aware names to functions, making the disassembly far more readable.
It can also detect strings; both raw strings and VT52 enhanced ones (which it annotates), and gives them meaningful labels too.
Based on the same library that powers rg-asm, it can also show you cycle timing for instructions.
rg-dis has convenience functionality that allows you to disassemble files directly from containers like ZIP files without unzipping them. It also understands common Atari disk image formats, and you can disassemble files directly from them.
Another useful disk based feature - it can disassemble bootsectors directly, or full raw disk images, or any range of tracks and sectors you specify. Very handy for working with raw disk images.
rg-dis is a single binary with no dependencies - just unzip and run.
This is the second in our range of tools for Atari developers. More to come.



Comments
Thanks!
@AdamK - good idea. Put together a new release which will now detect the common C libraries of popular Atari C compilers (VBCC, PureC etc). It stores binary signatures for library functions, so can identify then and give them function names. It also understands the calling convention (fastcall vs stdcall) so can annotate arguments passed to standard C library functions.
Would it be possible to export source code compatible with Devpac?
MOVE.W D0,-2(A6)
BRA.S _L642A
dc.w $4E5E
RTS
#2 "0238 / FFFD / 0484" - andi.b #$fd.$484.W
ADDQ.L #6,A7
MOVE.L D0,-8(A6)
_L9890:
dc.w $0238
dc.w $FFFD
dc.w $0484
MOVE.L -4(A6),D0
BNE.S _L98AC
MOVE.L -8(A6),-(A7)
MOVE.W #32,-(A7)
JSR (_L50B76).L
and more
Decoding of the two opcodes above has also been fixed.
Following up on AdamK's idea, starting to add detection of GFA basic executables, and annotation of GFA core library function names.
As ever, this is a pre-1.0 release, so if you spot any more bugs, let me know :)
Are you on discord?
".dc.b" => "dc.b"
".dc.l" => "dc.l"
".ds.b" => "ds.b"
"LINEA #3" => "LINEA 3"
checked in "0.9.4"
"LINEA #3" => "LINEA 3"
"LINEA #5" => "LINEA 5"
"ANDI.B #$FFFD,($484).W" => "ANDI.B #$FD,($484).W"
"MOVE.B #$FFFA,(_D56B2C).L" => "MOVE.B #$FA,(_D56B2C).L"
"MOVE.B #$FFE5,(A0,D0.L)" => "MOVE.B #$E5,(A0,D0.L)"
Have been working through all the issues that you are raising and pushing fixes.
I'm not on discord, but am around on IRC.
Will also take a look at anything you post here.
0.9.9: disassembled and assembled Sound Designer II - 103K asm lines. no issues.
thanks
And yes, we are building some other tools around the DSP56K; including a dis-assembler. More news soon.
movea.l 4(pc,d2),a2 similarly jmp $42(pc,d1)
One feature request, can you add the option to use tabs rather than hard spacing? Devpac 2.25 only allows 999kb :) at the moment I have to run the source through Stew's source convertor.
Cheers
Devpac 2.25? You know they have now released Devpac 3, right? ;)
Anyway, I have fixed the source code emission for PC relative addressing for devpac2 dialect.
Have also enhanced the --tabs option so it is used for all spacing, not just line indentation. This should reduce source code size, so you can squeeze more into your devpac2 buffer.
does rg-dis also generate label names? meaning labels like: SAVED_PHYSBASE, SAVED_LOGBASE, VBL_HANDLER.. it makes sense that a tool could detect these label names.
Regarding Labels, would it be possible to use them from an external file?
@cyprian - the tool already loads embedded symbols and sidecars (DRI/GST), but now label file loading has been added (you can add your own TSV file of address,label_name pairs), or specify labels directly on the command line. More details in the readme.
https://photos.app.goo.gl/kw5PdzcRyzKQ6Z7p8 RG
https://photos.app.goo.gl/x2Tcs69Nfv9Ssrci7 ER
GRZ
Should all be fixed in the latest version now.
a little bug report. rs-dis 0.9.16 hope this helps!
org $184FA
OR.B $0001(PC),D3 ; rg-dis output for bytes 863A 0001
vasm -m68020 -no-opt produces 863B 0170 FFFE 7B05.
The same happens with MOVEA.L $0006(PC,D0.W),A0 (207B 0006).
my original reported issue was already finished. my buddy claude still finds the following issues. using VASM and 68020:
What still happens in 0.9.30:
Issue 2: .cpu / .text / .globl are still emitted, so the sed rewrite stays.
Issue 3: 16 byte immediates like ORI.B #$86EE,D1 still don't reassemble.
Issue 4: the target of BRA.W at $9FA4 ($9EBE) is still left as data.
Issue 7: the pointer table at $184E4 still has its last four entries decoded as instructions (now OR.B *+3(PC),D3). The sine table also still decodes as code.
Is there a specific executable you are disassembling that shows the issues that you could share?
Now in disassembled code I see:
; prgflags: $00000007 (fastload, ttramload, ttrammem)
But it would be cool to have something like this:
Fastload EQU 1
Fastload EQU 1
Fastload EQU 1
TTRAM_RUN EQU 2
TTRAM_Malloc EQU 4
COMMENT HEAD=Fastload+TTRAM_RUN+TTRAM_Malloc
The ori.b #$86ee,d1 assembles fine in rg-asm (and some other assemblers) as it is actually legal code; this instruction has a full word for its immediate value. Of course the instruction itself only uses the lowest 8 bits of the immediate, so you may wonder why you have all these unused bytes sitting around in your source code, what possible use could they have .. and then you see something like tIn's compofylla ...
@cyprian - have added devpac compatible prgflags, will be automatically inserted in your code when you have that dialect selected.