Mr SQL

Here is the latest build of Scrollout: Scrollout7.bin I really like the French Retro Gamer Review of Scrollout: Don't be fooled by Scrollouts graphical resemblance to some of the first primative Atari games, Scrollout is a new genre... the beauty is in the gameplay... once you have sent the Ball wisely breaking through the first barrier it disappears to a distant plane of the table where you can listen to it or follow it as you choose. And now you also have more control of the ball to subtly change the angle on it's long journey through the virtual world for more interesting gameplay. I've slowed it down a bit too. And if you have a black and white Television, Scrollout supports the BW switch and changes to an all grey scale palette like some of our favourite retro games

Excellent game RT! Very challenging with fantastic sound effects and melodious chip tunes This is easy to play but the difficulty rating for clearing a board is definitely pong champion! This is a great addition for retro parties

FalseApricot, if you can get DASM running under dosbox, the ASDK is another option you can use to write games http://atariage.com/...25#entry2737902

SvOlli, I remember Apple having a fit over the C64 emulator being able to run code; it went back and forth for a bit but I think they eventually re-released a functional version after locking it down. Has anyone ever used a C64 Editor/Assembler to write Atari games like with the Apple? Awesome presentations btw - I watched your sequel to The Ultimate Talk, fantastic!

Thanks GroovyBee! Agree those are Microvision pixels

Here is the latest version of the ASDK with the following updates: asdk.asm ;---------------------------------------------------------- ;-- Updates: ---- ;-- 20130408 PT4WD: Primary Kernel can now be disengaged when not scrolling ;-- 20130409 Solid 262 scanline timing fix from Omegamatrix: ;-- Scanlines previously kept spiking to 263 when scrolling; see friendly name timing constants. ;-- 20130412 playfield pixel updates are now visible with or without the primary kernel ;-- 20130415 pixel setting routines optimised for better perf since they are heavier ;-- 20130415 rendering engines moved to bank1 to free up more room for game code here in bank 0. ;---------------------------------------------------------- I used this version for SCROLLOUT (the game version, not the demo): http://atariage.com/...all-atari-2600/

SCROLLOUT - follow the Ball! New! ATARI 2600 PORTABLE compatible! Is a scrolling Breakout game where you control the scrolling; once you breakout into the land beyond you can sit back and listen to the ball bouncing all around the virtual world, or you can follow it with the camera and put English on it to influence it a bit. You have unlimited lives and the game is completed when there are no more blocks on the screen. The character in the center of the screen, is also playing Scrollout Scrollanoid features an original chip-tune composed by Der Luchs! An expanded and extended version of the game called SCROLLANOID is under development. Play on the real hardware if you can; phosphor should be turned on in Stella and OpenGL drivers should be installed if you are using the emulator or Scrollout will not display properly. Enjoy the game, ideas and comments welcome! scrollout5.bin Here also is the previous version of Scrollout which is almost impossible to play but an interesting demo: Scrollout2.bin Edit: Flashback Portable Support added! All Atari 2600 consoles are now supported! Scrollout7E.bin

LOL! I didn't realise I had initialised the stack to 254 instead of the large timing loop Thanks again Omegamatrix!

Awesome Omegamatrix! Thank you I think you must have optimised for a few cycles somewhere or possibly started one of the timing blocks earlier - very curious as to where and trying to find it now - I spent lots of time trying to stabalise this at a solid 262 so that PAL 262 users would not lose colour. I like the friendly names for the constants too! TIME_OVERSCAN1 = 35-1 ; $D38A TIME_OVERSCAN2 = 35-1 ; $DA0D TIME_VBLANK1 = 43 ; $D2B1 TIME_VBLANK2 = 17 ; $D9D5 TIME_BIG = 255-1 ; $D9DF

Omegamatrix, thanks I gave this a try and changed those three spots but still see it alternating between 262/263 whenever you scroll and then going back to 262 solid when not scrolling; did this fix make it 262 solid when scrolling on your version of Stella??

Definitely stay! It would be fantastic if you could write a catchy tune for the ASDK demo's: http://atariage.com/...b-and-the-asdk/ The next chapter is going to be on editing the music table, I will translate your bB example and integrate it into the chapter. I also have a game I'm working on that needs a cool background tune that I will PM you about

