azure

A quick update on what I'm working on. I don't have a binary this time. I spent several weeks on an experimental intermission kernel that didn't really pan out. I'll see later if I can reuse it for another game, because I like the strategy. I finished the intermission screen of the ship landing. Afterward, I took a step back from the code. Over the course of the last few weeks I thought about what could be done better. I came up with a bunch of things. Since this is my first game and I know considerably more about the peculiarities of the machine today than I did when I started, there's a bit of questionable code going back to my 1st version. I'm dealing with some design decisions that didn't account for an idle screen. The event flow has to handle being interrupted on the game screens and title screen. I'm working on a new design to redo the flow of game state. I'll be moving kernels around in the banks. The game was bouncing during screen transitions on real hardware, which wasn't showing up on Stella. That's fixed; however, I'm still trying to figure out a strange rendering problem on the play screen. When the dealer has 3 cards the screen expands in height (top and bottom margins). It renders normally when the dealer has any other number of cards. It doesn't happen in Stella--only real hardware. It resembles a timer issue, but that doesn't explain why the top margin expands upward. It's probably an amalgamation of bugs with the timer. It was not happening in older versions. I'm redoing parts of the game to free up more RAM. I can free up about 4 bytes by just being smarter with variables. I'm also redesigning my memory layout to formalize the reuse of temporary memory, because right now it's a bit of a hodgepodge. The layout will follow this format: [global memory] [local memory] [stack memory] Local memory is local to the bank. For example, I have a block of memory (12 bytes) that's not being used efficiently. It's reserved for the graphics of the 2nd split hand. It's only used on one screen, so it should be made available for the other banks. I'm redoing the joystick and switch handling, because it's wasting 2 bytes. It reads the joystick in the vertical blank and then makes its joystick decision making in the overscan. It's all being moved to the overscan to avoid storing state. Finishing these changes will greatly expand what I can do with the features, because I'm a bit boxed in at the moment. I think I should spend some time analyzing the ROM usage as well.

The sprites use blank space above and below their graphics, because it saves cycles on vertical positioning. It lets you move calculations from inside the kernel to outside the kernel, because Y maps directly onto the sprite graphics. It's a trade off between ROM and CPU cycles. As far as I know, it's a commonly known technique. If you look at the HMOVE lines on the left it reveals where the game splits the screen into multiple horizontal bands where the ships reside in. When the enemy ship does its wiggle, it takes up two bands. I think a better Gond could have been made using player graphics, but I don't know the context the game was developed under. I think the most likely explanation is Dave ran out of ROM space. Looking at the ROM as a hex dump, I don't see much blank space other than the buffers between sprites, which was required for using this render technique. These are the trade offs 2600 developers had to make. You can't have everything. It's why the platform is so interesting.

It's half started. I'm working on the sound, so my dev version has some sound already. I'll probably add a flame animation and a casino appearing in the background. I've fixed a few serious bugs in my shuffle task (task logic in general). I was trying to run 2 simultaneous tasks when my design only supported one. It now supports two. I've also fixed the player's score which was temporarily showing the dealer's accumulated score when the dealer is playing. I'm currently trying to fix a small graphics glitch with split hands. The colors flicker a little (similar issue). I've also recovered 2 bytes of RAM, so that resolves an issue with the betting screen message bar where the stack and temporary variables were overlapping.

I just caught the video with Sky Jinks. I've never heard of it. The game looked fantastic with the shadow effect. I like the mix of homebrew and originally released games. When you're done with the Activision series, I hope you mix in some from other game companies. I'm particularly interested in seeing Imagic and Parker Bros games.

I also figure out the problem with the player's score flickering. It's momentarily showing the dealer's current score. I need to re-think and re-work a few things.

