Jump to content
IGNORED

Kaboom! Deluxe!


SpiceWare

Recommended Posts

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.

post-3056-0-18927800-1548980092.jpg


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.

  • Like 11
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by davyK
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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:

post-3056-0-91905900-1549225185.png

 

in order to hide the HMOVE bars.

post-3056-0-97440600-1549225191.png

 

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

  • Like 3
Link to comment
Share on other sites

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 by Omegamatrix
  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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
Link to comment
Share on other sites

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!

Link to comment
Share on other sites

Noticed a couple more glitches.

 

 

1) As the bombs move past the first bucket they jump right a few pixels for a few frames

post-3056-0-19454900-1549237394.png

 

post-3056-0-31638500-1549237398.png

 

post-3056-0-48949300-1549237404.png

 

 

2) If both paddles are turned fully clockwise the scanline count is correct:

 

post-3056-0-95316600-1549236869_thumb.png

 

but if both paddles are turned fully counter-clockwise the scanline count increases by 1.

post-3056-0-95734600-1549236873_thumb.png

Link to comment
Share on other sites

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 by Thomas Jentzsch
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

  • Like 2
Link to comment
Share on other sites

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).

post-9364-0-95813700-1549337569.png post-9364-0-71533300-1549337577.png

 

And a more crappy tripled standard width sprite:

post-9364-0-32275300-1549337578.png

  • Like 2
Link to comment
Share on other sites

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:

 

post-3056-0-33225500-1549381103.png

 

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:

 

post-3056-0-17345700-1549381107.png

 

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.

 

post-3056-0-90775600-1549381099.png

  • Like 2
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...