I have read several articles and sincerely admired ANTIC (and POKEY too) from a distance for many years, but I never found room on my bedroom desk for Atari hardware (it was already covered with Apple ][+ and Commodore 64 hardware). Display lists seem like a very flexible and elegant way to handle text and graphics.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

I think there's a couple of ways in which thinking of bandwidth can be quite useful
- the bandwidth needed from RAM to keep the video system working
- the bandwidth needed from the CPU to RAM to update (enough of) a full frame in good time

Sprite hardware helps with the second, as it's a cheap way to animate the visible pixels without moving data around. DMA might help too, or indeed a blitter.

Another approach is to offer tile-based graphics. The CPU updates tiles or indices and the video system pulls together the visible frame.

To some extent I feel that sprites and tiles both tend to push game design in certain directions, but they are a good way to get more from less.

Sprite and tile hardware can also help with bandwidth because the sprite and tile image data can easily be stored in separate banks of RAM... if you can afford it!

Good point! One way to look at bandwidth is as the product of bus width and bus transfer rate. So, if you can use a wider bus, or more busses, you get more for a given transfer rate.

Another useful idea is decoupling. If two systems have to run in lockstep, or if they have to use the same bus widths, that can be a limitation. It can be useful for the video system to access memory with a wider bus than the CPU does, or to run at a different speed. Ideas above about posting writes into a buffer can be seen as decoupling too - decoupling the write-as-requested from the write-as-performed.

Yep, I was just reading a doc about the VIC-II that outlined how no matter the mode, it made the exact same memory accesses - very clever for cost saving and simplifying the chip, with the side effect that graphics mode was laid out just like character mode.

The 40 column limit was always a pain, I was jealous of other systems with an 80 column mode. I ended up writing an 80 column emulator in assembly that used hi-res graphics mode and split each 8x8 cell into two 4x8 characters. With an effective width of only three pixels for each character (leaving space in between the chars) it was just barely readable. But, I could at least log onto BBSes that assumed 80 columns and get some readable output.



That certainly makes sense! I have built some very minimal breadboard 6502 designs with 2 line LCDs, but regardless don't have much plans for graphics. I'd love to have 80 column VGA output, and some kind of command line OS.

I'm just fascinated with the different ways video was accomplished in the old systems!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I can imagine that cost may have been an issue ... or maybe a very tight schedule, or both. Woz (undoubtedly working under similar constraints) created some eccentric magic on the Apple ][ video generator in 1977 using off-the-shelf ICs, but his circuits required even more software contortions. Still, the Apple ][ easily had the most featureful display of the '77 trinity, and he was kind enough to provide optimized firmware routines to deal with the frustrating quirks of the display map, so the casual user didn't need to resort to tons of POKEs as was the case with the VIC-20 and C64.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)