I just realized yesterday shuffling is broken, so it will go to black screen when it runs out of cards. I think I know what it is. I'm trying to do two out of band tasks on the same frame, so the shuffling task gets overwritten by a card animation task. I only have 7 tasks, so I'm thinking I can store 2 in a byte to support two simultaneous tasks. TSK_NONE = 0 TSK_DEAL_CARD = 1 TSK_FLIP_CARD = 2 TSK_SHUFFLE = 3 TSK_DEALER_DISCARD = 4 TSK_PLAYER1_DISCARD = 5 TSK_PLAYER2_DISCARD = 6 TaskWork ds.b 1 TaskArg ds.b 1 Hmm, or I can pass the 2nd chained task in the TaskArg. This bug must have been there since I implemented the card flip animation. Version 0.7 or 0.8 I think. Too lazy to check.

There are dozens of us!

Hmm. That's weird, because I did nothing to make sure it works on AFP. I couldn't test on it, because my daughter took my AFP (again), so I'm not sure where it is at the moment. I guess moving some code around made a difference. The intermission code and data filled up some empty space in bank 4, so maybe that had something to do with it. Also, I see what you're saying about the score. I'm not sure what is causing that. I'll look into it.

I'm uploading a new version 0.9. The biggest addition is the intermission screen. It's totally pointless, but I enjoyed working on it. I gained some insights I can use for my other game. It's a work in progress, so I'll be futzing with it more. I intend to reuse it for an idle screen and a game over "Break the Bank" screen that r_type2600 suggested. I also added a timer delay upon the end of a hand to momentary disable joystick input, so that the player has a chance to review the results without accidentally pressing the fire button. This version is not well tested, so there may be screen rolling on real hardware. My intention is to post an update showing what I've been working on. I've not had much time to devote to this lately so development is moving at a snail's pace. Also, I've been playing a lot of Spider Fighter (436,360 points!) and Pilot Wings on SNES. I don't have a flashback portable version, because it's not compiling at the moment and I want to work on more interesting features for now. I have to do some adjustments to the ballast data in order to get it to compile. I'll have an AFP version for the next update. BlackJackThetaVIII-0-9.bin

Anyone notice the chapter links in the first post no longer work? Did the site upgrade break the links? edit: Oh, nevermind. I didn't see the new thread.

Try re-formatting the SD card with this app: https://www.sdcard.org/downloads/formatter/ The portable is very touchy with formatting. My SD card was formatted by Windows and it wasn't working. After re-formatting with the app, it worked fine.

Does anyone know a list of 2600 games that were unbeatable due to bugs or impossible difficulty (such as jumps that cannot be made even if they're flawless)? Not including games with intentional endings (Raiders, ET, etc) or scores rolling over to 0.

I recently picked up a Gemini, but it displays a black screen and produces no audio. I think it's probably the VIC chip (Coleco's version of the TIA), because both video and audio are affected. If not, then could it be something with the RF modulation? I know the power adapter works. I tested it on an Atari 2600. The power input jack was loose so I reflowed the solder on that. The screen goes from static to black screen on power up, so I know something is happening. I have a multimeter but I'm not sure what to look for. I could grab a VIC chip from a ColecoVision expansion module or maybe just get another Gemini. I'd rather reap an expansion module, because they seem to be cheaper and more common than Gemini consoles. My console is very clean and I got it cheap, so I'd like to fix it instead of selling it for parts. Before I buy something I was wondering if there's something else I should check. Maybe capacitors? I looked over the board and chips very closely and saw no oxidation, no breaks in the traces, and no obvious loose parts. I should mention when I got the console it had 3 metal screws bouncing around inside the case. The screws were not from the Gemini, so someone probably dropped them inside the cartridge opening. They would have been bouncing around during shipment and I wonder if the shipper might have shorted something out by plugging it in for test. Got any suggestions? (RF cover removed by me.)

I'm thinking this could be used for making a better Congo Bongo. I feel like there are more possibilities with this.

The 3D effect reminds me of Q*Bert. Hmm.

Just a question, because I'm not familiar with how Twitch works. Will Twitch store all 12 hours of the stream or do you plan to store a full recorded copy locally and upload to Youtube? I may end up missing parts of the stream due to work. It'd be great to be able to catch up on missed parts after the event.

