AkashicRecord

Stumbled across this one today and thought it was kind of interesting. It's essentially an A.I. network that learns to play Atari games by analyzing the system's RAM during gameplay. An earlier revision seems to have relied on video output to "learn" from, but this one uses the VCS' RAM. Kind of interesting! https://deepsense.ai/playing-atari-on-ram-with-deep-q-learning/ Here is a SeaQuest run which seems to be better than the Breakout example on the page. You can see how it starts to learn where things are going to appear on screen before they do:

Yeah, it's funny how cheap things like that are now. Almost 20 years ago, I strangely ended up with many hundreds of EPROMS, for free, but I had nothing to do with them. (I even think they were the same ones found in the VCS cartridges, but I could be mistaken.) I eventually threw them away at some point for some stupid reason. I guess making "old" games never crossed my mind as something that would be even be possible...or desired. I can see 3D printing cartridge case halves as being a thing, if it isn't already... Edit: it seems that it is...

...which leads me to a question: Is there any reason to shoot for a 2K ROM instead of 4K? I'm afraid I don't know a lot about costs for particular cartridge formats (should it be possible for me to actually do this without being sued.)

A stretched sprite is what I'm currently experimenting with for my own implementation. Everything is either 1, 2, 3 or 4 solid pixels.

Sorry for another technical post (I'll have more media later.) Code as data, data as code... This is something that jumped out at me as I was working on the game's playfield data representation. Normally, I'm not a big fan of premature optimization, but it might be some sort of secret Holy Grail thing for the VCS... I noticed that the PF1 (and PF2) bitmap that I was using to draw the 2 player wells (#$E0) is the opcode for the immediate addressing mode of the CPX instruction (ComPare X.) What's even better is that this bitmap for a "default clear" line state only represents only half of the well. Throwing in the other (clear) half puts "E0" into two side-by-side RAM locations, which boils down to the following instruction: CPX #$E0 This is comparing the X register to the immediate value "E0" which is almost exactly what I want to do to check if half of a game row is clear.... This recursive nature of the CPX opcode definition almost allows direct execution of my data with no change. If I load the next half needing to be checked into the X register, and with a few more clever instructions, I may be able to use this method to check the next segment after that, and so on, and so forth. I can potentially use a byte after the first failure of the clearing logic to flag where the "dirty" lines start and then use this for the lion's share of the "line clear" stuff. Combine this method with dynamically self-modifying code and we can have very tight and optimized wizard shit going on... This method may even compress my playfield data somewhat, saving a bit of RAM, since most lines (unless you suck) should be in the clear state. Since this recursively self-executing data-code will reside in RAM (as the playfield data normally would anyway), then only the lines, or the number of lines, that actually have a "dirty" flag will need to exist as a bitmap in RAM (up to a maximum of 80 bytes) and having this line clearing check "kernel" down to only a handful of bytes will help a lot for CPU usage as well. I shouldn't be particularly starved of CPU in the VBLANK and OVERSCAN areas, but everything helps. I can focus more ROM and CPU on good music then.

I dont think the splash screen should be *too* hard. You could even have the scrolling beam flash (whatever it's called) over a couple scanlines.

Chopper Hopper

And shouldn't this thread be me moved to the programming sub?

The jingle blows up pretty badly after one rep on my portable Stella emulator.

The image on the TV should be in a SECAM format (of 8 colors.)

Here's one thing about VCS programming that is vastly different than what most anyone will ever come across: You essentially have to look at your game's rendered image and find areas between the pixels in which you can execute your code. Not all code will need to use the actual scanline because you get some free time (if you exhaust VBLANK) during each horizontal retrace period...you can kind of think of each scanline as the lines of a lined notebook, and the margins on the left are the retrace period. You can execute code within the margin notes, but if you want to fold the paper, you have to do it at one particular location...

The way that I imagine that this works (for a reflected playfield) is that the TIA reads the PF0, PF1, and PF2 registers in one direction, and then it immediately sweeps back to read them in the reverse order. [Please correct me if I am wrong. I haven't read a developer's manual.] This causes a severe contention for the PF2 register at a point directly in the middle of the screen. There is a more "standard" mode that accesses PF0, PF1, and PF2 more sequentially, and also buys you more time across the scanline to make changes to PF2. I don't want to use that mode unless I have to, so I have to work this kernel to write to PF2 (when it needs to) at an exactly perfectly-timed CPU clock cycle. No more, no less.

So today I started working more on the playfield and ran into some interesting issues. One of them was somewhat expected, especially since I really like the aesthetics of a reflected playfield...then problem is, with an Atari 2600 game, the CPU and the television interface are in a certain lock-step with each other, so to say that timing is critical is a huge understatement. The issue isn't so much of a problem though, because I'm (mostly) ignoring writes and changes PF0, so that buys me a write to each player...so...problem mostly solved...but the key issue is in timing. To create an asymmetric playfield, you essentially have to cheat. The system wasn't really designed to do this, but it can be achieved by exploiting a CPU and TIA timing issue. I need to write an asymmetric playfield which is also reflected. This reflection point is the PF2 register... In order to do this, I need to write a change to the PF2 register at the exact CPU (and TIA color) clock cycle when it is possible to do so. This is only on one cycle.

I didn't know that 60Hz PAL was even a thing... Should I even bother with SECAM? Does anyone still even use those old French 2600s?

I won't get too hung up on timing, but I should have clarified that I wanted to basically have the game "clock" ticking at the same rate on both 60 and 50Hz systems so that there really won't be any noticeable difference in game play or speed between regions. Right now I'm moving forward on to strategies on representing the games playfield data and manipulating its bitfields.

Wow, that's very similar to what I was experimenting with, but my code was not as reusable. I was also writing my timer multiplier value to VBLANK (instead of 2) to save a few bytes and cycles. Thanks for the useful response!

I was really tempted to spinlock on a timer until the end of the overscan period, but does this cause any problems or issues on real hardware?

If the football thumbnail image was any clue, I'd say its a Hail Mary.

Thanks for bringing that one up, because I did think about it very briefly when I was selecting palette colors. I think I can find a nice balance between the two, and I was leaning towards 50Hz as the standard difficulty speed, anyway. PAL support is definitely on the early list. It looks like the majority of it will only require different spinlock timer values and different color values (along with your list too, of course.)

That was the thread I was looking for It looks like the video got its own thread recently, which is even better. I hope the system does well and finds its niche. Everyone I've mentioned it to has had positive opinions, and thinks it's an interesting idea. We now return to your regularly scheduled Tetris programming...

I saw this too the other day. Why not post the video?

As I was writing code for my shiny new Atari 2600 Tetris game just a few days ago, I heard Atari's CEO on Fox Business in the background talking about the new console (and also about stocks, of course...)

This is a little off-topic, but it came up the other day as I was writing some of this code. Completely out-of-the blue, Atari's current CEO appears on a television segment in the background talking about stocks and the upcoming console:

I think this should be the last silly little test for this one. Here's two simultaneous orientations of the T block (with true colors) packed into one sprite:

...and here's the J and Z blocks (faked) in the color of the S block: