Comment by bananaboy
7 hours ago
> What's the advantage of this approach vs cycle-accurate emulation? (I'd guess it can go faster, due to compiler optimization?)
I don't think anyone is doing it this way because they chose to do it this way. All the AI decomp/recomp projects I've seen recently have done it this way. It just seems an easy way to have an AI brute force "port" something.
This only works for something noninteractive that always executes the same code (unless I'm misunderstanding the LLM's description of what it did)
Ah yeah true, no I don't think you're misunderstanding. Actually sorry I misspoke - what I've seen in the game re/decomp projects is that the binary gets turned into a direct C implementation of the instruction stream, and it's basically a sort of emulation with CPU/memory state and emulation of whatever hardware it might need to talk to.
I agree on this description. It looks like a wrapper for an app alias demo, not a generalization for all app following the hardware possibilities at the time.
On the other hand, at least these folks build and create and I prefer wrapper demos instead of a perfect emulator that will never finish.
Nevertheless, on the feature side of these wrappers I really miss a fast-forward option. If you go pseudo-emulation, then at least come up with some convenience features.
Maybe this is the irony: the ff button is perfectly legit, I used mine many times with the 486DX3-100 and Pentium 133. Back then it was called turbo button.