Very nice. This game is going to be fascinating to watch develop.

I don't actually. I'm currently using 100% of RAM. However, it's not at 100% usage all the time. The rendering of the top status bar on the betting screen consumes a bunch of stack space. I was looking into rewriting a few routines for it and flattening the call depth. I have a couple RAM variables that I could do without or pack together. The card dealing and discarded card search has been the most difficult part of the project, because I'm finding it difficult to minimize or eliminate modulo bias without entering into a costly loop. If I spread it across frames, then there could be inconsistent delays, which may give the impression the game is lagging. I think I have a solution, but it's going to require changing the bit packing format for cards, which is going to affect a number of routines. I've already rewritten two discard routines, but I'm having some issues because it's CPU intensive. I get screen bounce when dealing cards above ~65% deck penetration. I'm trying to work out a way to spread more of the logic across video frames, but that requires splitting the search into smaller work tasks, which is not going to be simple, because the algorithm doesn't know in advance where in the search it will begin. I have an out-of-band mechanism for task work, but this particular algorithm is going be more work to divide into smaller tasks, because state needs to be maintained between frames and that requires more RAM, which I don't have at the moment. I could take the easy way out on this and just go with a top down search, but I don't find that appealing. It would bias the deal in favor of Aces, Twos, Threes, etc. A bottom up search would bias in favor Kings, Queens, Jacks, etc.

