Just Jeff

Oh.. I see now I misunderstood his question somewhat. Sorry about that! Thanks SpiceWare..

woops.. removed.

Thank you.. good question.. Well Its using the playfield, player 0 and player 1 to make the blocks so we can store 3 colors before the beam gets anywhere. Then, registers a,x, and y are loaded up with 3 more colors. Still plenty of time and only 2 colors to go. In fact, we waste10 or 12 cycles to let the beam get far enough along, then do the stores, and load, store, load, store for the last 2. The score is actually a 48 pixel display with the last zero being drawn with 2 moving missiles. Makes sense?

Here's the version from the show with scoring and progress bar, and the show link. https://www.youtube.com/watch?v=o8GXX6gJK20 .bin attached main.asm.bin

Block Party is friggin awesome.

That's a pretty good idea I think... Jeremy and I will discuss it. Not a difficult task at all. That's a contender! There has been much progress. We even had a conference call to discuss project status/strategy. We're knocking items off the grid or at least reducing them to the point that they are column 2 or 3 level items. The game is more playable and the project grid is less formidable. New .bin attached. main.asm.bin

Hello! JeremiahK and I have been working hard at this Atari 2600 version of Bejeweled and its coming along nicely. The attached version is partially playable, no scoring or game over yet. If you are not familiar with the game its pretty straight forward. Switch two blocks to make runs of three or more blocks of the same color. When you do, the blocks disappear and new ones fall in from the top. Tip: On this version, to switch blocks, select one by pressing and holding the fire button on the first block, then point the joystick to the other tile that you want to switch it with. Bin attached.. Enjoy! BBlocks.bin

Latest bin attached below. Now you can switch two tiles. Hold down the fire button, then hit a joystick direction. It will switch those two tiles. No validation yet so you just go around switching tiles. Summary looks good overall. I'm inclined to make one player, one game version for now, fancy later though. And I think we hammered out the Gravity mode a little differently- right? Move Mode: As I've written some of this, it has occurred to me that I have potentially valuable data when its done. I know the coordinates of the two tiles that were switched. This would reduce the Match Mode requirements from 16 rows and columns to 3 in this case- either 2 rows and one column, or 1 row and 2 columns if it could be passed to the routine. The routine could return a true/false back to me so I know it has to be switched back. Maybe that could be worked in there somehow? I dunno. What do you think? Doing all 16 rows and columns every time may be too simple to pass up though, and more importantly, if it does have to do all 16 sometimes, it might have to be able to do it all the time for timing purposes. That said, I think I lean towards just checking it all, so long as I can get a yes or no back from it when I call. I'd keep the coordinates while waiting for an answer. .bin attached. main.asm.bin

Note: This refill routine runs completely independent from the match code. In this way, once the match code blacks out the blocks it found, its job is done.

Yeah I wrote off the falling animation pretty early on as well. (Maybe at the end, but probably not) Flashing the blocks for a couple of frames is perfect I think. I also thought up something pretty similar to your gravity mode but its different- and I think its a decent replacement for the falling that we aren't doing. Short description is this- On every frame (no mode necessary) A subroutine searches the grid from the bottom up for black. When it finds one, it searches straight up until it finds a color. When it finds a color, it moves it to the bottom spot (or maybe down one row only which would slow the animation if desired). Then the routine quits until the next frame so it doesn't take too long, and thereby creates a bit of animation as well over the series of frames. Joystick and match checks do get disabled when black is found.. maybe that's similar to your gravity mode.

Oops. Deleted

Yeah I know what the issue is, I just need to re-arrange. The updates from ColorBank to ColorBankDisplay never happens until the second row. The top row gets its colors from the original random sequence generation.

