AkashicRecord Posted October 10, 2018 Share Posted October 10, 2018 (edited) UPDATES: 11/16/2018 - New 1P kernel design is almost complete. Playable prototypes coming soon. 11/07/2018 - The SRS (Super Rotation System) is in place, and piece rotations are almost finished. 11/02/2018 - An unfinished 2-player joystick prototype is now available. (See page 6.) Here's the original post: After a bit of searching, I failed to find a "Tetris-like" game for the Atari 2600 / VCS that struck my fancy, so I've toyed with an idea to make one myself. I'm kind of surprised that there isn't a flood of them, even given the limitations and restrictions of the platform... Twenty years ago, I wrote a few Tetris games using as many languages as I could manage and ended up with BASIC, Pascal, and C / C++ versions, with the latter being a crude stab at X Window programming on Linux and FreeBSD. Unfortunately, those programs and their source code were lost to the sands of time (i.e.; hard drive crashes.) This isn't entirely a bad thing, because none of my previous strategies would be even remotely fitting for realizing a "Tetris" within the constraints of the VCS and TIA... I'm no stranger to assembly programming, as I've had a lot of experience with emulator programming and debugging in general, mostly concerning the Sega Genesis' Motorola 68k processor and FM sound chips, though I wrote an x86 assembly "kernel" for sprite handling for a Sega Genesis emulator project which gave an 80-90% speedup for the processors of the day, and I later wrote (half of) a TurboGrafx-16 emulator and ROM disassembler...that's close enough to the 6507 for my tastes. That said, any good project needs to first have an idea and goal, though some concept "art" certainly doesn't hurt. Here is a (slightly enlarged) animated GIF mockup of the idealized game pieces in their various rotations, using colors close to the TIA's NTSC palette. The pieces are fairly close to being aligned with their center or "rotation" point, though there might need to be some minor adjustments: I'm aware of "issues" with the limited amount of time for color changes regarding playfield and sprites, and most importantly...RAM...so I'm quite flexible with adaptation to change. Some of the pictured pieces would obviously require a "single-scanline" kernel, for instance. If that image looks like "too much" for the 2600, I'm actually aiming for single-color pieces for 2-player modes (if 2P is feasible, of course... I'm not even thinking about a CPU opponent at this point.) Ideally, I'd like both 2-player cooperative and competitive modes, along with some other things that haven't existed in any version of a "Tetris" game...yet. I want people in the future to be able to say that the best "Tetris" is only available for the Atari 2600! Edited November 17, 2018 by AkashicRecord 5 Quote Link to comment Share on other sites More sharing options...
iesposta Posted October 10, 2018 Share Posted October 10, 2018 There are no good 2-player versions I know about. The 1-player version sold in the Atari-Age store is quite advanced, saving scores to cart, 3-channel selection of 3 tunes. Many tricks for different color pieces... Your game will be compared to it. https://atariage.com/store/index.php?l=product_detail&p=1003 A 2-player Puyo, Puyo / Dr. Mario may be more desired. Tetris 2-player would be a first, and in no way un-liked. Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 10, 2018 Author Share Posted October 10, 2018 There are no good 2-player versions I know about. The 1-player version sold in the Atari-Age store is quite advanced, saving scores to cart, 3-channel selection of 3 tunes. Many tricks for different color pieces... Your game will be compared to it. https://atariage.com/store/index.php?l=product_detail&p=1003 A 2-player Puyo, Puyo / Dr. Mario may be more desired. Tetris 2-player would be a first, and in no way un-liked. Ah, that's the one that I was looking for. The cartridge type seems a bit ...hefty. My target is only the "standard" 4K, but I wouldn't rule out any of the more 'advanced' types if the need arises. Quote Link to comment Share on other sites More sharing options...
Mr SQL Posted October 10, 2018 Share Posted October 10, 2018 Cool project and coding background, looking forward to seeing this! Anyone know where the ROM for Chetiry is? I thought they used to be linked. 1 Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted October 10, 2018 Share Posted October 10, 2018 I made a two-player Tetris a few years ago in Batari Basic. http://atariage.com/forums/topic/135837-tetris/page-5 2 Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 10, 2018 Author Share Posted October 10, 2018 (edited) I made a two-player Tetris a few years ago in Batari Basic. http://atariage.com/forums/topic/135837-tetris/page-5 Thanks for that one, I overlooked that section of the forum and missed it. Edited October 11, 2018 by AkashicRecord Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 10, 2018 Author Share Posted October 10, 2018 Certainly worth a watch for anyone interested. 1 Quote Link to comment Share on other sites More sharing options...
Shawn Posted October 10, 2018 Share Posted October 10, 2018 Ah, that's the one that I was looking for. The cartridge type seems a bit ...hefty. My target is only the "standard" 4K, but I wouldn't rule out any of the more 'advanced' types if the need arises. Just wanted to say your username is awesome! 1 Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 11, 2018 Author Share Posted October 11, 2018 Just wanted to say your username is awesome! Thanks! 2 Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 12, 2018 Author Share Posted October 12, 2018 A few days ago, I threw together a simple kernel that cycled the background colors and writes the line counter to two playfield registers. (We've all seen that one before...) I used that to put together a mockup image of the game field (with a few pieces in unrealistic fashion) to help envision the playfield with respect to the to playfield registers: (NOT real) It didn't take long to notice that the best route is just probably just use 5 bits of each playfield register. Shaving a few lines from the top gives space for two 10x20 "wells" for a 2-player layout: (Real) 2 Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 12, 2018 Author Share Posted October 12, 2018 (edited) A 2-player Puyo, Puyo / Dr. Mario may be more desired. Tetris 2-player would be a first, and in no way un-liked. Dr... Atario? That idea crossed my mind around the same time as a Tetris clone, but I feel there will be a LOT more wizardry required for a Dr. Mario game if it isn't going to be a flickery mess... Edited October 12, 2018 by AkashicRecord Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 12, 2018 Author Share Posted October 12, 2018 My next step is to flesh out the game pieces into some code. I'm envisioning judicious use of the sprite sizing register and the missile objects, if my understanding of the mechanisms are sound. Color changes might be hardcoded into each kernel, but I may investigate using the DCP/DCM illegal opcode to decrement the value in RAM. Quote Link to comment Share on other sites More sharing options...
JeremiahK Posted October 13, 2018 Share Posted October 13, 2018 (edited) You might want to use a mirrored playfield for 2-player mode to make the screen look symmetrical. You would 5 bits of PF1 and PF2 for player 1, and 5 bits of PF2 and PF1 for player 2. Edited October 13, 2018 by JeremiahK 1 Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 13, 2018 Author Share Posted October 13, 2018 You might want to use a mirrored playfield for 2-player mode to make the screen look symmetrical. You would 5 bits of PF1 and PF2 for player 1, and 5 bits of PF2 and PF1 for player 2. /salute Sounds like a good idea, and it wouldn't impede the game logic in any way. Quote Link to comment Share on other sites More sharing options...
JeremiahK Posted October 13, 2018 Share Posted October 13, 2018 (edited) I'm not sure how you are planning to implement drawing the bricks. I don't know if it's best to use the players and missiles for a 10-wide grid. Each player gives you 8 "pixels", plus one more with the missile, giving you only 9 pixels. You could stretch/move/disable the missile row-by-row to "simulate" 2 pixels, but I think it might be easier to use just the playfield for drawing the bricks, using the players and missiles to draw thin borders around the play area. You could use "score mode" on the playfield, to draw the left side in Player0's color (COLUP0), and the right side in Player1's color (COLUP1). I know that might not be quite what you have in mind, I'm just thinking out loud. Are you wanting it to be like actual Tetris, where each shape in the grid keeps its original color? I'm not sure if that is possible with 2 screens, even if you were using a DPC+ chip to cheat with register-stuffing. (I have never done this, SpiceWare or Thomas Jentzsch would know way more about this, but as simply as possible, that's when you have a second program running in the background on a separate faster CPU built into the cartridge with access to the 6507's registers. The HarmonyCart has support for this. This way, for example, you can keep executing sta COLUBK over and over. Normally, this would just keep writing the accumulator to the background color, which wouldn't ever change. Your background code would be changing the contents of the accumulator at the right times, so that the color could be precisely changed every 3 cycles. This would give you a maximum number of 18 color changes per line, which isn't enough room to fit two 10-wide grids.) Edited October 13, 2018 by JeremiahK 1 Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 13, 2018 Author Share Posted October 13, 2018 (edited) I'm not sure how you are planning to implement drawing the bricks. I don't know if it's best to use the players and missiles for a 10-wide grid. Each player gives you 8 "pixels", plus one more with the missile, giving you only 9 pixels. You could stretch/move/disable the missile row-by-row to "simulate" 2 pixels, but I think it might be easier to use just the playfield for drawing the bricks, using the players and missiles to draw thin borders around the play area. You could use "score mode" on the playfield, to draw the left side in Player0's color (COLUP0), and the right side in Player1's color (COLUP1). I know that might not be quite what you have in mind, I'm just thinking out loud. Are you wanting it to be like actual Tetris, where each shape in the grid keeps its original color? I'm not sure if that is possible with 2 screens, even if you were using a DPC+ chip to cheat with register-stuffing. (I have never done this, SpiceWare or Thomas Jentzsch would know way more about this, but as simply as possible, that's when you have a second program running in the background on a separate faster CPU built into the cartridge with access to the 6507's registers. The HarmonyCart has support for this. This way, for example, you can keep executing sta COLUBK over and over. Normally, this would just keep writing the accumulator to the background color, which wouldn't ever change. Your background code would be changing the contents of the accumulator at the right times, so that the color could be precisely changed every 3 cycles. This would give you a maximum number of 18 color changes per line, which isn't enough room to fit two 10-wide grids.) Thanks a lot for the information and suggestions. I didn't have any plans to retain the piece colors once they are placed. I didn't think there was much capacity (even with external hardware) for that kind of bookkeeping. I don't even hardly want to change the playfield color (with a constant black background) except maybe a few times. The above tests with colored bars are just to measure screen real estate and to get a visual overview. The idea of a cart with an ARM processor is tempting though...ARM and Thumb assembly was my all-time favorite, especially the barrel shifter... I'm still working out the logistics and to see what is actually possible with 76 clock cycles and preloading as much state change as possible before the target scanlines, because if this game was easy to write while still looking good, it would have already been done many times. Abusing the processor status flags will probably go a long way. In my testing late last night, I can change 11 values in RAM across a single scanline...but it was sometimes dropping Stella's FPS on my netbook from 60 to 15fps! Edited October 13, 2018 by AkashicRecord 2 Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 13, 2018 Author Share Posted October 13, 2018 (edited) I'm not sure how you are planning to implement drawing the bricks. I don't know if it's best to use the players and missiles for a 10-wide grid. Each player gives you 8 "pixels", plus one more with the missile, giving you only 9 pixels. You could stretch/move/disable the missile row-by-row to "simulate" 2 pixels, but I think it might be easier to use just the playfield for drawing the bricks, using the players and missiles to draw thin borders around the play area. You could use "score mode" on the playfield, to draw the left side in Player0's color (COLUP0), and the right side in Player1's color (COLUP1). Those are good ideas, and almost in line with what I was tinkering with. For a single player well, it would make sense to draw the borders using the second player and associated missile...it would look nice. Also writing #%00000001 to CTRLPF fixes the playfield and it fits very nicely, I had certainly overlooked that. I only need about 16 pixels at most for a piece, so I was imagining that most pieces could be drawn by just modifying NUSIZx (and a color) a couple of times. Some pieces might be able to reuse the existing data from other previous pieces since they are so simple...4, 8, 12 or 16 pixels changing every four scanlines at most is the general case. I would certainly have a competitive mode which has the associated players playfield in the color of their current "level" (100 lines cleared.) I was aiming for a 2-player coop within a shared well of at least 12x20, as well as some other modes like alternating 1P/2P or modes where one player rotates the piece, while the other moves it...possibly with the paddle, for instance. Edited October 13, 2018 by AkashicRecord 1 Quote Link to comment Share on other sites More sharing options...
JeremiahK Posted October 13, 2018 Share Posted October 13, 2018 Awesome, sounds like you have really thought this out and understand the constraints of the system. I wasn't sure, since you are new on here. Many times when people (like myself) first start out, they don't realize that a particular idea they may have isn't actually possible. In the kernel I am working on right now, I am writing to 12 TIA registers and 1 byte of RAM in a single 76-cycle stretch. As you can imagine, there isn't any space left in this kernel big enough to fit a burnt match in. I recently discovered that one of my VCS systems won't display this kernel correctly, which unfortunately sometimes happens when you push the system to the limits. 1 Quote Link to comment Share on other sites More sharing options...
Andromeda Stardust Posted October 13, 2018 Share Posted October 13, 2018 congrats. i still have chetiry cart with my high score pegged at 198k (2k shy of earning a big rocket). there is also a gb_chetiry rom with lime green palette compatible with harmony. it uses the pitfall ii mapper. i am looking forward to seeing what you create. cant have enough tetris clones, lol! 1 Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 13, 2018 Author Share Posted October 13, 2018 Here is a glitchy output of something close to what I envision for most of the progressive levels. You can ignore some of the garbage at the bottom of the playfield because I haven't finished the loops yet. 2 Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 13, 2018 Author Share Posted October 13, 2018 Is it considered bad form to steal Battlezone's positioning code? Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 13, 2018 Author Share Posted October 13, 2018 Awesome, sounds like you have really thought this out and understand the constraints of the system. I wasn't sure, since you are new on here. Many times when people (like myself) first start out, they don't realize that a particular idea they may have isn't actually possible. In the kernel I am working on right now, I am writing to 12 TIA registers and 1 byte of RAM in a single 76-cycle stretch. As you can imagine, there isn't any space left in this kernel big enough to fit a burnt match in. I recently discovered that one of my VCS systems won't display this kernel correctly, which unfortunately sometimes happens when you push the system to the limits. That's very impressive...basically pushing the envelope there. I've put some brainpower into this one, and it helps having five other game versions under my belt. I was even looking at hardcoded indexed permutation tables in ROM to represent the game state since RAM is at a premium especially with 2 players. Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 13, 2018 Author Share Posted October 13, 2018 (edited) In the worst cases, an entire frame (or more) can be consumed processing anything "hard" or CPU-intensive. At best, this gives the player a small break (while still hopefully hitting on input polling in good fashion) on fast-paced levels, but I don't feel that I'lll need to go that route...yet.A standard 10x20 "Well" requires about 25 bytes at best for the simplest possible bitmap representation of possible playfield states, and this breaks down into two 5-bit halves of two reflected TIA registers. There is a 160 scanline "resolution" which breaks down into "chunks" of 8 scanlines for drawing game pieces and playfield blocks. (Can we use a quad-sized player and octuple-sized missile to fill 40 solid pixels???)This is where I can imagine using indexed permutations of 5 (which is essentially...120 states.) Using a lookup table could shave some bytes off of each player's RAM usage, while still leaving 1 bit available for some other use...such as a "line clear" flag(?) with the permutation tables still possibly fitting within a single page boundary... (I hope I got that right...) The processor status flags might be more useful for signaling the "line clear" state, however. Edited October 14, 2018 by AkashicRecord Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 13, 2018 Author Share Posted October 13, 2018 (edited) Here's what a single-player field might look like with (glitches) and a cycling of the level progression... I'm kind of debating on whether or not just to use the 2-player layout even for 1-player....possibly with just using the empty space for the number of lines or what have you, as well as reserving some black lines at the top. I usually liked to use a small "staging" area for the next incoming piece that was slightly above the game board so that you could have an actual chance toward the end of your game... Later on I should have some drawing tests for the basic game pieces... Edited October 13, 2018 by AkashicRecord Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 13, 2018 Author Share Posted October 13, 2018 (edited) Cool project and coding background, looking forward to seeing this! Anyone know where the ROM for Chetiry is? I thought they used to be linked. It appears that the Internet Tetris Gods (see YouTube video above) have once again graced me with their benevolent presence; this time in the form of lost source code: Searching the Internet Wayback Machine for one of my old expired domains revealed a strange little Easter Egg from exactly this day, October 13th, almost 20 years ago... Somehow I let a code listing slip through just long enough for it to be archived. Damn. https://web.archive.org/web/19991013125024/http://pknet.com:80/xtrix/HTML/S/main.C.html Edited October 14, 2018 by AkashicRecord 3 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.