Portable Apple II On An AVR

The Apple II was one of the first home computers. Designed by Steve “Woz” Wozniak, it used the MOS technologies 6502 processor, an 8-bit processor running at about 1 MHz. [Maxstaunch] wrote his bachelor thesis about emulating the 6502 in software on an AVR1284 and came up with a handheld prototype Apple II with screen and keyboard.

pic_15
Prototype on veroboard

Originally, [maxstrauch] wanted to build an NES, which uses the same 6502 processor, but he calculated the NES’s Picture Processing Unit would be too complicated for the AVR, so he started on emulating the Apple II instead. It’s not quite there – it can only reference 12K of memory instead of the 64K on the original, so hi-res graphic mode, and therefore, many games, won’t work, but lo-res mode works as well as BASIC (both Integer BASIC and Applesoft BASIC.)

[Maxstrauch] details the 6502 in his thesis and, in a separate document, he gives an overview of the project. A third document has the schematic he used to build his emulator. His thesis goes into great detail about the 6502 and how he maps it to the AVR microcontroller. The build itself is pretty impressive, too. Done on veroboard, the build has a display, keyboard and a small speaker as well as a micro SD card for reading and storing data. For more 6502 projects, check out the Dis-Integrated 6502 and also, this guide to building a homebrew 6502.

36 thoughts on “Portable Apple II On An AVR

    1. Expanding the current “architecture” to utilize the full 64K is not that great of a deal. But the function to “draw” the HiRes graphics on the display (if used in the presented configuration) is rather complex. From the experience(s) I gathered with this project I assume that it would be possible (e.g. if implemented in AVR ASM). But the bigger question (for me) is: why would you throw money at it? Nowadays you can get a Pi Zero and do much more … (***sad***)

      1. the main issue with the Apple II “hi res” graphics is the addressing.

        Woz is a really smart guy, but the trade offs he made with DRAM and video refresh can be somewhat “vexing”…

    1. The insanity is strong with this one … love it though and I would never have finished it but I can make PCBs so I would have done it differently anyway. I would love to make this on a PCB but it’s not open hardware.

      1. my Lingo 128 clone has, 128k.
        the main thing I use it for is a RAM disk when I’m running UCSD Pascal.

        the Lingo also has a built in 80 column card, serial, parallel and a Z80 (that I’ve never been able to get working)

        1. I had a CHE-1 clone build back then. I also had a problematic Z80 card which would not switch properly. I remember finally got it working properly by adding a 22pF cap in the CPU switching circuit on the Z80 card. I can’t remember the schematic and the exact location, but it worked.

        2. Right, I meant exact clones of the ALC. Later there was the Saturn RAM cards and their clones, the IIe, IIc, IIgs, and so on that allowed well beyond 64KB of RAM. Much of the hardware Woz had a hand in used smart tricks to avoid high BOM costs. The ALC for example stealing the DRAM refresh by having you unplug one chip from the main bank, place it in a socket on the card, and attach a cable to the original socket on the motherboard. Saved having a DRAM refresh circuit on the ALC card itself.

    1. More of interest is which 12k it is addressing in the Apple2 memory map.
      As you mention the monitor and basic didn’t take up much space, and only the first two or three pages was really required (zero page as registers and page 1 for the stack)

      Basically from the 48k to 64k mark is the most interesting 16k, as that is where the hardware IO and ROM lives.
      But that is 17k so far, which seems to not add up.

      I’m assuming that 12k is really at the low end of the map for actual RAM, and excludes the top 16k of hardware IO and ROM, since the top of the map is pretty much required for it to function.
      12k at the lower end of the map will take you up to $2FFF of RAM. The first highres page was $2000 to I think $3FFF, and being “cut in half” by the 12k limit would reach the functions and limits as stated.

      None the less this is a fascinating mix of hardware and emulation!

      1. You can get away with just the first 4KB of RAM, and just 2KB Monitor ROM if you don’t need ROM basic. In addition to ZP & Stack, you need the keyboard buffer (Page 2) and screen (Page 4) Page 3 comes in handy as most small machine language routines are prototyped there (DOS and Basic entry points too). For HiRes graphics 16 or 24 KB is a good idea but doesn’t leave much room for code.

  1. Back in the day I knew a guy who had an Apple IIe with a colour monitor and a large library of games. I wasted many hours playing the original Wolfenstein, Lode Runner and Choplifter. Good times!

    1. Davids Midnight Magic???????
      Reach for the stars?????
      Sneakers???(more fun than squashing tadpoles!)

      Choplifter is a great game, it always freaked me out when AppleII and C64 games “appeared” as full size arcade cabinets in my arcade!!

  2. The “AVR1284” is actually an Atmel ATmega1284p it’s just like the ATmega328p used in the Arduino Uno and most of the other smaller Arduino’s but has more I/O, FLASH and SRAM –

    Micro: ATmega328p , Atmega1284p
    FLASH: 32kB, 128kB
    SRAM: 2kB, 16kB

    You can easily modify the Arduino to work with this chip but you need a programmer to load the bootcode into the ATmeg1284p.

    It’s an excellent chip if you need just a bit more I/O and SRAM

  3. I tried this with a 6809. I was a little more than half way through the instruction set when I realized the available address space was sorely lacking. Even though the hardware I was emulating then appears to have portions of the RAM shadow mapped, I didn’t have enough space.

    After fussing with different ideas for about six months, I just dropped the project altogether. I did toy with a 6502 version, but by then I was already burnt out on the AVR.

    Tried a similar thing on a more capable computer but the OS kept getting in the way.

  4. I wonder what sort of minimum build would be required to construct a “real” Apple ][. Could you use a 6502, plus a modern microcontroller to emulate all the discrete logic, RAM, ROM, I/O, etc.?

    Actually, I’d really like to have an Apple IIGS (65C816 processor) clone done this way, as I’ve always regretted getting rid of mine and it’s too expensive to buy (and upgrade) a real one now.

    1. Depends on what you’re trying to minimize. If you want to minimize parts, replacing the peripherals with an FPGA is an option. If you’re trying to minimize price, I’d use a separate microcontroller for each major subsystem.

  5. Very impressive build. I’ve been finishing up a .NET emulator for my homebrew CPU design and am looking at hardware emulation options until I can afford an FPGA. I had been planning on a cheap ARM Cortex-M4F, but now I’m wondering if I could manage with just an AVR after all.

    1. CP/M is probably much easier to port over to an AVR as it’s well documented and intended to be quite portable to start with.

      So just think of a retro-computer (CPU) install the CPU emulator (plenty written for AVR for most of the old CPU’s like 6502 6802 Z80) and port away (which is mostly ^C ^V).

  6. You could do away with the CPU emulation and use a real 6502. There was a Propeller project that used the Prop for clocking, address logic and peripherals, a real 6502 or Z80 for executing code, and an SRAM chip for main memory / ROM. Saves tons of room in the AVR for video logic and peripheral logic.

  7. I certainly don’t want to belittle this project but on the other hand it’s not as uncommon as the author implies that Apple II emulators are partly written in assembly language for performance reasons. The MS-DOS emulator ‘ApplePC’ was written for ~20MHz 80386 machines and provided a _WAY_ more accurate emulation than this project. The Windows 3.x emulator ‘AppleWin’ didn’t require much faster machines. It used an assembly language 6502 emulation and bypassed the Windows GDI for video output completely but rather directly wrote to the PC video memory with a set of assembly language bitblt routines customized for the different PC video modes used back then.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.