Those with a keen eye may have noticed that I've been relatively inactive as far as new projects and development of old projects go (RubEXQBR), I hope to change that with this project.

I am proud to present:
DZ8x: My eZ80 disassembler.

I've hinted at a disassembler before on the irc channel, but was too reluctant to make a post up to this point. But I finally have been convinced by friends on my Discord server to make a post about it.

INFORMATION:
The name DZ8x comes from 3 different words: Disassemble, eZ80, and 8xp.
I have been working on this project for 1 year, 5 months, and 20 days as of this writing.
Please note that this is a computer application, not a calculator executable.

FEATURES:
DZ8x started out as just a simple disassembler for eZ80 in hex files, but quickly expanded into other territory as I figured out what was possible.
DZ8x can read and display the contents of any 8x? file (73/82/83/85/86 support is still experimental, and there are no plans to support bundles), can take hex and bin files as input, and can take input directly from the command line.
Because of my research into TI's formats for this program, I can tell you almost anything about any of TI's file's formats.
Output is designed to be directly recompiled with spasm.

FUTURE FEATURES:
Defining multiple entry points would be nice,
as well as include files, but I don't want to have to parse those messes…
I hope to branch into Z80 soon.

ALPHA BETA GAMMA:
Currently, this software is in alpha, but will soon (hopefully within the next month) be moved into closed beta at which point I will find out that it is the most buggy software in existence.

RELEASE:
I may or may not end up publicly releasing this project, but if I do, the download link will be available… Somewhere.

SOURCE:
Closed, likely indefinitely, or at least until I get around to completely rewriting it.

FEEDBACK:
Feel free to post any feedback, questions, comments, concerns, and suggestions in this thread.

SCREENSHOT:
Stopwatch


I believe the reason I stopped working on RubEXQBR was the lack of community support, I'll just have to hope that this project does not have the same fate.
Should I be posting at all?…

Very handy indeed - also I love the colour scheme!

I wrote an e/Z80 disassembler five years ago. Haven't seen any need to update it further, but feel free to look at the code or even branch it.

It's written in C# so porting it to a calculator isn't directly an option; but it was quick to put together and served my needs back then. Looks like you're adding a larger feature set, so that's interesting.

Thumbs up for the implementation and design ( colors, font). It is very readable and it has a good structure:

Prologue: The info about the header file, file status

Middle: The dumped OP Codes ( An option for ASCII + HEX would come more pretty maybe has in the "hexdump -C" output command )

Final: The Disassembled Code with lines, Addresses and the final stats.

I hope you were using the File Format and Link Protocol Guide and not trying to figure out the file formats by yourself!

What's it written in? What's still left to do? I see that you mention "I hope to branch into Z80 soon." but also specify that it can handle the 73, 82, 83, 86, etc. Help me understand that.

Thanks! I quite enjoyed choosing the colours out. They will probably be less vibrant in Windows terminals >.>

I will definitely look into your disassembler, though at-a-glance yours is much cleaner-cut than mine; I blame the larger feature set you mentioned

I may not be Mateo, but even I don't see a purpose to this, so no. Just run the file directly through hexdump if that's the output you want.

I was figuring everything out by myself (referencing sources such as that when I couldn't create the files on-demand) because the File Format Guide didn't include anything specifically on the CE/CSE formats, for example: The color section of GDB formats, color image formats, tokens that didn't exist on the 83/84, the exact vartypes, and the last bit in the mode settings does have a purpose now: 0=DridDot, 1=GridLine, in fact, last I checked it is even missing from grfDBFlags in ti84pce.inc. They were also wrong in several locations, such as the function flag byte, which has much more depth than they let on. So I do all the research I can and only fall back onto the documentation when necessary, surely you can relate.

It is written in C. I'm not really sure what's left, I have a small list of technical bugs and a "nice to do" list, such as zx7 decompression. My attempts to use MinGW to compile it into a windows executable (exe) have been futile, so I only have the Mach-O binary. Come to think of it, I should figure out what subset of the functionality I should release, and what parts I should keep to myself…
I mention 73/82/83/85/86 formats with the 8x extension because it can read .85? and .83? file headers as well as the content, for example, 83 files have a header length of 0xB, rather than the 8x 0xD and that's something it can handle (Just dropping the ProdID and Archive from 8x in this case). But the 83p's Z80 contents is handled the same as eZ80 because it can identify Z80, but it doesn't know how to process it differently yet.