h0trod

I have the Myarc RS232 manual (not scanned), would be happy to take pictures or scan as necessary if anyone wants it. But I can confirm no schematic is included.

Oh man. It was a lot of work for a first timer like me to break up the hand scoring routines in Cribbage Squares so that no single chunk took too long, no matter the hand complexity. I wish I knew this then, I would have happily turned off the screen for a moment ?

sweet, i'll try to tune in!

Presenting, the latest entry in the most exciting genre for your Atari 2600.. solitaire card games.. Cribbage Squares Solitaire! I've been posting about it in the Atari 2600 Programming forum but figured I'd let people over here know. Link to the other thread: Calling this a Beta release, hope you'll check it out and definitely report any bugs you find. Summary rules: You're placing cards in a 4 x 4 grid, to form 8 cribbage hands horizontally and vertically. There's a 17th "starter" space on the fifth row, this card is shared among each of the 8 hands formed by the grid. Try to place the cards to score as many points as possible. Cribbage hands score: 2 points for every combination of cards that adds up to 15. (Aces are 1, face cards are 10, all other cards are face value) 2 points for every pair. (This means three of a kind is 6 points, because there are three distinct "pairs"; similarly 4-of-a-kind is 12 points) 1 point for every card in a run of three or more. (Aces are low only) So: A-2-3 is 3 points. A-2-3-4 is 4 points. A-2-3-4-5 is 5 points. Easy enough. But there's also the hands like A-2-2-3. This is 6 points for the two distinct runs of three (and of course also scores two for the pair). Similarly A-2-2-2-3 is 9 points for the runs (and additionally scores 6 for the 3-of-a-kind). I'll leave 4-5-5-6-6 to the reader. Don't forget your 15s! 4 points for a flush - if every card in a hand except the starter is of the same suit, score 4. If the starter is also the same suit, score 1 extra point for 5 total. 1 point for nobs (AKA "the right jack"). If you hand contains the Jack of the same suit as the Starter card, score one point. Thanks! Cribbage_Squares_beta1.bin

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

Hi Guys, Thanks so much for this tool - currently moving my dev workflow over to it. Hoping to make use of the Sprite Editor to generate data tables for a 64-pixel sprite for use in a 2600 title screen. So far I'm only seeing an option to export to .png - which I guess is for 7800 development? Is there an option to export to .asm data / color tables? Figured it out - I didn't explicitly create a new project, and it must have defaulted to 7800.

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

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.

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.

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

Thanks - it all makes for a really impressive visual!

I love the look of this game. What technique generates a scoreboard like that?

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?

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.

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

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.

Good news: found and fixed the problem that was causing the behavior above. Don't yet understand why it wasn't occurring on Stella. Bad news: fixing this uncovered another bug that is only showing up on real hardware. All these issues are tie back to my game state and debounce logic which is a mess. Won't have a lot of time today but I probably need to focus on cleaning that up next.

What @SpiceWare pointed out was certainly an issue, and fixing it made the game behave with the Developer settings on in Stella; but the game is still behaving improperly on real hardware. The problem appears to be in this code, which executes in the Vertical Blanking period: WaitForFireButtonToStart: jsr IncrementDeckPointer lda #%10000000 bit INPT4 bne VBlankWait lda INPT4 and #$80 sta Debounce lda #0 sta GameStatus GoGame: lda Card ; load Card into A. at game start and after a card has just been placed this should be zero. bne .jumpOut ; if it's not zero we already have a card and can skip all this ldx DeckPointer ; if we don't have a card we execute this code.. get the current deck pointer lda Deck,X ; and get the card at that offset, the "top" card sta Card ; store it in Card, now we have a Card. now we want to put that card in the first open position in the grid. jsr FixMemoryHole ; ldx #0 ; we're going to try positions until we find an empty one starting with 0 .tryAgain lda Grid,X ; Grid,0 is it empty? beq .foundEmpty ; if it is - run the foundEmpty code inx ; if it's not, increment X and try again jmp .tryAgain .foundEmpty ; now we've found an empty slot stx CardPos ; set CardPos = X lda Card ; get the Card back in A sta Grid,X ; and put it in the grid at Grid,X .jumpOut ; if we already have a card we don't have to do any of this stuff! ; the fire button handler should set the Card back to zero, ; and increment CardsPlayed ; END Code to execute in VBlank The symptom is that tapping the fire button flickers the screen as if I'm outputting too many scanlines, but the first card is not played to the board. The same flicker occurs in Stella, and I do see the scan line count momentarily flick higher than 262, but the first card is always played. On real hardware, it usually takes about a half-dozen presses before the game starts, and which point it behaves properly. A hint is that if I hold down the fire button on real hardware (in the WaitForFireButtonToStart code), in the failure case (no card played) the screen will go black and remain black until I release the fire button, but in the success case (card played), the screen will flicker and the card will play. Going to do some trial and error debugging, which is a little painful on real hardware with the setup I have here!

I use BIT to check, but also save the value of the last SWCHA / INPT4 state for debouncing purposes - which is what's causing me trouble. I will have to check on which bits of SWCHA can be trusted as well.

Wow. I'm not sure I ever would have figured this out since I wasn't aware of the Developer settings in Stella or of this behavior of the TIA registers - and within 15 minutes of my post you laid out a comprehensive explanation. Thanks again.

Broke out the Harmony cart today to give this a try on some real hardware: it works, but strangely requires multiple fire button presses before the first card is successfully dealt. After that it proceeds normally until the next game, then, same issue. This doesn't occur on Stella. Should be a fun one to try and figure out.

Small update with a two-copies-medium kernel (thanks @Karl G) and some visual "slots" for cards. Also added up / down controls. Screen shot: Bin: cribbage.bin Next steps: Instead of handling 13 card value (A, 2, 3 .. Q, K) sprites and 4 suit sprites separately, try 52 card (value + suit combined) sprites. This should free up 8 bytes of RAM I'm using for pointers into the suit sprite graphics table at the expense of some ROM, which I can currently spare. Explore the white-sprite over black background/red playfield technique for displaying cards that @RevEng suggested in a comment above. Incorporate @JeffJetton's shuffle alternative also suggested in a comment above. It's not a great game but it's a good learning experience and I appreciate all the help from the community. Maybe as I get better at this, there's a chance of this becoming a full cribbage game in the future.

I like this idea, thanks. The only downside I can see is that currently I can stick the shuffled deck at the end of memory and not really worry if the stack overflows into the end of the deck, because I know I'll only be using the top 17 cards or so (maybe a few more with some variants I'm hoping to add.) With this method I need to be careful none of the cards get clobbered. I'm making some RAM saving changes though and should be able to make it work.

Amazing. Thank you!

Thank you Karl, I would love to see that!