I recently found an active online community of Atari 8-bit computer retro enthusiasts. Having grown up playing games on and programming an Atari 400 (1982-1985) and an 800XL (1985-1989), it’s been fun getting back into it. A couple years ago I loaded the Atari800XL emulator on my Raspberry PI to show the kids the games I used to play. They were unimpressed. Too bad, because I could beat them at Asteroids. More recently, I’ve been working on a BASIC program using the Altirra emulator on my Windows 7/10 desktop. I learned about a 10-line BASIC game programming competition on the ANTIC podcast, which gave me a goal for my retro ruminations. I’m hoping they’ll rerun the competition in 2016 so I can enter.To prepare, I decided to brush up on my BASIC. I only ever used Atari’s BASIC (cart. on the 400 and built-in on the 800XL), but have since learned there are many more BASICs from which to choose. For this program, I’m using Turbo BASIC XL because it’s faster and supports block memory copies. When I tried to write games in junior high, I didn't know about Atari's player-missile graphics (hardware based sprites) although I did learn a little of the C64 sprites in 8th grade computer programming. This time around, I set out to learn a couple of the things I missed growing up: page flipping and hardware sprites. To use these techniques in Atari BASIC requires lots of PEEKs and POKEs and some understanding of the memory map, which probably explains why I didn't get it back then.
I asked the boy what kind of game I should write and he thought "20-ball Pong" would be hilarious. I prototyped it in Python to get the game logic down so I wouldn't have to design the game while relearning BASIC. The concept is pretty easy and Python on a modern machine is speedy. Coding up the ball motion in an emulator, I quickly re-discovered how slow Atari BASIC was and abandoned trying to use hires graphics. The game(I call this version LMNOPing!) is now in text mode with 5 inverse ATASCII characters (L-P) standing in for software sprites and a player-missile paddle. The ball motion is not smooth moving 1 space per frame, but the paddle is speedy. The game play is still really slow, but has served the purpose of learning some new (to me) programming.
Page Flipping
To create motion, an object on the screen needs to be redrawn every frame at a new location while erasing the old location. This algorithm can easily create a flickering effect. The way around it is to draw the new frame while displaying the current frame and then flipping the page to show the updated screen. My Python prototype uses this technique. Because the Atari uses memory mapped graphics in RAM, it's pretty straightforward to implement in BASIC - a number of old magazine articles cover the topic (links are below). Point the graphics chip to display buffer A while filling in buffer B. Then flip the screen by pointing to B while filling in A.I learned an interesting feature of the clear screen (CLS) command that is
Player Missile Graphics (Hardware Sprites)
My 8th grade computer programming teacher taught us about C64 sprites near the end of the semester. I used them in my final project, which was a Simon game. For some reason, I never learned them on the Atari. I guess I never really understood why one would want to use some blocky single color thing when there are some great graphics modes to use. Obviously, I never tried to write a program with a software sprite back then; otherwise, I would have seen them for the genius they were.For this game, I’m going pretty simple with a basic bar that is moved vertically on the screen using the paddle controller. To move the graphic, the bytes have to be copied from one location to another and erased from their old location. Instead of tracking the move, it’s easier just to rewrite the whole column by copying a buffer with the appropriate offset. This is OK since I have plenty of RAM. I suppose in a tight 8K cartridge game this would be wasteful since I use 256 bytes just for the buffer and another 256 bytes for the sprites.
