An AI-Generated Interactive 68K Disassembler

[AlexTheCat123]

Last night, I was messing around with overclocking the LisaFPGA board to a 60MHz DOTCK and got tired of disassembling instructions by hand during the troubleshooting process, so I needed to turn to a 68K disassembler. But as I've learned many times in the past (including earlier in this project), there just aren't any good options out there, especially interactive ones where you can type hex digits in at a prompt, hit return, and get your result out in real time. So I asked Claude to write me one, and boy did it deliver!

It came up with a full-featured interactive disassembler, complete with a test suite that it used to confirm that everything was fully-working, and it's helped me figure out why the Lisa is a bit flaky at 60MHz (a COP-related issue). I'm honestly really impressed with what it produced!

Is this something that anybody else would be interested in having? If so, I'll stick it up on my GitHub (with the disclaimer that the code was AI-generated of course) and other people can try it out!

[sigma7]

Is this something that anybody else would be interested in having?

Yes, that's a great idea; I think that would be useful.

I can imagine circumstances (thinking of you, Stepleton) where it would be useful to know how many CPU and bus cycles would be used.

[AlexTheCat123]

Perfect, I just published the repo:

https://github.com/alexthecat123/Interactive-68K-Disassembler

Good idea about the cycle counting; I asked it to add that functionality and it seems to work just fine. I didn't check the correctness of its cycle-counting for every instruction, but I spot-checked a bunch of them and they were all correct.

Any instructions that require memory accesses are going to take a varying number of cycles depending on how fast DTACK is asserted, so I asked the program to print the base cycle time assuming that DTACK is asserted immediately. For non-memory instructions, it just prints the cycle time on its own, but for memory instructions, it prints the cycle time with a "+" after it to indicate that the instruction can take longer depending on how long it takes for DTACK to be asserted.

[stepleton]

Ha, neat! AI can certainly automate a lot of tasks... As I was writing Lisavox, I felt that the choice to hand-code everything was basically an indulgence on my part; I could have asked an AI to take care of most of the Python in particular and it would surely have done fine.

Anyhow, there are some truly heroic if-else ladders in that code; if I were asked to review it in my day job I would recommend use of Python's more recent match/case construct. You could surely ask Claude to rewrite it so that it did, but if the code works there is not much reason to tamper with it. I'd also ask for type annotations because I am a stickler for that; there too I'd expect Claude to be flawless, basically.

I'd ask Claude to use the unittest module for the tests (another thing it could fix for sure).

But probably more useful than any of this would be to do some really intensive testing sometime. Take some reasonably large 68000 binary and have it disassemble it, then feed that back into an assembler. If you get the same binary back that you started with, then that's a pretty good demonstration of effectiveness!

I wonder what the COP issue was. Do you think you'll be able to break the 60 MHz barrier?

[AlexTheCat123]

Ha, neat! AI can certainly automate a lot of tasks... As I was writing Lisavox, I felt that the choice to hand-code everything was basically an indulgence on my part; I could have asked an AI to take care of most of the Python in particular and it would surely have done fine.

Yep, I have a personal rule for the LisaFPGA project that I don't use any AI-generated code anywhere in it, although I absolutely do use AI for help when I get stuck debugging. It makes it a whole lot easier to understand weird little quirks of FPGA design that you wouldn't otherwise know unless you read thousands of pages of Xilinx documentation!

Given that it seems to be working pretty well right now, I'll probably just leave the code alone for the sake of not wanting to break it, but that's a really good idea about feeding a big program through to confirm that it's fully-functional. I'll give that a try if/when I get the chance!

I wonder what the COP issue was. Do you think you'll be able to break the 60 MHz barrier?

Give me a second and I'll explain that back over in the LisaFPGA thread!