[RyanfaeScotland]

My money would be on the Git / BitBucket solution as well for sure. Not done it myself yet but it's what I plan to do once I get round to having enough code to justify it!

What's quite nice with this as well is if you get your assembler working with Visual Studio (I'm using Visual Studio Code for 68K) then with a little bit more work you can get it integrated with GitHub which is really handy!

I wrote my own assembler for 68k (Sega Genesis/Mega Drive, etc)

I'd be interested in hearing more about that RedComet if you don't mind sharing or have links to existing info?

[RedComet]

I'd be interested in hearing more about that RedComet if you don't mind sharing or have links to existing info?

There's not much to tell really. You just need the 68k manual for the instruction encodings and then it's just parsing source code and generating the instructions.

I wrote the assembler over ten years ago in C at a time when I didn't fully understand how to write C, compilers or really any program over a couple hundred lines long. As I recall, there were a ton of memory leaks and other issues along with generally being poorly architected and not maintainable. That said, it did the job and it is the tool that I used for all of the work I did for Bare Knuckle 3 and the first set of work for Surging Aura.

I had thought about rewriting the assembler from scratch last summer and ultimately decided to just write a pretty simple Python script to do some post-processing of the output of asm68k, which I've been using for any homebrew endeavors. I estimated it would take me a couple months working nights and weekends to get something implemented and I decided I'd rather spend that time working on getting Surging Aura to the point it needed to be at.

[RyanfaeScotland]

...I had thought about rewriting the assembler from scratch last summer and ultimately decided to just write a pretty simple Python script to do some post-processing of the output of asm68k...

That always seems to be the toss up doesn't it! I'm currently fighting with the source code of Exodus to get it disassembling a LINK instruction correctly. It's being a pain in the ass to fix 'properly' and I'm fairly certain I could throw together a quick n dirty tool to perform the correction in the generated files in about an hour or so.

Might write my own 68K disassembler one day, seems interesting.

[jonk]

Might write my own 68K disassembler one day, seems interesting.

What will make that interesting (as opposed to trivially easy) to write, will be the ability to separate code from data. You can start by knowing where code execution begins, a priori, and then work from there through the binary data. But it's not uncommon for calls to include data that follows a call, and where the called routine may advance the return address on the stack before performing a return. There are also jump and call address tables, etc. These, and similar tricks, can make disassembly "interesting."

Without that, one is almost forced to disassemble-by-parts, using a human to help guide things. Which makes such "interactive disassemblers" far, far less useful than they might be. Focusing entirely on automated disassembly (good to have) results in what amounts to the halting problem. That said, a lot can be done. But it takes multiple passes to achieve good quality results.