I dumped the ROM out of a piece of retro-tech and have been working through the code in Ghidra. Unfortunately, I can’t exactly decompile it because I don’t think it was originally written in a higher level language.
For example, the stack is rarely used and most functions either deal entirely in global variables, or binary values are passed back using the carry or other low-level bits. Trying to turn it into C would just make spaghetti code with a different sauce.
So my current plan is to just comment every subroutine as best I can, but that still leaves a few massive lookup tables that should be dropped into a spreadsheet of some sort to add context. Not to mention schematics.
My question is what’s the best way to present all of this? I’d like to open-source the result, so a simple PDF is not ideal. I guess I should make a GitHub project? Are there any good examples or templates I can draw on?
I’m not an expert, but isn’t the goal often times to create a debug symbols file to name functions and variables? Then the next step is to provide source.
Yeah, I’m working on that part. It’s just messy because a lot of portions of the code can’t be confined to functions. There’s a lot of GOTO equivalents.
Hmm. Isn’t there a theorem that every combination of GOTOs is equivalent to some structured programming equivalent?
(Sorry for the late reply, the scaled feed setting isn’t scaled enough I guess)
Thanks for the response!
I think the issue is that the “structured programming equivalent” is just a really, really long function that’s not any easier to read.
Do you have any idea what the high-level language in question might be? There has to be some logic to it (or alternatively it was spaghetti code as written). Even just the era and platform would narrow it down a bit.
Edit: Although rereading this, you’re less asking how to make it pretty again, and more asking how to publish it, which I can’t comment on.
Yeah, it was a budget portable device released in 1995 running a processor from 1984. I think it was just written in straight assembly. I’ve even found some unreachable code snippets in the assembly that print debug messages which confirm that theory.
Yikes!
Yeah, I don’t think I can help too much with that, unfortunately. I hear there was quite an art to annotating hand-written assembly (to the point where you’re basically play-acting an interpreter or compiler), but I wasn’t there to learn.
Source with lots of comments.
If you do have a C compiler capable of inline ASM for the chip, you could use this to get some structure into the code, and it would allow for Doxygen-Style comments. This will only work with some code that already has a bit of a structure, though.