Basketball Disassembly

[DEBRO]

This is my attempt to reverse engineer Al Miller's Basketball.

 

While looking at this, I thought it would be a nice project for aspiring 2600 coders to hack this to have 3D sound where the sound is louder when the player bounces the ball closer to the screen (i.e. lower in the screen given the pseudo 3D perspective) and implement a 3 point shot including a 3 point line.

 

Have fun.

Basketball.zip

[tschak909]

So reading this.

 

DEBRO, btw, have you tried my dodgeball playtests?

 

-Thom

[DEBRO]

So reading this.

 

DEBRO, btw, have you tried my dodgeball playtests?

 

-Thom

I haven't played it. I don't get a lot of play time anymore. I am following the development as best I can. It reminds me of the [stella] days.

[LeChuck]

Cool! I intend to read this soon also. I keep my 2600 set up at work, and we have lots of Basketball games to blow off steam.

 

Any interesting tricks, code magic, or other revelations you got from this?

[DEBRO]

Any interesting tricks, code magic, or other revelations you got from this?

 

I didn't see anything that stood out to me.

[JasperAK]

First post and two-year necro for the win... I can change the player colors in Stella, and everything is fine, but once I change the .bin, player control reverses. I think I am a far way off from a 3pt line. What the heck is going on with the player control?

[Nukey Shay]

Since you didn't post the ACTUAL change you did, best guess is that you altered the last byte of the B&W colors (which this program shares with data table PositionChangeValues:

 

 

GameColorTable
;
; Color Values
;
   .byte PLAYER_1_COLOR
   .byte PLAYER_2_COLOR
   .byte CLOCK_COLOR
   .byte BLACK
;
; B&W values
;
   .byte BLACK + 6
   .byte WHITE + 1
   .byte WHITE
;
; last 1 byte shared with next table so don't cross page boundaries
;
PositionChangeValues
   .byte 0, 1, -1, 0

 

Look for some other byte to cut or increase your rom size to 4k so you can "unshare" this data byte.

[Nukey Shay]

BTW to increase the Rom size of 2k games, relocate the start vector to $FFFC instead of $F7FC

 

2k:

 

   .org ROMTOP + 2048 - 4, 234
   .word Start

 

4k:

 

   .org ROMTOP + 4096 - 4, 234
   .word Start

[JasperAK]

Thank you the quick response Nukey. In the unedited single-player game, the computer is COLUP0 = DA and the player is COLUP1 = 64. In Stella if I change F7F1 from 64 to 30, the player turns to red and retains control with joystick 1. When I edit the .bin with Hack-o-matic at 07F1 and change the DA to 30, it changes the player's character to red, but control switches to the green character. If I select a two player game, the computer controls the green character and the red one is now controlled with joystick 2. If I change either of the color values, this control switch happens.

 

Now I've only been doing this for a week or so, and whenever it looked like the kernel was going to pull a color from the RAM (in this case ram_F3), and there was some sort of glitch, I would just hard code the color I want with Hack-o-matic. I assumed that this byte in memory is being used for multiple purposes. For example, if the assembly is LDA ram_f3 (A5 F3) I would change it to LDA #$30 (A9 30). This worked for the half-dozen or so games I've hacked up to this point; shoot, that's how I changed the color of the fuel gauge in my version of Night_River Raid to a dark green to look like a nighttime instrument cluster. But this simple little 2k game just has me baffled. Any direction to go would help. What am I missing?

Edited November 28, 2018 by JasperAK

[Nukey Shay]

It appears that HOM is doing something screwy with it. Since you can successfully edit the colors in Stella without it going wonky, why not just save the hacked Rom from within Stella?

 

I'd be curious of what a binary compare of Sella's Rom and the one from HOM would reveal.

[JasperAK]

I just tried to use Stella to save the rom by using 'save rom'. It says, 'saved script to rom' but it does not do anything to the rom I loaded and I can't find it in the Stella or ..\appdata\roaming\Stella directories.

 

