Jump to content
IGNORED

A Two-Player Competitive and Co-Op "Tetris" for the Atari 2600 VCS


AkashicRecord

Recommended Posts

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:

 

post-66218-0-32929500-1539184136.gif

 

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! :grin:

Edited by AkashicRecord
  • Like 5
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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...) :roll:

 

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:

 

post-66218-0-22635400-1539348725.png

(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:

 

post-66218-0-29410600-1539349723.png

(Real)

  • Like 2
Link to comment
Share on other sites

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? :cool:

 

post-66218-0-72779100-1539355798.gif

 

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 by AkashicRecord
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by JeremiahK
  • Like 1
Link to comment
Share on other sites

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! :o

Edited by AkashicRecord
  • Like 2
Link to comment
Share on other sites

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 by AkashicRecord
  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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! :D

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by AkashicRecord
Link to comment
Share on other sites

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...

 

post-66218-0-66485500-1539458158.gif

 

 

Later on I should have some drawing tests for the basic game pieces...

Edited by AkashicRecord
Link to comment
Share on other sites

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 by AkashicRecord
  • Like 3
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...