You're welcome Loon! I thought you would like that Yes I'm not sure where that is comming from but fortunately it's only one scanline variance; the flicker version did that too and even stranger, depending upon where in the virtual world you stopped scrolling it would either say 262 solid or 262/263 fluctuating.

I've added a flicker-free mode to the ASDK that works like parttime 4WD It takes advantage of double buffering to disengage the primary kernel whenever the playfield is not scrolling across the large virtual world. This works out quite well because the flicker effect is far less noticeable when scrolling than when the playfield is static, and it gives a sense of motion when scrolling (you can still tell you're scrolling even if you're scrolling along continuous or uniform content). Here's the source with slightly different demo's from my Assembly tutorial thread: ASDK_pt4wd.asmASDK_PT4WD.bin The scrolling still looks better on the real hardware than windows stella unless you enable phospor and get the OpenGL glide drivers. Couple of minor changes - the game loop has been relocated and you don't need to call the "drawscreen" routines anymore, instead a toggle variable is set whenever the playfield scrolls across the virtual world. Note the Assembly example that draws the playfield on the sprite is still placed between the two rendering engines. Also the gameloop has less time than before (still plenty) and an additional gameloop can be declared in the header if more time for game logic is needed.

Cybearg, I found my way here from your other thread on Assembly, lots of complex code here! There are some simple examples of using Assembly or bB to assign sprites to players from a single sprite bank using an offset variable on my thread on learning Assembly.

SeaGtGruff, this is interesting! Has me thinking about making a 192 line PAL/50 version of the ASDK kernel that could run without flicker because of the extra block of time for the scrolling engines; not a bad tradeoff for a slightly squashed image. I prefer HD too and plasma over LCD, but when widescreen/halfscreen first became popular many years ago I was using an ordinary NTSC Television and it suddenly felt low resolution. I find I really miss programming on a CRT though; it has a warmer feel, the pixels are a softer hexagonal shape and always the right size. In order to properly display the 800x600 resolution I like on my LCD monitor I had to find one with 1600x1200 native resolution so that it could build square pixels for a genuine 800x600 display instead of displaying a dithering algorithm.