Whats weird to me it that it seems the program is calling the contents of F7F0 (player 1 color) for something other than just the color. Changing that byte after the main game is loaded seems fine. I just can't track down what it is doing with it. There is only one call to F7F0 and that is at 00D3 with a LDA LF7F0,Y. Tonight I'll trace through the routine there and see what happens to this 64 and why changing it to 44 changes the player control.

[Nukey Shay]

When you enter saverom (no spaces!) in the command window, Stella should report "saved ROM as " followed by the folder and filename. IIRC the saved files are placed in your documents folder (subfolder Stella) by default. I know that older versions of Stella had problems writing Roms (saverom) and disassemblies (savedis) unless you created a file there with the exact name it was trying to save (even an empty text file would work for it to overwrite).

 

A script file is not what you are after. This WILL happen if you put a space between "save" and "rom"

[Nukey Shay]

BTW the problem with saving new roms and disassemblies appears to have been fixed in the current version.

[+stephena]

I also plan to add a file selection dialog at some point, so saving files is more like it works in normal apps.

[Nukey Shay]

I don't mind it being like it is...so original files aren't accidentally overwritten during 24+ hour hacking sessions

[JasperAK]

So I saved the rom correctly and the only difference is the one byte (F0F1) that I changed for P1. P1 control went to P0's sprite in the new rom. Clearly something happens with that byte before I break in with Stella and change it. I just don't know enough to see why. I'm going to trace through the routine in the beginning around 0D3 and see if I see anything. Not really sure what I'm looking for though. Thanks for everything so far.

Edited November 29, 2018 by JasperAK

[DEBRO]

Hi there,

 

I think you are experiencing default values in the Stella emulator if I'm reading this and understanding correctly.

 

Stella uses a hash to recognize games. With this system they can then configure the emulator with these settings.

 

Remember you use the right controller to control the player in a one player game when playing on the console. In Stella, you use the left controller to control the player in a one player game. When you alter the ROM you alter the hash and Stella doesn't recognize the game as Basketball anymore. Now the control scheme reverts back to using the right controller to control the player in a one player game.

[JasperAK]

Thank you DEBRO. That clears that up. But. When I put the hacked game on my Flashback 9, the player controls are reversed. Would there be a way to hard code reversing the controls so that the left controller works for player 1?

[+SpiceWare]

Thank you DEBRO. That clears that up. But. When I put the hacked game on my Flashback 9, the player controls are reversed. Would there be a way to hard code reversing the controls so that the left controller works for player 1?

Took a quick look, due to how it's used it seems like the easiest thing to do is always swap them. Start by changing this section in tia_constants.h.

 

; SWCHA joystick bits:
MOVE_RIGHT        = %01111111
MOVE_LEFT         = %10111111
MOVE_DOWN         = %11011111
MOVE_UP           = %11101111
P0_JOYSTICK_MASK  = %11110000
P1_JOYSTICK_MASK  = %00001111
P0_NO_MOVE        = P0_JOYSTICK_MASK
P1_NO_MOVE        = P1_JOYSTICK_MASK
NO_MOVE           = P0_NO_MOVE | P1_NO_MOVE
P0_HORIZ_MOVE     = MOVE_RIGHT & MOVE_LEFT & P0_NO_MOVE
P0_VERT_MOVE      = MOVE_UP & MOVE_DOWN & P0_NO_MOVE
P1_HORIZ_MOVE     = MOVE_RIGHT & MOVE_LEFT & P1_NO_MOVE
P1_VERT_MOVE      = [(MOVE_UP & MOVE_DOWN) >> 4] & P1_NO_MOVE

---

 

To this:

