cribbage squares solitaire - beta 1

[h0trod]

1 hour ago, stephena said:

Please describe what the problem was in your code, and how you fixed it.  Then we can look into why Stella isn't detecting it, and perhaps fix it so it does.

Will give a full rundown when I have the time to really understand myself what was going on.  The short version is that this code:

CheckP0Fire:   subroutine
  lda #%10000000
  bit INPT4
  bne NoInput
  lda Temp2
  sta Debounce
  lda GameStatus ; $FF = GameNotStarted; $00 = Game Running; $01 = Game Over
  beq .skipRestart
.waitForFireReleaseBeforeRestart
  lda #%10000000
  bit INPT4
  beq .waitForFireReleaseBeforeRestart
  jmp START        ; if we hit fire when the game is over, restart
.skipRestart
  [more code]

was getting into the .waitForFireReleaseBeforeRestart block even in the "Game Not Started" GameStatus because of a bug in the conditional that was only checking for 0, and should have been checking for 0 or $FF.  hacking in a "bmi .skipRestart" after the beq resolved the startup bug.  Why this was problematic on real hardware but not Stella, I'm not sure yet.

 

[+stephena]

OK, no problem.  Feel free to report it here, or to create an issue on Github: https://github.com/stella-emu/stella/issues.  We want to have Stella act like real hardware at all times, to make it easier on developers (because as you're now seeing, doing development strictly on hardware is very time consuming).

[h0trod]

Turning on Developer Options was a little bit of a Pandora's box.  I don't know how some of this stuff ever worked.  For example, I have some equates for doing bit tests:

D0 equ %00000001
D1 equ %00000010
D2 equ %00000100
D3 equ %00001000
D4 equ %00010000

And I was using them to test bits like:

lda ThingToBitTest
bit D0

Of course, what I meant to be doing was:

lda ThingToBitTest
bit #D0

But bit doesn't have immediate mode, so I couldn't do that even if I wanted to.  Anyway, the first thing I was doing there, "bit D0",  was somehow working when developer mode was off. I can only guess that those addresses aren't mapped to anything and Stella just returns the memory location as the memory contents.  This all manifested as a scoring bug when I hadn't touched scoring in a couple weeks.  Fun!

 

My debounce logic was too convoluted for me to follow anymore so I ripped it out and replaced it with something much simpler.  I also consolidated all the button checking into one area, which helped simplify debounce, and consolidated the game status (not started, in play, game over) state setting in one place, and checking that status and branching accordingly in another place.  I now have a version that seems to work fine on real hardware with a Harmony cart.  Now I can get back to trying out some fun things.

 

cribbage.bin

[alex_79]

2 hours ago, h0trod said:

I can only guess that those addresses aren't mapped to anything and Stella just returns the memory location as the memory contents.

 

On real hardware, the undriven bits (0-5) typically keep the last state they were in, that is determined by the last byte that was on the data bus. This is the behavior of Stella with the "Drive unused TIA pins.." option disabled. In zero page addressing mode (which is what you get if you forget the "#" in a constant), the last thing on the bus is the zero page address itself.

So "bit D0" will read from address %00000001, that is register "CXM1P" (from the table posted by Spiceware in a previous post). Bit 7 and 6 depend on the status of that TIA registers, bit 0-5 will keep the value they previously had on bus ("000001").

So, if there aren't collisions, bit 6 and 7 are both 0, and the result of that instruction will be the intended one, even with the missing "#" (and ignoring the fact that "bit" doesn't have an immediate addressing mode) .

 

The problem is that on some very rare occasions, with some console, or some combination of console + cart, one or more of those undriven bits might behave differently from the typical case and constantly read "0" or "1" when undriven, no matter what the last value on the bus was.

This occurs so rarely, that many games (original from back in the day and homebrews) have those bugs.

 

The developer option in Stella helps identifying the bug as it returns random values for bits 0-5, ignoring the bus state.
This doesn't represent a real-world scenario (no real console would behave exactly like that), but in this case the point is to make the bug more evident rather than represent the typical behavior.

 

[+stephena]

Programming the 2600 is fun, isn't it ?

[h0trod]

Which look do you prefer?  The first is colored player graphics over a white playfield, the second is white player graphics over a black background for black cards, and over a red playfield for red cards.  The rounded (lol) corners of the cards let the red playfield peek through for red cards, but I don't think it looks too bad.

 

1)

2)

 

PS. I know the "club" graphic is awful.

[+SpiceWare]

I'd treat the top and bottom of the card as a special case and hard code it to use black and %10000001 for the graphics. See last row for mockup.

 

[+fdr4prez]

call me old fashioned, but I like the green background and the square cards.

[h0trod]

1 hour ago, SpiceWare said:

