Berry Fun! (New 2600 home brew) [WIP]

[+littaum]

Berry Fun!

 

 

Current Version (Last updated 5/21/2023):

Latest WIP Build [NTSC]:  Beta 4     BerryFun![Beta4][NTSC].bin

Latest WIP Build [PAL60]:  Beta 4    BerryFun![Beta4][PAL60].bin

Instructions:    Beta 4                     Berry Fun! Beta 4 Documentation.pdf    

                        

 

Older Versions (for posterity, recommended to use latest version!)

Spoiler

 

Latest WIP Build [NTSC]:  Beta 1    BerryFun![Beta1][NTSC].bin

Latest WIP Build [PAL60]:  Beta 1   BerryFun![Beta1][PAL60].bin

Instructions:  Beta 1                      Berry Fun! Beta 1 Documentation.pdf     

 

Latest WIP Build [NTSC]:   Beta 2         BerryFun![Beta2][NTSC].bin

Latest WIP Build [PAL60]:  Beta 2         BerryFun![Beta2][PAL60].bin

Instructions:                     Beta 2         Berry Fun! Beta 2 Documentation.pdf      

 

Latest WIP Build [NTSC]:   Beta 3         BerryFun![Beta3][NTSC].bin

Latest WIP Build [PAL60]:  Beta 3         BerryFun![Beta3][PAL60].bin

Instructions:                     Beta 3         Berry Fun! Beta 3 Documentation.pdf 

 

Farmer McDonald is trying out the new Accu-Pick 2600, the latest in automated strawberry pickers.  It can detect how many ripe berries are available for picking and move to them, but the machine's 8-bit processor doesn't have enough clock cycles left over to actually pick them.  So he's leaving it up to you to pick his crop!  Pick the ripe berries, but leave the unripe and rotten berries alone.  And be quick about it!  Farmer McDonald will grow more impatient with each row, giving you less time to pick but offering more money per pick.  Make as much money as you can before you either run out of extra chances (either due to berries that are not ripe or not making a pick when you need to) or complete all of the available rows.  Either 1 person can play by themselves, or 2 players can play at the same time to pick the yummy strawberries together! 

 

Farming has never been so fun!  You might even say it is now ... Berry Fun! 

 

Berry Fun! is my latest home brew project for the Atari 2600 (the first being ElectroBall).  This is an 8K (F8 bankswitch) game programmed in 6502 assembly.  I have a few projects in various stages of early development, including one with me messing about with changing the missile sprite over a few scan lines to make it "sprite-ish" looking.  After starting to read Oscar Toledo G's book "Programming Games for Atari 2600", some of the game examples in the book using non-sprites to make sprite-ish results gave me some further inspiration to make it into a fully featured game.  

 

In my practice program, the missile object looked a bit like a target reticle, so this would point towards the game being some kind of "shooter".  But what kind?  Then I thought of the NES game "Hogan's Alley" and how the way I played it was to hold the light gun up to the screen to shoot the targets (or avoid the "don't shoot" targets) at point blank range.  OK, so the game will be a "shoot some things, don't shoot other things" type of game, with some kind of time limit on making those decisions.  As to what objects to shoot and what to avoid, I was inspired by KevKelly's sequence of "work games" - so why not make the game about picking fruit?  After all, everyone loves games about food!  Based on my limited artistic ability, I decided to make the focal point about strawberries.  Pick the ripe strawberries, but avoid the unripe or rotten berries.

 

One of the advantages of the Atari 2600 hardware capabilities is its color palette and it's ability to display copies of the same sprite on the same scan line.  So I used those to have the game feature a 9x9 grid of selectable objects.  But I would need to learn how to properly re-use the same sprite object in a different X-position on a different scan line.  Fortunately I was able to learn how it was done by looking at some of Dennis Debro's excellent annotated source codes of classic 2600 games (Several of them are here, by Dennis and several other contributors).  I also tried my hand at the "HMOVE every line" to remove the blank repositioning lines at the left side of the screen (and the weird timing related issues if you issue sta HMCLR too early), as well as the Yar's Revenge-esque tactic of using actual source code as data values for the playfield, allowing the "dirt" background to have some additional texture (and to change the dirt pattern between locations!)

 

