AVR-based 6502 Emulator

[8BIT]

So, a few weeks ago I was looking at my ATMega1284, which has 16k of onboard RAM, and wondered if it would be possible to emulate a 65C02 system with it. I started with the idea of using the Flash for 32k of ROM and the most of the 16k of RAM for RAM. That proved difficult to implement as RAM and Flash are accessed differently. I ended up using just the RAM, with the emulator seeing 8k of RAM ($0000-$1FFF) and 7.5k of ROM ($E200-$FFFF). I strategically placed the IO page at $E100 which makes address decoding really simple.

So far, I have a 65C02 engine functioning, minus decimal mode and the WDC SMBx, RMBx, BBRx, & BBSx codes. I also have the AVR's serial port being emulated as a simple 6551. The data register is at $E100 and the status register is at $E101, with the TDRE and RDRF flags working. The baud rate is fixed and the handshaking is ignored, writes to the command and control registers have no effect.

To test it, I took the stock SBC-2 OS, remapped the ACIA to $E100, removed the init code for the 6522's, and loaded it in the emulated ROM.

After some debugging of the emulator, the SBC-2 OS is running perfectly. I can even use the U command to do an xmodem file transfer to RAM.

I am running the AVR at 24MHz and getting about 1.4MHz speed from the 6502 engine. This is in part due to some inefficient avr register usage on my part. I plan to optimize the code with a goal of 2 MHz or more. I am currently counting 6502 cycles but am not using it to throttle the engine.

Some interesting side benefits will include being able to activate a debugging mode that will dump register states after each opcode is completed down the serial port to help track down bugs. I will also add support to download via xmodem a new ROM image for testing OS code as well as user code.

As it is, it's a single chip (plus oscillator and RS-232 driver) 6502 system. For about $20, you could buy the parts and breadboard it up and be running in about 30 minutes! If you have a 5v TTL-RS-232 to USB adapter, then you could have it in about 10 minutes.

I am considering opening up $E000-$E0FF to to the AVR port pins, providing an 8 bit data bus, 8 bit address bus, and emulated PHI2 & R/W so external IO devices can be added easily. That is just in the maybe stage.

While working on my engine, I was searching the web and came across this site:
https://sites.google.com/site/retroelec/home

It uses an ATMega162, external RAM, and a few descrete logic chips to provide video, keyboard, sound, SD storage, and a 6502 emulator. I found it very well designed and implemented.

That's enough rambling for now...

Daryl

[BigEd]

