Current status - static starfield complete (NTSC version)

The next big step is turning the Star X,Y into DLL & DL entries and going to a dynamically built DLLs (one for on grid i.e. StarY&7=0) instead of the static DLL & DLs. Once that's done, I'll need to integrate the 4K SpaceWar! 7800 sprite to DL routine.

Sorry if this is a little dense and cryptic. It's mostly for me to remind me of the design decisions which I've made (or remade).

Reviewed old blog entries, found ROM memory map: 2K even star tiles, 22K (236x88) starfield tilemap, 2K odd star tiles, 2K code, 2K sprite graphics, 2K code/data/signature.

Regenerated starfield tilemap & tile graphics from Yale Bright Star Catalog - all stars < 6 magnitude (visible to naked eye) mapped to 236x108 cylindar (avg of NTSC/PAL aspect ratio), trimmed to 88 rows. 236 tiles per row with first 20 tiles duplicated at end for easy wrap-around. 0,0 = bottom left (note: top left used for sprite positions) so StarY&7 is used for CHARBASE & SPRITE LSB offset on last row & sprite Ypos adjustment. Tile map stored with 0,0 at $8800. Quincunx (diagonal) sampling with bit 0 lower left and bit 1 lower middle right (next row middle at bottom middle left, right). 4836 stars in starfield.

StarX is 2 bytes: 0-235 (row offset, two 4-byte DL entries per DL, width=21/20, handle wrap around by SBC & test) and -8 - -1 (Xpos + odd/even)

StarY is 4 bytes (2+2 fractional). MSW is 9 bits (8 * (88-25 = 63 row) + 0-7 raster) stored as signed value for SINE routine, so the MSB is just a sign extend (very useful for the SINE routine). The initial values of StarY[n] and StarY[n-1] will need to be adjusted for PAL to keep the starmap onscreen.

RAM will be primarily consumed by display lists (32 required for PAL). The two DLLs take up 213 bytes so can be stuck in $2100, which will extend into the stack page. That leaves 3.5 K for the display lists. Two possibilities exist. First, three 85 byte DLs per page. That nets 18 sprites per row. Second, allow the DLs to cross page boundaries giving 108-116 bytes per DL (depending on ZP overlap) with 24-26 sprites per row. Each player ship can use up to 4 sprite entries per row + shots. One option is to allow larger DLs for the rows which will contain the score etc.

One important item for display lists, vertical scrolling and vertical wrap around. The current SW display list builder uses a additional DL pointer list entry for bottom to top wrap around. With vertical scrolling, the display list builder works in the same way. However, the bottom display list is basically just a duplicate of the top display list with the StarY & 7 offset! I will have to do some thinking to make sure the vertical shift can't push a sprite off the bottom of the screen.