Lesson 3: Virtual Worlds and Playfields Topics: Load a different virtual world (just like loading another playfield in bB). Edit virtual worlds (like editing a playfield with bB). Set pixels anywhere in the virtual world Check pixel status and flip them Pan the camera to any part of the virtual world Scrolling around the virtual world using Assembly or bB. Load a different virtual world If you scroll down further in the initialisation section you will see the call to load the large virtual world into RAM: Note: The “Superchip” used is the double superchip, or CBS RAM which sports 256 bytes instead of 128; this is important because the large virtual worlds are 240 bytes in size! There are two other predefined virtual worlds that can be loaded with these descriptive calls: CallBank1ToLoadCBSRAMwithLargeBitmapSayingREADYPLAYER1 CallBank1ToLoadCBSRAMwithGameScreenBitmap Just edit the call in the initialisation section to load one of these other virtual worlds instead. Editing Virtual Worlds The virtual worlds are in WYSIWYG format similar to a bB playfield only “1” denotes the pixel is on and “0” means it’s off. Here is the first one, the other two are located below: There are twenty rows of 96 pixels, however the first four pixels are not visible for an effective virtual world resolution of 92x20 with a 20x10 playfield window that can be panned anywhere within. Note that the “%” is just a prefix for the Assembler that means we are using binary and can be ignored for now (we will cover it later) since using binary to construct a bitmap image is already intuitive and visual; you can see the corner of the larger virtual world outlined above and if you look around the image you will see the word Atari and the other designs. Play around with changing and customising the bitmap image. Adding more virtual worlds When we get to the lesson on bank switching (optional), you will be able to add more virtual worlds as they live in the second bank. For now you have three virtual worlds you can customise. Building dynamic virtual worlds It is possible to have an algorithm construct the virtual world just like with bB playfields; samples should be easily adaptable as follows. Setting pixels on the virtual world bitx and bity are the x and y coordinate variables for the virtual world. getbitstatus is the function to call. As this is a complex function, an argument is also passed in the Accumulator: 0 – Invert the bit; off if it was on, and on if it was off. 1 – Always turn the bit on, and pass back its previous state in the Accumulator. This gives us the ability to set, invert or poll specific pixels anywhere in the large virtual world. Setting a pixel Here’s an example setting pixel 1,1. Add this code to the game loop section of our latest Assembly file, asdktutr3.asm: ;---------Set pixel 1,1 on the Virtual World lda #1 sta bitx sta bity lda #1; argument to pass: turn bit on jsr getbitstatus Compile your code and launch it in Stella to check; you should see that pixel 1,1 has been set: Inverting pixels Inverting a pixel instead of setting it done by passing a zero in the Accumulator instead of a 1, then the pixel will be flipped from whatever it’s previous state had been. Poling pixels Note that the function call returned the previous status of the bit in the Accumulator, it was off in this case so the value is zero; if we had wanted to know the status of the bit but didn’t want to set it we would simply set the pixel as per our example to get it’s status - if the status came back as previously clear, we could just call the function again to flip the pixel back off (the poling function is built from stacking a set with a possible invert). Here’s the example: ;---------check the status of a pixel on the virtual world: ; --------(using set and invert functions) ;---------Set pixel 1,1 on the Virtual World lda #1 sta bitx sta bity lda #1; argument to pass: turn bit on jsr getbitstatus ; set pixel 1,1 ;------------------------ ;--- the accumulator now has the previous status of the bit (0 or 1) sta b ;store bit status in var b to work with it ;-- restore previous bit status with a 2nd call: jsr getbitstatus ; invert pixel 1,1 OR set pixel 1,1 (depending upon argument) ;------------------------- As you can see, we’ve built the poling function by just repeating the dual purpose set/flip function call again after first storing the target bit’s status in a variable. Pan the Camera to any part of the virtual world For this example, we will slide the playfield over the Atari text in the large virtual world by setting the camera to position 42,9 in the virtual world: Here’s what’s gong on with the purple code: BITIndex is the x position variable for the camera, we’ve set it to 42. The camera y position is a bit trickier, we are using an offset (BYTErowoffset) we increase by 12 for each y position increment, which is what the loop does; we could have done the calculation ourselves as well. Note: There is a “hidden” Assembly instruction in the loop! DEX (decrement X) also does an automatic compare against zero: “CPX #0” This hidden comparison allows the BNE (branch if <>) to keep looping the code until X reaches zero. Scrolling around the virtual world For the next example, we’ll use the joystick controllers to scroll the camera around the virtual world! And we’ll use bB to help us build the Assembly code. Using what we know to calculate BITIndex and BYTErowoffset this is pretty easy; we set up some aliases so we can use the ASDK variables for the camera and here we go: Compile your bB and copy the Assembly output block into the game loop section of the ASDK just as we did before: Now compile your Assembly and test it in Stella! You should notice two things – you can’t scroll quite all the way to the left, there was a bug in the bB code we converted, it should have been “>0” not “>1”. I’ve fixed it in the Assembly output above. I left the other bug in because it allows us to scroll down past the edge of the virtual world and view other memory areas, some of which is active RAM. Let’s take a look at the three new Assembly instructions the compiler generated: “bit SWCHA” “BMI” – branch if minus (if bit 7 is set) “BVS” – branch if overflow bit is set The bit instruction is examining the bits on the joystick port SWCHA and the two new branch instructions act on the different bits that are set when you move the joystick; we’re going to be reviewing bitwise operations later but for now you can reuse this block of Assembly like a template to hook up the joystick for your games. Chapter Review You now know Assembly well enough to write loops, code game logic, manipulate variables and marshal high level objects; start building some demo’s and games and you will get even better at it for the simple fact that you are actually using it! There are many paths to learning Assembly but we learn best by doing, and achieving enlightenment on the gamegrid is the most fun

Nice illustration! If I had to choose I'd much rather watch movies in widescreen format on PAL than NTSC - the vertical resolution is so low extra scanlines really make a big difference. With the games the programmer has a lot more CPU time to play with, your model frees up even more What happens with PAL 262 mode normally, does this correct for aspect ratio or stretch out the image?

Your Cathode environment looks comfortable, I like the markup colours and the black background. The CRT effect is really cool, had me going for a minute Makes me want a real CRT instead of a flatscreen again!

