Wickeycolumbus #26 Posted March 27, 2009 Just when I thought I could not chop it down much more, I save 12 bytes Archive_3.zip Quote Share this post Link to post Share on other sites
Mord #27 Posted March 28, 2009 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! Quote Share this post Link to post Share on other sites
Nukey Shay #28 Posted March 30, 2009 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 Quote Share this post Link to post Share on other sites
Wickeycolumbus #29 Posted March 30, 2009 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. Quote Share this post Link to post Share on other sites
Wickeycolumbus #30 Posted March 30, 2009 Shaved off a few bytes (15 bytes free now). Still need to try paddles though. Archive_4.zip Quote Share this post Link to post Share on other sites
awace #31 Posted May 8, 2009 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. Quote Share this post Link to post Share on other sites
Nukey Shay #32 Posted May 8, 2009 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. Quote Share this post Link to post Share on other sites
ZylonBane #33 Posted May 8, 2009 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? Quote Share this post Link to post Share on other sites
awace #34 Posted May 12, 2009 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. Quote Share this post Link to post Share on other sites
Wickeycolumbus #35 Posted November 22, 2009 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 Quote Share this post Link to post Share on other sites
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord