h0trod

The most recent screenshot in the Cribbage thread is two players medium, but interwoven: P0__P1__P0__P1 I think @Karl G is suggesting: P0____P0____P1____P1 which would give more time, but in terms of how far spread apart the cards are would (I think) be the same as I was getting with two players wide interwoven: P0____P1____P0____P1 (as in this screenshot:) @Karl G, if I am misunderstanding you, please let me know. It sounds like my best chance at getting cards close together and having control over Red/Black is the approach you suggest here and @RevEng suggested in the other thread - making the sprites themselves all white, and using the black background for a black card and setting a red playfield under the sprite for a red card. Thanks!

Clever, I will give it a shot. Thanks.

Is anybody aware of any games or sample code that uses "two copies medium" with both players interwoven (as in the six digit score routine) to generate four sprites on a line and assign each of those sprites chosen colors? (See my cribbage squares thread for what I'm trying to do.) My attempts so far have failed and if someone else has managed to do it I'd love to try to figure out their code. If it's just impossible, that's worth knowing too! (I guess I did have the crazy thought that since I only have two possible colors in my case, I could have sixteen different display routines, one for every combination from red red red red to black black black black, and save 12 cycles worth of memory access for color lookups every scanline.. maybe that would give me just enough time, but it seems.. drastic.) Thanks.

I didn't have much luck with using both players and two copies medium. I wasn't able to find enough time in the right places to get the bitmaps loaded, color loaded, bitmap stored to GRPx, and color stored to COLUPx. I don't know all (any) of the tricks, but there is a lot to do in very little time. The best I was able to come up with is using an empty-graphics line between every display line to buy some extra cycles to do some of the pre-display pre-processing for the next line. It's unattractive, and ultimately uses too many scanlines for my purposes anyways. If anyone knows of a game that uses two copies medium with both players to achieve the effect of four different horizontal sprites with arbitrary colors, please let me know, I'd love to dig into it! (I'll probably also ask this in a separate post.) Screenshot of my failure attached, for laughs.

I wanted to see if I could create a four-cards-per-row kernel with enough time to set the correct COLUP1/COLUP2 card colors without having to resort to the VDELP0/VDELP1 tricks of the six line kernel. (I guess this is my first experience "racing the beam", stepping through the Stella debugger keeping track of which clock cycles things get displayed on and how much time I have to do updates.) I don't love the "wide" look, and it's off-center to the right because I needed more time at the beginning of the cycle to prep some data. I could probably rectify this by moving some of the loading to the end of the previous scanline. I think my next experiments will be with "two copies medium" players to get the cards closer together, I expect I will have to resort to VDELP0/VDELP1 tricks to make that work, but we'll see. I've attached the latest version below. cribbage.bin

I am doing a Fisher-Yates shuffle, as you guessed. And it is not my intent to actually create all 52! possible shuffles with my code. I would be happy to understand how to use two random bytes effectively to create 65535 possible shuffles. (And, I'd like to seed the RNG differently every time, I've read about loading from INTIM - is this value not deterministic upon startup?) ShuffleCards: subroutine ldx #51 ; X = offset (card to swap) .keepShuffling: jsr Randomize ; A = Random 0 - 255 and #%00111111 ; A = Random 0 - 63 sta Temp ; Temp = A = Random 0 - 63 cpx Temp ; Compare X (offset for card to swap) to Temp = A = Random 0 - 63. bcc .keepShuffling ; X < Random Number, this is bad, find another random number. ; Otherwise, continue; Temp = Random 0 - 63 <= X lda Deck,X ; A = Card to be swapped out pha ; Top of stack = Card to be swapped out ldy Temp lda Deck,Y ; A = Random Card sta Deck,X ; Store Random Card where card to be swapped out was pla ; Pull Card to be swapped out off of stack sta Deck,Y ; Store Card to be swapped out where the random card was dex ; decremment X bne .keepShuffling ; repeat until x is zero stx DeckOffset ; X = 0, set the DeckOffset to the top card rts As you can see, I use an AND bitmask to go from range of 0-255 to a range of 0-64. I don't understand how to effectively go from 0-65535 to 0-255. The AND bitmask doesn't work, because then I'm just ignoring one of the random bytes wholesale and I'm back to where I started. Should I be combining the two random bytes in some way (EOR?) and then applying the bitmask? Thanks for your thoughts!

I like the idea but I am confused about the details when it comes to using a random value of more than one byte to generate a number between 0-51 for swapping purposes. With a single random byte, I can just use the low six bytes and throw the number away if it's > 51. But generating a multi-byte random number and throwing away all but six bits of one of the bytes does not seem like an improvement. I think there's something fundamental here that I'm not understanding.

