| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
(Ab)use of dummy accesses
For the next release of my "No more Secrets" doc i am preparing a chapter related to the dummy access which happen when the CPU performs an internal operation. Once again i am looking for some examples on how to (ab)use it :) I guess everyone knows "inc $d019" - but i am sure there is more than this. And not only with RMW instructions. So if you have anything in your mind - just drop it here!
here are some related notes which i pasted together. feel free to proofread and point out mistakes :) |
|
... 55 posts hidden. Click here to view all posts....
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
make em 3 cycles wide :) |
| |
Hoogo
Registered: Jun 2002
Posts: 105 |
What about the color of the colorram in multicolor FLI? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
what about it? |
| |
Hoogo
Registered: Jun 2002
Posts: 105 |
Is it an example for "side effect of fetching next opcode" for your purpose? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
yes and no - this particular case is already described in detail in the pdf ("Blackmail FLI") :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote: Lovely stuff!!!
” Most 1-Byte instructions will fetch PC+1 after the opcode fetch”
All 1-byte right?
btw, its not all of them .... the various JAM opcodes will stall before that happens. not that it matters :) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: btw, its not all of them .... the various JAM opcodes will stall before that happens. not that it matters :)
Haha wtf! That doesn’t count!! :D |
| |
CyberBrain
Administrator
Posts: 392 |
Ok, let me take a stab at abusing the dummy write-cycle of RMW instructions:
$3FFF (ghostbyte) under ROM
As we know, when reading a byte from ROM, the CPU reads from the ROM, but when writing to a byte in the ROM, the write falls through to the RAM beneath it.
So with an RMW instruction you can actually write 2 values to a byte in RAM, 1 cycle apart, where none of the two written values are the value that was already present.
Usually not a useful thing to do, but together with the VIC we could exploit this:
Put the VIC in bank 2 or 3 and enable the KERNAL/BASIC ROM. Then an INC (for example) can write to the ghostbyte twice, 1 cycle apart - and the first write doesn't necessarily have to write what was already there!
Unfortunately what you can write at the first dummy cycle is limited to what is in the ROM at the chosen ghostbyte address (4 possibilities).
What you can write at the 2nd write cycle also depends on that value as well as which RMW-instruction you use (so we have 6 possibilities per ghostbyte address for the second write-cycle).
Let's look at which possibilities of pixels we have:
First wcycle Second wcycle:
| INC DEC ASL ROL (C=1) LSR ROR (C=1)
- $B7FF in ROM contains $B0 = %10110000. %10110001 %10101111 %01100000 %01100001 %01011000 %11011000
- $BFFF in ROM contains $E0 = %11100000. %11100001 %11011111 %11000000 %11000001 %01110000 %11110000
- $F7FF in ROM contains $D1 = %11010001. %11010010 %11010000 %10100010 %10100011 %01101000 %11101000
- $FFFF in ROM contains $FF = %11111111. %00000000 %11111110 %11111110 %11111111 %01111111 %11111111
|
+----> (*)
The choice marked with (*) ($FFFF and INC) might be useful in practice to create a *single cycle* wide $FF pattern! ($00 -> $FF -> $00)
Just do an INC $FFFF somewhere the ghostbyte is visible. (And init the ghostbyte to $00 in advance)
(This can of course be repeated all the way throughout the border, the x-pos can be changed, can be done multiple times per rasterline, etc etc)
Perhaps one can even be creative and use the other patterns for something too...
Charset/Bitmap
Instead of the ghostbyte, the same could be done for charset/bitmaps (but not sprites or the screen) - maybe there is an application there too.
For example (using precise timing) a charset-byte could could be set to $FF at the exact time it is read by the VIC, using the dummy-write of an INC, and then to $00 immediately after, at the second write-cycle, so that it is $00 next time it is rendered by the VIC (instead of LDA #$FF, STA $xxxx, LDA #$00; STA $xxxx).
When repeating the 7th pixel-line of a text-line using linecrunch, for example, this could make the charset-byte $FF on one raster line and $00 on the next with only one INC $xxxx instruction.
That could of course be repeated again and again, every 2nd line, so that the charset-byte alternates between $00 and $FF every rasterline...
(Of course, this requires that there is a $FF or $00 byte in the ROM at that location - but other values might be nice too)
But I haven't really found a totally perfect use-case for this yet, so not sure if it's useful in practice. Ideas? |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
_Very_ cool! We approves. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
YES! keep it coming! :) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
