meh, i dont like cake unless theres chocolate in it.
anyway i was toying around with some ideas dealing with memory allocation on my video board. despite only having a 32k (dual, 2x32k) frame buffer for raster data, and 16k (really 12k cause i need a line buffer and some space for program use) for backgrounds, ive come to the conclusion that i will have some nice background, forground, and text overlay options.
turns out 8k buys me a set of 128 8x8 pixel characters, with 8bpp. this will come in handy for those highly detailed backgrounds that dont really change a whole lot. to put that in perspective a the screen may display roughly 32x24 characters at any given time, so many of those 128 chars will need to get reused since there is room for 768 characters on the screen. but that was common on 2d backgrounds on almost every major 2d console. im fondly calling this mode pure 8.
i also decided for some oddball reason to support a set of 128 characters at 4bpp. these characters are still 8x8 so no real quality is gained here. it does however allow me to **** with the palettes to create animated background effects, like flickering lights and whatnot. unlike with the pure 8 mode, i now got to store an extra 3k of palette indices, as well as 1k worth of palettes. so i only have 4k to store the set. im calling this pal 4.
and then for situations when you really feel masochistic, im also doing a large number of 4 color palettes. 256 palettes in fact. this frees up some ram so i can also have 256 distinctive sprites. im kinda thinking of halving the number of pallettes and putting that ram to additional characters, but then id need a larger data type to store the character index, and that would actually increase memory usage. this will have the lowest overall quality, however it will allow for the most variation in background objects. this mode will be called pal 2, obviously.
regardless of the character mode, i need to define layers. each cell, which will hold one of those characters, needs 2 bytes of data (or 1 byte in pure 8 mode). the first is an index into the array containing the characters, and the second byte an index of the array containing palettes. thats why the palettes and the character set are closely related. the character doesn't know what its colors are, and a palette is just a list of colors. this essentially connects everything together. background layers in most 2d systems are not tied to the screen at all, in fact they contain much more pixel area than the screen can display. this allows you to offset the background so you can make the backgrounds scroll and move as you play whatever platform game or top down shooter you decide to make. if you have multiple backgrounds you can play wit perspective by scrolling at different rates, for some cool effects. this also takes the most ram, 6k, unless its pure 8 mode (where i can dump the palette index and half the size as a result).
you can also allocate all that memory to either one big background layer, or several smaller layers. seems i can support a max of 3 layers (in addition to the contents of the framebuffer) and still have backgrounds big enough to cover the entire screen. as i said above the minimum size is 32x24, but the 3 layer mode allows backgrounds that are between 32x32 and 42x24. where as using one big layer lets you do something between 32x96 and 128x24 character area. i have 5 modes actually, and each has a number of available resolutions, so im not going to cover every possibility. but i will mention that i can have text overlay with one or two additional layers. my text overlay will be limited to 32x24 chars (these will use a font stored on the "gpu"'s flash and wont use any ram) and wont move, but it will be useful for scoreboards, game time, huds, etc. the available areas to the backgrounds are smaller, but still have a fairly good area to work with.
unfortunately ive used up the entire 12k of free ram on the gpu (aka mcu, an atmega 1284 in a dip 40 package to be precise) and i haven't allocated anything for sprites. no problem, with backgrounds out of the way and the rotating buffer design of the board, i can draw those in the frame buffer pretty quickly. i dont have to wait for any interrupts or anything. when im done drawing i just bring one of the pins high, and wait for another pin to toggle, and the buffers will flip when the gpu has a nanosecond or two to spare. its even theoretically possible i could do some wireframe stuff in 3d. provided the cpu running the show is powerful enough.
should point out i haven't even wrote any code yet. let alone build the board. or prototyped anything. im still waiting on parts. and i dont want to cut any pcbs until ive tested the subsystems in a breadboard. programming it is gonna suck a lot, much of it will be in assembly, a language i am not all to familiar with. this is necessary to keep the timings correct. for example if i need to branch off my code, i will need to make sure both paths take the same number of cycles to complete. i will not have much time on the gpu to do all the stuff that i just said, sicne the thing will be pumping out pixels most of the time. il have to page in a line from the frame buffer every blanking period, where i have the most cpu time available. blending will occur in asm while im piping out pixels. im only using a quarter of the vga resolution (so my screen res is only 160x120) in my frame buffer. so i have an octal latch to hold the inputs of my dac at the last recieved value, so i can go about processing the next pixel. background pixels then frame buffer pixel, followed by forground pixels and text overlay pixels, a max of 4 pixels worth of blending.
tldr: you suck for not reading that!