How many scanlines do we have if we make sure to only use half of them? I was amazed when widescreen became popular because the format effectively deinterlaced the image.

SeaGtGruff, I'd like to check out that editor, can you post the executable (guessing it's standalone)? Did you learn Assembly previously or with the 2600 SDK, or by working with bB and it's objects?

Thanks Loon! Notepad or any plain editor is fine, I prefer DOS edit because it has line numbers, lets you split the screen and has a fun retro feel. I'm not going to recommend Emacs over Vim or vice versa

Lesson 2: Player sprites and missiles Topics: Make a sprite appear in the center of the screen Load a different sprite besides the default Edit sprites and expand the inline sprite library Moving sprites around the screen using Assembly or bB Sprite Animation using Assembly or bB Make a sprite appear in the center of the screen To make a sprite appear, simply set it’s X and Y coordinate variables to the desired positions. To make a sprite vanish, you set it’s X and Y coordinate variables back to zero. Since this is our first topic working with the ASDK we’re going to use this blank template to start our project and add our code to the initialisation and game loop sections: ASDKtutr.asm Open it up for editing as shown below, find the initialisation section and add the purple code as shown: Save it and then compile and launch it in the other window like this: You should see the corner of the virtual world displayed in the playfield with two sprites in the center of the screen: Here’s what’s going on with the purple code: “LDA” is an Assembler command for loading the Accumulator which is like an internal temp variable on the CPU; there are three of these registers (A,X and Y) and access to regular variables must go through them. “LDA #45” tells the 6502 to put the number 45 into the Accumulator (note that the # prefix means we are using the number 45 rather than the contents of memory location 45; this is important). The next instruction “STA player0y” does just what you think, it puts that 45 into a player sprite Y variable, player0y. Then we load the accumulator with values for our sprites X axis variables spaced a bit apart so we can see them next to each other. This isn’t very different in bB: player0y=45:player0x=45:player0x=70:player1x=80 Later in this chapter we will use bB to compose and import a complex Assembly logic block for moving and animating our sprites, but first we will cover some more topics you will already find familiar. Load a different sprite besides the default In bB you must also load a sprite definition, we didn’t do that above but if you scroll down the init section a bit you will see this is done much the same way: Again, here’s what’s going on with the purple code: “LDY #0” is an Assembler command for loading the processor’s Y register with the number 0 (#0); in this case we are using the Y register to pass an argument to our sprite loading subroutines; “JSR” is just GOSUB. I’ve split the screen to show the inline sprite image library section; you can probably guess that arguments #0 and #8 load images 1 and 2 respectively. You can change the Y argument values to load different images from the sprite library either in the initialisation section like we are doing now, or on the fly in our game loop for animation sequences which we will do later J Edit sprites and expand the inline sprite library Go ahead and edit the WYSIWYG sprite definitions you see or add additional sprite definitions – there are about 10 in the inline library right now and there are room for 32 sprite images (it’s not a space issue just the constraints of the table size). Moving sprites around the screen using Assembly or bB We can use the bB compiler to write complex Assembly logic blocks for the ASDK both to help learn Assembly and for reusing complicated routines without rewriting them! This works out very well in practice. Here’s a bB routine to move the player sprites all the way across and halfway across the screen, respectively: We just compile it and insert the generated Assembly block into the Game loop section of the ASDK as shown: Then we can save and compile our ASDK file and the code works fine! Here’s what’s going on in the compiler generated code, it’s not too different than BASIC: “LDA player1x” loads the player1x variable into the Accumulator, “CMP #150” compares the contents of the Accumulator to the number 150. “BNE .skipL014” means Branch if not equal to or “goto .skipL014 if player1x <> 150” “INC player1x” means increment the player1x variable directly or “player1x = player1x+1” The rest is the same. Now let’s add some sprite animation! Sprite animation using Assembly or bB We already know that we can call loadplayer0 with an offset argument to load the selected image into the player0 sprite from the image library, but this function has no counterpart in the bB framework so what do we do if we want to model sprite animation with bB? We use a placeholder in place of this function and write the rest of our code: Now we simply paste in the generated Assembly block like we did before, but we edit our code as shown to replace the dummy code with the function call to load the sprite, passing our f variable argument: (Note: Don’t forget to also init f to 24 in the init section since we want f to start at image 4) Compile the code and you’ve got the smooth animation demo! Here’s what’s going on: “LDA f” loads the Accumulator with the variable f “CLC” clears the carry bit (we don’t want it when we add unless we’re doing 16-bit calcs) “ADC #8” adds 8 to the contents of the Accumulator. “STA f” stores the new value back in variable f. “LDA f” redundantly loads var f back into the Accumulator (it’s still there) “CMP #72” compares the Accumulator to the #72 “bne .skipL026” jumps around the next two statements if var f <>72 (from our CMP statement). Those next two statements reinitialise var f to 24. Chapter review You’ve learned quite a bit of Assembly already! Now review your source code and compare it to the pure Assembly example used in the Abstract Assembly Development Kit Thread. Your Assembly source should look like this at the conclusion of this lesson: ASDKtutr3.asm And here is the Pure Assembly source from the ASDK thread to compare. Note the Assembly in both examples is nearly the same (the bB compiler is excellent)! However you will also notice the pure Assembly example is easier to follow with it’s friendly naming conventions; by contrast, the compiler cannot come up with descriptive and imaginative names but it does the next best thing by putting the bB code in comments (I always look at that). It’s important to review both examples together; Assembly output from a compiler is more cryptic and confusing to review without the bB source. For this reason you should never dissemble in Stella; if you want to look at how an interesting classic was programmed search AtariAge instead – other developers have probably already dissembled, analysed and produced a friendly or well commented source listing; that’s the kind of Assembly you will absorb best. Looking ahead Some really fun things are coming up next in lesson 3, particularly as we connect our examples together! Lesson 3 preview: Virtual Worlds and Playfields Topics: Load a different virtual world (just like loading another playfield in bB). Edit virtual worlds (like editing a playfield with bB). Set pixels anywhere in the virtual world Check pixel status and flip them Pan the camera to any part of the virtual world Scrolling around the virtual world using Assembly or bB.