I'd treat the top and bottom of the card as a special case and hard code it to use black and %10000001 for the graphics. See last row for mockup.

 

My plan was to just not enable the red playfield on the first and last lines as a special case, but I screwed up and used a non-reflected asymmetric playfield and ended up having to load / clear all three PF registers and didn't have enough time to handle special cases.  When I rework it for reflected and only have to deal with PF2 I think I can make this improvement.  But it sounds like you're suggesting something different using the player graphics?

 

 

[+SpiceWare]

Looking at your posted build with debug colors turned on:

 

 

 

I assume your notched card graphics are done using the players (shown in red and yellow) like this:

 

 

Keep doing that - but set the player colors on the first and last row of each card to the same color as the background.

[h0trod]

Latest version attached.  I think this is getting about to where I'm happy with the basic version of the game.  I will polish it up with some version of getting rid of the red bleed on the corners of the cards, and I think I'd like a nicer, bolder score display.  Maybe play with some simple tick sounds for moving and placing cards, and a visual flourish and happy sound for a good score.  Also, right now the space between rows is only defined by how many clock cycles it happens to take to process everything to get ready for the next row, and this can change during game play causing a row to visually shift up or down a row.  I'd like to fix that, and also break up the scoring algorithm over a series of frames to fix the flash or roll the user will see at the end of the game when the scoring runs.

 

From a gameplay standpoint, I'd like to implement a variation with one or two "recycle piles" where the player can temporarily store up to three cards.  The user can play the top card off the deck, or the top card off the recycle pile.  This variation tilts the game more towards skill than luck.

 

cribbage.bin

 

 

[Arenafoot]

On 6/23/2020 at 5:05 PM, h0trod said:

Which look do you prefer?  The first is colored player graphics over a white playfield, the second is white player graphics over a black background for black cards, and over a red playfield for red cards.  The rounded (lol) corners of the cards let the red playfield peek through for red cards, but I don't think it looks too bad.

 

1)

2)

 

PS. I know the "club" graphic is awful.

I vote #1 ..... looks just like Blackjack Theta VIII background. And its the tradtional casino felt green too!

 

 

 

 

[Prizrak]

Latest version attached.  I think this is getting about to where I'm happy with the basic version of the game.  I will polish it up with some version of getting rid of the red bleed on the corners of the cards, and I think I'd like a nicer, bolder score display.  Maybe play with some simple tick sounds for moving and placing cards, and a visual flourish and happy sound for a good score.  Also, right now the space between rows is only defined by how many clock cycles it happens to take to process everything to get ready for the next row, and this can change during game play causing a row to visually shift up or down a row.  I'd like to fix that, and also break up the scoring algorithm over a series of frames to fix the flash or roll the user will see at the end of the game when the scoring runs.
 
From a gameplay standpoint, I'd like to implement a variation with one or two "recycle piles" where the player can temporarily store up to three cards.  The user can play the top card off the deck, or the top card off the recycle pile.  This variation tilts the game more towards skill than luck.
 
cribbage.bin
 
 

What would your preferred method of naming would you like for your "versions" of Cribbage. Every release has the same title and I've been uploading them to PlusCart and I'm having to give them like a 1,2,34 type naming to let them know which one is the latest. How would you prefer to name them?

Sent from my SM-N960U using Tapatalk

[CapitanClassic]

2 hours ago, Prizrak said:

What would your preferred method of naming would you like for your "versions" of Cribbage. Every release has the same title and I've been uploading them to PlusCart and I'm having to give them like a 1,2,34 type naming to let them know which one is the latest. How would you prefer to name them?

Sent from my SM-N960U using Tapatalk
 

I have always had a preference for UTC date stamp. That way you know exactly which version was the latest version and exactly when it was released.

 

cribbage_2020_06_25.bin

[Arenafoot]

1 hour ago, CapitanClassic said:

I have always had a preference for UTC date stamp. That way you know exactly which version was the latest version and exactly when it was released.

 

cribbage_2020_06_25.bin

I change them this ^ when I download the ROM so I know which one is the newest.

 

 

 

[h0trod]

8 hours ago, Prizrak said:

What would your preferred method of naming would you like for your "versions" of Cribbage. Every release has the same title and I've been uploading them to PlusCart and I'm having to give them like a 1,2,34 type naming to let them know which one is the latest. How would you prefer to name them?

Sent from my SM-N960U using Tapatalk
 

I never really considered that anyone would be saving these, I consider them throwaway snapshots just to give anyone who wants to a look at snapshot of a work in progress.  If there is no metadata associated with them other than the file name you should probably have cribbage squares or cribbage solitaire in the name, to distinguish between this game and the two-player card game it is based on.  Going forward I will post builds with unique version numbers.  Thanks for trying out the game.

[+ZeroPage Homebrew]

