| |
Wile Coyote
Account closed
Registered: Mar 2004
Posts: 646 |
Limitations - Sprites in the Borders
hello,
I was thinking, has anyone drawn up a doc with (pictures :)explaining *all known* possibilities with placing sprites into the border areas of the screen.
I know:
8 sprites can be placed in the upper and lower borders.
7 sprites can be placed in the side borders.
I was thinking, what about the corner borders,is that classed as a sideborder or a top or bottom border (8 sprites).
Another question :) when 7 sprites are placed into the sideborders can the 8th free sprite be placed into the main (center) screen areas or by opening up the side borders, is the option for an 8th sprite not available.
I am asking these questions as i am thinking about designs that use the border areas :)
thanks
/wec
|
|
... 35 posts hidden. Click here to view all posts....
|
| |
JackAsser
Registered: Jun 2002
Posts: 1997 |
Ahh! Removing border AND setting single colour at the same time! Splendid! =D |
| |
tlr
Registered: Sep 2003
Posts: 1736 |
Quote: Ahh! Removing border AND setting single colour at the same time! Splendid! =D
Actually I'm not so sure that X is $0b anymore. I kind of misread it. I'll look some more. ($1200)
EDIT: Actually it looks like it is a Multicolor bitmap with two $d021 split points.
What are the criteria for the color below the border in this case?
Is it the last one present before the border, or something else?
|
| |
JackAsser
Registered: Jun 2002
Posts: 1997 |
@tlr: uhm, still havn't checked the code but if you, when opening the borders also disabled multicolor, then the border color will be fetched from the bg-nybble of the screen data. Then when you changed d016 again u simply at the same time switch back multicolor mode. Hence you open the border AND change bg-color of the border at the same time. I.e. no $d021 involved at all. |
| |
tlr
Registered: Sep 2003
Posts: 1736 |
He loads $d016 with $1f.
Border open is inc $d016, and then later $1f => sta $d016,x.
This does what you say, but $20 is defined as the reset bit in my books (which seems to do nothing in VICE).
Is this safe on all revisions of the VIC-II?
|
| |
Oswald
Registered: Apr 2002
Posts: 5034 |
I have never ever heard of a reset bit in d016 :) |
| |
tlr
Registered: Sep 2003
Posts: 1736 |
From mapping the c64:
Quote:Bit 5: Bit 5 controls the VIC-II chip Reset line. Setting this bit
to 1 will completely stop the video chip from operating. On older
64s, the screen will go black. It should always be set to 0 to insure
normal operation of the chip.
Maybe it's only available on the very old VIC-II's (i.e 5 luma levels).
My original c64 was one of those. (i.e 9,8,7,1,7,8,9 looks like gold!)
It's in the attic right now though.
Roland has one of them...
|
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
The VIC-II's reset bit is a pretty mysterious thing. I have never encountered in real life, perhaps only the very early NTSC VIC-II's have it. I'm pretty certain that no PAL VIC-II has it, although you can never be sure... |
| |
tlr
Registered: Sep 2003
Posts: 1736 |
But it is still a read/writeable bit?
Very odd indeed...
|
| |
tlr
Registered: Sep 2003
Posts: 1736 |
BTW, while poking around with $d016 I just noticed that the 38 column mode is borked in VICE (WinVICE 1.17 and 1.19 tested).
It covers 7 pixels to the left and 9 pixels to the right instead of 8, 8. :)
POKE53270,0 I reported it to the team just now.
EDIT: Or is it supposed to be this way? CCS64 is the same....
I have forgotten way too much stuff. :P
Note that the PAL C64 DTV covers 8/8... so I guess that one is wrong then?
|
| |
Jetboy
Registered: Jul 2006
Posts: 242 |
@_@
Just checked it on a real thing (its good to have real thing at work).
well... on standard c64 its 7-9 too.
so it seems there is no bug.
but all the time up to now i was sure it's 8-8 @_@
|
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