Looks doable, but do you think we'll need the RAM? My instinct is to keep it as is why I'm doing the match code. Its complicated enough for me as is. (Often I think this incremental approach contributes to my rarely finishing though, so maybe I'm wrong) Do you want to do the match code instead of me? Also not sure about using the kernel time. There is plenty now, but those black bands are going to shrink vertically as we try to fit scoring and a title or something above and below, and surely other code will end up in there as well (I envision COLUBK and blocks fanfare maybe, for example.) Though.. I think this is less of an issue, and potentially not an issue at all. Gotta love black kernel bands. I've attached my latest .bin (which I have not pushed). You can move the cursor now with the joystick. It won't display on the top line yet though (Though it is there). Due to placement, the code for displaying it doesn't run for the top line yet. I haven't figured out how to post (or even view) a complete .asm anymore so its not here main.asm.bin

I like the button-direction idea. Very unique. Will your centering involve asymmetrical playfield stores? Yeah I think game state could be done with one byte or less and is the way to go. Yes I used the standard object positioning but until the end, who knows if we'll need to position other objects, so it may end up in there anyway, then the custom code will be a waste.

Since no one had any advice on anything that I should have done first, I made one up. Borrowing a little from Franklin Covey, I made a grid with tasks. When something pops into my head, it will go on the grid. How critical is it? How difficult is it? That will determine the order. Often, difficult tasks are not important and will crowd out important tasks. (Thanks Franklin Covey cult leaders!) The goal here is to set the clutter aside, focus on #1 tasks (top left) of which aren't very many when you slice it up, then #2, etc I also did a little of work on the code, not much, just a blinking cursor. I need a second cursor type, one that indicates that you have selected that block. Probably, instead of blinking with black, it will blink with white. Attached. BBlocks.asm

Hmm, you guys are right. I changed it to ora #1 for now which gives 128 possible seeds I think. Thanks! I suppose I'll change it to INTIM.. on the list. JeremiahK.. I have a bare bones code template that I made that happens to be 2K.. I usually end up going to 4K. I've been considering making this game 2K but really haven't decided. My sense is that it would fit rather easily- only one playfield, pretty repetitive game. I wrote off trying to use different shapes pretty early on here, feeling like the square blocks have a nice clean look. Even if it were achievable, the Atarified graphics might actually bring it down a notch in my mind. Just having big pretty-colored squares reminds me a little of a Lite-Brite. Or Christmas lights. Of course I'll likely have graphics above and below the main playfield where its easy to do. OK.. I'll do the cursor next. Having a pulse or flash is an obvious top contender- looks good, won't use kernel time outside the black bands where its tight. Another thing I've been thinking of is crosshairs. The ball is still available so I could use it in combination with COLUBK. I was also thinking that fat, faint crosshairs (same height and width of a block) could be interesting and again- be taken care of in the black bands. Thanks for the advice! -Jeff

Good Afternoon, Experienced developers or generally smart people- I’m looking for game development guidance… Having dragged a couple of projects across the finish line to the point that they could arguably be called games- confusing, crappy games with major loose ends and no polish, I’m trying a different approach this time. My most common issues: I get confused and/or lost during development. And while its probably not obvious, I try to avoid asking for help from the forum. So I’m approaching this one from a different direction and asking for design/process/method type help. (And the usual technical too) This one is like Bejeweled (but made exclusively with the finest Princess cut stones- No pretentious Briolette or Ceylon BS here ha ha!). No one has made this yet- right? I made this basic kernel over the weekend. Feeling like I should avoid pouring effort (and lots of code to confuse myself) into the graphics at this point. So, specifically, can you folks please tell me: 1. What steps would you have taken prior to making the kernel? 2. What do you think about my current code? Disorganized? Wrong? Missing something, could have done better, etc. 2. What would you suggest I do next? (broadly or specifically) Thanks in advance, Jeff BBlocks.asm

What would happen if code was running in RAM and hit address $00ff? (assuming the stack was clear or saved)

Hi- Is this an appropriate place to look for trades? I have extra Odyssey 2 games boxed w/ manuals I'd like to trade for some I don't have. If you are looking to do the same, let me know.. I can offer: Alpine Skiing!, Alien Invaders Plus!, Armored Encounter!/Sub Chase!, Blockout!/Breakdown!, Computer Golf!, K.C. Munchkin, Las Vegas Blackjack!, Showdown in 2100 A.D., Speedway!/Spin-out!/Crypto-Logic!, Thunderball! Also 2 loose carts with no box/manual- Bowling!/Basketball!, and Electronic Table Soccer! I don't need Baseball!, Cosmic Conflict!, Freedom Fighters!, Football!, Invaders from Hyperspace!, KCs Crazy Chase!, Out of This World!/Helicopter Rescue!, Pick Axe Pete!, Pocket Billiards!, UFO!, War of Nerves!, nor anything I mentioned in the previous paragraph, of course.

Here's a little more progress for this week.. I think the top bands came out nice and I've started the map (right of the red line) in earnest. You can see one of the two limitations of the red when it has to interact with black in the 4th row. I just can't update two players and playfield all on that same line when the (game's) playfield is present on the same horizon. You see it again on lines 4 and 5 but I'll be able to get rid of that the same way I did in rows 1 and 2. Right now the ball is drawing the red line, so I'm going to switch that out with P1 missile so the ball (VDEL on) can mitigate some of it. I believe line 8 will be the most restricted, with the playfield unusable- Only the ball will be available for that color. In any case, these are just patterns, and they can simply be designed around the issue so it won't show. As always.. if anyone knows of another way, I'd love to hear it.

