+SpiceWare Posted February 2, 2019 Share Posted February 2, 2019 NOTE: Final build is in Sept 25, 2023 Reply In this topic discussion between @davyK and @edladdin made me aware that the 5200 version of Kaboom! features a 3rd gameplay variation known as Pitch and Catch. After some back and forth I decided to utilize @DEBRO's awesome disassembly of Kaboom! (which can be found at MiniDig) to add this variation to the 2600 version of Kaboom! I believe I have this part working, but it's difficult to test by yourself. Let know know what y'all think. NOTE: this is an early build, see top of this post for link to the latest version. NTSC kaboom_deluxe_20190202_NTSC.bin PAL kaboom_deluxe_20190202_PAL.bin PAL60 kaboom_deluxe_20190202_PAL60.bin Changes so far are: Revised kernel to capture both paddles on every frame Revised game #2 to use the correct paddle value when alternating players Added game #3, Pitch and Catch. I plan to add the sunset skyline and colorful Activision logo next, at which point I'll consider this hack finished and post the source. 10 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 2, 2019 Author Share Posted February 2, 2019 I'm aware of these issues: Game 1 - player 2 can move the bomber between rounds, but not while the bombs are dropping. Player 2 should have no control of the bomber during game 1. Game 2 - likewise the other player can move the bomber between rounds, but not while the bombs are dropping. Likewise the other player should have no control of the bomber during game 2. Game 3 - between rounds, while the other player can move the bomber, the bomb he's supposed to be holding does not move with him. Quote Link to comment Share on other sites More sharing options...
TrekMD Posted February 3, 2019 Share Posted February 3, 2019 Cool. Will be testing this out. Quote Link to comment Share on other sites More sharing options...
davyK Posted February 3, 2019 Share Posted February 3, 2019 (edited) Wow - fast work. Will load this up and give it a go!!! EDIT: Just gave it a try. Excellent stuff, See what you mean by the bomb not sticking to the bomber but not sure if it's an issue as the bomb drops from where it is displayed the bucket mover hits the action button, Seems to work great apart from the outstanding items you mention above. Edited February 3, 2019 by davyK Quote Link to comment Share on other sites More sharing options...
Coolcrab Posted February 3, 2019 Share Posted February 3, 2019 This is amazing. Will it be on cart? Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 3, 2019 Author Share Posted February 3, 2019 Seems to work great apart from the outstanding items you mention above. I've already fixed those issues. I've tracked down a disassembly of Crackpots and am looking into the skyline and logo. I suspect I'll do a static logo rather than the scrolling copyright and logo, though I might change my mind. The skyline might take bit more work than I expected as there's only a single graphic image for the mad bomber and the kernel manipulates it on the fly for the frown/smile/surprise. It's possible I can update the skyline just after the sta GRP1 instruction, but the timing is variable due to the manipulation logic, which might corrupt the skyline. DrawMadBomber lda MadBomberColors,x ; 4 eor colorEOR ; 3 and hueMask ; 3 sta WSYNC ; 3 ;-------------------------------------- sta COLUP1 ; 3 = @03 lda MadBomber,x ; 4 cpx #22 ; 2 are we drawing Bomber's upper mouth bne .checkForLowerMouth ; 2� if not check lower mouth lda #%01101100 ; 2 Mad Bomber frown graphic .checkForLowerMouth bcs .drawMadBomber ; 2� lda #%01101100 ; 2 Mad Bomber surprise graphic bit bomberExpressionState ; 3 bmi .drawMadBomber ; 2� lda #%01010100 ; 2 Mad Bomber smile graphic .drawMadBomber sta GRP1 ; 3 dey ; 2 dex ; 2 cpx #21 ; 2 bcs DrawMadBomber ; 2� .colorMadBomberLoop lda MadBomberColors,x ; 4 eor colorEOR ; 3 and hueMask ; 3 cpx #3 ; 2 bne .colorMadBomber ; 2�+1 lda backgroundColor ; 3 sta WSYNC ; 3 If corruption occurs I'll need to clone the current MadBomber graphic: MadBomber .byte $00 ; |........| .byte $00 ; |........| .byte $44 ; |.X...X..| .byte $82 ; |X.....X.| .byte $82 ; |X.....X.| .byte $BA ; |X.XXX.X.| .byte $D6 ; |XX.X.XX.| .byte $BA ; |X.XXX.X.| .byte $D6 ; |XX.X.XX.| .byte $BA ; |X.XXX.X.| .byte $D6 ; |XX.X.XX.| .byte $BA ; |X.XXX.X.| .byte $FE ; |XXXXXXX.| .byte $FE ; |XXXXXXX.| .byte $FE ; |XXXXXXX.| .byte $FE ; |XXXXXXX.| .byte $FE ; |XXXXXXX.| .byte $7C ; |.XXXXX..| .byte $38 ; |..XXX...| .byte $38 ; |..XXX...| .byte $38 ; |..XXX...| .byte $6C ; |.XX.XX..| .byte $54 ; |.X.X.X..| .byte $7C ; |.XXXXX..| .byte $6C ; |.XX.XX..| .byte $EE ; |XXX.XXX.| .byte $FE ; |XXXXXXX.| .byte $D6 ; |XX.X.XX.| .byte $7C ; |.XXXXX..| .byte $7C ; |.XXXXX..| .byte $7C ; |.XXXXX..| .byte $38 ; |..XXX...| to make 3 distinct images. Then I'll need to find some RAM I can use as an image pointer to replace the lda MadBomber,x instruction with lda (MadBomberPtr),y (the X to Y also complicates things) as well as logic outside of the kernel to select an image. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 3, 2019 Author Share Posted February 3, 2019 This is amazing. Will it be on cart? Activision game ROMs are not available in the AtariAge database, so I suspect not. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 3, 2019 Author Share Posted February 3, 2019 Skyline's going to be more complicated than I thought - the playfield is already being used to black out the left & right side of the screen: in order to hide the HMOVE bars. I could use the ball to hide the left side, but that'd require the playfield to be black which would also make the buildings black. The Mad Bomber would not look good against black buildings. I'll need to think on this. In the mean time here's updated builds with the fixes in place: kaboom_deluxe_20190203_NTSC.bin kaboom_deluxe_20190203_PAL.bin kaboom_deluxe_20190203_PAL60.bin 3 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 3, 2019 Share Posted February 3, 2019 How about using P0 for making the sides black? The sprite is not used. 1 Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted February 3, 2019 Share Posted February 3, 2019 (edited) Skyline's going to be more complicated than I thought - the playfield is already being used to black out the left & right side of the screen: I could use the ball to hide the left side, but that'd require the playfield to be black which would also make the buildings black. The Mad Bomber would not look good against black buildings. Consider turning VBLANK on/off to create both borders. The timing would be: - VBLANK off with a write ending on cycle 25 - VBLANK on with a write ending on cycle 73 Edited February 3, 2019 by Omegamatrix 1 Quote Link to comment Share on other sites More sharing options...
davyK Posted February 3, 2019 Share Posted February 3, 2019 (edited) Top stuff. tbh the Rainbow logo would be enough for me! I can see this being a great tournament game at retro events and meets, Edited February 3, 2019 by davyK 1 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 3, 2019 Author Share Posted February 3, 2019 The bombs are player0. VBLANK is an idea, don't think I can do it for the entire display though as kernel timing is particularly tight when the buckets are being drawn (especially since I added code to read both paddles on every frame). If the 25 and 73 line up exactly with the black as it's currently seen then I might be able to use that just the Mad Bomber kernel, then use the current PF0 method for the rest. What I'm leaning towards is to no longer hide the right 8 pixels, and to use a combination of HMOVE bars and the ball to hide the left 8 pixels. If I use HMOVE on every scanline during the MadBomber kernel then the playfield skyline can be any color I want, just have to change it to back to black to hide the HMOVE bars on the lower section. Quote Link to comment Share on other sites More sharing options...
SoundGammon Posted February 3, 2019 Share Posted February 3, 2019 Is there a hack that makes the buckets disappear from top to bottom rather than the other way around? It would give the player a little more space to work with when you're down to your last bucket! 1 Quote Link to comment Share on other sites More sharing options...
davyK Posted February 3, 2019 Share Posted February 3, 2019 (edited) Just noticed a little bug @SpiceWare. Game 1 plays just like Game 2 with the latest ROM you updated, It's a 2 player game instead of a 1 player game. Edited February 3, 2019 by davyK Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 3, 2019 Share Posted February 3, 2019 The bombs are player0. I meant to use it only only in the planned skyline area. Which then would have to be above the top bomb. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 3, 2019 Author Share Posted February 3, 2019 Just noticed a little bug @SpiceWorks. Game 1 plays just like Game 2 with the latest ROM you updated, It's a 2 player game instead of a 1 player game. Hmm, the variable gameSelection holds the game number of 0, 1, or 2. However, bit 7 is used to flag for something which means it's sometimes holding $80, $81, or $82. The switch player routine only checks for zero to see if it should or shouldn't swap players. For some reason it's holding $80, which makes the routine think it's a 2 player game. I need to figure out what bit 7 is used for, where and why it's getting set/cleared, then figure out how my changes conflicted with the usage. As a bandaid I can change it from this: SwitchToOtherPlayer lda gameSelection ; get the game selection beq .skipPlayerDataSwap ; only game 1 (0 internally) is 1 player to this so it ignores bit 7: SwitchToOtherPlayer lda gameSelection ; get the game selection and #$7f beq .skipPlayerDataSwap ; only game 1 (0 internally) is 1 player Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 3, 2019 Author Share Posted February 3, 2019 I meant to use it only only in the planned skyline area. Which then would have to be above the top bomb. Hmm, currently the position of player0 for the bomb is set immediately after the score is drawn, and the position of player1 for the mad bomber is set on the next scanline. To make this change I'd need to reposition player0 in the middle of drawing the Mad Bomber, but as long as I do it after the jagged part of the skyline is drawn I no longer need to use the playfield for the building as the background could just be set to the building color.... Thanks! Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 3, 2019 Author Share Posted February 3, 2019 Noticed a couple more glitches. 1) As the bombs move past the first bucket they jump right a few pixels for a few frames 2) If both paddles are turned fully clockwise the scanline count is correct: but if both paddles are turned fully counter-clockwise the scanline count increases by 1. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 3, 2019 Share Posted February 3, 2019 (edited) Hmm, currently the position of player0 for the bomb is set immediately after the score is drawn, and the position of player1 for the mad bomber is set on the next scanline. To make this change I'd need to reposition player0 in the middle of drawing the Mad Bomber, but as long as I do it after the jagged part of the skyline is drawn I no longer need to use the playfield for the building as the background could just be set to the building color.... Thanks! If you do not want to repos P0 later, maybe you can use both missiles instead. Edited February 4, 2019 by Thomas Jentzsch Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted February 4, 2019 Share Posted February 4, 2019 VBLANK is an idea, don't think I can do it for the entire display though as kernel timing is particularly tight when the buckets are being drawn (especially since I added code to read both paddles on every frame). If the 25 and 73 line up exactly with the black as it's currently seen then I might be able to use that just the Mad Bomber kernel, then use the current PF0 method for the rest. Yes, that was what I was thinking... using VBLANK jiust where the cityscape is drawn. I believe the timing lines up perfectly. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 4, 2019 Author Share Posted February 4, 2019 Noticed a couple more glitches. Tracked down what was causing the line count to increase: .determineBombColor lda bombNumber ; 3 get the current bomb number cmp explodingBombNumber ; 3 skip the explosion random colors bne .skipExplosionColor ; 2� if this is not an exploding bomb lda BucketColors-1,x ; 4 get the bucket colors and hueMask ; 3 <----- B&W mode. Note: no attract mode for the buckets on this path. sta WSYNC ;-------------------------------------- sta COLUP1 ; 3 = @03 lda.w randomSeed ; 4 get the random number sta COLUP0 ; 3 = @10 set the color of the bomb explosion jmp .drawBucket ; 3 .skipExplosionColor lda BucketColors-1,x ; 4 eor colorEOR ; 3 <----- attract mode and hueMask ; 3 <----- B&W mode sta WSYNC ; <----- got here @ cycle 74 with both paddles left The addition of the 2nd paddle reading was sometimes causing that last sta WSYNC to occur on cycle 74, it needs to occur no later than cycle 73. The ero colorEOR is used for attract mode, the color cycling common in older 2600 games. During tests it appears the buckets are never onscreen when the attract mode is active, so I commented out this line which fixed the problem. I also noticed the eor colorEOR is missing from just above the ---- line which seems to confirm it's not needed. Commenting that out also fixed the issue with the bombs jumping to the right as they passed the first bucket. The and hueMask is used for TV Type, it turns the color values to greyscale if set for B&W mode. I'm debating removing both attract mode and B&W mode, neither where common in later games. Also fixed the issue with game #1 acting like game #2. kaboom_deluxe_20190204_NTSC.bin kaboom_deluxe_20190204_PAL.bin kaboom_deluxe_20190204_PAL60.bin 2 Quote Link to comment Share on other sites More sharing options...
KevinMos3 Posted February 5, 2019 Share Posted February 5, 2019 Pardon me for not remembering the rules on sprite widths with doubles or triples, but could you do a double wide (or more) P0 sprite that is repeated (doubled or tripled)? Or are repeated sprites not stretchable... I don't remember. Could you add another HMOVE above where the bomb never appears, to use P0 up there for buildings? Here's a mockup with the sunset being background color changes and the buildings as a triple P0 sprite (double wide). And a more crappy tripled standard width sprite: 2 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 5, 2019 Author Share Posted February 5, 2019 Nice idea! The players can be stretched or duplicated, but not both which is disappointing. As of last night I have a plan of action. While implementing the rainbow logo: I confirmed neither missile nor the ball was used in Kaboom. Player 0's used to draw the bombs, so I can use missile 0 below the score and above the first bomb to hide the right edge of the screen (while using HMOVE bars to hide the left). I only need to use this method while drawing the tops of the buildings. I've already prepositioned missile 0 for this, I turned it on via the debugger for this screenshot: I'll post a build with the rainbow logo later today after I add in the colors for PAL. While the Crackpots disassembly is configureable for PAL and PAL60, it only has the NTSC colors for the logo. I tracked down a PAL ROM for HERO, so I'll be able to get the PAL values from it. 2 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 5, 2019 Author Share Posted February 5, 2019 PAL colors in place, Rainbow logo is finished. ROMS kaboom_deluxe_20190205_NTSC.bin kaboom_deluxe_20190205_PAL.bin kaboom_deluxe_20190205_PAL60.bin 4 Quote Link to comment Share on other sites More sharing options...
Arenafoot Posted February 6, 2019 Share Posted February 6, 2019 PAL colors in place, Rainbow logo is finished. ROMS kaboom_deluxe_20190205_NTSC.bin kaboom_deluxe_20190205_PAL.bin kaboom_deluxe_20190205_PAL60.bin kaboom_deluxe.png I was expecting a rainbow "Spiceware" logo instead of that one Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.