s-macke

About halfway through my reverse-engineering process, I came across those documents and realized that roughly 50% were missing. I searched pretty much the entire web to see if anyone had stored these files elsewhere, but so far I haven’t had any luck.

Some early source code snippets of the game have even survived and can still be found on archive.org [0]. By today’s standards, they’re almost unreadable.

[0] https://web.archive.org/web/20030906124225/http://www.sonic....

Author here. I’m happy to see one of my projects on Hacker News. This has been a fun one. One evening you just try to disassemble it and wonder where the code is. The following months were a truly satisfying experience, reverse-engineering this diamond.

There is still a functioning Forth interpreter implemented in the game. If they hadn’t removed all the word names, it would have been possible to debug at any time and analyze the program state and call functions live with real Forth code. Some crazy feature at that time.

I am working on an AI multi-agent system to reverse engineer old C64 games and DOS games automatically.

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

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.

I’ve also been playing around with reverse engineering, and I’m very impressed. It turns out that Codex with GPT-5.2 is better at reverse engineering than Claude.

For example, Codex can completely reverse-engineer this 1,300-line example [0] of a so-called C64-SID file within 30 minutes, without any human interaction.

I am working on a multi-agent system that can completely reverse-engineer C64 games. Old MS-DOS games are still too massive to analyze for my budget limit.

[0] https://gist.github.com/s-macke/595982d46d6699b69e1f0e051e7b...

Blast from the past. In my mind, the Adventure Game Studio is forever tied to the ancient (German) Maniac Mansion Mania website [0]. Yes, that Maniac Mansion from Lucasfilm Games.

To this day, they’re are releasing fun new adventure episodes in the Maniac Mansion universe.

[0] https://www.maniac-mansion-mania.com/index.php/en/

> ... emitting a NYC worth of CO2 in a year is dizzying

Simplified comparisons like these rarely show the full picture [0]. They focus on electricity use only, not on heating, transport, or meat production, and certainly not on the CO2 emissions associated with New York’s airports. As a rough, back-of-the-envelope estimate, a flight from Los Angeles to New York with one seat is on the order of 1,000,000 small chat queries CO2e.

Of course we should care about AI’s electricity consumption, especially when we run 100 agents in parallel simply because we can. But it’s important to keep it in perspective.

[0] https://andymasley.substack.com/p/a-cheat-sheet-for-conversa...

Thanks. I have submitted my platformer "Interplanetary Postal Service" [0]. This is a lunar lander type game with real computational fluid dynamics.

[0] https://github.com/s-macke/Interplanetary-Postal-Service

Works again for me

Yes, it is down for me too. Germany.

> API Error: 500 {"type":"error","error":{"type":"api_error","message":"Internal server error"},"request_id":"req_xxxxxx"}

To compensate for this I have put 100 or more terrible text adventure game runs from AI online [0]. And with this post I even link to them directly for the next web crawler.

[0] https://github.com/s-macke/AdventureAI/tree/master/storydump

I try myself on multiple reverse engineering projects of old games such as [0]. The goal is to find a pattern in which an AI can reverse engineer at least 99% of the disassembly.

[0] https://github.com/s-macke/weltendaemmerung

WebAssembly itself is not that inefficient in storage. It is mostly the usual bloat that comes with binaries. For example, Go binaries have to provide a full runtime, including garbage collection.

If size is your top priority, you can produce very small binaries, for example with C. Project [0] emulates an x86 architecture, including hardware, BIOS, and DOS compatibility, and ends up with a WebAssembly size of 78 kB uncompressed and a 24 kB transfer size.

[0] https://github.com/s-macke/FSHistory

Difficult and it really depends on the complexity. I definitely work in a spec-driven way, with a step-by-step implementation phase. If it goes the wrong way I prefer to rewrite the spec and throw away the code.

Just some examples I’ve already made public. More complex ones are in the pipeline. With [0], I’m trying to benchmark different coding-agents. With [1], I successfully reverse-engineered an old C64 game using Opus 4.5 only.

Yes, feel free to blame me for the fact that these aren’t very business-realistic.

[0] https://github.com/s-macke/coding-agent-benchmark

[1] https://github.com/s-macke/weltendaemmerung

Opus 4.5 has become really capable.

Not in terms of knowledge. That was already phenomenal. But in its ability to act independently: to make decisions, collaborate with me to solve problems, ask follow-up questions, write plans and actually execute them.

You have to experience it yourself on your own real problems and over the course of days or weeks.

Every coding problem I was able to define clearly enough within the limits of the context window, the chatbot could solve and these weren’t easy. It wasn’t just about writing and testing code. It also involved reverse engineering and cracking encoding-related problems. The most impressive part was how actively it worked on problems in a tight feedback loop.

In the traditional sense, I haven’t really coded privately at all in recent weeks. Instead, I’ve been guiding and directing, having it write specifications, and then refining and improving them.

Curious how this will perform in complex, large production environments.

The link didn’t get enough votes a few days ago.

While the methods are similar in that they both ray-march through the scene to compute per-pixel fluence, the algorithm presented in the blog post scales linearly with the number of light sources, whereas Radiance Cascades can handle an arbitrary distribution of light sources with constant time by benefiting from geometric properties of lighting. Radiance Cascades are also not limited to SDFs for smooth shadows.

I stopped reading the article after this sentence. Now I am scanning the comments.

copy.sh has the advantage of being x86-compatible and can run many different Linux distributions. However, this CPU choice also makes it quite complex and relatively slow (not sure, if this is still correct).

My own OpenRISC CPU emulation fits into just 1,500 lines of code, and I optimized every single line. To make it work, I had to compile my own Linux distribution completely from scratch. I stopped working on it about eight years ago, but I’ve completed a dozen other successful projects since then.

I’m still very proud that nearly every browser-based Linux emulator, including JSLinux and copy.sh, uses my 9p-virtio- filesystem approach. It makes running complex Linux distributions in the browser much simpler.

Overall, my thoughts about copy.sh’s work are entirely positive.

By a factor of about 170. But this is more of a micro benchmark that gives you a rough idea. It's not a definitive figure.

This is exactly what [0] does. Try it out. If you know the IP you can even log in to another open browser window via telnet.

[0] https://github.com/s-macke/jor1k

You can write a network device driver, which exports the network packages into JavaScript. The author already wrote a console device. So, not much of a deal.

https://github.com/joelseverin/linux-wasm/blob/master/patche...

Not quite right. Try the following.

  echo *
  cd /proc
  echo *
  while read line; do echo $line; done < /proc/cpuinfo

The last line should work and print the entire file, but it seems there's a bug.

That’s fast. Buggy, but fast. I’m totally impressed! Especially because I researched the necessary steps to do the same thing 10 years ago based on [0]. The patches required for this hack touch LLVM, libc, Linux kernel, BusyBox, ... and total approximately 15,000 lines of code.

I ran a small performance test with 'bc -lq' and compared with [0]:

  scale=1000
  4*a(1)

This WASM architecture compilation completely blows away my old emulation setup, which only managed around 200 MIPS. Maybe this approach can be generalized. Running a full Linux distribution at near-native speed right in the browser would be awesome.

[0] https://github.com/s-macke/jor1k

I will give a lecture about Haskell next week and might use this website for demonstration.

Take oscar64 [0]. So far the best C compiler for the C64 with a lot of extra options, good library and a good documentation.

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

Like this one?

https://www.shadertoy.com/view/ltffzl