Zach's Projects

Guess what? This kernel would also be able to do Battleship if you could squeeze one more row in and just ignore 9 columns.

That looks very impressive, but I just can't see how it works! I am clearly missing a trick somewhere, so here are the assumptions that I am making:

• The quickest way to change colours is LDA COL; sta COLxx which is 6 cycles. This is approximately 18 TIA pixels, so I guess your 9 pixel figure is just for the STA bit, assuming that you already have the colour value loaded somehow?
  
• 19 colour changes would require 6*19 = 114 cycles which is clearly too many to fit in a scanline. Does your technique only draw some of the blocks on each scanline?
  
• If you use triple copies of the P0 and P1 sprites, then you have 6 blocks, but this still leaves 13 to be displayed using the PF?
  
• You can display more copies of P0 and P1 using the RESPx trick, but then you wouldn't have time to change the colours?
  
• You will need to use self-modifying code to change the colours between rows regardless of the implementation?
  

Chris

That looks very impressive, but I just can't see how it works!  I am clearly missing a trick somewhere, so here are the assumptions that I am making:

The quickest way to change colours is LDA COL; sta COLxx which is 6 cycles.  This is approximately 18 TIA pixels, so I guess your 9 pixel figure is just for the STA bit, assuming that you already have the colour value loaded somehow?

That's right; the 9 pixel figure is just the STA. It could also be STX or STY, so we have three colors to work with, two for the pieces, and one set to the background color. The A,X, and Y registers can be loaded in the scanlines between pieces, and there is enough time in the HBLANK to change one register between black and the background color. My other board games use the same technique.

19 colour changes would require 6*19 = 114 cycles which is clearly too many to fit in a scanline.  Does your technique only draw some of the blocks on each scanline?

See above.

If you use triple copies of the P0 and P1 sprites, then you have 6 blocks, but this still leaves 13 to be displayed using the PF?

I could have been more clear about this in the first post, but I'm also using missiles. The pieces are represented by:

BK P0 BK P1 BK P0 BK P1 BK P0 BK P1 BK M0 BK M1 BK M0 BK

(In some spots, the missiles and players overlap)

I chose to use BK instead of PF for pieces because I figured the BL might be useful for masking pieces at some point.

You can display more copies of P0 and P1 using the RESPx trick, but then you wouldn't have time to change the colours?

No RESPx trick needed.

You will need to use self-modifying code to change the colours between rows regardless of the implementation?

Exactly. Similar self modifying code is part of my other board game kernels as well. Here is the code for managing 19 pieces, stored in RAM.

   ; start at cycle 15
     stx COLUBK  ; 1st piece
     sty COLUP0  ; 2nd piece
     sty COLUP1  ; 4th
     stx COLUBK  ; 3rd
     sty COLUP0  ; 6th
     stx COLUBK  ; 5th
     sty COLUP1  ; 8th
     sta COLUBK  ; 7th
     sty COLUP0  ; 10th
     stx COLUBK  ; 9th
     sta COLUP1  ; 12th
     stx COLUBK  ; 11th
     sta COLUP0  ; 14th
     stx COLUBK  ; 13th
     sty COLUP1  ; 16th
     stx COLUBK  ; 15th
     stx COLUBK  ; 17th
     sty COLUP0  ; 18th
     stx COLUBK  ; 19th
     jmp BackToStaticCode

That's right; the 9 pixel figure is just the STA. It could also be STX or STY, so we have three colors to work with, two for the pieces, and one set to the background color.

 

I think you actually get four, one of which is somewhat restricted, since the 6507 also has a "SAX" instruction that stores the quantity (A and X) without affecting either register. It might be possible to also use the PF color (so you'd have four colors of pieces plus blank squares) but I don't think that quite works out; you'd have to place different combinations of playfield and objects to yield different combinations of objects (with proper [even fixed] object placement, you could get individual control over the playfield pixels by having sprites cover up half of them on the left and half on the right, but you couldn't then hide the sprites and not have the hidden playfield pixels show through).

