What started off as an experiment to build a 6502 core simulator, mainly as a means for demonstrating a simple comuter architecture to a graduate CS class, turned into most of an Apple IIe emulator. A lot of thanks needs to go to the Apple2Infinitum Slack community for help and encouragement.
There are a lot of moving parts here and that's because this project slowly grew out of the 6502 simulator itself. Over time, and as a way to build and run unit tests, this project picked up a very basic 6502 assembler. And, well because I wanted to see the output of the assembler and to debug the code that the simulator was simulating, I added a disassembler. Along the way a basic console 6502 "computer" started to take form (see the cruft in ConsoleTools) so that I could run basic 6502 programs.
At one point I'd sort of succeeded in getting the Apple IIe ROMs to load into the simulator, and to be able to basically "boot" a hobbled Apple environment. The Emu6502 project was the start of a console-based rendering, and it was just enough to get me interested in taking the next step.
The 6502 core is in InnoWerks.Simulators.Sim6502. It has support for 6502 and 65C02 processors that pass the Harte tests as far as "documented" op codes. There are a few odd things lurking in that project like the IBus, ISoftSwitchDevice, and ISlotDevice. IBus makes sense and should have the "computer" pieces removed so that the core really knows about the CPU and a bus for accessing memory.
InnoWerks.Computers.Apple has the basic structure for an Apple IIe. It's where you'd find the soft switches themselves, all the $C0xx definitions, implementation of hardware like the Disk II, and concrete implementations of an IBus and global machine state. There are a few interesting pieces here that might benefit from some additional documentation. Namely the interaction between the three "system" devices IntC8Handler, IOU, MMU, and the underlying memory subsystem. Memory in the Apple II is really interesting, and probably should make for a guest lecture on how hardware and software come together to form a system.
In Pomme the MMU is responsible for managing the soft switch state and reconfiguring how the underlying memory is made visible to the firmware and software above it. Memory128k is an implementation of an Apple IIe with 64k on-board RAM and a 64k Language Card. And with the exception of the I/O page at $C0xx, any address can be RAM or ROM. The MMU handles the what and Memory128k handles the how. The address space is partitioned into 256 byte pages numbered from $00 to $FF giving us an address range of 64k. Reads and writes into the $C0xx I/O page cause the MMU to change how those memory pages are made visible, and access to the memory is nearly always abstracted through the bus. There are three places where the abstraction is broken -- single stepping the CPU bypasses the cycle counting infrastructure in the bus to peek at the next instruction, unit tests can read and write to any of the underlying memory structures, and the video subsystem can read directly from the "main" and / or "aux" memory banks on an as-needed basis.
For a small computer that only has 128k of RAM Memory128k has to allocate a lot more internal space to make that 128k available. Each I/O slot can have both an I/O page and an optional 2k on-board ROM. When a hardware device is registered with the bus those ROMs need to be mapped. The Apple itself has 16k of ROM "firmware" that needs to be mapped into visible address space. The MMU and Memory128k are busy.
Finally, InnoWerks.Emulators.AppleIIe is the emulator core. It's a XNA / Monogame-based application that "wires up" an Apple IIe computer based on user configuration (well, it will, for now it's really kinda land-locked) and runs a core "game loop" model. There are three components of the emulator that are implemented here and they are the trickier code -- the ability to play basic sound (no Mockingboard support, sorry); the ability to render 40/80 column text, 40LORES/80LORES graphics, HIRES graphics, and DHIRES graphics; and the user input which is, right now, limited to keyboard only.
There's a lot left to do. I have to complete the emulator configuration model and either add a U/I or somehow make it easier to configure and start. The emulator needs a lot more auxiliary hardware support or a clean model for adding those when available (some will be simulated, some will be combinations like the Disk II). And the rest of the debugger model needs to be fleshed out so there was other ways to implement breakpoints, step / trace, and view on-board memory on demand.