3 ms·
It could be faster: lda #firstbyte sta dest+0 lda #secondbyte sta dest+1 etc. 6 cycles per byte, so 166KB/sec. But we can do better: ther
by jhallenworld 4y ago
It could be faster:
lda #firstbyte
sta dest+0
lda #secondbyte
sta dest+1
etc.
6 cycles per byte, so 166KB/sec. But we can do better: there are only 256 different bytes, so group the stores by byte value so that you don't have to reload before each one:
lda #0
sta dest+10 ; All the places that get 0
sta dest+29
sta dest+42
lda #1
sta dest+3 ; All the places that get 1
sta dest+82
etc.
Up to 250 KB/sec and less space. If the prior data in dest is known, it could be even faster: skip stores where the destination already has the correct data. And even faster: for video, skip stores which have a low hamming distance from the prior bytes and put up with a bit of noise..
- tedunangst 4y agoHow do you know which places get 0 bytes?
- jhallenworld 4y agoWith pre-processing: sort the source data so that the same bytes (along with their offsets) are grouped together, then convert this to code. It could be useful for drawing things like fixed sprites quickly.
- rzzzt 4y agoThis presentation of "A Pig Quest" for the C64 describes similar methods for efficient bitmap copying (the timestamped part is more relevant, but I recommend watching the entire thing): https://youtu.be/I8CTKeh8N0Q?t=578 https://youtu.be/I8CTKeh8N0Q?t=578
- vikingerik 4y agoEven faster: use the X register instead of A, because there's an increment instruction for it (INX) that takes only 2 cycles instead of 3 to do LDA with the next value. Also FYI, that 6 cycles to load/store each byte is only if you're writing to zero page (an 8-bit address, meaning the first 256 bytes of the address space.) Stores to a 16-bit address take one more cycle, 4 instead of 3, to read the operand when it's a two-byte address instead of one.