I'm looking to emulate a 6502 on the ARM but I would like to make it cycle accurate so I need some way to interface to an external clock. I can't rely on an internal clock as there are external components that will rely on the external clock as well and the emulator needs to be able to run in lockstep with everything else. One thing to keep in mind is once everything is in working order I will want to increase my clock to several hundred MHz so the mechanism with which I interface with the external clock has to be extremely fast, preferably a pin on the ARM itself that I can poll and sync with. I don't want to utilize interrupts either since the code is performance sensitive. Any ideas on whether this is possible on the ARMv8 such as the A53/A57? From what I understand, the Raspberry Pi 3 uses a low speed protocol for communication and is interrupt based, and for my purposes those two are big no-no's for what I'm doing so that won't work. I'd appreciate some expert advice as this is starting to stretch the limits of what may be possible.
I doubt that any SoC has an input which can sample "several hundred MHz" signals. I do not know the limits of AHB or AXI by heart, but what I remember on AHB you have something about 100 or 133MHz.I wonder, did you start to emulate the 6502 already? I doubt you can achieve several hundred MHz of simulated clock.Even a simple instruction like "nop" needs a dozen of ARM instructions. So for simplicity, if you need "only" 10 instructions and running the ARM with 1.5GHz, you cannot be better than 150MHz..Unless you do a JIT compilation of the 6502 code.You might want to go for an FPGA and do the 6502 in HW and only the peripherals in SW.
You may be right, I have emulated it in software and I'm now looking to emulate it bare-metal on an arm core but I'm going in blind without any ARM experience.The A75 will run at ~3ghz, so I'm counting on that boost, plus (hopefully) some cleverness on my part. Jitting (or any form of dynamic translation) will not work due to Apple II programs' ability to self modify and the inability to know what is an instruction and what is data. I'm curious that you mention the NOP instruction however; what makes you think that alone would cost a dozen instructions?
Right, 6502 code is full of "dirty tricks" :-) Wrote myself a lot ..
"the dozen instructions for NOP" comes out of experience. I my-self wrote a 6502 simulator for the Atari Jaguar.
You need to pick the opcode, update PC, call the emulation function, increment cycles. If you do this in C then you quickly get 12 instructions.
I saw one emulator in ARM Thumb-2 on githup (link below) (out of 235 6502 emulators) which needs 9 ARM instruction for one 6502 instruction.
But no special hardware emulated, yet. Which also takes time though can be directed to other cores.
BigEd/a6502: https://github.com/BigEd/a6502