Shamelessly Trying Again...Golf Hack Anyone

[Nukey Shay]

Game kernel altered.  It's using Ram addresses $F0 to $FB for PF0/CTRLPF data (currently undefined) as a placeholder to get the timing right.  You'll need to initialize these Ram addresses.  Upper nybble holds PF0, while the low bit sets mirror or reverse.  The other 3 bits unused.

 

Make sure the display portion LF22E to the end of LF2DE does not cross a page, since WSYNC's have been cut to provide the necessary cycle time.  VDELP0/VDELBL is also enabled so these writes can happen mid-scanline.

 

"Magic numbers" have not been deciphered, so you will end up with weirdness if you try to move or expand data tables (currently).  I haven't looked into that yet.

Golf.asm

[Nukey Shay]

Fairway data separated from swing gfx.  Here, each "band" of playfield is allowed to be any shape (instead of only 4 different types).  These square fairways are just placeholders.  The data tables are constructed via PF0/PF1/PF2.  I've already cut the top band out of Ram, since this band's data is skipped anyway, and Ram can be further streamlined by eliminating the lowest 2 bands (the ball is not allowed to go that low).

 

The status bar still needs to be hacked so that the hole # is allowed to go beyond 9 (hole 10 is the putting green).  Adding the number and variation of obstacles might also be favorable...but since spacing is solely done though the HM register, this may pose a problem there.

Golf.asm

[Nukey Shay]

Expanded to 18 holes...

Rather than use an additional digit in the status bar, I used missile0 to draw the tens digit.

 

6 bytes of Ram saved from PF data (mentioned in previous post).

 

Player and ball boundries edited slightly to keep them within reach of each other.

 

Data table added for object size (NUSIZ).  Problem with multiple copies is that those would be single width, tho (so it's not very useful).  Possible to add object height values if the screen saver color shift is removed.

 

Still haven't figured out this games funky object positioning.  They look to be always taking the previous position into account, so editing them would be a pain in the keester.

 

Golf.asm

Edited September 7, 2019 by Nukey Shay

[Nukey Shay]

Last one for this weekend:

 

Playfield bands can be multiple heights (2, 4, 8, or 16 double scanlines), similar to what was used for Adventure hacks.  Original game used 8's only.  If you use 2's or 4's, you'll have to compensate by making 16's on other bands (for a total of at least 72 in 9 bytes).  It's possible to work around that limitation by increasing the number of bytes used for PF0,PF1,PF2 in Ram.  Or better yet, using indirectY addressing for playfield (I still have some spare cycles to work on that).

 

Objects have a separate color value for each bitmap line...and can be various heights, as well.  Didn't need to eliminate the color shift, but unique B&W values was a casualty.  Updated B&W switch just strips off the hue.

 

Golf.asm

[Nukey Shay]

Playfield using (indirect)Y addressing.

This was easier than I thought.  Now each screen can be composed of as many "bands" as you want.  PF updates are still done via AND against the scanline counter, so each band can be 2, 4, 8, 16, 32, or 64 double scanlines high (the program overrides PF after 72 double scanlines, since that is the lowest the ball may travel to still be "hittable" from any direction).  I didn't make separate data tables this time, since using (indirect)Y makes everything sharable between screens   you can mix and match data tables any way you want to...to make playfield as detailed or sparse as you wish.  And since CTRLPF can be defined whenever you want, this could make some very interesting courses indeed!  Divot fields, just like it began in medieval Scotland. 

 

20 bytes of Ram saved.

 

Golf.asm

Edited September 9, 2019 by Nukey Shay

[Nukey Shay]

BTW the program doesn't absolutely need to only do changes as dictated via AND.  This could be altered very easily to use specific scanline counts instead.  Just change

 

lda (linecount),y

and rB2

 

to be

 

lda (linecount),y

cmp rB2

 

Then you'll need to edit the values in the fairway linecount to be scanline values instead...

Fairway1count:
       .byte 8 ; 0-7 is unhittable area below score
       .byte 13 ;draw first set of PF data until scanline 13
       .byte 20 ;draw second set of PF data until scanline 20
       .byte 37 ;draw third set of PF data until scanline 37
;                etc...

 

In this case, every value used for a screen will need to be sequential...if a lower count # is encountered next, the screen will continue to spill the last data it's been using.

That makes sharing partial data between different screens a little trickier, so I just kept things simple with AND values.

Edited September 9, 2019 by Nukey Shay

[Nukey Shay]

On second thought, using separate tables for each register makes things really messy to create new screens.  I went with using a single vector instead (6 more bytes of Ram saved), using specific scanline counts for changes.

 

Course data imported from the original game for the first 9 holes, but object positioning gets thrown off for hole #9 for some reason.  Need to track that down.  Also, game select can be used to preview screens, but the program currently reverts to hole #1 when you press game Reset (need to fix that so practice screens work).

 

Golf.asm

[Nukey Shay]

Initial object position was incorrect for #9...fixed.

Game select works for practice games now...

Score is reset and the hole # stays the same for practice games.

 

Need to add the option for a 9 hole short game.

 

Golf.asm Temp.bin

[Living Room Arcade]

@Nukey Shay  Thank you for doing this.  

[+Al_Nafuur]

1 hour ago, Living Room Arcade said:

@Nukey Shay  Thank you for doing this.  

😭

 

 

[Living Room Arcade]

8 hours ago, Al_Nafuur said:

😭

 

@Al_Nafuur  I didn't know.  Thank you.  

 

[Living Room Arcade]

To anyone interested in this project, I see what Nukey Shay did.  The game is expanded to 18 holes.  By repeatedly pressing Game Select, it looks like you can practice that hole.  Looks like holes 10-18 need to be completed.  Just form the shape of the fairways and place the obstacles.  Looks like most of the work has already been done.  Would be wonderful if somebody who knows how to hack and code would finish this upgrade of the great and classic Atari 2600 Golf game.  

Edited October 20, 2023 by Living Room Arcade