STMicroelectronics have a cheap evaluation board out called the STM32F4-Discovery (http://www.st.com/internet/evalboard/product/252419.jsp), and the specs are quite decent: 168MHz ARM/Thumb2 CPU, 1 MB of Flash, 192 kB of RAM, 80 GPIO pins, with all the capabilities you would wish for: multiple UARTS, USB, DAC Audio, external address/memory bus, ....for under $20.

Of course, it's bandwagon'ing after the hobbyist boards like the Arduino, of which a lot of cpu simulation projects have already been done. However, unlike the ATMega-based projects, the Disco comes with enough on-chip static RAM to make 8-bit cpu simulations a no-brainer, with their 64kB address space catered for easy.

Anyway, I've posted my own project online, at https://github.com/cjbaird/stm6502 .. This is a NMOS 6502 simulator with only basic character I/O for the moment (although through the 115200bps serial port on the Disco). The effective emulation speed is between 5 and 21 MHz.

It can run the famous Wozniak 256 byte Apple 1 monitor, so I'm fairly confident of the simulator's correctness ...but fortunately I've made Jim Butterfield's SUPERMON the primary system monitor. Lee Davidson's EhBASIC, and FIG-FORTH are also included.

As for my motivations for this project: it's not to emulate any particular hardware, but to provide a 'generic' 6502 system for testing code on.

Well... It's time to buy the Discovery board finally

BTW - There is a new C64 CPU accelerator project with a Cortex M0 running a 6502 emulator. Now it gives you 10x speedup. But this is in assembly, not in C/C++

_________________
Practice safe HEX !

This is a very nice project! In effect, it delivers a software-defined 6502. Anyone wishing for a few extra instructions can just(*) code them up in C - no HDL required.

(Edit: As Chris' repo link no longer works, see my fork for reference.)

As Konrad points out, this platform surely has room for higher performance if that's really important - this forum topic is the one to watch for 'core6502' progress.

Also, cjb pointed out elsewhere the possibility of adding lots of RAM:

(lib65816 might be a basis for that - but just adding load and store from columns 7 and f for use in the 'emulation mode' would go a long way.)

Almost all the pins are 5V-tolerant, but only powered from a 3 supply. (That's possibly the cause of my present trouble with the serial connectivity)

If the Discovery board is altogether too pre-packaged then the chip itself is surface mount LQFP100 (0.5mm pitch) and can run from an 8MHz crystal (or an onchip 16MHz oscillator?)

The chip has a collection of interface blocks on it, so the usual collection of i/o on an external bus mightn't be needed. There's multiplexing down to the 100 pins, so not all interfaces are available in all combinations.

(*)May be considerable work, depending on the instructions, but this ARM has hardware floating point, so that's promising.

Link?

Jim,
the only available info on that Cortex project seems to be in that mostly-Polish forum topic I linked to earlier. I did ask some questions and got some answers in English: it seems that there won't be a code release. It's established that it's in machine code (Thumb code, necessarily, I think.) The project does seem to have got to a functional state, delivering 9MHz emulated on an 86MHz M0, and the intent seems to be to make a (low volume?) commercial project.

Chris,
I note that you posted a performance-improving update to your code, which is great. I still hope to dig in to the source and the object code and see if I can do anything to help, but I'm not getting to it. In the meantime, you might be interested in an article by Blargg on general tactics for efficient emulator code, which includes a table of the most-executed instructions:
http://www.slack.net/~ant/nes-emu/6502.html

Cheers
Ed

I've actually being attempting the advice in that article and a lot of other tricks-- and the experimental versions are slower!.. At one point I had a version which dereferenced the pointers almost completely ("cpu->mem[256 + cpu->regs.sp] = val;" becoming a direct store into (0x20000100+sp)), and the resulting code was bigger and slower overall-- which of course came as a bit of a shock, having looked at the assembler output of 'arm-none-eabi-gcc -S'

Lesson learned: even though ARM GCC code generator is no-where near as polished as the one for x86, it's still smarter than me...

Interesting, and a bit disappointing!

I note that Blargg has some tricks for code density - some of which involve jumps or branches. I'd be incllned not to introduce extra branches or jumps. It's possible that denser code would have some advantage because of the way the flash is accessed.

The biggest likely win might be removing special cases from the memory handling, and doing i/o through opcodes. No longer a pure emulation, of course.

I also like the idea of deferring N and Z flag calculation: just put the result in a value (hopefully a register) and then branch and status register opcodes can figure out N and Z when they need to.

Cheers
Ed

Edit: see also my inspired-by project, a6502, in this thread.