I have just finished the initial release of my 6502 emulation project.



An ATMega running at 16 MHz emulates a 6502 at ~2MHz as the CPU in an SBC environment. The basic setup requires only one SRAM IC and some components to provide clock and an RS232 connection to a terminal. A variety of parallel IO can be added including 65xx IO ICs. I2C can be added with the option to have non volatile program storage on an I2C EEPROM.

http://2m5.de/6502_Emu/index.htm

The work is far from over. However, I hope that it will already be usefull in its current state. I am commited to improve the project. Feel free to contact me with any comments, on this forum or through the links provided in the source code.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

Excellent! (And with a GPL open-source license too!)
Thanks
Ed

Hi Klaus,

Several of links on your web page aren't working. Can you post the schematic, please?

Thank you.

Cheerful regards, Mike

Hi Mike,

The schematics are in this document: http://2m5.de/6502_Emu/Modular_6502_SBC ... ed_CPU.pdf

If you say some of the links are not working, is this one of them? Do you have a program installed to open pdf files?

cheers, Klaus

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

Hi Klaus,

I can open up all other PDF files from within my browser (Chrome) but not the ones on your web site or the one you just posted here. I'm not sure why.

Mike

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I'm using winXPSP3 and use PDFlite to read PDF's and it works fine. I see the schematics and the rest of the file fine.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

It won't open up the PDF using Internet Explorer 9 either. But, if I save to file to disk and then open it with Acrobat, it works fine... Weird, huh?

Thanks, Gentlemen...

Maybe the problem is the .htaccess file. I tried to implement an automatic view or download choice by setting the mime type of pdf files to octet stream, but it never worked and I forgot to remove it.

I removed it now and hope it works, since I haven't noticed any difference. Don't forget to hit refresh to force a fresh copy of the webpage to be loaded.

Thank you for letting me know. It is good to have such a great community.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I have updated the project page with the latest version 0.81

The project has been reorganised to have all configurable items in a single separate include file to be able to keep all settings over an update to later versions. Interrupts have been tested and improved. Access to AVR timer 1 has been added.

Application load, save and autoload has been added to support EhBasic and an EhBasic version modified for use with the emulator has been uploaded. To support downloading of programs as ASCII text to Ehbasic, a software flow control (XON/XOFF) has been implemented for the RS232 receive buffer. Tera Term was tested and can be used with the emulator as an alternative to PuTTY.

The project can still be found at http://2m5.de/6502_Emu/index.htm

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

Thanks to Daryls' verification of my 65C02 extended opcodes test the project now contains an option to include all 65C02 opcodes. It is now at version 0.82.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

I have updated my Website with version 0.83 of the emulator.

The debugger can now handle up to 10 breakpoints. SPI is supported and has been tested with an SPI EEPROM, SIPO and PISO shifters. Virtual DMA has been added improving data transfer speed for SPI and I2C. As DMA is virtual (done by the ATMega in the foreground) the emulated CPU is halted during a DMA transfer. However, DMA can be interrupted by a 6502 IRQ or NMI request between each byte transferred and will resume to transfer the remaining bytes when the interrupt service exits with an RTI.

I measured the DMA speed increase from programmed IO to DMA with 4k blocks of data:
Of course, the theoretical bandwidth of an 8 MHz SPI is 1MB/s, but the SPI bus is shared with the RAM address bus and the emulator must switch between both to store or fetch each byte. The I2C DMA at 400kHz is close to its theoretical maximum of 44.4 kB/s, but as expected the gain over programmed IO is not as impressive as for SPI.

The updated hardware and debugger documents have been merged into a single reference manual. Chapters on how to configure the ATMega source and how to use IO-registers have been added.

Because I have SPI now, the next step is to test SD-cards. A special partition on the SD-card will become another option to store binary program images as with the currently available optional serial EEPROMs.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

Hi Klaus,

cool with SPI support. That enhancement is really useful. As you mention, SD-Card would be great to load programs. Instead of a special partition, I normally use contiguous files on a FAT-16 formatted storage card. So I can copy the files between Cards on any normal system, and if available can be read as disk-images by emulators on Windows/Linux/MacOSX. You state that your reach the performance of a 2MHz 65C02 on a 16MHz AVR this is really a good performance. I was thinking about using a ATMega162 instead a ATMega16. This would give some extra (three in fact) IO pins. Although it AVR has no TWI but as you mention, the performance of TWI is not really faster than doing programmed IO.

Regards

Peter

Peter,

thank you for your feedback. Yes, it would be nice to have any type of compatible filesystem. However, it would make things much more complicated and would mean, that a larger flash size would become mandatory (it should be easy to migrate to an ATMega32). I have choosen to stick with the simplified Program store system I use with the serial EEPROM. Remember, it is still an SBC project, not a home computer. So there is only multiple boot-images, which can be downloaded from a PC as an Intel hex image.

The 6502 programmer can then implement any filesystem he chooses on the remaining partition(s) of the SD-card. If someone would ever need access to the special partition on a PC, it would be easy to implement a tool to do so. The boot-image system is very simple!

An ATMega162 could be used to substitute the ATMega16. Making use of the extra pins however, would require some emulator changes. TWI is not an issue, because it is currently implemented in software. 400 kHz is no problem for a 16MHz ATMega. When the data bus is disconnected while the I2C port is connected, there is nothing else usefull to do for the CPU.

I would not recommend to implement the ATMega162's built in external RAM interface. There are many performance issues associated with using this interface in an emulator. Some of them apply to internal RAM as well:

• Must swap Z register for both instruction decode and RAM access.
• Must add an offset to the RAM address because internal RAM addressing includes registers.
• Less than 64k address range available, must split the address range in 2 or more blocks.
• Required RAM access wait cycles can not be used otherwise.
• Timing critical address latch needed.

All of the above is avoided, when external RAM is driven by software. The Z-register is dedicated to instruction decode. No offset and no split of the RAM address is needed. Wait cycles are used to do background tasks: Increment PC, check for interrupts, instruction decode, address generate, check for IO address, jump to common instruction execution (this is why I get away with a single word RJMP opcode table). The 8-bit latch is now used to expand non critical port pins.

cheers, Klaus

_________________
6502 sources on GitHub: https://github.com/Klaus2m5