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

[Lillapojkenpåön]

Thanks alot for sharing so much information!

I'm now decrementing and I see what you mean

Some follow up questions..

 

Can I DCP the a register somehow instead of a byte?

 

What does this do?

eor #$FF ; ...

adc #$F9 ; it's complicated...

And the magic number 46?

That's it for now

[AkashicRecord]

Thanks alot for sharing so much information!

I'm now decrementing and I see what you mean

Some follow up questions..

 

Can I DCP the a register somehow instead of a byte?

 

What does this do?

eor #$FF ; ...

adc #$F9 ; it's complicated...

 

And the magic number 46?

That's it for now

That positioning routine is basically a perfectly calibrated subtraction loop. Because of HBLANK, we need to push the minimum coordinate out a bit so that the subtraction doesn't cross zero too early. "46" ends up being a suitable value for the loop.

 

The other instructions make up for the lack of a bitwise Negation instruction in the 6502 instruction set. What we can do however, is flip all of the bits of the value, giving the one's-complement of the number. Using some bit-trickery and exploiting wrap-around, we can massage this value a bit and get exactly what is needed.

 

The addition following the Exclusive-OR, adjusts the value via wraparound so that the value falls within a signed range of -7 and 7. The left shifts place the value in the appropriate area of the HMxx register...that is to say that only the upper 4 bits are relevant, don't think of those 4 shifts as mathematical, they are just moving a bit pattern into place. (HMOVE semantics are the real complicated thing here.)

 

One other factor here is that we have to treat that value as an unsigned value, otherwise you wouldn't be able to target pixels 128-159. That's why I say, "it's complicated."

 

 

As for the first question, DCP works memory and gives a free compare with the A register, saving 1 byte and 2 cycles. There wouldn't be any reason to compare against a register that you are decrementing!

 

And no way to INC or DEC the A register because it is designed for ADC and SBC.

Edited November 21, 2018 by AkashicRecord

[AkashicRecord]

I feel guilty not posting any updated code yet, but I've been kind of busy the past few days. I did manage to make some adjustments to my kernel strategy though, so it looks like I should be able to pull of great-looking 1-Player game modes (as far as detail is concerned.) The 2P modes (at first) will probably have simple, solid color schemes though. (Mostly because I'm striving for a single-scanline kernel as much as possible.)

 

I'm trying to make this kernel as "generic" as possible so that I can repurpose it in upcoming games, so it is taking a little more time than expected. (I was originally aiming for a two-month development timeline, but that may have been extended a teensy bit.)

 

 

...anyone interested in an "Excitebike" type of game for the 2600?

[Andromeda Stardust]

I really like this idea. It should have been obvious.

 

I'll experiment with writing the frame counter to VBLANK for an alternating effect every other frame.

Won't this cause some tubes to screw up the draw sequence?

 

Vblank uses a "blacker than black" color, essentially 0V over composite. Solid black is actually a few millivolts higher than this signal level. This is why Nintendo told developers not to use colors 56-63 on the color pallet tables because this signal could be misconstrued as a vblank signal by the tube or digital set.

 

Just curious, will use of this function to blank out an entire scanline potentially trigger a midscreen vblank (resulting in stuttering screen, rolling, or "unusable signal" display on some sets but not others?)

[AkashicRecord]

Won't this cause some tubes to screw up the draw sequence?

 

Vblank uses a "blacker than black" color, essentially 0V over composite. Solid black is actually a few millivolts higher than this signal level. This is why Nintendo told developers not to use colors 56-63 on the color pallet tables because this signal could be misconstrued as a vblank signal by the tube or digital set.

 

Just curious, will use of this function to blank out an entire scanline potentially trigger a midscreen vblank (resulting in stuttering screen, rolling, or "unusable signal" display on some sets but not others?)

Writing to VSYNC would definitely screw up the signal, but VBLANK should be fine.

 

I'm close to putting this stuff to the test later today...but not on real hardware.

[Andromeda Stardust]

Writing to VSYNC would definitely screw up the signal, but VBLANK should be fine.

 

