Pong 256 Bytes (2600)

[Wickeycolumbus]

Just when I thought I could not chop it down much more, I save 12 bytes

Archive_3.zip

[Mord]

Just when I thought I could not chop it down much more, I save 12 bytes

 

I will not be satisfied until you cut it down to 128 bytes so I can run that bugger from ram!

 

 

[Nukey Shay]

Since it appears that you are interested in adding paddle control...toy around with this. It doesn't save any bytes (other than eliminate the need for a joystick routine), but it's a starting place.

 

The stack pointer is reset to point directly at the ENAM0-ENABL registers (the php's automatically enable the sprite the stack is pointing at by pushing the status register following comparisons, and moves the pointer to the next one). This only takes half of a scanline to determine for all 3, so part of the remaining cycles are used to update paddle reads for both missiles. This also leaves the 8-bit sprites free (so you could use those to hold scores instead of drawing paddles with them). It all fits on single-line resolution with room to spare (and it could be optimized)

 

NOTE: I reversed the scanline count direction to simplify things.

 

       ldy    #0          ;2 reset scanline count
      sty    P0_Y        ;3 and both paddle vals
      sty    P1_Y        ;3
      ldx    #ENAM0      ;2
      txs                ;2 set stack=ENAM0 for 1st scanline
Picture: ;@50
;these are done before the scanline begins
;so that sprite enables don't hit too late...
      tya                ;2 @52
      sec                ;2 @54
      sbc    P0_End      ;3 @57
      ldx    #ENABL      ;2 @59
      and    #$F0        ;2 @61 draw paddle0...
      sta    WSYNC       ;3
;--------------------------- New Scanline
      php                ;3 @3 ...in 16 scanlines
      txs                ;2 @5 set stack=ENABL
      tya                ;2 @7
      eor    Ball_Y      ;3 @10
      php                ;3 @13 draw ball when equal
      tya                ;2 @15
      sec                ;2 @17
      sbc    P1_End      ;3 @20
      and    #$F0        ;2 @22 draw paddle1...
      php                ;3 @25 ...in 16 scanlines
;update locations for next frame...
      lda    INPT0       ;3 @28
      bpl    .save0      ;2 @30/31
      .byte $2C          ;4 @34/--
.save0
      sty    P0_Y        ;3 @--/34
      lda    INPT1       ;3 @37
      bpl    .save1      ;2 @39/40
      .byte $2C          ;4 @43/--
.save1
      sty    P1_Y        ;3 @--/43
;check scanline count & loop
      iny                ;2 @45
      cpy    #SCANLINES  ;2 @47
      bne    Picture     ;2 @49 (50 when looping)
;---------------------------Display done
      ldx    #$FF        ;2 @51
      txs                ;2 @53 reset stack pointer
      inx                ;2 @55
      sta    WSYNC       ;3
      stx    VBLANK      ;3 clear everything...
      stx    ENABL       ;3
      stx    ENAM0       ;3
      stx    ENAM1       ;3
      ldy    #0          ;2
;update paddle locations for next frame...
;using the values created in the kernel
      lda    P0_Y        ;3
      sta    P0_End      ;3
      lda    P1_Y        ;3
      sta    P1_End      ;3

[Wickeycolumbus]

Since it appears that you are interested in adding paddle control...toy around with this. It doesn't save any bytes (other than eliminate the need for a joystick routine), but it's a starting place.

 

The stack pointer is reset to point directly at the ENAM0-ENABL registers (the php's automatically enable the sprite the stack is pointing at by pushing the status register following comparisons, and moves the pointer to the next one). This only takes half of a scanline to determine for all 3, so part of the remaining cycles are used to update paddle reads for both missiles. This also leaves the 8-bit sprites free (so you could use those to hold scores instead of drawing paddles with them). It all fits on single-line resolution with room to spare (and it could be optimized)

 

NOTE: I reversed the scanline count direction to simplify things.

 

Thanks for the tip! I will have to play around with that when I get the time.

[Wickeycolumbus]

Shaved off a few bytes (15 bytes free now). Still need to try paddles though.

Archive_4.zip

[awace]

I cant do that anymore, because I changed the way the ball logic works (see attached source)

 

What he meant was that you can use an unconditional branch instead of a JMP when the status register is known. After an ORA involving a non-zero value, the Z flag would be clear...so you can BNE.

 

In that source, you changed it to load a zero directly...but an unconditional branch can still be used there. Instead of BNE, use it's opposite BEQ. You just loaded a zero, so the flag is set.

is that like a gosub return from a gosub subroutine/ bank switch of a gosub return reoutine??? cool

this was to a youre on youre way to a multi cart essentaly you could just make the same game's varied levels you select with the select switch button as varied so mutch that game 2 is like pacman and game 1 is like pong this way you could write youre own multi cart now that would be cool.

[Nukey Shay]

You could do that regardless. A "menu system" that even allows going back to the menu in-game can be accomplished in only 1 byte of ram to hold the current selection value for up to 128 games + an "enable" bit to flag when the menu is to be displayed. The remainder of ram and rom can be allocated uniquely for each program on the cart, since they all are intended to executed independantly.

 

So why didn't they do this back in the day for new games? Because it's more profitable to sell titles individually.

[ZylonBane]

this was to a youre on youre way to a multi cart essentaly you could just make the same game's varied levels you select with the select switch button as varied so mutch that game 2 is like pacman and game 1 is like pong this way you could write youre own multi cart now that would be cool.

. . .

 

WHAT?

[awace]

Since it appears that you are interested in adding paddle control...toy around with this. It doesn't save any bytes (other than eliminate the need for a joystick routine), but it's a starting place.

 

The stack pointer is reset to point directly at the ENAM0-ENABL registers (the php's automatically enable the sprite the stack is pointing at by pushing the status register following comparisons, and moves the pointer to the next one). This only takes half of a scanline to determine for all 3, so part of the remaining cycles are used to update paddle reads for both missiles. This also leaves the 8-bit sprites free (so you could use those to hold scores instead of drawing paddles with them). It all fits on single-line resolution with room to spare (and it could be optimized)

 

NOTE: I reversed the scanline count direction to simplify things.

 

       ldy    #0          ;2 reset scanline count
      sty    P0_Y        ;3 and both paddle vals
      sty    P1_Y        ;3
      ldx    #ENAM0      ;2
      txs                ;2 set stack=ENAM0 for 1st scanline
Picture: ;@50
;these are done before the scanline begins
;so that sprite enables don't hit too late...
      tya                ;2 @52
      sec                ;2 @54
      sbc    P0_End      ;3 @57
      ldx    #ENABL      ;2 @59
      and    #$F0        ;2 @61 draw paddle0...
      sta    WSYNC       ;3
;--------------------------- New Scanline
      php                ;3 @3 ...in 16 scanlines
      txs                ;2 @5 set stack=ENABL
      tya                ;2 @7
      eor    Ball_Y      ;3 @10
      php                ;3 @13 draw ball when equal
      tya                ;2 @15
      sec                ;2 @17
      sbc    P1_End      ;3 @20
      and    #$F0        ;2 @22 draw paddle1...
      php                ;3 @25 ...in 16 scanlines
;update locations for next frame...
      lda    INPT0       ;3 @28
      bpl    .save0      ;2 @30/31
      .byte $2C          ;4 @34/--
.save0
      sty    P0_Y        ;3 @--/34
      lda    INPT1       ;3 @37
      bpl    .save1      ;2 @39/40
      .byte $2C          ;4 @43/--
.save1
      sty    P1_Y        ;3 @--/43
;check scanline count & loop
      iny                ;2 @45
      cpy    #SCANLINES  ;2 @47
      bne    Picture     ;2 @49 (50 when looping)
;---------------------------Display done
      ldx    #$FF        ;2 @51
      txs                ;2 @53 reset stack pointer
      inx                ;2 @55
      sta    WSYNC       ;3
      stx    VBLANK      ;3 clear everything...
      stx    ENABL       ;3
      stx    ENAM0       ;3
      stx    ENAM1       ;3
      ldy    #0          ;2
;update paddle locations for next frame...
;using the values created in the kernel
      lda    P0_Y        ;3
      sta    P0_End      ;3
      lda    P1_Y        ;3
      sta    P1_End      ;3

Im glad you left the ; comments in the code otherwise i might get lost reading post...

thanks.

[Wickeycolumbus]

I don't think I uploaded this yet, this is the version that has sound. I haven't had the time to try making a paddle controller version yet. Note: this version requires Stella 2.8.4 or later as it is a 256 byte ROM.

Pong256Bytes Sound.bin