I could have been more clear about this in the first post, but I'm also using missiles. The pieces are represented by: BK P0 BK P1 BK P0 BK P1 BK P0 BK P1 BK M0 BK M1 BK M0 BK

(In some spots, the missiles and players overlap)

I chose to use BK instead of PF for pieces because I figured the BL might be useful for masking pieces at some point.

 

Thanks - this makes things much clearer! I had forgotten that you would also have 6 missile sprites to play with. I can now see how you can turn individual pieces on and off, but I am still unsure how the pieces are independently coloured, since it would appear that every stx would have the same colour value in this scheme (i.e. piece 1,3,5,9 etc), or perhaps this is where the overlapping comes in?

 

Chris

Thanks - this makes things much clearer!  I had forgotten that you would also have 6 missile sprites to play with.  I can now see how you can turn individual pieces on and off, but I am still unsure how the pieces are independently coloured, since it would appear that every stx would have the same colour value in this scheme (i.e. piece 1,3,5,9 etc), or perhaps this is where the overlapping comes in?

 

Since the code is stored in RAM, we can set any of the 3 colors for any piece. For example, instead of STX for 1,3,5,9, we could set STY for 1, STX for 3, STA for 5, and STY for 9.

I think you actually get four, one of which is somewhat restricted, since the 6507 also has a "SAX" instruction that stores the quantity (A and X) without affecting either register.

Brilliant! Three player Pente is possible then. It may take some time to work out the best color scheme. Furthermore, I don't think that 128 bytes is enough to store a 19x19 board with four colors and the dynamic code. However, there is nothing wrong with playing Pente on a 17x17 or 15x15 board.

 

(Of course I wouldn't publish a game under Parker Brothers' trademarked name. I'd call it "Pyat!", which is Russian for 5.)

Guess what?  This kernel would also be able to do Battleship if you could squeeze one more row in and just ignore 9 columns.

Do you like this kernel better than the mockup of 10 X's I sent you?

Since the code is stored in RAM, we can set any of the 3 colors for any piece. For example, instead of STX for 1,3,5,9, we could set STY for 1, STX for 3, STA for 5, and STY for 9.

 

Aha - I get it now! There are just 3 colours used, so you simply modify the code to display X, Y, or A as appropriate. Very clever solution ...

 

Chris

Furthermore, I don't think that 128 bytes is enough to store a 19x19 board with four colors and the dynamic code. However, there is nothing wrong with playing Pente on a 17x17 or 15x15 board.

 

A four-color 19x19 board would require an absolute minimum of 90.25 bytes for the board, and you'd need 33 bytes for the self-modifying code and 2 for stack. That's 126 bytes. I guess it might conceivably be workable if you played the right sorts of games (use the RIOT timer for the row counter instead of using a byte of memory; use five bits from the last byte of row data to keep track of the cursor Y position and use one byte to keep track of both cursor X person and the next person to play; use the last byte for user-interface timing and various other purposes.

 

Theoretically possible, but IMHO not worth the effort.

 

A three-color 19x19 board could be handled not-to-inconveniently in 76 bytes of RAM (store five stones per byte via arithmetic coding; store 5 bytes per line). It could be handled less conveniently using 72.2 bytes (store five stones in each byte). Using 36 bytes for the kernel (16x2 store instructions, 1 rts, and three bytes that the ROM would load into the color registers during HBLANK) and 2 for the stack, that would total 111 bytes. Enough left over to handle a reasonable user interface.

 

The kernel would need five 256-byte tables to convert byte values into stone "instructions"; if such tables were used, each row of stones would require about 200 instructions to set up--entirely reasonable. I don't think game logic could very well use the packed values; it would be necessary to pack the data after each player move was selected (during which time the screen is blanked) and then unpack the data when it's the player's turn again.