I'm close to putting this stuff to the test later today...but not on real hardware.

Okay gotcha.

[AkashicRecord]

Okay gotcha.

 

...I could be wrong however, so maybe someone with more experience can chime in.

[JeremiahK]

I don't understand all the intricacies, but I do know that if you leave VBLANK permanently disabled, the screen rolls. Even with proper VSYNCing and timing. So it does have some importance in the image syncing process.

[AkashicRecord]

I took a few minutes to throw together a quick test program that just outputs 7 blank lines (over a blue background) and then outputs a VBLANK line and repeats this pattern 24 times down the screen. This seems perfectly fine in Stella and RetroArch for Android, but I have no idea what this would do on a real CRT.

 

Until further notice, I think I'll press on with this idea and continue to integrate it into the new kernel for testing.

 

VBLANK-test.bin

Edited November 24, 2018 by AkashicRecord

[JeremiahK]

I just tested this, and it works perfectly on my CRT.

[AkashicRecord]

I just tested this, and it works perfectly on my CRT.

Excellent, can't appreciate it enough.

 

It might not be a necessary tactic, but it's definitely nice to know that it works.

[AkashicRecord]

Just a small heads-up.

 

I'm still plugging away at the game, but the most recent two weeks or so found me a new full-time job (with overtime) so I've had to focus on that recently.

 

I did have a sort of business meeting with an acquaintance over dinner as well, discussing this and future games.

 

I also did a little retro window shopping for an old VCS, so I have my eyes on a 4-switcher now...and the guys at the shop were pretty interested in seeing a cartridge of this game in 2019.

[AkashicRecord]

I've recently had some time to start working on this game again, and I've also been taking the time to study some disassemblies of other games, in addition to other Tetris games (and even the popular "official" NES version.)

 

 

I've spent some time experimenting with abusing the BRK instruction, which is essentially a rarely used software interrupt instruction (for the VCS, at least). The thing with this instruction is that it pushes the Program Counter and the Processor status flags onto the stack and then executes a certain section of code... If one sets the stack pointer to an "interesting" location, then they can exploit the fact that the Program Counter and flags will be written to the stack in only 7 machine cycles. If the "interesting" location is a color register, then 3 TIA color registers can be changed in 7 machine cycles...

 

It's not a groundbreaking feat, but it is certainly interesting and might have a future use. The primary difficulty with this ...method... is that you have to judiciously modify the PC to call the BRK from useful locations (since the PC bytes are pushed to the color registers, they should at least be useful colors), and the second issue is that the processor status flags can only be gently massaged to a certain extent. Even pushing *any* value to (a valid) stack and pulling the value into the status register (via PLP), certain bits of the status register will *always* be set to 1 ...or high ...or logic true ...or however you want to think about that.

 

That said, there's a somewhat limited amount of colors that you can squeeze into the playfield and player color registers by abusing BRK. I wrote a quick program earlier tonight to test what values can actually come out of this sort of abuse and mangling of the processor status flags by having the program display the intended color via the background with a sprite overlay whose color comes from the BRK pushing the flags into the sprite's color register. This helped visually contrast the differences of (intended) color values after being mangled by passing through the processor status flags, courtesy of PHA / PLP / TXS / BRK.

 

The results were actually quite interesting, and are definitely going into the arsenal.

Edited February 22, 2019 by AkashicRecord

[NostAlgae37]

My man is back! Welcome home, brother.

[AkashicRecord]

My man is back! Welcome home, brother.

Just took a little retro shopping spree and scored a light-sixer and a few games:

 

Atlantis

Pitfall!

Starmaster

Keystone Kapers

Yars' Revenge

Chopper Command

Grand Prix

Enduro

Spider Fighter

Solaris

Demon Attack

Dragonfire

Defender

Vanguard

Venture

Maze Craze

and Q*Bert

 

 

Over the next few days I hit up every retro game store within a 60 mile radius and scored more titles:

 

Space Shuttle

Adventure

Pole Position

Krull

Berserk

Midnight Magic <-- AMAZING

Riddle of the Sphinx

Centipede

Outlaw

Surround

Video Pinball