Well I spent the past few weeks working on it here and there, and did ok taking care of the above issues with an elaborate scheme using the ball, missiles, playfield changes and more. It was pretty functional, but with limitations. Then when I started on a routine to populate the play field with the different colors from RAM, I stumbled upon an illegal opcode that made all that work completely obsolete, used no kernel time, none of the objects, and allowed 100% of all possible configurations, 100% of the time. Random generated playfield arrangement. I knew my routine would generate an illegal opcode, but thought it would be harmless. In reality, it blew up the kernel with a 6 cycle code. So I tweaked my routine, to give me a different, hopefully harmless code ($87). The kernel ran, but I was getting some odd, mustard colored squares in addition to the red, yellow, and blue. Once I read up on $87 (SAX), I thought hey, I can use this for a cursor color (rearranging what a,x. and y were holding would give me gray as the fourth color. It took me a few more minutes to realize that my red and blue only had one bit in common, and a minor change to one could give me a black cursor (note the red is darker now). It took a few more minutes to realize, my playfield limitations could be completely resolved this way as well. So, now it works better and the ball and missiles are free for other possible uses (Note the red divider line that appears in the original game is now there).

Good Morning, I found a game called Amado that I think can be done in a reasonable amount of time. Originally thinking that the map on the right could not be displayed in the same horizon as the (full, top two rows of) playfield, I'm giving it a shot anyway and I think It might work. Here's what I have so far. (Note, the map on the right will only occupy 32 scanlines when finished): Spiceware showed me how to run a kernel in RAM, so I'm doing that here. The shortcomings I still have are: 1. PF2 is symmetrical, so only one black square is available in that area via the ball. Being able to cram 2 more store PF2s would allow unlimited playfield designs and free up the ball. 2. I still have not represented the player's current position in any way. 3. I've deliberately made the last column red so I'd have red in the map on the right. This won't work in a game, so I'll need another store #RED to the background crammed in there. I've got a few ideas involving using missiles display two squares at strategic locations but I dunno.. Sounds like that might be overly complicated. I feel like my handling of line index / a,x,y, and a is already needlessly messy. Any ideas?: jmp ZProutineRAM ;3 67 because will be in RAM eventually RAMKernel: SUBROUTINE ; ZProutineROM: ; This all is loaded and runs in RAM .loop sta WSYNC ;3 0 ;This can eventually be removed lda #%00100100 ;2 2 ;Vertical grid lines sta PF1 ;3 5 ; Register Update Allows for one register update per scan line lda MapSec1,x ;4 9 ;New pattern for either P0,P1,or PF ldy MapReg1,x ;4 13 ;Specifies which register to update sta 0,y ;5 18 ;Store the map pattern to that register. Can this be reduced to 4 cycles somehow? ldy #BLUE ;2 20 ;Restore the colors to the registers ldx #YELLOW ;2 22 lda #RED ;2 24 stx COLUBK ;3 27 1st column These stores are changed in the black horizontal bands above so that loads are not needed. sty.w COLUBK ;3 30 2nd column Needs to be @ cycle 31 or 32 sta.w COLUBK ;4 34 3rd column 4 cycle stores keep them in line with the beam but 2 cycle ops could be used in some spots instead. stx.w COLUBK ;4 38 4th column Perhaps missiles could replace one or two of these but I still have nothing displaying a cursor that sta.w COLUBK ;4 42 5th column will show what spot the player is on sty.w COLUBK ;4 46 6th column stx.w COLUBK ;4 50 7th column MapOperand: ldx #%00001111 ;2 52 Represents the red in the map via PF1. This operand is updated in the above register update. sta COLUBK ;3 55 I'm cheating here because I forced red in the last column. This will not work during a game. stx PF1 ;3 58 This won't match P0 and P1 changes verticlly. dec RAMKernelCount ;5 63 ldx RAMKernelCount ;3 66 bne .loop ;3,2 69,68 jmp JumpOutofRAM ;3 71 ZPsize = *-ZProutineROM Note: I still have plenty of time left to set stuff up in the black horizontal bands.

Do you know a good way to get the assembler to label the ZProutineROM routine once its loaded into RAM? For example, if you had lda #%10011001 somewhere in ZPRoutineRAM, and wanted to change it on the fly to lda #%11111111 could you: lda #%11111111 sta MySpecialRAMLabel+1 ;(the operand portion of that load) I think this could be figured out manually, but while writing, it would be great if a labelled location could be figured by the assembler.

OK yeah I fixed it- Thanks... And I see the ZPsize too which would eliminate the jmp issue I mentioned. Though that looks like it can be risky if I don't manage RAM appropriately.

Thanks! So that looks really straight forward if I understand it correctly. Like this?: ZProutineRAM ds 16 ldy #15 InitZP lda ZProutineROM,y sta ZProutineRAM,y dey bpl InitZP ZProutineROM: ;read 3 bytes of garbage from here up. Be careful about the jump to RAM ;address because it can change. I think I might use iny and cpy #15 instead. lda #SomeNumber ; 2 bytes sta SomeRegister ; 2 bytes lda ($44,X) ; 6 bytes jmp KernelEnd ; 3 bytes