Apropos of this tangent...
The VIC-20 normally displays 22x23 8x8 pixel characters (176x184), a 3:2 pixel aspect ratio, underscanned with a border (the NES's 256 pixels correspond to 195 pixels at the VIC-20's 1bpp pixel clock). 22x23 is one of a few choices that comes as close as possible without exceeding the 512 total nybbles of color attribute memory.
The VIC-1 supports adjusting the left margin, upper margin, and width and height of the visible screen, while the underlying NTSC timing isn't changeable(other than interlaced vs not). It has such a paucity of RAM for the tilemap that games (I am told) usually use 20x10 8x16 pixel characters (160x160).
So the unimportant question: why doesn't the C64's VIC-2 support the same adjustments?
C64 screen pixel count
Re: C64 screen pixel count
I don't have a link to the answer, but the VIC-II introduced sprites, which need to be processed (perhaps in the borders?) plus there are DRAM refresh cycles. Maybe someone with a more detailed, factual account can explain what goes on in the C64's side borders.
-
- Posts: 1565
- Joined: Tue Feb 07, 2017 2:03 am
Re: C64 screen pixel count
All data here on in is PAL unless specified.
The C64 is 402x292 visible.
The VIC needs to fetch Char data each cycle to display. so a normal access looks like xgxgxgxg... 40 times,where x is Cpu and G is char/tile data
To display it also needs to know the Char number so ever 8 lines it has a "bad-line" where the access is cgcgcgcgcg x40 so the VIC eats both cycles during c it gets the Screen code and pulls in the CRAM colour value on its private 4 bit bus to it.
Sprites need 4 cycles to grab, one for the Sprite Ptr, then 3 for the sprite's data for the next line, so again the VIC steals cycles, thus it takes 2 "clocks" The C64 is a 1mhz machine with a 2mhz bus.
Borders are 23 chars wide, of which about 10.5 are visible
and NTSC example ( Which has 25 char wide borders ) with sprites
c Access to video matrix and Color RAM (c-access)
g Access to character generator or bitmap (g-access)
0-7 Reading the sprite data pointer for sprite 0-7 (p-access)
s Reading the sprite data (s-access)
r DRAM refresh
i Idle access
x Read or write access of the processor
X Processor may do write accesses, stops on first read (BA is low and so is RDY)
So the border is wide enough to hold 8 sprite fetches, DMA take over delays, you must wait 3 clocks after pulling BA/DMA low, and mask the screen size differences between NTSC and PAL
The C64 is 402x292 visible.
The VIC needs to fetch Char data each cycle to display. so a normal access looks like xgxgxgxg... 40 times,where x is Cpu and G is char/tile data
To display it also needs to know the Char number so ever 8 lines it has a "bad-line" where the access is cgcgcgcgcg x40 so the VIC eats both cycles during c it gets the Screen code and pulls in the CRAM colour value on its private 4 bit bus to it.
Sprites need 4 cycles to grab, one for the Sprite Ptr, then 3 for the sprite's data for the next line, so again the VIC steals cycles, thus it takes 2 "clocks" The C64 is a 1mhz machine with a 2mhz bus.
Borders are 23 chars wide, of which about 10.5 are visible
Code: Select all
6569, Bad Line, no sprites:
Cycl-# 6 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 5 5 6 6 6 6
3 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
�0 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
__
IRQ ________________________________________________________________________________________________________________________________
________________________ ____________________
BA ______________________________________________________________________________________
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
AEC _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _________________________________________________________________________________ _ _ _ _ _ _ _ _ _
VIC i 3 i 4 i 5 i 6 i 7 i r r r r rcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcg i i 0 i 1 i 2 i 3
6510 x x x x x x x x x x x x X X X x x x x x x x x x x
Graph. |===========01020304050607080910111213141516171819202122232425262728293031323334353637383940=========
X coo. \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
1111111111111111111111111110000000000000000000000000000000000000000000000000000000000000000111111111111111111111111111111111111111
89999aaaabbbbccccddddeeeeff0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff000011112222333344445555666677778888999
c048c048c048c048c048c048c04048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048
Code: Select all
6567R8, no Bad Line, sprites 2-7 active in this line, sprites 0-4 in the
next line (abbreviated):
Cycl-# 6 1 1 1 1 1 1 1 1 1 1 |5 5 5 5 5 5 5 6 6 6 6 6 6
5 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 |3 4 5 6 7 8 9 0 1 2 3 4 5 1
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _| _ _ _ _ _ _ _ _ _ _ _ _ _ _
�0 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _| _ _ _ _ _ _ _ _ _ _ _ _ _ _
__ |
IRQ ______________________________________|____________________________
__________________|________
BA ______________________ | ____________________
_ _ _ _ _ _ _ _ _| _ _ _ _ _ _ _
AEC _______________________ _ _ _ _ _ _ _ _ |_ _ _ _ _ _ _ ______________
|
VIC ss3sss4sss5sss6sss7sssr r r r r g g g g |g g g i i i i 0sss1sss2sss3s
6510 x x x x x x x x x| x x x x X X X
|
Graph. |===========0102030|7383940============
|
X coo. \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\|\\\\\\\\\\\\\\\\\\\\\\\\\\\\
1111111111111111111111111110000000000000|1111111111111111111111111111
999aaaabbbbccccddddeeeeffff0000111122223|344445555666677778888889999a
48c048c048c048c048c048c048c048c048c048c0|c048c048c048c048c04cccc04c80
g Access to character generator or bitmap (g-access)
0-7 Reading the sprite data pointer for sprite 0-7 (p-access)
s Reading the sprite data (s-access)
r DRAM refresh
i Idle access
x Read or write access of the processor
X Processor may do write accesses, stops on first read (BA is low and so is RDY)
So the border is wide enough to hold 8 sprite fetches, DMA take over delays, you must wait 3 clocks after pulling BA/DMA low, and mask the screen size differences between NTSC and PAL