I knew from the start a card game wouldn't be winning popularity contests. 🤓 I chose Blackjack because I was sorting through some recently purchased 2600 games and found the original Blackjack Atari game. I was extremely underwhelmed, because I knew something much better could have been accomplished even with 4KB and 128 bytes of RAM. I was also watching STNG and had just watched "The Royale" (S2E12). I thought a card game would be a gentle introduction into the 6502 instruction set and Atari 2600 hardware, because I didn't have to deal with 3 or more moving sprites. I was always intending to work on an action game once I understood the hardware better. I didn't want to get discouraged by taking on something too big or too complex as a first game. My first attempt was actually in 2008, but I got sidetracked with a new programming job that took a lot energy out of me, so I didn't have the endurance to spend every waking hour of my day coding. I had been keeping tabs on the site periodically from 2008 to 2018. I recently found my old files for that game, but I don't think it wasn't a very good idea, so I won't be finishing it. You're right about card games being a difficult genre when all the attention goes to the hot action games, but I found enjoyment from thinking about the algorithms and solving problems unique to the 2600. Many of those problems are already solved by others, but going through the process is what's fun. Puzzle fans still love solving puzzles even if they've been solved by others. (See Rubik's Cube.) Arenafoot was also a big motivator. He's given some valuable suggestions and found bugs I wasn't finding. I was struggling to figure out if there should be an ending to the game. I had given it some thought last year and then sort of forgot about it without coming up with anything. I like your suggestion about following along with the plot of the STNG episode and escaping by breaking the bank. I have room in the 4th bank for something like that. It would tie up the loose end of why in the world would a card game be based on a Star Trek episode. 😄 There are the other parts of 2600 game programming I'm itching to work on because they are "unsolved" to me whereas the Blackjack game is in my "solved" file. I will continue working on two simultaneous projects, because I have to take occasional breaks from each project in order to maintain interest. I'm aware of the grandiose promises this community has seen from those who haven't delivered, so I've been holding back on my other plans. Atari 2600 programming is Hard Work, so I can hear the audible sighs when there's more talk than action. However, I think my mistake was not beginning Proton sooner, because I got burned out a little bit back in December and January. I've picked up work on Proton again. I'm trying to figure out this new kernel, so it's interesting. I'm planning for Proton to have Xevious style game play, but with much faster action and some real-time strategy. How that's going to work I'm not so sure yet. I'll probably solicit some ideas once I've got the kernel worked out. My other plan is for a platform shooter I've tentatively titled Cop Justice. It's a Martin Riggs and John McClane inspired character cleaning out the baddies in a building loaded with baddies. Once Blackjack is done I'll be working on both of those. For now I'm working on Blackjack and Proton.

I can see it working as 16 bit sprites. P0 and P1 set adjacent to make a larger sprite. It just needs to keep them in separate layers.

I might steal that. The method I've used with my one and only 2600 game is I have a few sections: Persistent globals: game state that persists between game rounds; reset when powered on or pressing Game Reset Game globals: game state exists only for a single round; reset in a loop Temporary variables: these overlap with the stack Stack: subroutines and some special purpose uses My game global section is reset with a loop: ldx #0 ldy #(MemBlockEnd - MemBlockStart) .Memset stx MemBlockStart,y dey bpl .Memset I make sure to check my subroutine call depth before using some of the temporary variables or before nesting another subroutine call. I've had to refactor a few subroutines, because my call depth was getting a bit too much. My game is not CPU intensive, so I have the luxury using lots of subroutine calls and pushing data onto the stack for a few special cases. I'll probably use the stack more in the future. I like using it.

Just an update on current progress, because its been 2+ months since my last posting. I'm not posting a binary, because it's not ready. Development work really slowed down for a couple months, because of life events and a new job. Now that most of those things are settled, I've been finding more time to finish up my game. I have a few more features completed: Dealer stand or hit on soft 17 (left difficulty switch) Late and early surrender (right difficulty switch) New random number generator using a LFSR (simpler than it sounds) I also worked on a number of internal changes that won't be seen by the player. Reorganizing files, reducing ROM foot print, and reducing CPU cycles. Moved the betting screen to its own kernel Reduced the number of CPU heavy subroutine calls Found modulo bias in my card dealing routine Finding more ROM space in bank 3. In progress: Selecting 1, 2, or 4 decks (game select button). 3 decks might be too difficult or messy to bother with (for reasons). Fixing a bad bug in the card discard logic. Duplicate cards were being dealt. Fixing the bias in my card dealing routine. I may not fully fix it because CPU reasons. My current solution is a compromise. Fixing screen bounce on real hardware Fixing bugs: card dealing, discard, and some edge case bugs Player chips representing actual chip amount A few more animations. I'm deciding on what else I should do with it. I'm hitting the 80/20 part of development. There's lots more I could do, but I also want to wrap it up in the next few months and get to my other game ideas: Battle for Proton (River Raid + Xevious) or a police action game (Lethal Weapon movie + Elevator Action). For this Black Jack game, I'm going to end it with the current feature set. I thought about implementing 6 and 8 decks, statistics, casino loans, and a 2nd player, but I'm shelving those ideas for now. I don't want this to be a multi-year project. One year is enough. I can see myself revisiting the game in the future for a 2nd version or maybe rework it for a different card game. I've also got my Commodore 64 set up with a LCD monitor (4:3), and plan to spend some time learning C64 development and playing some C64 games. I'm somewhat split between my 2600 and C64 interests. I also play SNES and Genesis games, so there's that too.

Can the Harmony or UNO carts create and delete files on the SD card? I'm wondering if a message passing system could be constructed using a Wi-Fi enabled SD card. Messages would be passed as files on the SD card. If the ARM CPU could do message passing to a server, it might be able to relay those messages to a running game on the 2600 by updating RAM variables. The server and ARM CPU would have to periodically poll for message files. The game would periodically read/write RAM variables. If any of that's possible, then I'm thinking a game could do a few things: Trigger a bankswitch that loads a bank with server supplied ROM data to produce longer games. Use server generated content on the fly for playfields, sprites, and game maps. Load the next chapter of a game while maintaining game state variables. Upload high scores and game state to a server. Personalized graphics. How feasible is this with a Harmony or UNO card?

Noticed something in the graphic. That should be 12PM-12AM PT. 12PM is noon and 12AM is midnight. It would be noon to midnight.

This would have made a nice game for the Top Gun movie. Is Danger Zone is referring to the Top Gun song?