
GENERIC 6502 EMULATOR CODE
On the 6502, placing frequently-accessed variables in zero page makes the code smaller and faster. This simplifies the design no end, as well as playing to the processors' strengths in being basically memory-memory architectures.ĭeciding what variables to put where becomes an easy and effective exercise in optimisation. Now there are no stack frames! So each variable is effectively static. (The Z80 failed at this, too.) The solution here is easy: forbid recursion. One other interesting feature is that a lot of these early processors don't really do stack-relative addressing, so stack-frame-based languages like C and Pascal generally work really badly. Making it self-hosting means lots of interesting design choices: I was planning that it'd be a multipass streaming design, where each stage would consume tokens from the previous stage and write out tokens for the next stage, keeping in-memory as little state as possible depending how much RAM you had you could pipeline stages together for faster compilation, provided you were willing to have less memory available for symbol information.

I was planning to target the BBC Micro, as it's the only 6502 8-bit I've found with a real operating system, but it ought to be easy to port. The tape dump of the resulting product “Apple-80” can be found at .one of the items on my Very Long List Of Potential Projects is a self-hosted compiler for a proper modern type-safe C-like language for the 6502.

GENERIC 6502 EMULATOR SIMULATOR
“borrowed” from some company where I was working at the time? Apple-80ĭann later ported the simulator to the Apple-][. The text editor may likely have been running on my Apple ][…. The all-upper-case makes me think I printed this stuff out on an oldĭrum printer that I resurrected from the American Surplus ComputerĬompany in Boston back in the ’70s… And there’s yet another story! :) Listing” format for the purpose of publishing the code and “lookingĬONSEQUENTLY, be on the lookout for typographical (and thus operational) Honestly, I don’t remember for certain… BUT… MORE THAN LIKELY, it isĪ FAKE – i.e., I probably just text-edited a listing in “assembler I wrote this by hand, pencil and paper assembly (BTW, did you ever read Carl Helmer’s article about pencil and paper in one of the very early issues of BYTE magazine? ) and much of the simulator was written as I rode the bus to and from work… )Ībout the tools used to create this program: Thanks a lot to Dann McCreary, who provided scans of his original work, as well as additional insights:
GENERIC 6502 EMULATOR SOFTWARE
The four-page article “8080 Simulation with a 6502” (MICRO – The 6502 Journal, issue 16, September 1979) explains the motivation and design of the software in detail:ĭann McCreary: 8080 Simulation with a 6502 Īnd here is the original commented source code with usage instructions:ĭann McCreary: An 8080 Simulator for the 6502, KIM-1 Version This was done by compressing the 256-entry opcode space into 25 sections of similar instructions that could be handled by one generic function. The emulator is extremely size-optimized and fits in less than 1 KB of RAM.
