[s-macke]

I’ve performed many experiments using AI to reverse-engineer old games like this one, and it looks like the newest generation of models has no trouble with it. They’re actually awesome.

Even with the current models, we might be able to automatically reverse-engineer all those old games, decode all assets, and even rewrite them in a more sensible language than assembler.

[glimshe]

For the Atari 2600, Assembly is almost a necessity because of the very tight "racing the beam" timing required to draw things correctly on the screen. Your argument applies to some other platforms and games, though (not that many among the oldest ones, to be honest).

[direwolf20]

For the uninitiated: 78 clock cycles per horizontal line (Y coordinate), minimum 2 clock cycles per CPU instruction, 3 if it accesses memory.

[drzaiusx11]

"Racing the Beam" is a great book by MIT press that covers the specifics of the Atari 2600 platform. The 2600 sparked a number of innovations _largely because of_ the limitations of the platform forces you to think outside the box.

[s-macke]

There’s a small misunderstanding here. Reverse engineering by annotating a disassembly file is fine. However, the next obvious steps would be to write a sensible, high-level documentation of the internals of the game and then port it to a high-level language. Indeed, whether this would run on the original hardware might be questionable for such an Atari Game. But have you seen modern C compilers like Oscar64 [0] for such old hardware? Never say never …

[0] https://github.com/drmortalwombat/oscar64

[ASalazarMX]

> I’ve performed many experiments using AI to reverse-engineer old games like this one

Do they generate camel case by default? While the long, friendly names are nice, I looks weird because source code back then was all uppercase.