Release notes:

Here’s a proof-of-concept demo for a brick-busting game with an unusually generous number of brick colors per row (FIFTEEN!). The kernel would require self-modifying code to allow a changing brick field and thus for all practical purposes would require something like a SuperCharger or M-Network cart, but would support three bouncing balls in a one-line kernel.The colors aren’t really solid colors, but consist of two colors blended on alternate scan lines. On even scan lines, the colors are black, gray, red, and cyan; on odd scan lines they are black, gray, purple, and gold.Presently, the bouncing balls are tracked in a bitmap with one byte for every two scan lines; each byte is Z-zYyXxq where xyz are the enables for the first scan line and XYZare the enables for the second; q is an end-of-data flag. Data are accessed via (zp),y addressing with a constant Y value ($18 for color gold) and must not be too near the start of a page. If the data were kept in zero-page RAM it would be possible to read it via PLA instruction, but it would be necessary to have some blank scan lines between rows of bricks to reload zero-page RAM from somewhere else.Incidentally, I wonder if this kernel–if built into a game–would set the record for the maximum number of TIA register changes per line in a practical kernel (19!)

http://www.atariage.com/forums/index.php?showtopic=82609