2600 in 2006

Very nice!

Can anyone explain how this works?

It looks like a variant of the Video Chess kernel. Is there more to it than that?

It looks like a variant of the Video Chess kernel. Is there more to it than that?

 

It uses some similar principes, but there's a lot more to it. The video chess kernel only has to do three writes after the first item appears, so if desired everything could be loaded into A, X, and Y or A, X, and S. The timing might be workable to include the color changes while showing five items on a line instead of four; I've not worked out whether that can be done without self-modifying code. My guess is that it could probably be done without too much difficulty if no space was left for the board's dividing lines. Providing for those, however, would probably require that the two colors be chosen such that, when ANDed together, they yielded zero.

 

In this Sudoku kernel demo, the spacing of the sprites is a bit wider than with the chess kernel, and there are no color restrictions. My next challenge is to make it work without having to use the playfield to hide some 'extra' sprites.

In this Sudoku kernel demo, the spacing of the sprites is a bit wider than with the chess kernel, and there are no color restrictions. My next challenge is to make it work without having to use the playfield to hide some 'extra' sprites.

I see. There are apparently 40 pixels between sprites. (I assume P0 and P1 are staggered.) That strongly suggests that you are using the multisprite trick. The 40 pixels give you about 13 cycles to update the TIA. Since there are at most five numerals per line, you can easily set the first two, and then maybe update the colors and shapes like so:

 

Let A, X, and Y be the shapes of the remaining three pieces.

sta GRP0; 3	
lda color3 ; 6
sta COLUP0 ; 9
sta.w RESP0; 13

stx GRP1  
lda color4 
sta COLUP1
sta.w RESP1

sty GRP0
lda color5
sta COLOP0
sta.w RESP0

I see. There are apparently 40 pixels between sprites...

 

The sprites on a line are 24 pixels apart. You are correct about using the multisprite (Galaxians) trick. The digits are 6 pixels wide for the same reason that the Galaxians in formation are. I got the thing to work without any "extra" sprites appearing, but the code bloated. I then shaved a few cycles back off so I could un-bloat the code. The present code stores the grid using 54 bytes. I think I'll rework it to use the top 5 bits of 81 bytes, since I have some plans for the other three bits. Too bad the 6507 can't handle 9-bit bytes--it would make some things so much more convenient.