After 20 years of thinking about it, I decided it was time I tried to make something. Here's a very ugly but mostly functional prototype of a Cribbage Squares solitaire game. The aim is to arrange 16 playing cards, plus a 17th "starter" card into a 4x4 grid (and starter space) such that the total value of the 8 cribbage hands formed by the horizontal and vertical rows of the grid + the starter card (which is shared by every hand) is as high as possible. Here's a brief description on Wikipedia: https://en.wikipedia.org/wiki/Cribbage_Square_Solitaire The fire button starts the game, and presents you with the first card to place. Use left/right to move the current card in the grid. Use the fire button once you've selected your spot for the card. The starter card goes in the one available slot on the fifth row. When all cards have been placed, your grid will be scored. I think over 100 is pretty darn good. Press fire a couple times to play again. Some development notes: This is my first Atari 2600 code, and my first assembly code of any kind. It's really, really bloated. I worked out the logic and scoring first and then "borrowed" a six digit kernel to use as a display routine to see if I could get something functional. Good: something functions! Bad: I understand the 6 digit display routine in broad strokes, but not enough that I can manage to even center it in the screen. But the biggest problem with this is there's no time to set the P0/P1 colors and make the cards Red/Black appropriately. Is the route to a 4 sprite per line kernel the same approach as six sprite but with each player doubled instead of tripled, or is there another common method I can apply? (Flicker is also an option.) Unexpected source of trouble #1: Joystick debounce logic. This took forever to get right and I still feel like I'm jumping through too many hoops. But it seems to work. Unexpected source of trouble #2: Randomization. I grabbed a common randomization routine and use it to shuffle the cards. I run the "Randomize" routine until the user presses the fire button, and then I shuffle the cards, at which point I need a lot of random numbers consecutively with no opportunity for user input to introduce further randomization. I have a 16 bit randomization routine but currently only using one of the random bytes in the shuffle. I'm not sure how to use a 16 bit random number to help me generate random digits between 0-51 for shuffling? I think this is limiting me to 255 possible sequences of cards that the player could get. Expected source of trouble: There must be an elegant or fast method of scoring Cribbage hands but this ain't it. The timing definitely goes off the rails for a few frames while your score is being calculated. Props to Andrew Davie, SpiceWare, Steven Hugg, and Gustavo Pezzi and the AtariAge community for putting the resources out there that allow a beginner to get started. cribbage.bin

Thanks, and followed!

Thanks Spiceware. Your Collect tutorial has been helpful resource! I have the Stella Programmers Guide - in print, even! - but just missed this bit. RTFM, as always. FWIW, Steven Hugg's book misses this in his discussion of score routines, and in his example program at 8bitworkshop (https://8bitworkshop.com/v3.5.1/?file=examples%2Fscore6.a&platform=vcs)

Thank you kindly. This did the trick!

Hi, I'm working on my first game for the Atari VCS, it's also my first time programming in assembly code of any sort, so it's been a lot of fun. I'm seeing a discrepancy between how the Stella emulator and the 8bitworkshop IDE (javatari) emulator is rendering my code. In my game, I need to display four playing cards in a horizontal row. I figured a good way to get started was to experiment with the 6-sprite (48-pixel) score routine, as explained on the Stella List (https://www.biglist.com/lists/stella/archives/199704/msg00137.html) and in Steven Hugg's book. I think I almost understand it. The hope is that from there, I should be able to work backwards to a four sprite routine. The problem is that the Stella emulator shows improper spacing between the cards / digits. The 8bitworkshop IDE spaces them fine. There's a bit in the code that does a HMOVE for Player1 that looks like it's taking effect on 8bitworkshop, but not in Stella: lda #$10 sta HMP1 sta WSYNC sta HMOVE sta HMCLR If I vary the high nibble of the byte I load into HMP1 on Stella, I see no change [*]. If I vary it on 8bitworkshop, I see P1's horizontal position change as I would expect. Here's the 8bitworkshop rendering: And the Stella rendering: I've extracted just the 6 digit score routine part of my code and attached it here: spacingissue.asm I hope someone can tell me if I'm doing something wrong or one of the emulators is doing something wrong. [*] I got an extreme shift with an extreme value of #$80 in HMP1, but all other values I tried did nothing in Stella.

Every few years I come back around to giving programming the VCS a shot, and that started with Andrew's tutorials. Currently working through "Making Games for the Atari 2600", and was happy to pick up these two to go along with it. Thanks to all involved!

What build of VbB are you using? In older builds sometimes the bin was there just not in the \bin folder. -Jeff I am using build 544. I am pretty sure the bin is not being created, as I did a system wide search for file.bas.bin without finding it. The zero-byte output.txt also seems fishy.

I am also having the problem where file.bas.bin is not found when I try to run. My compiles _do_ complete (according to the output pane), but the only thing generated appears to be a zero-byte "output.txt" file -- no bin. Compiling on the command line (2600bas file.bas) works fine, and does successfully create a bin. I am using XP and my account has administrator privileges. Any ideas?

I've been waiting for a 0.3 release before jumping in too far, so I'd love to get my hands on it. Thanks for your work!