Commodores (Was: Teaching kids about computers...)

On Mon, Nov 26, 2007 at 03:45:20PM -0800, Chris M wrote: That's not my recollection... Let's consider a monochrome bitmap for the VIC-II (as opposed to the double- bit 4-color screens, which is just an extension of the simpler case)... Whatever portion of RAM the VIC-II points to to display as a bitmap (there are address bits to twiddle in one of the VIC-II registers), the VIC-II grabs the first byte at that location, let's use $2000, and shoots out 8 pixels (the two possible colors of which are contained elsewhere). If we consider the top left of the screen to be (0,0), then that first byte is (0,0) through (7,0). The next byte ($2001) gets rendered as (0,1) through (7,1). As you said, the order is to fill out an 8x8 character sized block, then move to the next character position, so the ninth byte renders as (8,0) through (8,7), the seventeenth byte comes out as (16,0) through (16,7), etc. 320 bytes later, you are down to (0,8). The only "ascending" thing you might have to worry about is that (0,0) is bit $80 at $2000 (our assumed base address in this example), unless I've mis-remembered, and (0,0) is bit $01 at $2000. You can see the effect of this mapping when you turn on the 'highres' bit in the VIC-II - with a default C-64 configuration, you see the C-64 character map rendered at the top of the screen, then a bunch of random RAM garbage (the character ROM takes precedent over RAM unless you map it out). It's optimized for rendering characters into a 40x25 grid on top of bitmaps, not for rendering raw bitmaps. I found it to be annoying at first, but in the end, as long as the pattern is known, it really doesn't matter what it is. The Apple II also has a strange mapping, but not for character convenience... it's so Woz could save a chip or two on the DRAM refresh circuit. I think it's something like the first 40 bytes render to the first line (7 mono bits per pixel, which _is_ inconvenient), then the next 40 bytes render something like 8 or 16 lines down, and so on. You can see the consequences when switching to a HIRES screen - there's sort of a venetian blind effect as the 6502 zeroes each byte sequentially, but the video hardware renders that in stripes. Having written commercial games for both platforms, the standard way to handle it was to pass an X and Y coordinate to a translation routine (which most commonly used lookup tables for the starting address of each line). Y coords were looked up and turned into a zero-page base address, X coords were divided by 8 or 7 to ignore pixel positions, then turned into an offset from the start of line (more or less, since the C-64 had 320 bytes between the left and right edges), then the remainder from the X calculations was used to figure out which pixels needed tweaked. Between a lack of hardware DIV/MUL, 8-bit offsets on 16-bit pointers, and, from platform to platform, random geometries, the rendering part of any program from the era was a source of much head-scratching and optimization when porting your app to a new platform. Since this was, I think, originally part of the "teach computers to kids" thread, I would like to add that I don't think that the C-64 is a great platform to teach bitmapped graphics on. It's good for character-cell graphics (as is the PET), and Sprites can be interesting (especially since there's such good hardware support for them on the C-64), but I agree that it is convoluted to go from (X, Y) to figuring out which particular byte needs to have its bits twiddled. The Amiga, at least, uses a bit-plane arrangement - much better than bit-stuffing, which, ISTR, VGA still uses. If you want a 320x200x8 color screen, you multiply 320x200 to get 64000 bits - 8000 bytes, then go allocate 3 sets of those and start rendering. If you want 16 colors instead, go get 4 chunks of 8000 bytes and remember to use the extra bitplane. The X*Y math stays the same. -ethan -- Ethan Dicks, A-333-S Current South Pole Weather at 27-Nov-2007 at 01:10 Z South Pole Station PSC 468 Box 400 Temp -25.8 F (-32.1 C) Windchill -48.6 F (-44.8 C) APO AP 96598 Wind 9.3 kts Grid 3 Barometer 681.5 mb (10572 ft) Ethan.Dicks at usap.gov http://penguincentral.com/penguincentral.html