Physical Apple II peripheral cards accessible to an emulator!?

Jan 9, 2013 at 10:26 PM
This is my first post here, but I came across this project while searching for apple //e info to build some microcontroller projects to adapt an apple floppy drive to usb so it can be read all the way down to the flux level for each quarter track with a file format that will allow copy protection to work off image files. In the process I created a probe device I use with a microcontroller with an edge card slot for experimenting with old apple 2 cards and 8 bit PC ISA cards. Originaly I started playing with a 6507 a few weeks back and memory mapping with a microcontroller that monitors registers and zero page for interrupts and addresses outside that CPU's 8k memory limit. (the core supports 16 bit addressing but its missing the pins for the entire 64k and interrupts which I can direct write to the memory prior to releasing the memory back to the CPU). I used the 6507 initially to execute the disk controller rom entry points. When I saw the peripheral card abstraction it gave me the idea of completing the device and adding support to this app to map a real live peripheral card or anything else through my bridge device to Virtu. Would anyone be interested in that sort of bridge? As far as I can tell, as long as all of the signals can be transferred and timed properly, then the application shouldn't care as long as all of the signals and buses are in your peripheral card model. Please split this post off to a new thread if you feel it merits it. With debugger support and VintageStudio when it gets apple support, AVR Studio which is also a variant of visual studio, developing new devices is getting alot easier.
Jan 10, 2013 at 12:37 AM


I wrote the peripheral card abstraction, but it's very simple. Since Apple II I/O is memory mapped you just have to implement the memory accesses for whatever card is being emulated - or in your case, bridged. However this is done at a high level, and none of the Apple II bus signals are emulated. Timing is probably the blocking issue though as Virtu pauses occasionally to slow down perceived speed, so you wouldn't have real time control over the card. Here are the methods:

public virtual int ReadIoRegionC0C0(int address)
public virtual int ReadIoRegionC1C7(int address)
public virtual int ReadIoRegionC8CF(int address)
public virtual void WriteIoRegionC0C0(int address, int data)
public virtual void WriteIoRegionC1C7(int address, int data)
public virtual void WriteIoRegionC8CF(int address, int data)

In any case Virtu is more of a proof-of-concept and hobbyist Apple II emulator. Most people, myself included, would use AppleWin on Windows for serious Apple II emulation. But if you want to play around with your idea, Virtu's source code is much nicer and easier to work with than AppleWin. ; - ) I'm happy to answer any questions you have though.

Cheers, Nick.