I originally strived to make this a 4K game, but despite my continued gains in code efficiency and space savings it was not to be.  So I expanded it into an 8K game and added a lot of "embellishments".  I have about 1K left over for possible future work or added "flair".  Everything can be controlled by a joystick, making it "Couch Compliant" (but the select switch can be used to go back to the main menu when playing a game, select game options when at the title menu, and the reset switch can be used to start the game from the title screen or re-start the game during game play).

 

I've made both a NTSC and PAL60 version - I am in NTSC land and simulated the PAL60 colors via Stella - hopefully the PAL60 colors look sufficiently lifelike!

 

I've attached instructions, but the rules are pretty simple.  Move the joystick around to select 1 of 9 locations (not moving the joystick at all puts the target reticle in the center).  Then press the fire button to pick the current location.  If you pick a ripe strawberry, you get paid for the pick.  If you pick a rotten or unripe strawberry, you lose an extra chance.  On later levels if you fail to make a pick at all during your time limit you also lose an extra chance.  Later levels also cut the amount you make per pick if over half the current time for the location has elapsed.  Make a mistake with no extra chances left and it is game over.  As you progress through each round, the value per pick goes up but the time per location to pick decreases.  By row 12 it gets really hectic.  So far my best score is $45.76 (see snapshot for proof you can get to the end.  ).  The best earnings you can get in "Play" mode is 50 cents, and the best theoretical earnings you can get in "Work" mode is $99.99.  

 

 

A second player can jump in at any time with a second joystick and two players can play at the same time, contributing towards a common score.  There is a "play" mode which has the longest available time to pick, only ripe strawberries for picking and no penalty for not making a pick.  Great for practicing or just to chill.  The regular game is "work" mode where the chance to make money is significantly greater, but you are penalized for mistakes and the game can end early.  The game also keeps track of the high score during the current play session.

 

I've tested the game on Stella, the javatari.org web emulator and via harmony cart on my Atari 7800 (where my high score screenshot comes from).  The last thing I struggled with was making sure I had enough time in the Overscan and Vertical Blank sections for all of the possible game logic combinations.  If you give it a try let me know if you see any cases of screen rolling during play (this seemed to be what happened when one of the Overscan/Vertical Blank locations exceeded its allotted time).  My allocations in each section can run right up to the limit in some cases and if goes over -- the screen rolls (hopefully I have that fixed!)

 

As of beta 4, the game officially supports SaveKey/AtariVox+ high score saving and can upload your highscore with a PlusCart enabled system (either through Stella emulator or with a PlusCart).  

 

Youtube video of game in action:   

 

 

 

[+Philsan]

Very nice, it reminds me wack-a-mole games.

 

Colors on my PAL machine are like Stella emulator.

Image is not centered, like your photo.

 

When I died at row 06, screen started rolling in black and white.

Without doing anything, after 15 seconds color returned, for few seconds screen moved a little bit to the left and to the right and then returned normal.

[LatchKeyKid]

It may seem like an odd comment but I like the background/playfield.  What made you decide on such an abstract pattern?  Is it always repeating or does it change?  I'll be trying it out tomorrow.

[+littaum]

14 hours ago, LatchKeyKid said:

It may seem like an odd comment but I like the background/playfield.  What made you decide on such an abstract pattern?  Is it always repeating or does it change?  I'll be trying it out tomorrow.

 

It was the source code that decided on the actual background/playfield texture. I essentially feed the PF0/PF1/PF2 source code "gibberish" to populate the playfield, taking care to randomize the positioning of the gibberish after each movement.   Howard Scott Warshaw talked about this technique in his book for making the shimmering field in Yars' Revenge.  I always thought it would be a good technique for making a generalized textured background.

 

In the source code, variable Temp1 contains a random number between 0 and 63.  I then load the memory address of one of my source code locations, add the random number to it and store the end result in an array.  When I need to randomize the appearance, I just generate a new random number and assign it to Temp1.

 

lda <#Main+#40

clc

adc Temp1

sta PF2Array

 

lda >#Main

sta PF2Array+1

[+littaum]

On 3/26/2023 at 11:43 AM, Philsan said:

Very nice, it reminds me wack-a-mole games.

[Snip]

When I died at row 06, screen started rolling in black and white.

Without doing anything, after 15 seconds color returned, for few seconds screen moved a little bit to the left and to the right and then returned normal.

 

Thank you for the feedback and additional testing - Beta 2 is now posted in the first message with improvements to stability (shuffled some things around from the Vertical Blank to the OverScan where I still had some extra clock cycles).  I also slightly darkened the dirt color in PAL60 to more closely match what I see on NTSC.  In addition, I also did some small rebalancing of the early levels so that they go slightly quicker and in the process managed to have the theoretical best score max out the counter.

 

You are also correct that there's a strong Whac-A-Mole vibe to the game - something I did not pick up on when designing it.  

[Arenafoot]

On 3/29/2023 at 10:34 AM, littaum said:

 

Thank you for the feedback and additional testing - Beta 2 is now posted in the first message with improvements to stability (shuffled some things around from the Vertical Blank to the OverScan where I still had some extra clock cycles). 

And just in time for our local Ponchatoula Strawberry Festival in mid-April!!!!  https://www.lastrawberryfestival.com/

 

 

[+ZeroPage Homebrew]

ZeroPage Homebrew is playing Berry Fun! on tomorrow's ZPH stream LIVE on Twitch, hope you can join us!

 

Mon Apr 3, 2023 | LIVE @ 6PM PT | 9PM ET | 1AM GMT

WATCH LIVE: https://www.twitch.tv/zeropagehomebrew/
WATCH LATER: https://youtube.com/zeropagehomebrew/

 

Games:

• Space Taxi (2023 WIP | 2600) by Jeff Haber @Just Jeff
• Berry Fun! (2023 WIP | 2600) by Mike Littau @littaum
• Beyond Parsec (2023 WIP | 2600) by Grocer Games / Kevin Kelley @KevKelley
• Carrot Kingdom (2021 | 2600) by Joseph Nesbella @Jinroh

 (WATCH AT 1080P60 FOR BEST QUALITY)

 

 

[+SpiceWare]

in case you have the space, I have some keyboard routines here:

 

Quote

Here's where I figured out how to read the joystick and the keypad. Each key on the keypad will change the background color, while the directions on the joystick will change the playfield color(the narrow bars in the screen shot).

 

[Thomas Jentzsch]

Another idea for a variation: Instead of always going for the ripe berries, the player has to go for the berry type of the one displayed in the center. 

[+littaum]

Thanks to ZPH for playing the game on their stream - based on the gameplay I'm pretty happy with the rate of difficulty progression.  Not surprising that you ran into stability issues, I have not quite ironed out all possible pathways of the functions during Vertical Blank/Overscan.  But I did recently learn you can insert a break in stella if your scanlines exceed your desired rate (breakif _scan>#262) which is helping figuring out where they come from - and I'm storing the vertical blank and overscan time remaining (lda INTIM -> sta testvar) before the final wait loop so I can get an idea of how much idle time I have remaining at various points in the game.

 

@SpiceWare thanks for the sample code on keypad controls - since this is also a learning exercise for me I'll at least come up with a variation where keypad controls are used, even if it is an offshoot version.  And if I can figure out how to auto-detect they keypad (or have the player press a specific keypad button to be able to notify the program that a keypad is plugged in) then perhaps both controllers can be supported.    But I think Tap-A-Mole is the grand shining example of this type of game with keypad controls.

@Thomas Jentzsch I have been thinking about possible "bonus rounds" and that sounds like an interesting idea.

 

Other things I plan on doing:

1. Make sure it is a stable 262 lines at all times.

2. Add in SaveKey support.  I've actually done that already thanks to past postings on the subject, but I am using "Scratchpad" space at the moment for testing.  I've put in a request to reserve some space (even though I only need 2 bytes!)

3. Try to have the ripe/unrotten berries appear 3 in a row some times.  At present it is limited to 1 or 2 each time.  

[+littaum]

I've updated the ROM with beta 3 versions and instructions.  I am hoping I've slayed the instability beast this time.  I've been logging the INTIM time in vertical blank and overscan and store the lowest value seen in each across the various planning and playing phases.  So far the lowest the vertical blank INTIM value goes is 2 (64 clock intervals) and the lowest the overscan INTIM value goes is 1 (64 clock intervals).  I typically have a lot more cycles left but due to various routines taking various amounts of time depending on how the various berries are distributed on the screen it can change wildly.  When I used up more clock cycles in one of these two phases than allotted that is when the screen rolls happened.  Using debugging feature breakif _scan>#262 in Stella has also helped see issues, and I had a debug-only stress test mode where I disable the loss of extra chances (so that it really is impossible to end the game early) but make the joystick input random so the game played over and over, and with 2 hours of Stella in turbo mode I did not see the scan lines exceed 262 once.   Lots of rebalancing between vertical blank and overscan in this version, as well as a few function optimizations.

 

Also included in this beta 3 version:

 

*  "Technically" supported the SaveKey.  I read from an attached SaveKey from scratchpad ($3000 address, marked in the list as for test use) and write to the same location after a high score (the screen is blank for 1 frame between the "End of Day" screen and title screen), but the actual variable in the game written is a temporary variable.  This is a long winded explanation for it tests out the read and save functions in SaveKey, but doesn't actually save the high score yet.  Once my request for a SaveKey address is answered and once I get the game to a "completed" state I will change the values so that the high score is actually saved.  If you have a SaveKey and can test it, that would be great - it doesn't actually save the high score yet, but at the moment I'm just looking to make sure it doesn't freak out at the title screen or end of day screen when you have it plugged in.  I tried it with my AtariVox on my Atari 7800 where I actually saved the high score and did not see any issues. 

*  There are now some opportunities where the rotten/unripe berries will appear 3 in a row.  Previously it was limited to 1 or 2.  Most people probably did not see that, but I did, and it was a nice to have for me.

*  The distribution of berries should be a lot more randomized from the start.

 

If you've played the game before, hopefully the main thing you see is that it doesn't roll anymore.  If you do see screen rolls or other instability, please let me know!

 

I have a little less than 100 bytes in bank 0 and about 800 bytes in bank 1.  At this point it's not so much ROM space as it is CPU space to do things in a given frame.  I did look at the keypad code from the sample program, and the having to sleep for 1908 total cycles to read the keypad overall is .. daunting. I have not given up on the idea of having a keypad mode, but it would likely take a lot more optimization (or some distribution of the reads throughout frame?  Admittedly I have not spent a lot of study time on mastering the keypad programming).  Still also thinking about possible bonus rounds or other modes of play.   At least now with my debug/stress test compiler options I have an easier way of testing to see if my changes cause screen rolls.

 

My plan is to have this game "complete" by the end of the year, and am looking into the "stretch goals" of keypad support and bonus rounds.

 

[+littaum]

Hi all!

 

