| |
johncl
Registered: Aug 2007
Posts: 37 |
Sprites at $d800 ?
I was always under the impression that the screen color information was stored in ram at $d800. But while working on a Vice Snapshot File viewer I found a lot of sprites in RAM at $d800 for e.g. the game Great Giana Sisters (sprites start at $cc00).
So am I right to believe that when the IO/C rom is visible any sta/lda to/from $d800 is redirected to the vic in some sort of color ram it has? But if you point a sprite at $d800 the vic will see the data in the system RAM?
Sorry for the n00b question, but this was new info for me. :) |
|
| |
johncl
Registered: Aug 2007
Posts: 37 |
Ok, googling a bit I found this hacking article that explains it:
http://codebase64.org/doku.php?id=magazines:chacking7#hiding_ki..
"Note that the VIC-II always fetches its information from the internal RAM, totally ignoring the memory configuration lines. There is only one exception to this rule: The character generator ROM."
So this means that it can always get access to sprite data in ram even if the IO/C rom is on. Also from another place in that article:
"D800-DBFF Color RAM (only lower nybbles are connected)"
Which indicates that the 4 lower bits of each byte is stored somewhere else in/around the vic chip to use as color information per char position. Obviously to get sprites into this area you have to turn off the IO/C rom (by setting address $01 accordingly), copy the sprite data into it and then turn it on again. I guess many games use this area for sprite data since its basically overshadowed by the rom (IO and Kernal) and you dont have to bother with any flip/flopping of them while your program is running. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
correct, also favorite place for 4x4x16 softmode bitmaps in demos as that bitmap doesnt changes, there's no need to take care of ram configuration in the irq handlers IO can be always on. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
D800 colors are indeed some extra RAM of 1000 nybbles. So if you don't use D800 colors, there's actually about an extra half a K here that can be used for other things, e.g. raster colors.
|
| |
yago
Registered: May 2002
Posts: 333 |
Please note that RAM under I/O is best used for constant stuff (like oswald said) that needs not to be read by the CPU.
So, D000-DFFF is not good for Raster Colors, as you would need to change $01 for reading them (and you do want IO on all the time after init).
|
| |
johncl
Registered: Aug 2007
Posts: 37 |
Yes, I believe Cruzer meant that if you dont use the color memory in the VIC at $d800 you can store other data there, for example raster colors.
And yes you are right that the area under the IO and Kernal is best used for static stuff - especially since the VIC can see this memory - so excellent for sprites and a static charset (no good if you are updating it in realtime).
|
| |
yago
Registered: May 2002
Posts: 333 |
Ah, now i see... Well please note that the colorram is only usable for colors, since its not only 4 bits big, but the upper 4 bits behave kinda... strange :-)
|
| |
johncl
Registered: Aug 2007
Posts: 37 |
It will take some cpu time if you need that data as bytes (and, shift, or) so not terribly efficient, but nice to know if you are really down to your last bits. :)
I think I have read somewhere someone using those upper bits as a random generator.
|
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Yeah, ofcoz you can only use the lower 4 bits. The upper 4 ones are junk, but not totally random. As far as I remember they are related to d012, which can be seen if you do something like:
loop:
lda $d800
lsr
lsr
lsr
lsr
sta $d020
jmp loop
|
| |
johncl
Registered: Aug 2007
Posts: 37 |
Yes, tried that little routine you pasted in and I see that the contents change in a repetitive fashion once it drawing the character area. Interesting... |
