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.