Tiny Emus: 8-Bit emulators
floooh.github.io
floooh.github.io
The UI is in a separate version of the emulator, launched with the little "UI" button in the top right corner of the image panels (e.g. https://floooh.github.io/tiny8bit/kc85-ui.html?type=kc85_4).
The UI is updated once per 60Hz frame, so you only see a per-frame snapshot of the microchip pins which on its own isn't that useful yet except for a nice blinkenlight effect, but it will make a lot more sense once a step-debugging window is added. This will let you inspect the pins after each CPU instruction (still not as accurate as the emulation, which is running with machine-cycle granularity on Z80, and clock-cycle granularity on 6502 machines.
The emulators are written in C(99), with some platform-specific bits written in Objective-C and Javascript, and in C++ for the UI parts (since Dear ImGui is implemented in C++). Apart from the WebAssembly version, Win32, Linux, OSX and iOS is also supported, but you need to compile those yourself :)
A little off-topic: I end up doing a sub par job at writing some classic 8-bit emulators myself. At first it looks pretty straightforward, but becomes daunting as I progress, end up losing motivation for a couple of days before starting yet another project. How do you correctly learn this magic?
Once I had the first machine working (which required Z80 CPU, CTC and PIO emulations), it was fairly easy to build emulators for the other East German 8-bitters, and after that for the ZX Spectrum, and with each new machine it becomes easier and the chip emulations become better...
Another factor is that the emulators are only like a fallback project which I return to when I don't feel like doing something else (usually I reserve my Christmas vacation for this), and the emulators are also a nice testbed for my other projects (the sokol cross-platform headers, and generally doing WebAssembly stuff). These are small complete applications, yet built from very little code, so they're quite easy to maintain and experiment with.
It's definitely useful when you write emulators.. particularly if you're writing the only one in existence (and that's not so unusual, if you're targeting a relatively obscure mini, for example). I've written two emulators/simulators, I have hardware for one of them and that'll let me figure out the missing corner cases (not documented, or poorly documented), but I don't have hardware for the other one - and there are three or four undocumented areas. I wish I had the hardware.
This is hardware I used to work on in the eighties and early nineties. One day you kind of wake up to the fact that it's all gone, from everywhere.
It's another story if you just using (already existing) emulators. But for many people it's not really the same thing. It could be the speed, the mechanics, the hands-on.. heck, I lost the interest in pinball arcade machines when they replaced the mechanical score counter with LED counters. Can't really explain it, but the magic somehow evaporated.
Yeah, me, too.
Unlike the iOS emulator in xCode, it looks like you can actually load third party apps into this. Can't help with dead activation servers though.
It was released the same year the App Store launched. My wife was addicted to that game. The game and the author later disappeared. When my wife's phone was stolen in Rome, she couldn't re-download the game because it wasn't available on the App Store anymore.
Shame, too, because it was a really good game. I think it was the first app we ever paid for.
Actually, there's a decent chance it won't even work in iOS 10 or would have major glitches, because legacy compatibility in iOS just isn't great in general.
And it's literally impossible to downgrade to an older OS version after Apple has closed the signing window.