| |
chatGPZ
Registered: Dec 2001
Posts: 11130 |
(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....
|
| |
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: 1717 |
_Very_ cool! We approves. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11130 |
YES! keep it coming! :) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Perhaps I'm missing something, but aren't the 'alternate' ghostbytes at $B9FF and $F9FF (when using ECM)? |
| |
CyberBrain
Administrator
Posts: 392 |
Yes, you're absolutely right of course. Their values unfortunately doesn't become much nicer:
$B9FF = $A0
$F9FF = $D2 |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Nope. But the 'trick' is very interesting though, never would have thought of it :) |
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
nice trick, but 3fff can be set to any byte in a 8 pixel wide area with another trick. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Pray tell. |
| |
tlr
Registered: Sep 2003
Posts: 1717 |
Quote: nice trick, but 3fff can be set to any byte in a 8 pixel wide area with another trick.
I assume you are refering to exploiting the difference in pipeline delay between changing the videomode and changing the fetched graphics data to be fetched?
That is a neat trick, but it is dependant on the type of VIC-II (old/new) and it takes more cycles per instance.
The inc $ffff trick is only 6 cycles per instance. |
| |
Hoogo
Registered: Jun 2002
Posts: 102 |
Dec $dc0d after a Timer A IRQ occurred would acknowledge that IRQ and stop further ones. But I don't see a good reason to do that. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
