Not very good, I wouldn't think. It didn't have many instructions or registers. There would be a LOT of memory reads/writes, a lot of extra finnagling of things that modern architectures can do in one or two instructions very cleanly.
Assuming no extra modern stuff was added on top of the 6502 and you just got a bog-standard 6502 just at a very high clock speed, then as the other comment mentioned there was no memory caching, no pipelining (though there have been lots of people interested in designing one with a pipeliner), and not a whole lot of memory space to boot as it had 16-bit wide registers.
Thus, most 6502 applications (including NES games, for example) had to use mappers to map in and out different physical memory regions around the memory bus, similar to modern day MMUs (just without the paging/virtualization). It would be hammering external memory like crazy.
“On the 65C02, STA (indirect),Y requires five clock cycles to execute: two cycles to fetch the opcode and operand, two cycles to read two bytes in the 16-bit pointer, and one cycle to perform the write to the calculated address including the Y offset. All good. But for the NMOS 6502 the same instruction requires six clock cycles. During the extra clock cycle, which occurs after reading the 16-bit pointer but before doing the write, the CPU performs a useless and supposedly-harmless read from the unadjusted pointer address: $CFF8. This is simply a side-effect of how the CPU works, an implementation detail footnote, because this older version of the 6502 can’t read the pointer and apply the Y offset all in a single clock cycle.”
“The Woz machine on the Disk II card is controlled by the address lines (which set its mode) and exploits this "phantom read" to switch from SHIFT to LOAD mode during floppy disk write operations so in the CPU cycle immediately following the phantom read, which is the write cycle, to the same address as the phantom read (assuming no page crossing this time), the Woz machine will be in LOAD mode and grab the disk byte ("nibble") from the 6502 data bus. The Woz machine does a blind grab of that byte, it does not look at the R/W signal to determine if it's a write cycle. If the phantom read is missing, it just won't work because the data byte will be gone before the mode changes to LOAD.
I am quite sure that this is how the Disk II works. But this is where my own hands-on experience ends.”
> If only. Its program counter is 16 bits, but the other registers are 8 bits.
Oh wow, I didn't remember that. I had to go back to double check it! Maybe the NES had wider registers? Or maybe I'm just completely misremembering, which is definitely probably absolutely the case.
Also, thanks for all the other links! Really interesting stuff.
There's the mostly 6502 compatible 16-bit WDC 65C816 that'd probably be a much better, less painfully minimalist starting point.
Apart from a MMU, the biggest hurdle I think for modern dev on the original 6502 is the lack of multiply/divide and the pain of having to either forgo modern levels of stack use or emulate a bigger stack.
Assuming no extra modern stuff was added on top of the 6502 and you just got a bog-standard 6502 just at a very high clock speed, then as the other comment mentioned there was no memory caching, no pipelining (though there have been lots of people interested in designing one with a pipeliner), and not a whole lot of memory space to boot as it had 16-bit wide registers.
Thus, most 6502 applications (including NES games, for example) had to use mappers to map in and out different physical memory regions around the memory bus, similar to modern day MMUs (just without the paging/virtualization). It would be hammering external memory like crazy.