11 hours ago, CapitanClassic said:

I have always had a preference for UTC date stamp. That way you know exactly which version was the latest version and exactly when it was released.

 

cribbage_2020_06_25.bin

It may be overkill but I put every .bin in their own directory along with any pdf/txt instructions or code files released along with the build. This not only preserves the original naming by the uploader for historical purposes but also allows me to verify which version I downloaded against another one I might run across at a later date.

So this last release would be put in a directory: "Cribbage 20200623 (h0trod)" which is under a directory "Cribbage (h0trod)", which has five builds now (20200608, 20200611, 20200617, 20200620, 20200623). I changed over to adding the name of the developer to the main directory entry when TWO(!) Tower of Rubbles came out around the same time. So I have  directories of "Tower of Rubble (Dionoid)" and "Tower of Rubble (mksmith)" and all the various builds of each game in those directories.

 

So my homebrew structure is:

 

Atari 2600 Homebrew

   |--- Game (DevName)

      |--- Game YYYYMMDD (DevName)

           |--- originalgamename.bin

 

- James

Edited June 26, 2020 by ZeroPage Homebrew

[+SpiceWare]

On 6/23/2020 at 5:05 PM, h0trod said:

Which look do you prefer?  The first is colored player graphics over a white playfield, the second is white player graphics over a black background for black cards, and over a red playfield for red cards.

 

 

Suggestion - let the player decide this at run time. Use the TV Type switch:

• Color = Green background
• B&W = Black background

[h0trod]

7 minutes ago, SpiceWare said:

 

 

Suggestion - let the player decide this at run time. Use the TV Type switch:

• Color = Green background
• B&W = Black background

Not sure this is possible with my current implementation as the white parts of the cards are P0 and P1, the black portion (for spades and clubs) is just unaltered background, and the red portion (for hearts and diamonds) is red playfield graphics underneath the white card.  Spades and clubs would be green.  I will have to check and see if it's feasible to have two different playfield colors under the player graphics.  This would mean the playfield graphics would no longer have to be asymmetric, I would just have to change the colors with correct timing.

[+Karl G]

I also like the green background version, but I think they both work just fine. Just go with what appeals to you best. ?

[+SpiceWare]

1 hour ago, h0trod said:

Not sure this is possible with my current implementation as the white parts of the cards are P0 and P1, the black portion (for spades and clubs) is just unaltered background, and the red portion (for hearts and diamonds) is red playfield graphics underneath the white card.

 

Ah, I see you changed it:

 

 

If you don't turn on the playfield for the first and last scanline of the cards then you won't get the red notches in the corners.

[JeffJetton]

On 6/26/2020 at 10:03 AM, Karl G said:

I also like the green background version, but I think they both work just fine. Just go with what appeals to you best. ?

 

Another vote for green. Maybe gray if you want to give a B&W choice.

 

But having playing cards on a black background just seems... idiomatically incorrect for a VCS game. (Didn't Atari have a policy against black backgrounds for anything that wasn't a space game?)

[h0trod]

Very small update.  Couldn't bring myself to look at the code for a while - hopefully I've got a little productive time in me before that happens again.

 

Good: This build fixes the over-scanline (screen flashing / rolling) issue during scoring, after the last card is placed.  

 

Bad: This is done by breaking up the scoring over (8 hands * 5 parts) = 40 frames, which means it's over a second from the time you place the last card until scoring is complete and displayed.  Additionally, the reset game logic is going to need some tweaks because currently pressing fire while your score is being calculated will start a new game.  Finally, there's still an over-scanline issue when starting a new game with the fire button.

 

cribbage2020_11_30.bin

 

Quick fix for the striken-through issue above, in the updated build below.

 

cribbage_2020_11_30-2.bin

Edited December 1, 2020 by h0trod
quick fix, new build

[h0trod]

Going to call this a Beta.  There's very little I plan to change before I call this done - just want to root out any remaining bugs.  I have tested with Stella and on a 2600jr with a Harmony cart.  If anyone would care to take a look on any other hardware combinations I'd appreciate it.

• All scanlines > 262 conditions have been fixed.  Should be a solid 262 lines throughout.
• Fixed "card creep", where rows of cards would shift down by a scanline or two as you placed them due to additional processing required to display them.
• Added a title screen.
• Fixed all the bugs that were caused as a result of fixing the above ?
• You would not even believe the spaghetti-ness of this code.  Truly next-level.

The only functional changes I have in mind before release are some bigger, nicer digits to display the score, and reset button handling.

 

Also, if anyone knows of someone in the community that is talented with label design and accepts commissions please send their names my way.  Probably just going to make a cart for myself to hold in my hand and say "I did this!"  (I know there's a label-designer site out there, but I have no art / design skills.)

 

Cribbage_Squares_beta1.bin