Lesson one: Keep Thinking Abstractly Assembly allows you to work at a very low level but you don’t have to! We will not be coding advanced and esoteric algorithms to manipulate the exotic hardware of the VCS. Instead of counting cycles we’ll be on the game grid, racing the beam with our lightcycles: Marshalling high level objects with the ASDK: The ASDK has the abstract sprite and missile objects already familiar from batari BASIC: sprite0x, sprite0y, sprite1x, sprite1y, missile0x, missile0y, missile1y, missle1x And a playfield object like bB, and a large virtual world object with additional properties: Like bB playfields, virtual worlds are defined in WYSIWYG format in your code and are loaded into RAM to render them malleable. Virtual world pixels are x,y addressable using similar high level commands to pfpixel with extended properties to set pixels on and off the visible screen or pan the camera (also x,y addressable) to scroll anywhere around the virtual world. Game loop and initialisation sections Like bB, the ASDK provides a game loop for your code that runs every frame and an initialisation section that runs only on startup. Getting started – Editing and Compiling Assembly You already have all the tools you need! The ASDK is integrated in a single file along with your code and uses the same version of DASM that you already have installed with bB! Best (easiest) Assembly coding practices Get comfortable using a dual window setup as shown in lesson 2 where you can code your Assembly in one window and switch to another to quickly compile and then test it in Stella – it’s a best practice to do this with each block of code you add to your project to ensure it is working as expected; this is a good way to never have to open up the debugger in Stella or hook up an oscilloscope and multi-meter to determine what went wrong with your Assembly code.

LEARN ASSEMBLY IN 8 HOURS with bB and the ASDK Tutorial Intro This tutorial will teach you 6502 Assembly programming for the Atari 2600 using a RAD Framework that abstracts the hardware so you can quickly marshal high level objects to build games like batari BASIC. Due to the similarities we will use BASIC examples side by side and use the bB compiler to illustrate (and to help with creating Assembly when preferred). Peruse and complete these short lessons over time or stay up all night drinking coffee and taking breaks to play Defender

Thanks Atarius Maximus! I like your new game with the pitfall theme, great animation on the sprite I got started on the tutorial last night using bB with the ASDK, I will post some of it soon!