Graphically impressive z80 machine

Can't do 3D on C64? https://www.youtube.com/watch?v=zVPW40ygds4 :P

I didn't say it couldn't do delta-compressed movie playback!

But yeah, it can do okay even when performing actual 3d computations if given enough storage space for lookup tables (that's a large cartridge game). It's just that decent 3d on that platform is much rarer than on the z80 machines.

Though it might just be the low clock rate on that specific 6502; the Atari does a much better Escape from Fractalus than the C64, and the BBC does a much better Revs.

Much like the consoles, I think; the hardware is well optimised for a big tranche of games, and for cost.

Aside: glancing at the 65816, the '16-bit' (ish) drop-in (sort of) 6502 replacement, I see they added block move instructions. So we're not the only ones to have considered the 6502 solutions to LDxR to be problematic.

(EDIT: though, that being said, LDxR aren't exactly brilliant on the Z80, since they spend 50% of their memory accesses on redundantly rereading their own opcodes.)

Also, of course, I forgot the refresh cycle. There are five memory accesses total for each iteration of an LDxR: two to read the operation, a refresh cycle in between, then a read and a write to perform the memory mutation. So actually it's only 40% of memory accesses that are redundant, amounting to 5 of 21 cycles. Or, on an MSX, 6 of 22. I guess there might be some additional decode costed in after the second opcode byte fetch (decode of the first byte happens during the refresh cycle) but the dominant cost seems to be the 16-bit arithmetic.

EDIT:

Apologies to -LeoN- for missing his post, then saying the same thing, with less detail! At least there's one regard in which the 65816 isn't an absolutely terrible thing.

Yes, in the common case an 'internal repeat' that doesn't re-read opcodes would allow much faster block-copy. But whether you'd want that, depends on what you want the documented behaviour to be:

I tend to regard eg. LDIR as LDI + JR back to the opcode's start address (while BC<>0). Re-reading the opcode there may produce a different opcode than the previous read. For example if that LDI(R) overwrote itself. Or if external hardware interferes with the opcode read somehow. Or say that opcode is produced by a memory-mapped I/O device that produces a different opcode once some other hardware condition occurs. A program may use this for code obfuscation. Or the last write changed the memory configuration (including opcode's address) through a memory mapper style mechanism.

Okay such cases are unusual, but even then it's possible that is the intended behaviour for LDIR & co.

If you only want to have the fastest possible block-copy ignoring the possibility of cases like above, then yes such 'internal repeat' would be preferred.