; SWCHA joystick bits:
MOVE_RIGHT        = %11110111
MOVE_LEFT         = %11111011
MOVE_DOWN         = %11111101
MOVE_UP           = %11111110
P1_JOYSTICK_MASK  = %11110000
P0_JOYSTICK_MASK  = %00001111
P1_NO_MOVE        = P1_JOYSTICK_MASK
P0_NO_MOVE        = P0_JOYSTICK_MASK
NO_MOVE           = P0_NO_MOVE | P1_NO_MOVE
P1_HORIZ_MOVE     = MOVE_RIGHT & MOVE_LEFT & P1_NO_MOVE
P1_VERT_MOVE      = MOVE_UP & MOVE_DOWN & P1_NO_MOVE
P0_HORIZ_MOVE     = MOVE_RIGHT & MOVE_LEFT & P0_NO_MOVE
P0_VERT_MOVE      = [(MOVE_UP & MOVE_DOWN) << 4] & P0_NO_MOVE

---

It seems the original P1_HORIZ_MOVE is incorrect, think that should be:

P1_HORIZ_MOVE     = [(MOVE_RIGHT & MOVE_LEFT) >> 4] & P1_NO_MOVE

---

 

and likewise the new version should be:

P0_HORIZ_MOVE     = [(MOVE_RIGHT & MOVE_LEFT) << 4] & P0_NO_MOVE

---

However it doesn't look like any of the _HORIZ_ or _VERT_ constants were used in Basketball, so doesn't matter if they're incorrect.

 

in Basketball.asm I see this:

.determinePlayerMovement
   ldy playerJumpingValues,x        ; get player jumping value
   bne .determineNextPlayerMovement ; branch if player jumping
   ldy fireButtonDebounceValues,x   ; get fire button debounce value
   bmi .determineNextPlayerMovement ; branch if fire button held down
   lda joystickValue                ; get joystick value
   cpx #0
   bne .setTmpJoystickValue         ; branch if checking player 2
   lsr                              ; shift left port value to lower nybbles
   lsr
   lsr
   lsr
.setTmpJoystickValue

---

changed the bne after cpx to beq (and update comment):

.determinePlayerMovement
   ldy playerJumpingValues,x        ; get player jumping value
   bne .determineNextPlayerMovement ; branch if player jumping
   ldy fireButtonDebounceValues,x   ; get fire button debounce value
   bmi .determineNextPlayerMovement ; branch if fire button held down
   lda joystickValue                ; get joystick value
   cpx #0
   beq .setTmpJoystickValue         ; branch if checking player 1
   lsr                              ; shift left port value to lower nybbles
   lsr
   lsr
   lsr
.setTmpJoystickValue

---

 

After that the firebuttons need to be swapped.

ReadJoystickActionButtonStatus
   ldx #0
.readPlayerFireButton
   lda INPT4,x                      ; read the player's fire button value

---

becomes this:

ReadJoystickActionButtonStatus
   ldx #0
   lda INPT5
   .byte $0c
.readPlayerFireButton
   lda INPT4

---

After that the ROMs too big for 2K:

   .org ROMTOP + 2048 - 4, 234

---

so change it to 4K:

   .org ROMTOP + 4096 - 4, 234

---

 

Search for dgs to find all the changes.

Basketball.zip

[JasperAK]

Wow. Thank you SpiceWare. I had hoped it would be a quick little fix. I bet in the grand scheme of things it is. I have no idea what I'm getting into with programming for the VCS do I?

[+SpiceWare]

You're welcome! It was a quick fix, though I had to reinstall jEdit and such first as I recently did a clean install on my Mac. If you're interested in programming the VCS you may find my tutorial useful - it covers the creation of a 2K game.

 

jEdit's a cross-platform programmer editor I've been using since 2006. This post goes into reasons to use something like jEdit, the biggest being syntax highlighting.

[JasperAK]

I read through your tutorial and bookmarked it. If that site was a real book, I'm sure it will be dog-eared like a mo-fo when I start programming. Heck, I think it would help with flat out hacking. Thank You and everyone else here who is giving back and supporting the community.