8 replies to this topic

[BigO]

Anybody know of a commented disassembly of Casino (or other card game)?
I've looked, but I can't seem to find one. (Can't say I'm surprised.)

I'm curious about various aspects of working with cards on the 2600.

[DEBRO]

BigO, on Wed Apr 25, 2007 12:30 AM, said:

Anybody know of a commented disassembly of Casino (or other card game)?
I've looked, but I can't seem to find one. (Can't say I'm surprised.)

I'm curious about various aspects of working with cards on the 2600.

AFAIK no one has labeled this game. If you're curious about card games on the 2600 then search the [stella] archives for Poker Squares (or Poker Solitaire). I think Brian posted his source there.

[Nukey Shay]

Rough disassembly of Casino.

For card games, it's generally required to store an array of 52 variables. Of course, that would probably be unacceptable with the 2600...even if you broke that amount up to be 6 bits per card (4 bits to hold face value, 2 bits for suit). Therefore, it's easier to set up an array of the maximum number of cards used for any hand, and give card/suit values to them in seperate nybbles. A "shuffle" happens every hand in that case, with a short routine to grab random values and check them against earlier values in the array.

BTW source code for Euchre can also be found at the Stella list.

Attached Files

•  Casino.zip   12.06K   26 downloads

Edited by Nukey Shay, Wed Apr 25, 2007 8:05 AM.

[BigO]

Hey, thanks guys.

I have a pretty compact memory footprint in mind that is specific to the game I'm toying with. I should be able to store the cards and a representation/mapping of a game "field" well within the 128 byte RAM limit. The game play itself shouldn't take much RAM and the logic for the rules seems to fall together nicely with the way I have chosen to represent the cards. If it were not for that pesky need to display the output, this should be a piece of cake.

It remains to be seen whether I can extract the cards from that storage scheme fast enough to actually display them during game play. It also remains to be seen if I can figure a way to display as much stuff as I need to display. Though, I'm assured by an accomplished 2600 game developer that such a kernel can be constructed.


Thanks, Nukey for the jump start. Much appreciated. I really like the use of the paddle controller in those games and think it would fit my game well. (Though, I have delusions of supporting multiple controller types.)

Poker Squares sounds similar to the game on Casino that I've been looking at as something of a model for display purposes. I'll check that out. I'll check out the Euchre code, too. Among other things, I want to see how shuffling and randomization is implemented and how tracking of undealt cards and such is done in other peoples games.


Can someone help me navigate the waters of the stella archives? For example: I find the threads in which the Euchre code was posted, but can't find the actual files, just the tags that indicate where the files had been attached. What blatantly obvious thing am I missing?

Edited by BigO, Wed Apr 25, 2007 10:30 AM.

[Nukey Shay]

I dunno...the archives always display the tags (as you've seen), but also usually include the entire text of the assembly below the post. At least it's doing that for me...as seen here for Euchre:
http://www.biglist.c...7/msg00390.html

...or working tags, like this for Poker Squares:
http://www.biglist.c...1/msg00421.html

Quote

It remains to be seen whether I can extract the cards from that storage scheme fast enough to actually display them during game play.

If you are planning on using an actual deck of 52 cards, something that might speed things up is to store all face values in 1 array (a card in each of the nybbles - 26 bytes of RAM), and all the suits in another array (4 pairs of bits - 13 bytes of RAM). That saves 13 bytes of RAM.

[BigO]

I'll check it again, thanks. I just stopped looking at the point where I saw the dead tags.

Hmm...I'll have to give that storage scheme some thought.

So, you're saying the first nibble of the first location in the values array would be associated with the first two bits of the first location in the suits array; the second nibble of the first values location would be associated with bits 3 & 4 of the first suits location, etc. That makes sense. It's a nice way to pack the bytes. Adds a little bit of overhead to interpret what goes with what, but in case the RAM situation gets ugly, I'll definitely keep that in my bag of tricks.

[supercat]

BigO, on Wed Apr 25, 2007 6:00 PM, said:

So, you're saying the first nibble of the first location in the values array would be associated with the first two bits of the first location in the suits array; the second nibble of the first values location would be associated with bits 3 & 4 of the first suits location, etc. That makes sense. It's a nice way to pack the bytes. Adds a little bit of overhead to interpret what goes with what, but in case the RAM situation gets ugly, I'll definitely keep that in my bag of tricks.

Another thing to consider is that the number of cards remaining to dealt will go down as the number of cards actually dealt goes up, so you may be able to overlap the storage usage.

For example, in a Poker-Squares game, if you use 25 bytes to store the grid of cards (one byte each) and you use the most significant bit of each byte to indicate whether a card is displayed, then you could start out by shuffling 25 cards into the grid but setting the MSB on all of them.

To play the game, move the first card into a 'next card' spot to display it (clear the MSB) and let the user select where it goes. If the user tries to place a card in a non-empty spot, swap that card with the 'next card' spot. If the user plays a card to the empty spot, move the card in the first remaining spot whose MSB is set into the 'next card' spot.

[BigO]

In my 52 byte per deck scenario, I have notes on various ways to utilize the extra 2 bits per byte. "Visible/face up" was one of the options. The cards would all stay in one array, but be rearranged according to plays, and flagged as displayed or not.

Employing Nukey's packed scheme, I could use one more array to store the "show it" bits which would take another 7 (6.5) bytes bringing the total to 26+13+7 = 46 bytes, saving 6 bytes.

In my particular case, a "dealt" bit isn't necessarily beneficial but would certainly be in other games. In that case, you'd end up back at 52 bytes if each card needed both the "Dealt" and "Displayed" attributes. Of the possible 4 states, Undealt+Displayed probably wouldn't be used much.

I'm now wondering if it might be possible to build a self-contained card game core logic/storage library. It'd take a way smarter person than me to figure out a configurable display kernel.

[BigO]

What was that thread I saw the other day about linking 2600's together through their joystick ports? I was going to post the theoretical possibility of 2 player card games. The latency would be of minimal concern. The data transfer requirements could be small: maybe a few bytes per play to share the play to allow the "deck" in the partner 2600 to be updated and subsequently the display generated by that console.

Not terribly practical, I guess, but would allow the uber-geeky to play games that required their hand of cards be kept private...pretty much most multi-player card games, I guess.

If the display could be done, Battleship also might make a good multi-console game.

[EDIT]: For practical purposes, the console that was powered on first could become the "master" if necessary. It could be the source of the shuffled deck initially. A 52+ byte initialization data transfer doesn't seem terribly daunting.

There would also have to be some "chit-chat" going on between units to identify when the other console goes dead or quits playing or whatever. I suppose that could be a very small number of bits just to say "Yes, I'm here". Maybe 2 bits could be used to say either "I'm alive", or "I'm alive and I'm sending some more data following this teensy header packet."

Edited by BigO, Thu Apr 26, 2007 12:17 PM.