ApplyPy

Back when I was at school, just when the BBC Micro was busy making a big splash as the hottest new computer to penetrate the school system, Staffordshire Education Authority were busy purchasing computers from a company called Research Machines. These guys had a competing 8bit micro on the market in the early 80's called the 480z.

This wasn't just a standalone computer however (although it could boot off 5 1/4" floppy disks), our schools installation booted off the network and could share files / programs with other users.

During the fabulous early IT education in the UK that was concerned with mice and thermal printers, a wondering mind would sit in the computer lab, experimenting with the network and its various secrets. After writing a chat program in pascal to allowed the class to communicate with each other (some mischief did surprisingly occur), I fell over the game of games, RobotWar.

This game quickly turned into the ultimate programming competition amongst a few friends. Many lunchtimes were spent hiding in the lab, coding up robots (it used a BASIC like language) and fighting battles against each other. Fond memories, which on recent recollection gave me a hankering to dig this game up.

As 480z machines were never popular enough outside the education market to be emulated in these modern times, the only version I could find was for the Apple ][ , stored as a WAV recording of the original cassette tape. I found what looked like an interesting emulator for the Apple ][ and downloaded it, ready to run through a few rounds of the game and then retire to bed. But the emulator didn't support the cassette HW (or disk).


APPLEPY

Instead of grabbing another emulator, I took a quick look at the the src to ApplePy, written in (sic) python. The basics of the emulator are pretty neatly put together.

• cpu6502.py - a model of the 6502  processor including the instruction set and the bus (basic ROM and RAM models included)
• applepy_curses.py (or simply applypy.py) - the front end to the emulator that uses the curses API or pygame module to visualize the display

The cpu6502 module runs as a separate process in the ApplePy emulator. Note that this module is not a direct proxy for an Apple computer as a whole, but more an abstract just representing the CPU complex and bus of a MOS Technology 6502. It does however hardcode the location of the RAM (0x0000 - 0x2000) + ROM (0xD000 - 0xFFFF) available in the design to the locations used by the Apple ][ , where in reality the processor is agnostic of the allocation of the address ranges.

The display, keyboard and other peripherals that make up the Apple ][ hardware live in the applypy_curses.py OR applepy.py files (depending if you want a ncurses based display or something that uses pygame). These peripherals simply accept in read or write bus requests for data and either output to the display or read from a keyboard peripheral. However, as these are in a different process, the 2 python modules need communicate via a socket that is established when the cpu6502.py is spawned. This protocol uses a simple character based message passing protocol for the CPU to request bus read / writes from the remote process.

TAPE INTERFACE

The Apple II tape interface was pretty much an in sourcing of the Apple I external cassette adapter or ACI. The original Apple 1 cassette interface was mapped directly onto the 16k internal bus from the 6502 processor (same method as the display / keyboard peripherals) and consisted of 2 main parts:

• 256bytes of ROM (routines to read / write to the tape)
• Analog to digital HW to sample in the cassette signals

You would install the Apple 1 ACI interface to your nice and new Apple computer, boot the system and then jump to 0xC100 (where the ROM for the cassette interface was mapped) and it would take over reading in the tape contents to another location in memory. The ROM actually implemented a very basic cmd line to specify where to load the contents of the tape to (tapes usually shipped with instructions about how much memory was needed and the loading instructions).

In the Apple ][ however, the tape ROM was mopped up into the main monitor ROM and so you could simply read or write from the main monitor shell.

There is a great walk through of the physical tape interface and the Apple 1 ROM internals here - fitting in the code for the tape interface into 256 bytes of ROM was an amazing bit of coding and working through it, I came out with a lot of admiration for +Steve Wozniak.

Apple II, Panasonic RQ-2102 cassette, and TV - Photo credit: Carl Knoblock, Phil Pfeiffer

WHERE IS THIS GOING!

So, I modified the ApplyPy to support the cassette interface and in the process, had to write a great little hack to 'clean up' recordings of Apple cassette tapes. But its late, so I'll save writing this up for tomorrow.