3 ms·

Great video. Is there any reason why the color cells had to be split into an even grid? It seems like if the API allowed the software developers to define cust

Great video. Is there any reason why the color cells had to be split into an even grid? It seems like if the API allowed the software developers to define custom grids on the fly (perhaps with different scenes or levels), it would open up lots of creativity (though I suppose that would also use some memory).

timbit42 11y ago
The cells were split into an even grid because that's how the video chip was designed. There was no other grid size and no customization. There was no room on the silicon to do other grid sizes. There is no graphics API in the Commodore 64. You programmed the hardware directly in assembly. If you wanted an API you wrote it yourself.
egypturnash 11y ago
The c64's default video mode was a 40x24 grid of 8x8 monospaced text characters. The video chip was designed around this: each scanline it would look at the characters occupying the current row, then use that plus how many times it'd displayed that row as an index into the 1k of character ROM to pull out the appropriate byte, and display its individual bits as pixels. You could also tell the video chip to look somewhere in RAM for these character definitions. Maybe just to replace the standard font with something cooler; maybe some of your font would contain little 8x8 building blocks you could use to make bigger images. Most games would build their backgrounds this way - you'd only have so much variation available, but you also only had to move about 900 bytes around to scroll the screen, rather than 8k. Which sounds like nothing to a modern machine but was a serious difference for a 1mhz computer. The bitmap mode jiggled with this a little, and ignored the 'look at the characters on this row' part in favor of just stepping through an 8k chunk of RAM over the course of the display. (Well, the multicolor bitmap mode looked at the characters in the row as well, but used them for color data rather than an index to the character map.) If you want to know about this in more detail then try firing up a c64 emulator and going through the 'graphics' chapter of the c64 Programmer's Reference Guide: http://www.commodore.ca/manuals/c64_programmers_reference/c64-programmers_reference_guide-03-programming_graphics.pdf http://www.commodore.ca/manuals/c64_programmers_reference/c6... I'm not sure the acronym "API" even existed at this point in time. I sure never heard it when I was fooling around with 6502 assembly. tl;dr: severely limited hardware, programmed right on the bare metal. API? What's that?
- panic 11y ago
  The video chip was designed around this: each scanline it would look at the characters occupying the current row, then use that plus how many times it'd displayed that row as an index into the 1k of character ROM to pull out the appropriate byte, and display its individual bits as pixels. The C64 reads the current characters every 8 scanlines, not each scanline (well, you can get it to read on arbitrary scanlines by manipulating the vertical scroll register, but that's beside the point here). Due to the way the C64's data bus works, the main processor has to stop executing instructions while the graphics chip reads the character data. You have to account for this if you're trying to synchronize code to particular scanlines -- on the scanlines where character data is read, you'll only get 23 cycles instead of the usual 63 (on a PAL machine, at least). For even more info, see http://www.zimmers.net/cbmpics/cbm/c64/vic-ii.txt http://www.zimmers.net/cbmpics/cbm/c64/vic-ii.txt
  - egypturnash 11y ago
    Yeah, I should have been more clear on that. I didn't feel like explaining the care and feeding of badlines. grin

timbit42 11y ago

The cells were split into an even grid because that's how the video chip was designed. There was no other grid size and no customization. There was no room on the silicon to do other grid sizes. There is no graphics API in the Commodore 64. You programmed the hardware directly in assembly. If you wanted an API you wrote it yourself.

egypturnash 11y ago

The c64's default video mode was a 40x24 grid of 8x8 monospaced text characters. The video chip was designed around this: each scanline it would look at the characters occupying the current row, then use that plus how many times it'd displayed that row as an index into the 1k of character ROM to pull out the appropriate byte, and display its individual bits as pixels. You could also tell the video chip to look somewhere in RAM for these character definitions. Maybe just to replace the standard font with something cooler; maybe some of your font would contain little 8x8 building blocks you could use to make bigger images. Most games would build their backgrounds this way - you'd only have so much variation available, but you also only had to move about 900 bytes around to scroll the screen, rather than 8k. Which sounds like nothing to a modern machine but was a serious difference for a 1mhz computer. The bitmap mode jiggled with this a little, and ignored the 'look at the characters on this row' part in favor of just stepping through an 8k chunk of RAM over the course of the display. (Well, the multicolor bitmap mode looked at the characters in the row as well, but used them for color data rather than an index to the character map.) If you want to know about this in more detail then try firing up a c64 emulator and going through the 'graphics' chapter of the c64 Programmer's Reference Guide: http://www.commodore.ca/manuals/c64_programmers_reference/c64-programmers_reference_guide-03-programming_graphics.pdf http://www.commodore.ca/manuals/c64_programmers_reference/c6... I'm not sure the acronym "API" even existed at this point in time. I sure never heard it when I was fooling around with 6502 assembly. tl;dr: severely limited hardware, programmed right on the bare metal. API? What's that?

panic 11y ago
The video chip was designed around this: each scanline it would look at the characters occupying the current row, then use that plus how many times it'd displayed that row as an index into the 1k of character ROM to pull out the appropriate byte, and display its individual bits as pixels. The C64 reads the current characters every 8 scanlines, not each scanline (well, you can get it to read on arbitrary scanlines by manipulating the vertical scroll register, but that's beside the point here). Due to the way the C64's data bus works, the main processor has to stop executing instructions while the graphics chip reads the character data. You have to account for this if you're trying to synchronize code to particular scanlines -- on the scanlines where character data is read, you'll only get 23 cycles instead of the usual 63 (on a PAL machine, at least). For even more info, see http://www.zimmers.net/cbmpics/cbm/c64/vic-ii.txt http://www.zimmers.net/cbmpics/cbm/c64/vic-ii.txt
- egypturnash 11y ago
  Yeah, I should have been more clear on that. I didn't feel like explaining the care and feeding of badlines. grin