Now lets get into how these screens are created!

Let's focus on one subbank or one screen set of 64 screens.

Step 1.  draw 64 screens.

I only had to draw half of each screen of course since the end result is mirrored on the Atari.  There are restrictions of course so I can't just draw whatever I want.  Here's the restrictions:

-every screen is composed of chunks... every chunk must be stored in the chunk palette but can be reused many times -reusing chunks is the key to keeping the byte count down

-an entire set of screens with chunk palette must be under 1KB... actually even a tad less than 1KB because of some overhead.

-each screen can only have 15 chunks maximum (the playfield can only be changed up to 15 times per screen)

Breaking any of these restrictions will cause corrupt data and random game crashes/glitches.  I automated all this to make it super easy for the artist (who is me).  My screen bitmaps to code converter app reports if I break one of these constraints.  Here's a report snippet on one bank of good screen data:

004-000: screen= 388 PF= 120 Total= 508 (513 target 5 available)
004-001: screen= 567 PF= 235 Total= 802 (825 target 23 available)
004-002: screen= 546 PF= 317 Total= 863 (881 target 18 available)
004-003: screen= 570 PF= 297 Total= 867 (889 target 22 available)

It reports how many bytes are used by the screens in a subbank and also how many bytes are used on the playfield (chunk palette).  It also attempts to let me know how many bytes are still available in each subbank so I can beef up the screen data up to the limit.

Here is a report snippet on a single screen:

====================================================================
== SCREEN: 15  Chunks:13
====================================================================
.......1.1....................1.1.......[1]
.......111....................111.......[2]
.......111....................111.......
.......1.1....................1.1.......[1]
........................................[4]
........................................
........................................
........................................
.................1.11.1.................[1]
.................111111.................[2]
.................111111.................
.................11..11.................[1]
.................111111.................[3]
.................111111.................
.................111111.................
.................11..11.................[1]
............1.1..111111..1.1............[1]
............111..111111..111............[2]
............111..111111..111............
............1.1..11..11..1.1............[1]
............111..111111..111............[2]
............111..111111..111............
00000001010000000000[01] (04)    screens: 15, 22, 
00000001110000000000[02] (02)    screens: 15, 22, 
00000001010000000000[01] (04)    screens: 15, 22, 
00000000000000000101[01] (10)    screens: 07, 10, 11, 15, 20, 21, 22, 23, 33, 57, 
00000000000000000111[02] (11)    screens: 07, 10, 11, 15, 20, 21, 22, 23, 33, 
00000000000000000110[01] (42)    screens: 07, 10, 11, 15, 17, 20, 21, 22, 23, 26, 33, 34, 36, 44, 47, 
00000000000000000111[03] (11)    screens: 07, 10, 11, 15, 21, 22, 23, 
00000000000000000110[01] (42)    screens: 07, 10, 11, 15, 17, 20, 21, 22, 23, 26, 33, 34, 36, 44, 47, 
00000000000010100111[01] (03)    screens: 11, 15, 20, 
00000000000011100111[02] (11)    screens: 00, 11, 15, 20, 28, 33, 57, 
00000000000010100110[01] (11)    screens: 00, 11, 15, 20, 28, 33, 57, 
00000000000011100111[02] (11)    screens: 00, 11, 15, 20, 28, 33, 57, 

I can see at a glance that this screen has 13 chunks.  In the column to the right of the screen is a number in square brackets.  This is the run length data - how many rows tall the chunk is.

Then I get a report on every chunk that appears in the screen.  The name of a chunk is a string of every bit of playfield data (PF1 and PF2) and how many rows tall the chunk is in square brackets.  Then in round brackets I get a count of how many times this chunk appears in this set of 64 screens.  Finally I can see which other screens this chunk appears in.

Here's another:

====================================================================
== SCREEN: 18  Chunks:11
====================================================================
........................................[9]
........................................
........................................
........................................
........................................
........................................
........................................
........................................
........................................
..............1.1.1..1.1.1..............[2]
..............1.1.1..1.1.1..............
..............11.11..11.11..............[1]
..............1...1..1...1..............[1]
..............1....11....1..............[1]
..............1..........1..............[2]
..............1..........1..............
......1.1.1....1.1....1.1....1.1.1......[1]
......11.11....1.1....1.1....11.11......[1]
......1...1....1.1....1.1....1...1......[1]
.......1.1.....1...11...1.....1.1.......[2]
.......1.1.....1...11...1.....1.1.......
......1...1....1...11...1....1...1......[1]
00000000000000101010[02] (01)    screens: 18, 
00000000000000110110[01] (01)    screens: 18, 
00000000000000100010[01] (01)    screens: 18, 
00000000000000100001[01] (01)    screens: 18, 
00000000000000100000[02] (01)    screens: 18, 
00000010101000010100[01] (01)    screens: 18, 
00000011011000010100[01] (01)    screens: 18, 
00000010001000010100[01] (01)    screens: 18, 
00000001010000010001[02] (01)    screens: 18, 
00000010001000010001[01] (01)    screens: 18, 

This screen has a huge rom footprint!  I had extra space so I made this wasteful screen - the "ghost castle".  I can see there's 10 chunks of non-empty space.  And of those chunks they all appear only in this screen!  So there's no amortized savings in chunk palette space.  The rom cost of this screen then is 11 bytes for the chunk indexes + 10x2.5 bytes for the chunk palette entries = 36 bytes total!  An average screen is less than 16 bytes.

I also get a report on the chunk palette.  Here is a snippet of that.

00000000000000000010[01] (08)    screens: 36, 44, 47, 

00000000000000000011[01] (08)    screens: 06, 14, 34, 36, 47, 
00000000000000000011[02] (02)    screens: 17, 44, 

00000000000000000100[01] (06)    screens: 27, 39, 51, 53, 61, 

00000000000000000101[01] (10)    screens: 07, 10, 11, 15, 20, 21, 22, 23, 33, 57, 

00000000000000000110[01] (42)    screens: 07, 10, 11, 15, 17, 20, 21, 22, 23, 26, 33, 34, 36, 44, 47, 

If I need to trim my byte count I can look at this report and find chunks that are only used in one place.  Then I could modify or delete the wasteful screen.

I needed to improve the quality of some screens so my report generator also puts out a collage of all the screens so I can easily spot screens I don't like and where they are located.