6502.org

There is a bit more documentation here:
http://sourceforge.net/p/em-65c02/wiki/Home/
http://sourceforge.net/p/em-65c02/wiki/ ... Interface/

Andrew - nice project! I am doing something similar with a 1541 cycle-exact emulator that I am working on. It uses a PIC24HJ256GP210A (that is also used as a floppy disk copier/emulator). My code is different than yours (quite a bit actually) as I am calling the instruction fetch from an interrupt and using the non-interrupt time for handling the emulation of two 6522's and an ASIC (data separator). I needed cycle-exact emulation and it just worked out that a timer interrupt was quicker than checking a flag. I have everything unrolled and use duplicate sets of instruction emulation, one that fetches data from RAM (like mov [w4]++,w0) and another that uses tblrd fetching for the ROM code. So, where ever code is being executed from (RAM or ROM) there is specific instruction emulation for it. Yes, it makes things long - but there is tons of code space anyways that is just going to waste otherwise, and its a lot faster. I am at the point of needing to test the instruction emulation to make sure the flags are all correct, and I keep reading about this Klaus test program, so I must go see what that is.

By the way, when I attended the Microchip Masters conference I was told that I should be sampling some new 100MIPS PIC24 parts soon, and they will have a few with 64K and 128K of RAM. These are suppose to be fully pin compatible with existing 64 and 100 pin packages.

Interesting. I hadn't seen any information about faster PIC24 devices. With 128K you could easily put the emulator and some kind of video generation in a single chip. Its a shame Microchip have not yet put the graphics module in any of the faster chips.

I've been looking at the PIC32MX chips as an alternative platform for the emulators. I've rewritten the code for a PIC32MX795F512H in pure MIPS assembly but its not quite finished. I was distracted by writing 8080, Z80, 6800 and 65C816 emulators for the same device. I haven't quite reached the point of being able to determine how fast they will go on the 80MIP MX device and I'm waiting for the 200MIPS MZ devices to be released next year - a 14Mhz+ 65C816 with 512K of RAM on a single chip looks possible. The problem with these emulation projects is they spawn sub-projects: boot ROMs to code, assemblers to the written, micro SD card partitioning for virtual CP/M disks. And then there are my HackSpace projects (http://rlab.org.uk/wiki/Projects/CheeseBoard). I even have to find the time to do some paying work.

I must release the latest version of the 65C02 chip for the 24EP512GP202 which ups the emulator RAM to 32K and includes a slight emulation speed enhancement but I want to try it on real chip first, just haven't had the time yet.

Is there any bench mark code or are you just running Klaus' suite so many iterations and timing it?

My emulator will run an unmodified BBC BASIC ROM so I can compare its performance to the real 2Mhz 6502 in a BBC Microcomputer using a BASIC benchmark. It gives me a figure of just over 6Mhz on the last version of the code.

Klaus' test suite tests out the accuracy of your emulation but not the performance.

OK, thanks. I might look at trying to run that as a test, but it would probably require some changing. I have mirror'd memory maps and such for the 1541 as they didn't decode all of the address space and so there is special handling for that and there is only 2K of actual drive RAM and the ROMs are in PIC flash accessed via table reads. I was going to use the PSV but that invokes an automatic 2-4 cycle penalty so it ended up being quite a bit faster by not using the PSV. I need just a 1MHz emulation, so I have tons of spare time left over with the best case instruction like NOP being 2us (80 instructions) and worst case being up to 7us (560 instructions) with BRK. I am using a timer int as the instruction fetch to make it cycle exact.

Hi Andrew... I just now got around to trying to assemble your 6502 emulator, and I am having no luck using MPLAB 8.92. Depending on which processor I choose I get different error messages, and none of the code can be assembled without errors. What version of MPLAB did you use to create these?

Thanks!

I'll have a look at the code just as soon as I get my main machine up and working again. My boot SSD drive was corrupted last night but all my files are on a separate drive.

You gotta love backups! I will check back later. Thanks!

Andrew, two other issues... I noticed there is no MPLABX data at all in your archive (I was going to try that), and you are missing one of the ROMs in your ROM folder... although you do have some sort of make file perhaps to create it? Is there the binary somewhere? I managed to get one of the MPLAB projects to assemble with some creative editing, but I had to comment out the high ROM - which of course has the reset vector at $FFFC.

The materials I've published so far use MPLAB. I had to use MPLAB X for one of the new targets as the device include/linker files are not available for MPLAB but I haven't uploaded it all to the repository yet.

I haven't got as far as reloading MPLAB yet. Maybe over the weekend.

Ah... that makes sense. I will check back periodically. I would like to get that ROM binary file that is missing so I can do some testing of my emulation code vs. your emulation code. I have a lot of different hardware being emulated while the CPU emulation is going on, and I have some glitches I am trying to track down. So, I would like to try turning off the extra hardware and running the same ROM set you are using to test with. I am sure I have some flags swapped or missing.

Hi Andrew. Did you make any progress on looking into the files that are on your site? I setup a new machine with MPLAB 8.92 and I still have the same issue of not being able to assemble without errors, with the errors being different depending on the defined CPU type. Thanks!

Sorry been busy with work and recovering from an SSD corruption that wiped out my main development machine. I'll take a look over the weekend.

Yikes... good luck with that mess - been there before.