That's great! Did you run Klaus' test suite (now linked at http://6502.org/tools/emu/)? It's relatively easy to remove decimal mode tests.

The debugging mode idea could be handy for my a6502 emulator, and maybe for Chris's stm6502 - hoping you'll release your sources!

Cheers
Ed

[8BIT]

I will run the test suite eventually, after optimizing some more. Yes, sources will be available once its done.

thanks!

[BigEd]

Excellent, thanks

[Klaus2m5]

Interesting Project!

You may have to rearrange and split the code as it requires 12k consecutive RAM.

It was actually written for a similar project.

An ATMega16 emulates a 6502 with NMOS version opcodes. It uses external 32k RAM, up to 64k addressable. So far it successfully ran my test, EHBasic and microchess. I am now working to add IO modules to the project.

I hope to add a webpage with all relevant information on my website soon.

edit: took out the picture - too big and obsolete, ETA of webpage is now January 2013

[8BIT]

Seems I am not the only one with this idea - nice project! I will look forward to seeing your site.

Daryl

[8BIT]

I have worked out the memory decoding better now and have put the ROM back in flash, so there's 32k available from $8000-$FFFF. That makes more RAM available too, 15+k from $0000-$3EFF. Reads from $3F00-$7EFF return $FF and the IO is located at $7Fxx. More optimization has brought the clock speed up over 1.5MHz. That is with replacing some subroutine calls with macros, which costs a little more in Flash usage, but I am at less than 25% capacity so not too worried about it. My next step is to re-organize the register usage to streamline the data manipulation.

If anything else, its been a fun distraction for the past few weeks.

Daryl

[8BIT]

Here's an update:

Emulator is done. In addition to the emulated 6551 (data and status register only), I have mapped almost all of the ATMega1284P's IO resources to emulated IO space. This includes the 4 8-bit ports. Many of the port pins have second functions, so these are included too: a second USART, SPI interface, Two-Wire (I2C) interface, 8 10-bit A/D channels, and even access to the Main USART. The user can easily connect any IO device to this platform.

In adding support for all this IO, and the debugging mode, the overall clock speed has dropped back down to around 1.3Mhz. Code running primarly in RAM runs faster, and a tight loop testing IO ports runs the slowest, at about 1.1 Mhz.

While not fast, it will keep up the early 1Mhz machines. The debugging mode is crude, but had helped me track down a couple of 6502 engine bugs. This is an example of the debugger output:

Code: Select all

:E518-AD t7F01 a18 xFF y01 sFA f31
:E51B-29 tE51C a10 xFF y01 sFA f31
:E51D-F0 tE51D a10 xFF y01 sFA f31
:E51F-68 tE51F a3E xFF y01 sFB f31
>:E520-8D tE521 a3E xFF y01 sFB f31
:E523-60 tE523 a3E xFF y01 sFD f31

You see the address, opcode, target address, a,x,y registers, stack pointer, and flag (status) register.
The code here reads the 6551 status register and waits for the TX buffer to be empty to send the ">" prompt.
Since the debugger shares the serial port with the emulator, the > actually gets printed as well. That in itself took a little special handling to accomodate.

This "project" was started less than three weeks ago and is nearly done. I am working on the final feature; a boot loader that will allow users to download (via xmodem) their own 32k ROM images to the Flash memory. The boot loader will ensure that even if a buggy image gets loaded, the end user can still recover and put a good image back in without needing any special programming tools.

Once the boot loader is done, I will generate up a few how-to's and example ROM images (an SBC-2 clone with EhBASIC and also a FigFORTH version) along with the full source code.

More when its done!

Daryl

[BigEd]

Nice - I like the idea of showing the target address.

[8BIT]

Version 1.0 is complete. The project information and full sources are on my website:
http://sbc.rictor.org/avr65c02.html

I ended up adding a single-step function to the dubugging mode. I also decided to add a way to trigger an IRQ and NMI from software, so interrupt handling could be experimeted with. A later version might include either external interrupt inputs and/or AVR resources being able to interrupt the emulator. Either function will add a little more delay to emulation speed so that will have to be carefully considered.

The two design goals that I had were to keep it all in the ATMega1284P, and to complete the entire project in 30 days or less.

As of today, it has been 29 days and this version does not require any external hardware, other than a 24MHZ oscillator, RS-232 level conversion (or in my case - a USB to RS-232 converter), and 5v power. I am getting my power from the USB adapter. If you look at the photo on my site, you see it is mounted on a PCB board. This is PCB I designed my Graphical Composite/LCD display on. It required no changes to host this project on and helped me stay within my time limit.

Both the 32k ROM image and the Emulator Engine can be updated by the user without the need for an AVR programmer. The updates are simply transferred over the RS-232 link via XMODEM and written to the Flash memory. The only AVR programmer requirement is to load the initial bootloader code into the ATMega1284P, which I will do free of charge for anyone interested. I can also provide a pre-programmed ATMega1284P for a minimal fee.

I hope some of you will find this project useful.

Daryl

[8BIT]

I fixed a couple of bugs in the emulator engine and have added a FigForth download file to the source. Since FigForth runs in RAM, it is just downloaded using the SBC-2 monitor Rom image. I do have a version that is stored in ROM and gets copied to RAM after a reset if anyone is interested. I don't plan to do much more work on this project, as it was just something I did to see if it was possible.

Cheers!

Daryl

[8BIT]

One more bug fix - the CLV opcode was not working right. I know, of all the opcodes, this one should be pretty simple to code . It's fixed now, thanks to Andrew Dunn for pointing it out. The sources have been updated and can be found here:

http://sbc.rictor.org/avr65c02.html

Daryl

[8BIT]

My AVR Emulator, connected to an ENC28J60 ethernet module, served up its first web page last night . After a little more testing, I will add the code to read the ADC port and read/write some digital IO through a web page, providing a simple remote monitoring and control system. I expanded the emulated ROM to 48k and have the CC65 compiler working successfully to make the ROM images. Sources will be released when they are done.

Daryl

[8BIT]

I have finished the code to serve a webpage that reads the AVR's 8 ADC ports and 8 digital IO ports.

The user can also set custom labels for all 16 ports. They can also set each digital IO as an input or output and set its state.

Since this is running the emlated code at about 1.2MHZ, it is a little slow, but still quite useful.

If you want to have a look, it is online (Dec 9-Dec 11, 2012 only). (Link removed)
The actual adc and digital ports are not connected to anything real so the ADC reads 255 and the IO will float if the set to input with the pull-up disabled.

Comments welcome!

Daryl

Edited 12-11-12 - removed temporary link

[GARTHWILSON]

Even if slow, this should fill a long-time need for a 6502-based microcontroller where the user's code is onboard. (WDC's 65134 and 65265 microcontrollers are really neat, but onboard ROM is mask-programmed, making them unsuitable for hobbyists. You can have external memory on them only by forfeiting a lot of the I/O pins.) Your onboard A/D converters are definitely a plus! A few questions I was not able to answer from what is written so far are:

1. Are all the AVR's I/O features available to the emulated 6502?
2. Are interrupts supported by the emulated 6502, including for the 4 timer/counters?
3. Does the user's 6502 code get stored in non-volatile memory so it doesn't have to be loaded at every power-up?
4. Is RS-232 the only thing so far that requires the oscillator to be crystal-accurate? I'm wondering if some non-speed-critical applications can get by on an RC oscillator.
5. What price do you think you'll be putting on it?

Thanks. I expect there will be more interest when it appears finished and it's in the webshop and it's clear that development of user applications is easy. I know one thing I myself should eventually look into is videos, since it's too easy for a great thing to go nowhere while those who might have been interested unintentionally shun it because it appears too mysterious.