Commodore 64 and Amiga 500 video hardware characteristics?

You can talk about almost anything that you want to on this board.

Moderator: Moderators

Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by Oziphantom »

Okay...

C64
320x200 bitmap with 2 colours from the 16 per 8x8 block.
160x200 bitmap with 3 colours from the 16 per 8x8 block + 1 global background per screen.
320x200 char map with 1 colour from the 16 per 8x8 block + 1 global background per screen.
160x200 char map with 1 colour from the lower 8 colours per 8x8 block + 3 global background colours per screen. You can intermix 320x200 1 colour from the lower 8 per 8x8 block + 1 global background per screen.
320x200 char map with 1 colour from the 16 per 8x8 block with 4 background colours to choose from but only 1 per 8x8 block. This comes at the cost of only having 1/4 the amount of chars to select from.

Sprites
8 per raster line
24x21, 1 colour + transparency
12x21 1 colour + 2 colours shared with all 8 sprites + transparency
each sprite can be expanded 2x in the X and/or Y giving you twice the size but same pixel count

Enhanced modes
FLI - this forms a bad line every line so you loose the first 3 char rows to single colour grey, but you get 1 colour per 8x1 and then 3 colours per line at 160x400 interlaced
See also NUFLI, MUFLI XFLI etc for fixes and other compromises
Borders can be opened, allowing sprites to appear in the borders, there is also a single control byte for what is drawn in the border area.
Sprite stretching is also possible allowing you to duplicate Y rows as much as you like

Priority
A Sprite can appear behind char data or in front of char data. In Multi colour mode it can appear in front of background colour + mCol1 but behind Char colour + mCol0 allowing you to put the sprite behind somethings and in front of other things.

Amiga 500 ECS
320x200,320x400,640x200,640x400 2,4,8,16,32,HalfBirght(~64),HAM(~4096) colours
640x480 progressive, 1280x200/256 (NTSC/PAL) 2,4 colours
You can also enable Overscan to paint over the "border" for more pixels
Dual playfields lets you have a 8colour + 7 colour and Transparent screen giving you 2 "planes"
Sprites 16xasTallAsYouLike 3 colours + transparent, you can bolt 2 sprites together to make a 14 colour sprite. There is 8 per line however you can plex sprites on the same scan line to overcome the limit. Sprites are always "lores" so the use pixels as if they are in 320x200
Sprites can be behind the bitmap, above all bitmap or between the playfields in Dual Plane Mode
Blitter this is a fully programmable blitter than also has built in line drawing and polyfill instructions, this allows you to and,or,eor upto 3 planes to a single target plane
Copper this is basically HDMA, its a custom programmable chip that lets you modify any video register whenever you like, however unlike HDMA it is not limited to HBlank and can run anywhere in the frame
The Amiga has hardware windows, (7 or 8 I think ) that allow you to render different parts of the screen in different resolutions and with unique pallets, not used often in games but if you are making a strategy game it can be handy.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by Drew Sebastino »

Thank you for finally compiling this! :beer: If you're actually programming for the C64, you should have an explanation for how these limitations exist due to memory, but they should really still have an easy to understand overview...

Character based modes are a lot worse than I would have thought... I don't really know all of the full ramifications of using either bitmap mode but, uhh, it clearly leads to better results: ("Another World" (not the one you're thinking of) on C64) https://youtu.be/fcNxoXwnFWY

One thing I guess you forgot to mention about the Amiga 500, is how much sprite color memory is there? Do you typically have Copper multiplex the sprites, because the majority of Amiga games definitely don't have that 8/4 sprite per line limitation.
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by Oziphantom »

So the Commodore 64 has a 2Mhz bus, the VIC chip gets 1 half cycle the CPU gets the other. Its a shared RAM system. The VIC is limited to see 16K at a time. the VIC has a private 4bit bus to CRAM which is made up of Nybbles.

For each char the VIC needs, CRAM data, Char number and then 8 char bytes to draw it. So to get all the data it needs 4bits of CRAM, 8bits of Char num and then 8bits of Each char for that line it is to draw

Code: Select all

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
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)
This is a DMA steal case. There are 40chars per Row, and they take 40 clocks to draw. The VIC and CPU are in perfect sync.

Code: Select all

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 r g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g 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 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 x x x x x x x x x x x x x x x

Graph.                      |===========01020304050607080910111213141516171819202122232425262728293031323334353637383940=========

X coo. \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
       1111111111111111111111111110000000000000000000000000000000000000000000000000000000000000000111111111111111111111111111111111111111
       89999aaaabbbbccccddddeeeeff0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff000011112222333344445555666677778888999
       c048c048c048c048c048c048c04048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048
Sprites need 1 fetch for their PTR ( like tile in NES) and then 3 bytes to fetch a row 24bits. this is done in the borders of which the borders are wide enough to fetch 8 sprites worth. Again it does a DMA steal so it grab 4 bytes is "2 cycles"
The reason why the resolution drops to 160 vs 320 is it would have to halt the CPU for the entire screen in order to get double the data down the bus.
A Screen uses 1000 bytes for the screen map, colour is stored in CRAM which is seperate from the 64K, and the char set is 256*8 = 2K of data. So a Screen with chars take 3K a bitmap is 1000x8.
Hires uses the Screen map to hold 2 nybbles for the 2 colours, aaaabbbb this lets it fetch 2 colours per 1 byte.
Multicolour uses the Screen map to hold both multicolours and then CRAM to hold the extra colour. Again this does not change the bandwitdh needed.
EEBM is a hires char mode, so uses 1000 for the screen map, 64x8 for the chars. So it uses the chars in the screen as
XXaaaaaa XX = background colour 0-2 and then aaaaaa = char what they should have done is still keep all 256 just have it so each "bank of 64" could have a different colour.
Every single step, trick, feature, access, memory access of the VIC-II is documented here in extreme detail http://www.zimmers.net/cbmpics/cbm/c64/vic-ii.txt
But basically the vic gets 1 byte per character per line normally, and 4 bytes of data per sprite per line. This is 7 out of 8 lines, on the other line it DMA steals and gets 2bytes + 4bits of private bus per character. You can sacrifice CPU and force the VIC to "bad line" every line and hence it gets all new data per line for more colours. Or you can stop it from doing "bad lines" and shift the screen down ( see FLD) or even stop it for ever and hold a image in just its internal buffers and trash RAM for the extreme demo trick )
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by Oziphantom »

Amiga 500
Most games don't use sprites, they suck. Or you use them for hud, cursors, background layers etc to which you Plex them in the same row using the copper.
The "sprites" you see are BOBs Blitter OBjects, you use the blitter chip to shift and move around bits of bitmap really fast and build the games image that way. hence Shadow of the beast has really big things as its not bound by sprite limits but a fill limit which it can work around by offseting the planes start to make a "cylinder scroller"( I think this was Shadows big trick, it was the first to do it ) and things like that. It eats RAM, can eat DMA but gives total freedom.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by Drew Sebastino »

Oziphantom wrote:The "sprites" you see are BOBs Blitter OBjects, you use the blitter chip to shift and move around bits of bitmap really fast and build the games image that way.
Hmm... The only thing is, wont sprites then have to share the BG colors? That's fine for 6bpp, but not really for 3bpp...

It sounds like you'd have to go to town with the Amiga's windows if you want a reasonably colorful image in dual playfield mode.
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by Oziphantom »

Yes, they must share the palette, I think even the sprites have some palette overlap, not really done that much hardcore A500 stuff.

Dual Platfields can usually end up as 1 = background, 2 = "sprites"
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by Drew Sebastino »

Hmm... I'm assuming performance will be shit if you just try and render two layers and objects to one 6bpp bitmap...
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by Oziphantom »

