atari 2600 homebrew programming - 88 lines about 32 pixels

I've been getting back into programming the Atari 2600 again.

This past week I updated my 2015 Global Game Jam project Loaded4Bear - now it has an aggresive but not too bright AI opponent option.


I've always liked Atari games that have the computer playing by the same rules as the human, and long was thinking I should get back to add that to the Loaded4Bear. - I wasn't sure if I could! So I'm chuffed to have done it.

Also, the music by Oliver Getz is amazing- I showed him the basics (no pun intended) and he did some great work back then.

This is all made feasible by batari BASIC - my first homebrew in 2004 was in assembly and cost me a year. The GGJ version of this game took a weekend, thanks to this language.

The canonical place to learn about the bB is Random Terrain's batari Basic command page though it is rather overwhelming! There are more tutorials and information at the AtariAge batari Basic forum.

Many bB users like coding in "Visual batari Basic" as an IDE though, besides the fact it's Windows only, I never could get my head around its version of asset management. There is a pretty good plugin for Visual Studio Code called "Atari Dev Studio" that makes the process look more familiar to folks who program as day job. It's cool to be able to copy and paste in a program listing, click the button, and have it run in an emulator.

I hacked together two simple P5.js tools for drawing the Playfield (background) graphics - one for the old school regular playfields and then one for the  highrez 88-line DPC+ playfields... for the former, it creates an entire runnable program, and the latter outputs something you can put in a standard DPC+ template. (The ability to just copy and paste into a single file, and then run and have a game, harkens back to the old days of magazines with type-in-listings. (Also Java Processing/P5, come to think of it) - just so elegant to have pure text turn into graphics and interaction!)

The DPC+ thing-- a lot of Atari 2600 homebrew has gotten away from the classic "4K Rom, 128 bytes memory" and using "DPC+" which offloads much of the processor work onto an oncart-chip. There's a temptation to think of this as cheating, but it's based on what Activision was doing with Pitfall II, and then what companies like Nintendo would do with Star Fox etc. Still, I think there's much charm to seeing what kind of a game can be made using the original limitations of the basic hardware and sofware.

GEEKNOTE on those editor tools I built - it was great to be able to make them in a hurry! (Though a little weird to be using such power technology in the tool chain for such old stuff.) The only bit of cleverness was A. a flashing cursor box to show you which pixel would be set and B. at first I just drew whatever pixel was under the mouse during the "drag" movement, but if the mouse was moving quickly, spaces in between would be missed.

I went from this simple check: (edited for clarity)
function mouseDragged() {
      const x = int(mouseX / PIXW);
      const y = int(mouseY / PIXH);
      grid[x][y] = isDrawing;
  }  
}
to this loop that imagines a line with 100 intervening points from the previous mouse position to the current mouse position, and runs the same check for each pixel underneath -
function mouseDragged() {
  for(let i = 0; i < 100; i++){
      const tx = map(i,1,100,pmouseX,mouseX); 
      const ty = map(i,1,100,pmouseY,mouseY); 
      const x = int(tx / PIXW);
      const y = int(ty / PIXH);
      grid[x][y] = isDrawing;
  }  
}
A little redundant but works great!