Commodore 64 and Amiga 500 video hardware characteristics?

[Drew Sebastino]

The NES vs Commodore 64 discussion a while back made me wonder what exactly the Commodore 64's video hardware is. Unlike for other 2D based systems, Wikipedia doesn't do too great a job of explaining it. My initial question because it left me a bit confused: are the colors used by each tile actually unique (they don't just reference a palette)? Also, about tiles either being double width 4bpp or 2bpp, what basis can you change this on, or can each tile decide? It says sprites are 24x21 pixels tall, which seems a little odd... It doesn't say how the colors are defined for these either, unless every sprite can freely choose.

One last thing: does graphics data reside in main ram or somewhere else? Regardless of the fact that this will eat all of your already limited ram, with the tilemap, is it at all possible to change vertical scroll and have 8 tilemaps in a row for 8x1 pixel attributes like you theoretically can with the SNES? I can see this having a dramatic impact on graphics; you could just about seamlessly go between 4bpp and 2bpp modes.

And I figured that while I'm at it, I might as well ask about the Amiga 500 because Wikipedia is even worse here... I've heard the Amiga has either one 6bpp layer or two 3bpp layers, but other than that there's somehow no penalty for having to access more tilemap data (like on the SNES where every new layer consumes an additional 2bpp beyond the color depth) there's this:


It's still only 6bits of color depth between all the layers (I was really surprised to find out that the rear most layer is only 1bpp...) but yeah.

The Amiga also can't get away with defining what colors to use for every tile like the Commodore 64, but I can't find anything on color other than that the Amiga has a 12bpp master palette.

[TmEE]

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.

[Drew Sebastino]

Oh, really now? I'm actually surprised to find out that the 68000 in the Amiga 500 only ran at 7.16MHz; flight simulators and whatnot are much smoother on it than the Genesis could hope, unless the advantage of being framebuffer based is actually that large.

[psycopathicteen]

There is still a graphics chip drawing things onto the buffer. Aparantly it has several layers of buffering too. I'm not sure if it's a scrollable buffer or not.

[Drew Sebastino]

I'm not sure if it's a scrollable buffer or not.

I'd imagine; it seems like a huge waste of processing power to completely rerender everything just shifted a few pixels every frame.

[lidnariq]

The NES vs Commodore 64 discussion a while back made me wonder what exactly the Commodore 64's video hardware is. Unlike for other 2D based systems, Wikipedia doesn't do too great a job of explaining it. My initial question because it left me a bit confused: are the colors used by each tile actually unique (they don't just reference a palette)? Also, about tiles either being double width 4bpp or 2bpp, what basis can you change this on, or can each tile decide? It says sprites are 24x21 pixels tall, which seems a little odd... It doesn't say how the colors are defined for these either, unless every sprite can freely choose.

Try the wikipedia page on the VIC-2 instead of the page on the C64...

One last thing: does graphics data reside in main ram or somewhere else? Regardless of the fact that this will eat all of your already limited ram, with the tilemap, is it at all possible to change vertical scroll and have 8 tilemaps in a row for 8x1 pixel attributes like you theoretically can with the SNES? I can see this having a dramatic impact on graphics; you could just about seamlessly go between 4bpp and 2bpp modes.

The VIC-2, like the SMS's VDP, loads and caches tilemap data every 8 scanlines. (During this time the VIC-2 stalls the CPU—the C64 demoscene calls these "badlines"). But it can be tricked into fetching tile data every scanline.

—

Similarly for the Amiga 500, try reading up the capabilities of its Original Chip Set. The OCS has a coprocessor ("copper") that is basically the same as the SNES's HDMA unit.

[Drew Sebastino]

Try the wikipedia page on the VIC-2 instead of the page on the C64...

Oh, yeah, that helped... Even better I found is this: https://www.c64-wiki.com/wiki/Character ... _character I had no idea the C64 was like the SNES in that it had a hundred which graphics configurations to make up for its relatively slow video bandwidth.

It appears that you can have both high color and low color tiles on the same screen together, but that you sacrifice some of the colors you can choose from.

The VIC-2, like the SMS's VDP, loads and caches tilemap data every 8 scanlines. (During this time the VIC-2 stalls the CPU—the C64 demoscene calls these "badlines"). But it can be tricked into fetching tile data every scanline.

That's what I'd have thought; like I had suggested, you could also have a smaller attribute space vertically on the SNES if you were to use HDMA to scroll down every couple of lines and upon reaching the end of the tilemap, changed the VRAM tilemap location register. 2bpp BG3 might not stick out like a sore thumb then.

[lidnariq]

I had no idea the C64 was like the SNES in that it had a hundred which graphics configurations to make up for its relatively slow video bandwidth.

Not really? The C64 only has (edit) one fetch pattern; its different modes are more like the CGA than the SNES. Every 8x8 HiRes pixel zone has its own unique 12-bit attribute, and the mode just changes how those 12 bits are interpreted.

Unlike the VIC-20's VIC-1, where the tilemap actually addresses three 4-bit wide RAMs and the portion of address space corresponding to the attribute data is open bus for the upper 4 bits, the C64 uses 64K x 8 of DRAM, so it's vaguely a shame that the attribute data isn't 8 bits wide. It'd've been nice to have more variable colors per tile.

[Drew Sebastino]

Oh; the C64 wiki had me believe otherwise. Yeah, the fact you only get 2 colors at normal resolution is a real shame. I think games could have looked a lot better if they were smarter about when to use 2bpp vs 4bpp graphics. It looks like many games only ever even stuck to one mode. :/

[lidnariq]

Er. There's no 4bpp mode. (There's 16 color modes, but they're still 2bpp)

Also, I'm at least somewhat wrong about different VIC-2 modes https://www.c64-wiki.com/wiki/Graphics_Modes

But they don't differ as much as the different SNES modes; they're about how the 12-bit tilemap entry is interpreted rather than changing fetch cadence:

edit#large: reformatting into a table:
Each tilemap entry is interpreted as:

Code: Select all

name                $D011,$D016  interpretation    summary
Standard Character   $00   $00   [FFFF TTTT TTTT]  8x8 1bpp tiles, shared background
Multicolor Char      $00   $10   [WCCC TTTT TTTT]  8x8 1bpp or 4x8 2bpp tiles, depth and foreground color selected per tile, shared background and other three colors (per palette at $D021,2,3)
Standard Bitmap      $20   $00   [.... FFFF BBBB]  8x8 1bpp tiles, foreground and background selected per tile, tilemap address used as tile number
Multicolor Bitmap    $20   $10   [CCCC DDDD EEEE]  4x8 2bpp tiles, three colors selected per tile, background from $D021, tilemap address used as tile number
Extended Color       $40   $00   [FFFF JJTT TTTT]  8x8 1bpp tiles, foreground selected per tile, background selects from entries in shared palette at $D021,2,3,4
where
FFFF - color of color '1' in 1bpp mode
BBBB - color of color '0' in 1bpp mode
W    - 2bpp double-wide vs 1bpp normal-wide
CCCC - color of color '3' in 2bpp mode (or color '1' in 1bpp mode)
DDDD - color of color '1' in 2bpp mode
EEEE - color of color '2' in 2bpp mode
JJ   - software palette entry for background
TTTT - selected tile number

[tokumaru]

Yup, sounds as confusing as the SNES to me!

[Hojo_Norem]

The thing to note is with architectures like the C64 and chipmem only Amiga, video bandwidth is ultimately constrained by how much CPU bandwidth you are willing to steal. Of course, the large advantage of such a design is the ability to randomly access the memory the video hardware is currently addressing.

Actually, C64's main RAM bandwidth is insufficient to feed the VIC-II. That's why the C64 has a separate 1024 x 4 SRAM for use as colour attribute memory. It is accessed in parallel to the character pointer data during the badlines.

If you want a fully comprehensive run down on the VIC-II then you can't do much better than look at this document.

Multicolor Bitmap ignores the upper 4 bits, and uses the lower 8 bits to specify one of 16 colors for two of the four shades for each 8x8 region.

All 12 bits are used. In fact, you could say there are 16 bits. 12 bits for three colours come from the tilemap and colourRAM respectively while the fourth colour is defined by the 4 bit background colour register.

Oh, really now? I'm actually surprised to find out that the 68000 in the Amiga 500 only ran at 7.16MHz; flight simulators and whatnot are much smoother on it than the Genesis could hope, unless the advantage of being framebuffer based is actually that large.

While being a framebuffer architecture helps the Amiga a bit, what helps is that the Amiga has a hardware blitter it can use for filling polygons, amongst other things.

[lidnariq]

All 12 bits are used. In fact, you could say there are 16 bits. 12 bits for three colours come from the tilemap and colourRAM respectively while the fourth colour is defined by the 4 bit background colour register.

That makes more sense... it's also not what the c64 wiki says here

[Dwedit]

I hear Amiga can be 5bpp (32 colors) through use of Extra Halfbrite Mode.

[lidnariq]

6bpp. There's a 32-entry palette, and the sixth bitplane can generate 64 colors with extra half-bright mode.

That's also how HAM mode generates 4096-color images: two bitplanes specify what is done with the contents of the bottom four bitplanes. (Set R/G/B or reload all three components from the palette)