you have ~1 million bits per second, so it depends on how you want to use them.
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by Bregalad »

TmEE wrote:Both of those machines are framebuffer based, without any tiles and whatnot (except C64 in its character modes). Framebuffer sits in main memory that is shared by CPU, and accessible as normal RAM to the CPU.
Not necessarly. The C64 can also work with a tilemap-like scheme, and that's what the vast majority of games uses I think, if you want to scroll you have pretty much no choice.

The confusing thing with C64 is that when switching to 2BP mode (either BG or sprites) they use two bits for the colours of two consecutive pixels, effectively halfing the horizontal resolution, but in the official documentation they call the two consecutive pixels "a pixel", even though this is wrong. There's no 160x200 mode, it's just 320x200 with every BG pixel being duplicated. The proof that the resolution is still high internally is that you can fine-position sprites.
User avatar
Hojo_Norem
Posts: 137
Joined: Mon Apr 16, 2007 10:07 am
Contact:

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by Hojo_Norem »

lidnariq wrote:That makes more sense... it's also not what the c64 wiki says here
The C64 wiki is wrong. Here's a quote from the C64 Programmer's Reference Guide:
MULTI-COLOR BIT MAP MODE

Like multi-color mode characters, multi-color bit map mode allows you to display up to four different colors in each 8 by 8 section of bit map. And as in multi-character mode, there is a sacrifice of horizontal resolution (from 320 dots to 160 dots). Multi-color bit map mode uses an 8K section of memory for the bit map. You select your colors for multi-color bit map mode from (1) the background color register 0, (the screen background color), (2) the video matrix (the upper 4 bits give one possible color, the lower 4 bits an other), and (3) color memory.
I fixed the wiki entry.
Insert witty sig. here...
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by Oziphantom »

the image resolution is 160x200 its displayed on a 404x312 screen, but the image it self is only 160 pixels wide. You can't have a half pixel, you can scroll it to the left by 1 pixel, but there is still only 160 addressable pixels.

A sprite is only 12 pixels wide, you can't set a half pixel, you can place it anywhere on the 404x312 resolution of the VIC-II with a single pixel resolution, however the sprite it self only has 12 individual pixels.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by tepples »

Which leads to a philosophical question: Are the sub-screen columns in Super NES pseudo-hires "pixels" or "half pixels"?
ccovell
Posts: 1045
Joined: Sun Mar 19, 2006 9:44 pm
Location: Japan
Contact:

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by ccovell »

Oziphantom wrote:Amiga 500
Most games don't use sprites, they suck. Or you use them for hud, cursors, background layers etc to which you Plex them in the same row using the copper.
Most graphically impressive Amiga games (ab)use sprites in several clever ways. I urge you to check out the analyses Codetapper has made here:

http://codetapper.com/amiga/sprite-tricks/
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by Drew Sebastino »

Oziphantom wrote:you have ~1 million bits per second, so it depends on how you want to use them.
So, 320 * 200 = 64,000 pixels,
1,000,000 / 60 frames / 6 bpp = 2,778. Ouch...
ccovell wrote:
Oziphantom wrote:Amiga 500
Most games don't use sprites, they suck. Or you use them for hud, cursors, background layers etc to which you Plex them in the same row using the copper.
Most graphically impressive Amiga games (ab)use sprites in several clever ways. I urge you to check out the analyses Codetapper has made here:

http://codetapper.com/amiga/sprite-tricks/
Could one make more elaborate backgrounds by changing sprite attributes while plexing them, or is this not possible?
ccovell
Posts: 1045
Joined: Sun Mar 19, 2006 9:44 pm
Location: Japan
Contact:

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by ccovell »

Espozo wrote:Could one make more elaborate backgrounds by changing sprite attributes while plexing them, or is this not possible?
I think Brian The Lion was dynamically replacing 1 bitplane of the cloud sprite, as the beam traced horizontally. Limited things can be done, though not in many bitplanes.
Post Reply