In anticipation of episode #4, here isa is supercut of lessons 1-3 of the Atari 7800 Basic Tutorial. 1 – Hello world  This is the first in a series of videos showing my own techniques using Atari 7800 Basic.  I do not claim these are the best or only way to do things, but they are the methods I have developed over the past few years.   The code in these tutorials is designed to be simple to read, so most of it will be unoptimized.  Feel free to download  the code from Github and optimize it yourself if that bothers you.   You will find the GitHub link in the end notes. Step 1: Visual Studio code The Atari 7800. For me, it’s Atari’s most underutilized console, and the one that holds the most promise as to what can be done with a 6502 based Atari machine.  The 7800 is backwards compatible with the 2600, but sports the Maria chip designed, at the time, to move graphics around the screen like no other machine, but especially better than the Colecovision, Atari’s main competition in 1983 when design started. We will talk more about the history of Atari and the 7800 as this series continues, but for now, let’s get started by jumping in and created Atari 7800 Hello World” — The first step is to download Visual Studio Code: You can find it for the PC or Mac or Linux at code.visualstudio.com:Visual Studio Code: Visual Studio Code – Code Editing. Redefined  Once  you have downloaded that you click the plug-in extensions button on the left side of the IDE, and you will see a searchable list of all the extensions available.   There are many. Search for “Atari Dev Studio” Atrari Dev studio combines Atari 7800 Basic (created by Fred Quimby with help from Bruce Tomlin) and now maintained by Mike “RevEng” Saarna. With the plug-in you can easily compile bAtari basic code, Atari 7800 Basic code, and DASM code.  It also features a spirit editor and the A7800 emulator for easy testing. Look over on the preview pane and see the information for Atari Dev Studio Notice it was created by ChunkyPixel We are all indebted to ChunkyPixel for creating such a fine price of software. Now click the install button. Next create a new file and save it on your hard drive.   I will call mine demo1.78b The .78b extension will make sure Visual Studio Code associates the file with the 7800 compiler and provides code hints included in the Atari Dev Studio plug-in. Now we are ready to go! Step 2: Boilerplate First we will drop in some boiler-plate code of which we will need in all of Atari 7800 Basic games. I’m not going to explain every detail of every option we are using, but just enough so you can dive-in later and explore all the incredible options available in Atari 7800 Basic.      You can find detailed descriptions of all Atari 7800 Basic functions in The Atari 7800 Basic Guide (https://www.randomterrain.com/7800basic.html)  set zoneheight 16  displaymode 160A  set plotvalueonscreen on  set romsize 32k Note: All code (except for jump labels and couple other things we’ll discuss later) must be tabbed-in at least one space) The first line  “set zoneheight = 16” is how we set the horizontal band zones for sprites.  Each horizontal band can have a set number of sprites, usually 16-20 depending on how many CPU cycles it takes to draw the entire screen.   You can set this to either 8 or 16.  8 allows for more bands, but with fewer sprites in each band, while 16 has less band, but more sprites in each band.   You will need to experiment with these options, and many others to optimize your Atari 7800 game.    The next line sets the graphics mode:  displaymode 160A 160A is the most basic mode.  It is 160 x 192 pixels, which means the pixels are like tall rectangles.  Each sprite in this mode can be 3 colors plus transparent. There are other modes too: 160B allows for 12 color sprites, while multiple 320 modes allow for various hi-res screens that rely on color artifacting for multi-colored sprite display. If you watched our previous video on 7800 Sprites, you can see some of these modes in action. There will be a link in the notes. (https://www.youtube.com/watch?v=oUuy5c5_8kA&t=1s) My favorite in 160A mixed with some 160B sprites, as we will see later in these lessons. The next line,   set plotvaluesonscreen on  is used for debugging and we will talk about it later. set romsize 32k, this is the size of the cartridge.  32K is small, but we don’t need anything else yet.  There are many cartridge sizes including ones that contain extra RAM to hold data and expand the number of sprites that can be displayed. The Atari 7800 Basic guide created by Mike “RevEng” Saarna and adopted by Duane Alan Hahn, a.k.a. Random Terrain will give you detailed information about the valid options for this command, as well as invaluable information about Atari 7800 Basic.   I usually keep it open in a window while I’m working. This guide is updated often. There are many more commands and options listed in 2023 than there were in 2019 when I first started with it.   In fact, just now I discovered something new. For instance, while writing this I discovered these palette fading com,mands i’ve never seen before.  These would have saved me a lot of work on my last project. There is absolutely no way I can cover all of Atari 7800 Basic  in these tutorials My job as I see it,  is to show you these demos and  get you started.  Once you are comfortable you can devour the Atari 7800 Basic Guide, and then even tackle Assembly language some day (if that’s your thing). Anyway, for this game we will keep it simple for now and just use 32K. With 32K we will not need to bank-switch, as the 7800 can address all 32K ROM space at once. Don’t know about bank-switching?It’s a way to almost infinitely  expand the ROM addressable on cartridge. I hope these lessons are successful enough that I’m inspired to tackle it later down the road. The last line BACKGRND = $60 sets the background color.    BACKGRND=$60 Press the little “rocket” button on the bottom menu to compile and run the code we just wrote. You must have your cursor in the code window for it work work properly. The output window will show the compilation steps. When it is done, the A7800 emulator will automatically launch.  When we compile and run this program, it will go off into space with this mustard colored background.  This is a warning that something has gone wrong. What has gone wrong is that we have not displayed anything yet. Hit the Escape key [ESC] to close the A7800 emulator. If you don’t close it, your next compile might not automatically launch the emulator.  To fix this we will add a simple game loop with the _gameLoop label with a goto plus a clearscreen and drawscreen lines, and recompile. _gameLoop  clearscreen  drawscreen  goto _gameLoop clearscreen removes everything from the current  display, then drawscreen draws the sprites in the displaylist. Right now we have no sprites, just a background color. And yes, that is a GOTO. Get used to it. To recreate complex logic in Atari 7800 Basic, you almost can’t avoid using GOTO. Sorry. You can create functions, but they also take-up precious resources, so I mostly avoid themOtherwise you have goto, gosub, for:next and if:then for ALL your branching and logic. Will these limits might break your long-held religious beliefs about programming?  Probably.Will you also get used-to-it and find yourself thinking about how to solve complex problems with just a few control structures:  Also: probably.  _gameLoop is a label, which means it can be jumped to or be the start of a subroutine called by a gosub.  Our “gameloop” is simply a never-ending loop that is called 60 times a second to refresh the screen. This is done with the  last line, goto _gameLoop. All labels start in the first column, most other code must be tabbed in at least 1 space.  When we run it, this a happens Our background color is displayed — Step 3: Game Loop Next we will play with this background color settings to create a good old Atari color cycle. The Atari 7800 has a 256 color palette and we will use ½  of them. You can see the full color palette used in Atari 7800 Basic by opening the Sprite Editor or on The Atari 7800 Basic Guide. We are going to write a quick program to cycle through 1/2 of the colors. First we create a couple variables. dim bgColor  = var1  dim wait = var2 Atari 7800 Basic has a set of 126 built-in spaces for variables. They are named a-z and var1 – var99 You can also set variables to memory locations in RAM, but we don’t need to do that yet. We will create a bgColor variable  to hold the color of the background as var1 We will create wait, which we will use to wait 10 frames before we change the color. Since the NTSC Atari 7800 runs at 60hz, or 60 frames a second, that means we will change the color 6 times a second. Then we will initialize those variables.  bgColor = 0  wait = 0 Next, inside the game loop  we will increment the wait variable, and when it makes it to 10, we will set it back to 0, and increment bgColor. Then we test bgColor and reset it when it gets to 127. Why? no reason we could never reset  it and just let the byte that represents bgColor increment past 255 and it would have become 0, but most of the time we will be setting limits so this is good practice. _gameLoop  clearscreen  wait = wait + 1  if wait > 10 then wait = 0 : bgColor = bgColor + 1  if bgColor > 127 then bgColor = 0  BACKGRND = bgColor  drawscreen  goto _gameLoop Notice in the code above I used a “:” on the if statement line.  The “:” lets you have multiple lines of of code statements on the same line. Now if we compile and run the program you will see the background color changes 6 times a second. — Step 4: Hello World One final touch for this first demo. It can’t be “hello world” unless it says “Hello World”. However, the Atari 7800 does not have any kind of native text capabilities. So instead, we must load in a graphic that represents our text. Atari 7800 Basic provides functionality to turn that graphic into a character set that can be plotted like text on the screen There is a font graphic provided in the sample programs that come with Atari 7800 Basic. To get it, you need to download the Atari 7800 Basic package (see a link the notes: https://github.com/7800-devtools/7800basic/releases), or download the code for this lesson from GitHub (also in the notes) Each character in 160A mode is 4 pixels wide, and 8 pixels high (with one blank horizontal line at the bottom on most characters) You load-in in the sprite  with the incgraphic command. incgraphic font.png 160A Atari 7800 Basic 160A mode supports 4-color PNG files.  Next you use the charcterset command to set the name of the font graphic minus the extension, Then use the alphachars command to tell Atari 7800 Basic which ascii characters are represented in the font graphic  characterset font  alphachars ‘0123456789abcdefghijklmnopqrstuvwxyz>`?!/.,-_()[]&AB ‘ These “font” characters we will be displaying are just sprites cut from the font graphic, and nothing else.  That means we need to introduce the color palettes before we move on. The Atari 7800 contains 8 programmable color palettes, each containing four colors (3 plus alpha channel).  In 160A mode, a single palette is assigned when putting a sprite into the displaylist. In 160B mode, 12-color sprites use either the first 4 or 2nd 4 palettes.  We will get to that in a later lesson. By the way, these palette are completely redefinable at execution time, which makes them very useful for color-based animations. You define a palette like this:   P0C1=$0F   P0C2=$0C   P0C3=$0A This is the “0” palette, signified by the “0” after the P in the variable name. $0F is white, the other two colors are shades of grey. Now, inside our _gameLoop we can use the plotchars command to put  text on the screen plotchars ‘hello world’ 0 58 5 There are four parameters for plotchars Text to display in single quotes The color palette to use The x position of the text in pixels (0-159) The y position in lines of text (about coarse 13 lines) Optional  -number of characters Optional -doublewide Besides text, the plotchars and the associated plotmap and other commands can be used to plot map graphics for games.  These are called character graphics and while they are easy to manipulate, they have restrictions too.  Check out the Atari 7800 Basic guide for more details, Finding the right X and Y position for text may take a few iterations.  I think it took me 3 or 4 tries before it looked like “Hello World” was in the center of the screen. When we run this you should see a color cycling background with the words “Hello World” displayed in White over it. Hello World Atari 7800! You Can get the code for this and all future lessons on our GitHub:  intotheverticalblank/makeathing: Code for making things (github.com) All Links:Links:  Source GitHub : intotheverticalblank/makeathing: Code for making things (github.com) 7800 Graphics Modes And Sprites Tested: Visual Studio Code: Visual Studio Code – Code Editing. Redefined Atari 7800 Basic Github: Releases · 7800-devtools/7800basic (github.com) AtariAge 7800 Basic Forum: 7800basic beta, the release thread – Atari 7800 Programming – AtariAge Forums Atari 7800 Basic Guide: 7800basic Guide (randomterrain.com) Concerto Cart: Pre-production Concerto Cartridge | Erstwhile Technologies (square.site) Atari 7800 Basic Lesson 2: Sprites Note: This tutorial series is designed as video series. The text below is provided as a way to make it easier to follow, but I recommend you watch the video and use the text as supplemental. Introduction In Our first lesson on Atari 7800 Basic we made a simple “Hello World” program with a color rotating background. In this lesson we will begin to turn that idea into a game. The game we are making is called U.A.P. which is the modern name for U.F.O. and stands for Unidentified Aerial Phenomenon The game is based on a certain Discovery Channel TV show. In the game you play the UAP.  But that’s all we know so far. So in this lesson we will design a player sprite and get it moving on the screen with the joystick. — If you are like me, you found out about the Atari 7800 sometime in the summer 1984 reading a magazine like Electronic Games.   And the most exciting thing about the Atari 7800 was its sprite capabilities. Back then, the capabilities of most video game systems were defined by how many objects could be moved around the screen.  The Atari 2600 with the TIA chip had 5 sprites )player1, plater2, missile1, missile2, and the ball).  The Atari 5200 and 400/800 with CTIA/GTIA at 5 hardware sorites, but also a complicated displaylist and charcterset redefinition system  that made it seem like many more.   But the 7800, with it’s MARIA chip offered something different.  According to Electronic Games, it would put nearly 100 sprites on the screen, and would make a game like Robotron, then and still now, one of the most impressive arcade gamesa ever made, possible to create on the 7800 with very few compromises. But then the 7800  wide-release was canceled in 1984, and by the time it came out almost 3 years later, the NES had conquered America. When I finally did get to play the 7800 version of Robotron, I was not disappointed as it was spectacular!   There were so many independently moving objects on the screen, with no flicker, it felt like the culmination of everything we wished for in 1984.  But it was too little, too late by 1987 when I first played it.  I could only imagine what games the 7800 could have had by that year if game developers were three years into the development cycle. So To me, this is the actual lure of the 7800.The “What Could Have been”? And much of that stems from the sprite capabilities of the MARIA graphics chip. — One other note.  Atari 7800 Basic is very powerful, but it;s still a “game engine” built in assembly language that abstracts the full power of The Atari 7800.  In this regard, it’s better than bAtari Basic for the 2600, which but it’s still limited compared to programming in full Assembly language. A good indication of this is how it handles Zones. Recall, “zones” are horizontal bands, 8 or 16 pixels high.  Only a  certain number of sprites, determined by how long it takes to draw each line on the CRT, can be displayed at a time in a zone. Atari 7800 Basic abstracts the programmer from having to deal with the zones. 7800basic Guide (randomterrain.com) This is probably a good thing when you are getting started, but as you advance, you may find that you need more flexibility.  And that flexibility will come with Assembly language.  But that is too much for these tutorials so we will concentrate on what 7800 Basic can do for us. Note: The Three C’s In the last lesson I may have failed to make a few things abundantly clear. These are rules to live by when programming games in Atari 7800 Basic. I call them the “Three C’s”   Code.Case.Configuration. Well okay, I just made that up on the spot, but you’ll see what I mean Code Remember that tabs matter in Atari 7800 Basic. All regular code MUST be tabbed-in at least 1 space, or it will cause errors. All _labels for gotos and gosubs must be in the first first column. There are few exceptions, but we will talk about those if we bet to them. Case Case matters. If the code example says “32k” and the “k” is lower-case, and you use an upper-case “K”, the compiler will throw an error.  Just this one concept can save you a lot of headaches. Configuration VS Code needs to be configured to compile your code using the Atari 7800 compiler that came with Atari Dev Studio.  This usually occurs automatically if you have you saved  source files with the .78b extension.   However, if that does not occur, you need to configure VS Code to compile as a 7800 binary. Check the lower right of VS Code. If it says “7800 Basic” (white text on blue), you are good to go.  If not, click on the text in that location (it might say something like “bAtari Basic” and select Atari 7800 Basic on the selection screen. By remembering the “Three C’s” (Code, Case, Configuration) you should avoid a lot of headaches when compiling. Now onto the lesson Step – 1:  Title Screen / Game Loop First we need to separate our title screen from our game loop so we can have a place to initialize the game and a place to execute the game. We will be working from the code design in lesson 1, Hello World.   The first thing we will do is add a couple more variables : lives and score. We are not actually sure what we use these for yet, but they are indicative of the types of variables our game will use. First we will define them, then we will initialize them. dim lives = var3 dim score = var4 lives = 0 score = 0 Next we will change the name of _gameLoop to _titleLoop and make sure out goto now targets the correct label _titleLoop goto _titleLoop Let’s talk a bit about labels because I believe we glossed over the topic in lesson  1. The labels are “jump” labels and can be used with either goto or gosub.  My convention is to start them with an “_” underscore so I can easily tell them when i see them.  Label must be in the first column of a line.  Most other code must be al least 1 space in, or the compiler will barf and tell you it has no idea what to do.   Next we will change the name on the title screen from “Hello World” to “u.a.p”.  Notice we only use lowercase letters.  That is because only lower case letters were defined in our font graphic. If you want lower and uppercase letters you can draw your own font graphic.  Infact, in the 320 modes with doublewide fonts, you could get pretty elaborate with the design of a font.  If you create text-heavy game for the 7800, you may want to explore those modes and options. Next we plot the new text. plotchars 'u.a.p.' 0 68 5 Then we will test the first and second joystick buttons of the first joystick (joy0fire0, joy0fire1) and if either is pressed, we will jump to a new label named _initGame. if joy0fire0 || joy0fire1 then goto _initGame In _initGame we will reset everything.  This is redundant now, but as the game gets more complex there will be certain variables we want to initialize before the game executes and ones we want to reset every time the game starts. _initGame lives = 3 score = 0 BACKGRND=$00 And now we will create a new function named _gameLoop.  It will look pretty much like the old _titleLoop, except we draw some placeholder text that says “game” to remind us that we are no longer on the title screen, and the game is about to start. _gameLoop clearscreen plotchars 'game' 0 68 5 drawscreen goto _gameLoop When we compile and run the code, it looks like this: The title screen will still rotate colors but it says “U.A.P.” now.By pressing fire button 0 (Z-key or joystick button 0), the title screen will disappear and we see the “game” placeholder text. Now, I edited this lesson to make it look like I got all of this right the first time, but that is not the case at all. In fact, the first time I compiled I got an error, so I’ll show you what that looks like. The complier will stop and give you information to help you figure out what is wrong. The most useful information for beginners is this list of unrecognized symbols. Ignore the ones that you did not define,and look for things you might have messed-up. For this step I forgot that the name of our loop label was  _gameLoop not _gametitle.  Another common error with labels is not left justifying them. Most other code needs to be at least 1 character or tabbed in.   But labels need to be in the first column. So if I go ahead and fix the code and re-run, the code executes as expected. Step – 2: Drawing Sprites. So I’ve just been clicking things on this menu bar at the bottom of the screen and not talking about them. This little bar at the bottom right of the screen was added by Atari Dev Studio.  The functions are :  Welcome – takes you Atari Dev Studio Plug-On Page Sprite Editor – it is what it says it is  Compile Compile and Run We will spend most of our time on Sprite Editor and Compile and Run To create a player sprite for the game we will click the Sprite Editor button. You see a screen that looks like this: Now we create a new sprite file that is 16×16 with 4 colors for mode 160A, NTSC by pressing the Project+ button on the left. The windows can be arranged to make it easiest to see everything. You can grab them and move them around, resize, etc. I usually resize so I can see an entire sprite, and also the current set of sprites in sprite file I’m making.Next we set our colors.  For the sprite I’d like to white, grey and red Recall, as I draw this UAP sprite, that 160A mode have more pixels in the y, and less in the x, so we need to accommodate that when we draw. Sprite file and .spe extensions, and can hold as many sprite definitions as is reasonable to work with. .spe files are not sprites through. Each  sprite must be exported as .png to be used in a game. When I’m done designing the first UAP sprite, I want to make it animated by inserting a few little details that can move when we add more frames. I press the copy sprite button, and edit the sprite to make it animate.   I do this two more times so my UAP sprite, the player (as you play the UAP in the game) will have four frames.   … Next, I save the player sprite .spe file in a subdirectory of my project name “images”. I call it player.spe.   Then I export each individual frame as a .png file, naming them player1 through player4. Now we are ready to load this sprite into our Atari 7800 game and display it. Step – 3: Displaying Sprites Now we will display these 4 sprite frames in succession to make it look like our UAp is animating.The first thing we need to do is to create a color palette to match the colors we used in our sprite.   We can find the colors we need to set in 7800Basic by looking back in the sprite editor and rolling over each color to find it’s hexadecimal value. In this case the values are $0D, $08, $33 which are two shades of gray plus a deep red. rem pallette 1 player P1C1 = $0D P1C2 = $08 P1C3 = $33 Next we will include the sprite images we created. The order of the inclusion is VERY important. The order of the sprites is used for animating them. You can easily animate sprites that are loaded in succession. incgraphic images/player1.png 160A 0 1 2 3  incgraphic images/player2.png 160A 0 1 2 3  incgraphic images/player3.png 160A 0 1 2 3  incgraphic images/player4.png 160A 0 1 2 3  The file names of the sprites will be used directly in the code to identify them.   They can’t contain any special characters, and need to start with a  letter. After the name, you have other optional parameters. “160A” is the graphics mode of the sprite.  If you don’t specify, 7800 Basic will default to 160A, which are 3-color sprites.   However, in the next lesson we will see how we can load 12-color sprites in the same way by specifying “160B” The other numbers are color indexes.   These can be very confusing, but we will have an example in just a bit that shows how to use them. Next we will create a couple new variables to hold the X and Y location of the sprite: dim playerX =var5 dim playerY = var6 And initialize them to 0 playerY = 0 playerX = 0 In the _initGame subroutine we will then initialize the values for the start of a game: playerX = 70  playerY = 90 This is a good time to explain variables a little more in depth. In the first tutorial we told you that the Atari 7800 Basic has 126 built-in variables var0-var99 and a-z.Some functions in Atari 7800 Basic require the a-z variables, so I avoid using them. You can also assign direct memory locations to another 1535 single byte variables, which is ample space for most simple games. 7800basic Guide (randomterrain.com) Each variable in Atari7800 Basic represents a single byte, which of course can hold numbers from 0 through 255. Luckily for us, in 160A mode, the screen size is 160×192, which means a single byte can hold the X position and a single byte can hold the Y position of any sprite. Now, let’s draw the sprite in our game loop using plotsprite _gameLoop clearscreen plotsprite player1 1 playerX playerY drawscreen goto _gameLoop The plotsprite command 5 parameters: Name of sprite to display (filename without the extension) Palette number (we defined our sprite colors in palette 1) X location Y location Animation frame (optional, but we will use this soon) When we compile and test this code, our UAP sits pretty much in the center of the screen. Okay, this is where things get a bit technical. Now, let’s look at the compiler output to understand a little bit better what we have done. With the font and 4 player sprites loaded we have used just about 1K in the ROM (2992 bytes left) in the current block.  Graphics are stored in memory ROM  blocks on the Atari 7800. For a game with zoneheight of 16, the graphics blocks are 4k in size. Graphics in different blocks will not easily animate so as you create more and more graphics to load into your game, you might need to manage the order of how things are loaded.    Also, the more graphics you have, the more chances you will need to use bank switching. Blocks are created automatically when graphics are loaded, or you can use the “newblock” command to force a new block. One more interesting thing to see here The second to last line says “$1830 to $1fff used as zone memory, allowing for 31 display objects per zone.”With a height of 192 pixels and a zoneheight of 16, that means we have 12 zones. 31 display objects per zone = 372!!.  So conceivably we could get 372 sprites on the screen!! This why people were so excited about the MARIA chip in 1984! However, even though a zone can has the memory for 31 objects!, that doesn’t mean they can be displayed in the time it takes to draw each scanline. Also, those display objects are EVERYTHING including and text or background map objects, etc. Don’t worry though, there are ways to expand this using extra RAM in the cart and double buffering will help make sure everything needs to draw gets displayed. Step – 4: Animating The Sprite To animate the sprite we need a way to remember which player frame we are displaying. I like to use very very descriptive variables, so we will call this one playerAnimFrame.  dim playerAnimFrame = var7 We will initialize it before our game starts playerAnimFrame = 0 And also after our _initGame label  playerAnimFrame = 0 Then in _gameLoop we will add the playerAnimFrame variable as the last, optional parameter to plotSprite. After that we increment playerAnimFrame, then test to see if it is more than 3. If so we set it to 0.    _gameLoop clearscreen plotsprite player1 1 playerX playerY playerAnimFrame playerAnimFrame = playerAnimFrame +1 if playerAnimFrame > 3 then playerAnimFrame = 0 drawscreen goto _gameLoop Notice a couple things here. We only ever have to use the name of the first sprite, “player1”.  Because we loaded all 4 sprites in sequence, it will treat the  subsequent sprites as a “frame” of this first sprite if we use the optional frame parameter as we did here. There is no magic here.  The “frame” parameter is simply moving to the next 160A, 4-color sprite. This could be ANYTHING.  For instance, if you have an explosion that is loaded directly after the player sprite, and you don’t reset the playerAnimFrame back to 0 when it’s above 3, your explosion frames will be displayed. Now let’s test this. When you press the “rocket” and compile this version, you will see the UAP animating very quickly in the middle of the screen.   It’s neat, but too fast. There are many ways to slow this down, but we will employ one that will be necessary for our game: double buffering. 7800basic Guide (randomterrain.com) Double buffering allows you to define how many frames it will take to draw the screen. It also regulates the frames using a timing delta calculation so animation is smoother. This is a function of Atari 7800 Basic provided to help manage sprites, zones and memory, and it;s very useful one.   In our  boilerplate at the top of the program we will use the doublebuffer directive to turn on the functionality  doublebuffer on Then in _gameLoop we will replace drawscreen with this line of code doublebuffer flip 2 “flip 2” tells Atari 7800 Basic to use two frames to draw the screen. When we compile and run this version, you will see that UAP animates slower at 30fps or 30hz and not the default 60fps or 60hz.     Let’s look at the compiler output. Now the compiler tells us that we can only get 14 objects per zone.  This is because doublebuffering is turned on.  The resources needed to smooth out the animation mean there is less memory for sprites.  This is fine, don’t worry.   We were never getting 300+ sprites on the screen anyway.    There are other levers we can pull to get more sprites in zone that we will learn about later. But we are now getting closer to a more realistic number of sprites that can be displayed.     While we will ultimately need doublebuffering for this game, it’s not a great way to control the speed of animation.  Most likely we will want to control each sprite’s animation individually. To do this we will create a  new variable name playerAnimWait. We will use the variable to count frames before we move to new animation frame  dim playerAnimWait = var8 Will will also initialize it like  the other variables:  before the game start running andafter the  _initGame label  playerAnimWait = 0 And: And _initGame playerAnimWait = 0 Now, in the game loop, instead of incremented playerAnimFame every _gameLoop, we will count to “3” by incrementing playerAnimWait.  Every time it goes above 2, we will then increment playerAnimFrame.   By doing this we will get much more control over the speed of the sprite animation. _gameLoop clearscreen plotsprite player1 1 playerX playerY playerAnimFrame playerAnimWait = playerAnimWait +1 if playerAnimWait > 2 then playerAnimFrame = playerAnimFrame + 1 : playerAnimWait = 0 if playerAnimFrame > 3 then playerAnimFrame = 0 doublebuffer flip 2 goto _gameLoop When you compile and run this time, you will see that the sprite animated slower, but also that the middle portion doesn’t look quite right.  Now that we actually can see the sprite, we can also see how it animates.  Let’s go back into the sprite editor and update the frames to make a different animation,. Instead of animating horizontally, let’s make the middle portion animated vertically.  … Now. Save the player.spe when we are done, and export each frame again. When we compile and run the code again, something odd happens.  It looks like a couple of the colors are different than what we defined in the spirite editor. This happens a lot.   There is an explanation for it, about how the different indexes get transposed depending on which color is used first, or something, but I’ve never quite understood.  What it means in practical terms is that you can’t always trust the colors as they are saved in the .png, and you might have to reorder the indexes. The good news is, there is an easy way to fix this, but it might take bit of trial and error.Remember those final parameters on the incgraphic command: incgraphic images/player1.png 160A 0 1 3 2 incgraphic images/player2.png 160A 0 1 3 2 incgraphic images/player3.png 160A 0 1 3 2 incgraphic images/player4.png 160A 0 1 3 2 These are the MARIA chip color indexes.  To fix this little color glitch, all we need to do it swap the 2nd and 3rd indexes when we load the sprites . Now, when we compile and run, the colors look correct, and the animation is smooth. By the way, Atari 7800 Basic has some recent functionality that allows the programmer to extract color values directly from the loaded .PNG sprites. And putting them into color constants: 7800basic Guide (randomterrain.com) I have not used this functionality yet myself,  but it looks very interesting. (now, now I HAVE used it, and it will feature in a future lesson). Step – 5 : Move The Sprite! Let’s finish up this lesson by allowing the player to move the UAP around the screen using  joystick 0. Honestly this is the easiest lesson yet. All we need to do is stick this very much self-explanatory code in _gameLoop:  if joy0left  then playerX=playerX - 1 if joy0right then playerX=playerX +  1 if joy0up  then playerY=playerY - 1 if joy0down then playerY=playerY +  1 We will move the UAP 1 pixel depending on which direction of joy0 is pressed.  This code is in no way optimized.  We should add a “controlWait” counter as well, or we will read the joystick or fire button 30 times a second which might be too many. But for now, let’s compile this code and start moving! Well that is it for lesson 2.  Be sure to read the notes and download the code from GitHub.Good luck and let;s get some great new games on the Atari 7800, history’s most underutilized game console! Until next time, Into The Vertical blank! Feel the urge to support, click here (but no obligation): https://www.buymeacoffee.com/intotheverticalblank?fbclid=IwAR0ryLpAIZPgDgjZqSmMmXLVIOFKWtSDVymoPXsJoj3KsEI0x0KCQOpJMpM You Can get the code for this and all future lessons on our GitHub:  intotheverticalblank/makeathing: Code for making things (github.com) All Links:Links:  Source GitHub : intotheverticalblank/makeathing: Code for making things (github.com) Visual Studio Code: Visual Studio Code – Code Editing. Redefined Atari 7800 Basic Github: Releases · 7800-devtools/7800basic (github.com) AtariAge 7800 Basic Forum: 7800basic beta, the release thread – Atari 7800 Programming – AtariAge Forums Atari 7800 Basic Guide: 7800basic Guide (randomterrain.com) Concerto Cart: Pre-production Concerto Cartridge | Erstwhile Technologies (square.site)\ Atari 7800 Basic Lesson 3: Title Screens Part 1: Title Screen Do title screens matter? I think they do. They are like the bow on the wrapping of a present: Not necessary, but kinda cool none-the-less, and almost expected once you realize it is not there. If you didn’t grow-up in the golden age of Atari video games, you might not realize that a decent title screen for a game was not always a foregone conclusion.  Many computer games had nice title screens, as did arcade games. Computer games had their pedigree from college campuses and the garages and bedrooms, of hobbyists, where free expression was not only possible but encouraged.  Early companies like Sirius, Broderbund and MUSE making games for the computers like Apple 2, TRS-80 and Atari 800 used nice title screens to introduce their games in imaginative ways. Arcade games had to stand alone in large rooms begging for quarters, so very early it was established that they could benefit from elaborate attract modes and title sequences to get people interested in the games they held inside. But early video games systems with their comparatively limited storage, memory and processing capabilities eschewed title screens for color-cycling static screens, and let the box and manual do the talking.   They needed to get as much bang from very little buck as possible. Astrocade, Channel F, Odyssey 2 But this held true even when conventional wisdom might make you think it was not so. Even Atari VCS games one might think would have elaborate title screens given their relative importance and history for the VCS, really did not. Games like Superman, Adventure, Asteroids, Space Invaders, Missile Command, Yar’s Revenge, Pac-Man, Defender, Berserk and Vanguard eschewed any type of window dressing so every single bit of ROM onto the screen. Asteroids, Missile Command, Pac-Man The first exception to this might have been Howard Scott Warshaw’s twin releases of Raiders Of The Lost Ark and E.T. both of which featured elaborate title sequences.   Both Mattel and Coleco, Atari’s main competitors at the time, used uniform start-up screens that helped give their games a sense of community with the rest of the titles. Mattel used a standard  Green with white text title screen that was facilitated by the  system ROM. Coleco used an attractive branding of their logo with simple text to introduce the game, that usually lead into a game select screen.   While not exciting, they were attractive in a way that made it look like Coleco cared about having a common look and feel.  This changed over time. By the time War Games and Rocky were released they had added some animated intros that while not exactly title screens, seemed to understand the concept. I can’t pinpoint the exact moment title screen became important for VCS games, but it was sometime after the release of Ms. Pac-Man in the spring of 1983 when Atari was struggling to make a profit and losing game player mindshare to the likes of Coleco who brought fresh perspective to home video games with arcade-like graphics matched with unique games that did not feel stale.  For instance, Coleco’ pack-in game was Donkey Kong, then still one of the hottest games in the arcade.  By contrast, Atari’s 5200 included Super Breakout that, while a decent game, was almost 6 years old at the time. While the 5200 used a common intro screen similar to Coelco and Intellivision Many of the actual title screens were taken directly from their Atari 400/800 brethren, and while functional, many were not very impressive or uniform and made the games for the system seem like they were created willy-nilly.  In fact, after reviewing them for this lesson, I was surprised at how slap-shod they look.  Individually they are fine, but as the “Super System” from Atari, they look amateurish.  So by late summer 1983, The 5200 was not selling well, the VCS business was crumbling because of poor distribution planning and loss of consumer confidence in the platform, while the Colecovision was killing it.    Atari needed to do something.   The approach to title screens on VCS games became much more elaborate.  Maybe this was a directive from inside Atari, or maybe it was a result of many of the games being contracted out to GCC, the inventors of Ms. Pac-Man and the eventual designers of the Atari 7800.Whatever the reason, VCS arcade translations games like Centipede, Dig Dug, Phoenix, Jungle Hunt, and Moon Patrol each contained elaborate title screens and attract modes that went far beyond the arcade games from 1980-1982.   Atari 2600 Arcade Conversions These games were 8 and 16K carts that used bank-switching to creating their impressive title screens.  Even if the games themselves could not match Coleco’s near arcade quality, they title screens might pull some people in.  In may ways, these title screens from latter VCS games are like animations from the later Amiga and ST “demo scene”.  They push the limits of the system in ways no one ever thought possible.  In some cases it was lipstick on a pig, but you can’t deny that some of the title screens (and also many of the games) from the last years of Atari Inc.’s VCS output were pretty impressive. For the 2600 and the 5200, the epitome of the title screen might be Gremlins, a game released for the Atari 800, 5200 and 2600 near the end of Atari’s inc’s reign in the summer of 1984.    Both feature attractive title sequences and colorful, decent action games. 5200 Gremlins It feels like Atari finally learned their lesson on how to present their games that were translations of from other popular media, but it was too little, too late.    With the 7800, it appears Atari was not going to make the same mistake. When it came to the first batch of games GCC designed for the 7800, it is apparent that good title screens were not an afterthought.   Since the 7800 was a very capable machine, it was the first time all the games had some kind of standardized title screen. In fact the first 11 games, all developed for release in 1984, used a very similar style of title screen. First batch of 7800 games from 1984 While not all of the screens and logos matched the arcade counterparts, the effect of was a pleasing, almost uniform style for the first time on an American video game console.When the 7800 was finally released, the 2nd wave of games like Dark Chambers and Cracked used a wide variety of different title screen styles, as did. Later 7800 games used even more elaborate title screens that mirrored 3rd party screens for competing platforms, for example, Alien Brigade and Motropsycho. As a kid, I followed each nuanced change, update and advance to video games like it was a work of great art.   I loved Atari, but I could see how they were faltering.  Seeing the title screens 7800 AND gameplay  gave me hope that Atari was doing it right.  However, since these games would not see the light of day for almost two more years, the NES beat the 7800 to the punch with it its own uniform style.   And this, like many other things we’ve discussed in out video and podcast over the years, is essentially what we call “The Vertical Blank”.  It’s “what could have been” .   The nice thing is, with Atari 7800 Basic we no longer have to speculate about “what could have been”, we can just try it ourselves.  It may not be a time machine that lets us go back and change the course of video game history, but it just might be the next best thing, I try to create a title screen for my games as soon as possible, because it makes me believe they are “real”. However, from my own personal track record of releasing 7800 games (one), you might think the title screen would be paramount.  In fact, my single “released” games, my Last Stand Halloween demo, is the one game I never made a title screen for.  Oh well. Note:  Atari 8-bit In the last episode I said the Atari 400/800 could display 5 sprites.  While this is technically true, it needs more explanation.  The Atari 400/800 could display 4 sprites and 4 missiles and the four missiles could be combined into a 5th sprite.   The point though, was that the 7800 Maria chip was completely different kind of architecture.   Part 2: What Game Is This? So now it;s time to take a step back and think about what kind of game we want to make.  Don’t worry, we will get some coding  done in this lesson too, but just for a bit, let’s think on what exactly we are doing here. To get inspired, first I’m going to create a “banner” graphic (one that is larger in height that the zoneheight), In this case 96×32.And we are going to do it in 12 color. This is graphic designed for Atari 7800 graphic mode 160B Here goes! (watch the video to see the title being drawn) There is a show on The History Channel named The Secret Of Skinwalker Ranch.   If you have not seen it, it’s about a real ranch that is supposedly some kind of portal or interdimensional gateway.  On the show they are always shooting rockets into the air with various sensors, trying to simultaneously get UAPs to appear and to figure out where they might be coming from.   They use cows as “biosensors” because there have been some supposed animal mutilations in the area, they fly drones, and the owner of the ranch uses a sleek, black helicopter, flown by his brother, to help with the experiments.  It’s simultaneously fascinating and preposterous.   But for the sake of this game we will pretend like it’s all true and there are many ranches like Skinwalker with interdimensional portals above them, and this game takes place on one of them, but not necessarily the one from the show. The UAP you are flying is sort of interdimensional Uber transport. When a level starts, you arrive above the ranch in your UAP.  The portal you came through closes, and the next portal will not open until you collect enough “orbs” to energize the next one.   With enough “orbs” collected, the next portal opens and you can slip through to whatever dimension you need to go. But while you are on the screen collecting orbs over the ranch,  the “scientists” on the ground will be shooting rockets at you.   They will send drones, and if you miss too many “orbs” the black helicopter will show-up. If you collide with any of the objects, your “visibility” factor will go up. The worst thing for a UAP is to be so visible that someone can take a full photo of you. If you hit 3 objects on any level, a photo is taken, and the game is over. However, you have a chance. Cows happen to be your saving grace.  If a cow appears on the ground, collect it and your visibility will go down. You also have your own 1.6ghz wave-beam that can shoot the enemies out of the sky, but you can only have one beam on the screen at a time, so use it wisely. And that’s it.  Each level will get harder and harder, but that’s the basic game. We will use the full screen for the game,and let the player UAP move anywhere.  They game will be styled a bit like Robotron, and we will use it as a way to see just how many animated spirited we can get on the screenNow let’s load-in that title screen image we just made, and get moving! —- Part 3: More Memory And The Banner So let’s start by changing a bit of the boilerplate we used in the previous lessons.   Remember when I said we may only ever need 32K?  Well, that was just to not confuse things.  But now that you have some idea how things work, and you have seen a little a bit of how the 7800 uses memory, let’s expand the cartridge format a bit. set romsize 128kRAMset dlmemory $4000 $7FFF The first line sets the cartridge to 128K ROM, which will give us eight 16k banks to work with.  We will not talk about bank-switching yet, we are just getting ready for it.   The RAM of “128kRAM” means the cartridge we will be using has an extra 16K RAM available and addressable at all times.   THIS IS HUGE.  The Atari 7800 by default has 4K of RAM, which is okay, but not great if we need to track and display lots of objects on the screen with lots of properties.   “Set dlmemory $4000 $7FFF” takes extra RAM and uses it to expand the DisplayList of the 7800, which in-turn will allow more objects per zone.     So now Let’s display our title screen. To do this we will use a new function named “incbanner”.  incbanner tell Atari 7800 Basic that the graphic we are loading extends higher than the current zoneheight of 16. incbanner  images/title.png 160B Notice the 160B that comes after the filename.  That tells Atari 7800 Basic that we want to load a 12-color bitmap. In our _titleLoop function we will now display the title graphic using the plot banner command.  plotbanner title 0 32 50 Plotbanner is similar to plotsprite.  The first parameter is the name of the graphic to display, followed by the palette, and x and y location.  Notice only set a single palette, even though the sprite use the 12  colors.   This is because 160B sprites uses the first four or 2nd four pallettes.   For a 12-color graphic specify palette 0 for the first 12 colors, or palette 4 for the 2nd 12 colors Save the file, then let’s test it out.First but let’s look at the output window. Notice at the top, it loaded “title” as two sprites, title00 and title01. That’s what loadbanner does. Also, before we loaded the title, we has 2992 bytes left in bank#1, now we only have 1456, so the title with 12 visible colors is about 1.5K in size!   160B sprites can be large, so it’s good idea to limit them or manage them into multiple ROM banks.It now says we can have 136 objects per zone.  This is because of extra memory we added.  Now, practically, there will be no way to get 136 objects per zone in an action game, and we may find out we need some of that extra RAM for our active game data, but for now we will just keep it like this. What you will see is something like this: The colors are all wrong and we still have that color cycling background. The first thing we will fix is the colors. Recall, we set the color palette for text and sprites above all of our code in our previous examples.  But we need to be more flexible than that.  The color palettes on the 7800 are redefinable at run-time, and we want to make use of that feature. So first, let’s move our original color palettes to _initGame. _initGame lives = 3 score0 = 0 BACKGRND=$00 playerX = 70 playerY = 90 playerAnimFrame = 0 playerAnimWait = 0 rand = randomSeed gosub _randomOrb orbAnimFrame = 0 orbAnimWait = 0 rem pallette 0 text P0C1=$0F P0C2=$0C P0C3=$0A rem pallette 1 player P1C1 = $0D P1C2 = $08 P1C3 = $33 rem orb colors P2C1 = $92 P2C2 = $94 P2C3 = $99 Next, we will create a new label named _setTitleColors. This label will allow ud to set the colors once and then drop into _titleLoop. We donlt need this function now, but when we have a function to restart the game, we will want reset the colors so the title graphics displays correctly Then, after the _setTitleColors label, we will load all the color constants that Atari 7800 Basic created for the titlegraphic. _setTitleColors P0C1 = title_color1 P0C2 = title_color2 P0C3 = title_color3 P1C1 = title_color4 P1C2 = title_color5 P1C3 = title_color6 P2C1 = title_color7 P2C2 = title_color8 P2C3 = title_color9 P3C1 = title_color10 P3C2 = title_color11 P3C3 = title_color12 Recall that this is a new feature I just discovered by reading the Atari 7800 Basic Guide (I think from lesson #1).  Previously in my games, I had to set all of these colors manually.  In some cases, it took DAYS to swap all the colors of a multi-sprite, 12-color graphic, just to get them right. However, these new constants are created when the graphic is loaded, in the format of [filename]_color[x}.  So now we can set the first 4 palettes on the 7800 with these constants!  It makes everything easy.    How 160B, 12 color images use the 7800 color palettes Now that we have set the colors, let’s run the program again and see what happens. Ah look our colors are right. Part 4: Cleaning Up So now that we have a proper title screen graphic, and we have idea for what we are making, let’s clean this up.   We no longer need to cycle the background color, as. Let’s be honest, it’s pretty annoying. We will also add a subtitle “Quantum Lay Over”, because in the game we are at sort of interdimensional rest-stop, waiting to get out. We will also add the and then the text “Fire To Start” as an instruction to the player . _titleLoop clearscreen plotbanner title 0 32 50 plotchars 'quantum lay over' 3 47 6 plotchars 'fire to start' 2 54 10 if joy0fire0 || joy0fire1 then goto _initGame randomSeed = randomSeed + 1 if randomSeed > 254 then randomSeed = 1 drawscreen goto _titleLoop For the new text we set the palette colors to 3 and 2, which will use the colors in those palettes to display the text.   I’ve rearranged the locations a bit to optimize the look of the title graphic and the text. When we run it, we see this, which I think is not too shabby. And there we have it, a decent little title screen for our 7800 game.So that was shorter lesson this time, but we learned some value things about sprites, colors and memory.  Get the code from GitHub here:makeathing/Atari7800/Atari7800Basic/Tutorial at main · intotheverticalblank/makeathing · GitHub