Frogger

Haunted House

Word Zapper

and E.T.

 

(I couldn't believe it when my 3 year-old son finished Adventure on difficulty 1...three times in under an hour!)

Edited March 4, 2019 by AkashicRecord

[AkashicRecord]

Not to get too off track, but I was slightly bummed when my L6'er wouldn't power up the other day after I received it!

 

 

I immediately suspected the 40 year-old power supply was at fault, and not having a voltmeter or ammeter other than the pink fleshy one that we are all born with, I couldn't taste 9V @ 500mA, so it was time to do a little electrical autopsy of sorts...

 

Scavenging various boxes and such for orphaned AC adapters didn't produce much fruit, but I found a 500 @ 12V* which was still center positive on the tip, so I dissected that adapter and fashioned a makeshift power adapter with the help of a 3.5mm stereo audio cable for the end connector...

 

After wiring up the ground / sleeve and tip (with crossed fingers, of course) everything was in working order on the first attempt...with the exception of Chopper Command and Keystone Kapers, though a bit of rubbing alcohol fixed those right up just as well.

 

 

Now on to acquiring a Harmony cart I suppose?

 

 

*I know that the VCS technically runs at 9V (and you shouldn't go around arbitrarily licking random wall adapters either) but the small amount of extra heat produced at 12V shouldn't damage the voltage regulator any more than my tongue.

[JeremiahK]

I bought a couple light sixers last year, and neither one works as of now, and it isn't the adapter.

Definitely get a Harmony cart, it is a must-have for 2600 developers, as it gives you instant easy access to testing your code on a real machine (and lets you do a little "research", of course). The emulators are never perfect, and if you are doing anything "interesting", you are bound to see discrepancies, even between 2600's.

[AkashicRecord]

I bought a couple light sixers last year, and neither one works as of now, and it isn't the adapter.

Definitely get a Harmony cart, it is a must-have for 2600 developers, as it gives you instant easy access to testing your code on a real machine (and lets you do a little "research", of course). The emulators are never perfect, and if you are doing anything "interesting", you are bound to see discrepancies, even between 2600's.

Yeah, I can't wait to run some of my test code on this machine using one, especially for working on the graphics and input control.

 

 

As for the game right now, one of my current hurdles is coming up with an elegant solution to checking the playfield bitmap(s) for the game piece rotation and placement functions. I want to try to store and manipulate the playfield bitmap data "as is," or rather, keep it in the exact order as is needed for the actual display.

 

The annoying issue here is regarding the reflected nature of PF2 in the case of the asymmetric 1-player game field; when a piece is situated on the field in a way that its bits essentially straddle both "copies" of PF2, then the bit tests necessary to check for rotation and placement get a little bit...ugly...to say the least. (In other words, the 10 columns of the game field are split and mirrored across 5 bits of 2 independent copies of one TIA playfield register per game row. It's kind of headache inducing to think about.)

 

I might be over thinking part of this though, as I have some ideas on oaper here to work on tonight. One idea is to just kind of slease out and use some tables in ROM, since each piece rotation can only occupy a handful of horizontal positions within the game field.

[AkashicRecord]

Here's a Friday funny for everyone. Not planning on anything like this in my version...

 

(There's no sound in the video)

Edited March 15, 2019 by AkashicRecord

[+Karl G]

Ha! I would call it "messy Tetris".

[NostAlgae37]

What kind of diseased mind devotes a full 20+ minutes to insanity like that? The physics of it would be impossible on a Gameboy, much less an Atari 2600! But if anyone could make it happen, it would probably be Akashic.

[AkashicRecord]

I've been kind of flip-flopping between a few projects that don't have dedicated threads yet. I wanted to have at least one type of shooter; this particular one pits you as a hypodermic syringe firing drops of vaccines at bacteria, viruses, and bacteriophages, etc...something like that. "Outbreak!" seemed like a good name for it.

 

The other thing I noticed is that a lot of my test programs seemed like they could be repurposed into a useful utility, or at least a type of drawing / painting program...possibly with some frames of animation...like a better version of Surround's last two game modes.