I have updated my first post with my latest beta version of Berry Fun! (beta 4).  I'm really leaning into the "high score" aspect, as this version adds official SaveKey/AtariVox+ support for saving of high scores, and the game will be available on the PlusCart(+) when it is uploaded to the ROMs section (thanks to @Albert for reserving me a memory slot for SaveKey, and a big thanks to @Al_Nafuur for helping me figure out how to add the pointer reference to the PlusCart and setting things up on the PlusROM website (my game's leaderboard is here -- it is even formatted as a cash leaderboard!).  Thanks to ZPH for letting me use their cover art from their stream for the PlusROM image.  For posterity's sake, this is how I set up the pointer to the PlusROM in my 8K/F8 bankswitching scheme (Bank 0 was not touched, and I only had to modify the very end of my code in Bank 1 to accommodate it - the last section is literally the last parts of my code):

 

;===============================================================================

; BANK 0

;===============================================================================

    SEG Code

    ORG $8000

    RORG $1000

 

    ;ending vectors for bank 0

    ORG  $8ff8

    RORG $1ff8

    ds 4, 0

    .word $1000      ; RESET

    .word 0          ; BRK

 

;===============================================================================

; BANK 1

;===============================================================================

    SEG Code

    ORG $9000

    RORG $3000

 

PlusROM_API:

   .byte "a", 0, "h.firmaplus.de", 0

 

  ;protect PlusROM hotspots

 

    ORG  $9ff0

    RORG $3ff0

    .byte 0,0,0,$ff  ; Set ReceivedBufferSize to initial $ff

                     ; At startup on a device with PlusROM support

                     ; "lda ReceivedBufferSize" will read $00

                     ; a device without support will read the value in ROM $ff

 

   ;ending vectors

    ORG  $9ff4   ;was $9ff8

    RORG $3ff4  ;was $3ff8

    ds 6, 0        ;was ds 4, 0

 

    .word (PlusROM_API - $2000 + $1000) ; NMI (PlusROM API offset from ROM-start + $1000)

    .word $3000      ; RESET

    .word 0          ; BRK

 

 

I've decided not to try and include keypad support for this game, mainly for clock cycle timing reasons.  A lot of the game would be able to handle the delays needed to read each part of the keypad, but some of them (particular in transitions and "next patch of berries" setup) would not.  In some cases by the time I get to the end of the frame I'm down to 1 or 2 idle scan lines left, and that's simply not enough.  I'd have to come up with a system to stop reading in the keypad in this case, which could lead to the player wondering why the keypad isn't always responsive (perhaps it's the OCD part of me, but I like being able to move the target reticule around at all points of the game).   And even then I'm not sure I could catch all corner cases to prevent screen rolls due to going over my cycle budget.  I do have an idea for a keypad-based game that isn't quite so computation heavy so the sample code will still come into play.

 

I also thought about bonus rounds or mixing up what you pick, but am having trouble coming up with something that fits into the "story" of the game.  In my headcanon for this game, it could have conceivably been something commissioned by a farmer's association back in 1983 as a way to try to make toiling in the hot sun picking berries appealing to teenagers hooked on the video game "fad".  After all, there was also a video game about Dog Food!   I also wanted a game somewhat based on reality.  From this guide, picking unripe strawberries is no good, because they will not ripen after being picked.  You always want to pick them when they are bright red and ripe.   For diseased or blemished strawberries, you are indeed supposed to prune them off, but definitely not supposed to pick ripe and rotten berries at the same time - putting them into the same batch could ruin them all and during the game the implication is anything you pick goes in the same location (which is why picking unripe or rotten berries is a bad idea!).   So any sort of bonus round would have to deal with pruning rotten berries, and that would be kind of a icky end to the game.  After all, we're supposed to be tricking 1983 teenagers into thinking toiling in the hot sun could be fun.  One could change the bonus round or the entire game to be about picking other objects, but then it's no longer a game about picking fruit but of cleaning up some farmer's dirt field of randomly strewn objects.  And that's certainly not going to trick 1983 teenagers into working the fields.  

 

Please give it a try and let me know if you find any bugs or screen jumps or issues with saving of high scores or if you have issues getting your high scores sent to the PlusCart leaderboard.  Once I can confirm that no more bugs or screen rolls exist, I'll mark it as complete later this year.  I'll also be providing the "complete" version for the PlusROM website.