Apple II Emulation Evaluation (2022) | Hacker News Reader

Apple II Emulation Evaluation (2022)

juiced.gs

61 pointsmmphosis15 comments

The Apple II is rather hard to emulate correctly. While most Apple II software is relatively easily supported, some corner cases are absolutely brutal to get right.

For example, you can mostly treat the video system as a dumb framebuffer. But there are cases where this fails. It is possible to detect the vertical blanking period on an Apple II. [1] This relies on capacitance on the Apple II bus and very strict timing. On a real Apple II the value read from a non-existent memory address is not always 0, sometimes it's the last value read, which is sometimes the last value read by the video system which is overlapped with the CPU. To emulate this right, you need to emulate the whole video system lock-step and cycle accurate with the CPU.

The disk system is another major pain point. All of the timing and track movement is handled in software. Arbitrary disk formats can be created in software. One single spiral track was used by some games as copy protection. To support the Disk II completely requires emulating at a much lower level than that of 256 byte sectors. Some emulators going all the way for accuracy, use a structure, that is basically a map of the flux transitions on disk.

[1] http://deater.net/weave/vmwprod/megademo/vapor_lock.html

IIRC the vertical blanking detection can fail depending on what cards you have plugged in as they may load down the bus.

I wrote my own pet Apple IIe emulator for linux fairly recently [0]. It works fairly well, even if it doesn't try to emulate an exact cycle accurate 'pixel' video modes, instead, it 'cheats' and do it line by line. I think it is a good tradeoff between quality of emulation and CPU spent doing it... Only some demos will fail to display properly (mostly the ones changing video mode during line displays!), all the games and tools and applications I tried works just fine.

I mostly did my emu due to the rather poor quality I found for linux emulators I've seen, the 'goto' one is linapple, but the codebase is rather crusty.. I wanted a cleaner base to hack on, without the baggage -- more in the style of my own AVR emulator [1].

I've got a very big patchset to push 'soon' with a new UI library (that will be a topic of its own!) and a bunch of new features and improvements...

[0]: https://github.com/buserror/mii_emu [1]: https://github.com/buserror/simavr

If you're interested in Apple II emulators, the #emulators channel on the Apple2Infinitum Slack is a great place to ask questions or chat. Invites available here: http://apple2.gs:3000/

Virtual II is overall the best Apple II emulator across all platforms, and the article doesn't even mention how stellar its debugger is.

My only gripe with it is that it's not as accurate as AppleWin, despite excelling in every other aspect. This means that writing a cycle-accurate demo won't work as smoothly with AppleWin as it would with AppleWin and AMPLE. Several cycle-counting demos fail to run on Virtual II, a shame for an otherwise perfect emulator. Hopefully the author addresses and resolves this issue in the future.

Two other issues are that it is commercial/proprietary and only available on MacOS.

Check out Mariani, a port of AppleWin (Windows) for macOS and Linux. It's open-source, cycle accurate and emulates a fairly good number of devices: https://github.com/sh95014/AppleWin

The last version finally has a debugger. It lacks the killer feature of Virtual II though: the ability to mount a folder as a ProDOS disk. This is gold for cross development.

OpenEmulator has fantastic monitor emulation if you want to get as close an experience as possible to the feel of the time.

I've ported the GPU code that OpenEmulator uses to WebGL. You can view a demo here: https://zellyn.com/apple2shader/ (source is on github).

I also ported it to Javascript, in an Observable notebook, with some attempt at explaining what was going on, here: https://observablehq.com/@zellyn/apple-ii-ntsc-emulation-ope...

This was my attempt to understand what the code was doing, but I went down the “I should learn signal processing” rabbit hole for a while and eventually got distracted.

This notebook is great, kudos for sort of "thinking out loud" as you figured it out. I'd forgotten about Observable notebooks and makes me want to try them again.

What I really like about MAME is that the code in the high-level machine drives almost looks like enough to derive hardware descriptions in an HDL (provided you have files for the lower level logic implemented down the stack).

Satisfied Virtual II customer here, it's a beautiful piece of software, and I'm happy to pay for great work like that... but I really wish it ran on Linux.

I had some issues with Virtual II and the author quickly helped.

I thought mame is the only one doing IIc emulation

What parts of the //c worth emulating aren't just the stuff like double high-res that the enhanced/Platinum //e has as well? Many (most) Apple ][ emulators handle those.

Reply on news.ycombinator.com