Emulator Debugging: Area 5150's Lake Effect(martypc.blogspot.com)
martypc.blogspot.com
Emulator Debugging: Area 5150's Lake Effect
https://martypc.blogspot.com/2025/05/emulator-debugging-area-5150s-lake.html
9 comments
Love this write up (and one's like it - there's so much good stuff in their archives). The stuff GloriousCow is doing with MartyPC is just so impressive.
What impresses me most is that, back then, we thought the PC to be an extremely boring machine with absolutely crappy graphics.
We didn't have hackers like these, it'd seem. Or they were (understandably) distracted by Amigas and Ataris.
We didn't have hackers like these, it'd seem. Or they were (understandably) distracted by Amigas and Ataris.
I might be wrong but doesn’t he mention at the start that the effect isn’t possible on real hardware? Like there’s an emulator trick happening?
I’m not diminishing the skill involved in this but if it requires a trick in the emulator it can’t be said that a person could have accomplished this on the hardware at the time
Video footage of it running on real hardware: https://www.youtube.com/watch?v=BdM5j96tEpE
Back when the demo was released, there were no emulators capable of running it all the way through. People are free to believe what they want, but as we presented it at a demoparty (Evoke 2022), I can tell you that the organizers wouldn't have allowed it in the compo lineup if they didn't see it running on the hardware in person. :)
I am in awe of GloriousCow's crazy achievement in debugging it on MartyPC and making it work to perfect accuracy... that's true next-level skill, and the rest of the group would undoubtedly echo my sentiment!
Back when the demo was released, there were no emulators capable of running it all the way through. People are free to believe what they want, but as we presented it at a demoparty (Evoke 2022), I can tell you that the organizers wouldn't have allowed it in the compo lineup if they didn't see it running on the hardware in person. :)
I am in awe of GloriousCow's crazy achievement in debugging it on MartyPC and making it work to perfect accuracy... that's true next-level skill, and the rest of the group would undoubtedly echo my sentiment!
No. The author is saying that, in order to run the demo on MartyPC, the emulator previously required a small "hack" (in this context, that means a slight inaccuracy in emulation) to get the effect started. The post then covers the process of fixing multiple bugs such that the "hack" is no longer needed to match behavior on hardware, and thus MartyPC's behavior now more accurately models hardware.
Offtopic: in recent years, I've stopped saying "real hardware" unless also using the term "emulated hardware". To me, it's either "hardware" vs "emulator", or "real hardware" vs "emulated hardware".
Offtopic: in recent years, I've stopped saying "real hardware" unless also using the term "emulated hardware". To me, it's either "hardware" vs "emulator", or "real hardware" vs "emulated hardware".
Not really sure I see the benefit to the linguistic choices there. It makes sense, but I just don't see the point. Doesn't help that you can implement emulators in hardware (e.g. FPGA-based emulation), and that the "emulated hardware" phrase can be misinterpreted as a reference to the real device in question.
I can see the point of trying to make a distinction, but it is muddy.
An emulator can operate on many different levels of trying to match the behavior of the underlying hardware. CPU emulators can emulate at the opcode level (easier) or try to increase accuracy by emulating the CPU pipeline cycle by cycle (harder).
In this particular case, the distinction between an "emulator" and a "hardware emulator" seem apt because the article discusses that the required fixes needed to start tracking the state of individual pins of the hardware chips. This, to me, represents that the emulation needed to "go down another level" and model the physical hardware to a certain degree to gain the needed accuracy.
Having a way to mark that difference is useful.
An emulator can operate on many different levels of trying to match the behavior of the underlying hardware. CPU emulators can emulate at the opcode level (easier) or try to increase accuracy by emulating the CPU pipeline cycle by cycle (harder).
In this particular case, the distinction between an "emulator" and a "hardware emulator" seem apt because the article discusses that the required fixes needed to start tracking the state of individual pins of the hardware chips. This, to me, represents that the emulation needed to "go down another level" and model the physical hardware to a certain degree to gain the needed accuracy.
Having a way to mark that difference is useful.
No, the main thing to take away is that MartyPC is the only emulator that can accurately run this demo. Before that, the demo would only run on real hardware.
The "hack" needed to be there for the emulator to reproduce the effect as it happens on real hardware, before the author managed to fix those last few bugs.
>Historically, many famous emulators have relied on title patches to work around bugs or inaccuracies to get games to play. As emulators have improved in accuracy and research has uncovered more details about how systems work, gradually these title hacks became less necessary.
>Historically, many famous emulators have relied on title patches to work around bugs or inaccuracies to get games to play. As emulators have improved in accuracy and research has uncovered more details about how systems work, gradually these title hacks became less necessary.