Mr SQL

Thanks! I will absolutely share the whole story soon as soon as I post the pics - I'm writing up a descriptive account of it now

Yes, that's it exactly! I'm tremendously delighted and inspired to have the kit so I want to draw this out like a kid with an ice-cream bar! Don't worry I won't wait till it melts; I'm storing it inside in a cool dry place, not outside on my deck where I took the picture

Atari is awesome! Atari just shipped me this cool Nolan Bushnell era Legacy Development Kit!!! I did some recent work for them and shared my admiration for the iconoclastic VCS and the Flashback consoles. I haven't opened the package yet - just shook it to listen I need to pickup the hardware to connect it along with a six switch model it's designed for; I've only got a Vader and a Junior at present but I've been wanting six switches on the console for some time and now I really have no excuse! I will post pictures of my Retro Development Kit once I have that equipment; for now, here is a picture of the package as I received it from Atari last weekend - you can see it's from California and was shipped to my software company

Thanks Rabbit 2600, I'm glad you like it! It might be easier to explain what's going on in English than looking at the source code: The routine that draws the random city scape has a couple of loops that call bB's random function to determine the height and width, as well as the placement of each random building to be drawn (there are just a few). This creates one city scape, but it lives within a larger loop so a few city scapes are overlaid atop one another to create the effect. Take a look at the source and let me know if it's clearer now - I can explain in more detail if you have questions on any specific spots.

Awesome Sprybug! Just gave it a try, I like the way Sonic does the loops

Hi Ed, Awesome that you have DASM and batari BASIC! Programming the 2600 is incredibly fun Other tools you may like are the Abstract Assembly Development Kit and my Assembly tutorial. Follow the links in my signature to read about them and download the software/manuals

The awesome long play demo compilation is now on youtube playing on a real VCS Fantastic work SvOlli and the demo scene coders!!!

purduecrum, great question! Yes, follow the link in my post; the entire Assembly tutorial is available for preview. It will also give you an idea of my writing style for the 80's retro content included in the Book

This book contains an enhanced version of the online tutorial Learn Assembly in 8 hour on the 2600 with clearer images and formatting plus exclusive bonus chapters for retro players and Video Game fans: AN INSIDE PERSPECTIVE ON WRITING 80's VIDEO GAMES WITH SCREENSHOTS AND STORIES Details and how-to's for selling your Video Games to magasines and software companies in the 80’s. Bootstrapping your own company in the 80's. Colourful full page magasine ads for the authors 80's Video Games. Video Game Marketing models from the 80's. Insider stories and pictures from the 80's. Colourful video game artwork for the authors 80's Video Games inspired by Atari! If you want to learn 6502 Assembly in 8 hours or just like retro, don't miss out on this awesome fun book! The price is $10 for the eBook, please PM me your email if you'd like to order. Also included is a special publishers deal for anyone who wants a printed version of the book for an additional $10-20 (for spiral or bound) plus shipping.

This book contains an enhanced version of the online tutorial Learning Assembly in 8 hours with clearer images and formatting plus exclusive bonus chapters for retro players and Video Game fans: AN INSIDE PERSPECTIVE ON WRITING 80's VIDEO GAMES WITH SCREENSHOTS AND STORIES Details and how-to's for selling your Video Games to magasines and software companies in the 80’s. Bootstrapping your own company in the 80's. Colourful full page magasine ads for the authors 80's Video Games. Video Game Marketing models from the 80's. Insider stories and pictures from the 80's. Colourful video game artwork for the authors 80's Video Games inspired by Atari! If you want to learn 6502 Assembly in 8 hours or just like retro, don't miss out on this awesome fun book! The price is $10 for the eBook, please PM me your email if you'd like to order. Also included is a special publishers deal for anyone who wants a printed version of the book for an additional $10-20 (for spiral or bound) plus shipping.

Very cool SvOlli! I would be glad to upload it to youtube as the long play compilation is awesome and I asked for/suggested it

ASDK MANUAL.pdf Here is the latest version of the ASDK eBook manual Includes updates and details on utilising Flicker Free Mode with tie-in's to Chapter 7, Getting the Most out of the ASDK in the Assembly tutorial.

This is awesome SvOlli! I downloaded it a month ago but just unzipped it today All fantastic demo's and smooth transitions! My favourite was the hi-res spinning globe; wish I could view this compilation on my VCS instead of in Stella - someone should share a youtube video for NTSC land

Marienbad, you may like my Assembly tutorial (linked in my signature), it's designed to get you up and running fast with 6502 asm. I like the online book you linked, checking it out now

Lesson 7: Getting the most out of the ASDK Topics: Taking a closer look at the ASDK The ASDK Memory Map The Phantom Hardware The Dual Kernel Handling Kitchen Sink code in the Primary Kernel ASDK Enhancements – Disengaging the Primary Kernel to stop flicker Johnny Mnemonic explains the ASDK RAM Doubler Extra Memory exists beyond the edge of the Virtual World Taking a closer look at the ASDK You’re already familiar with using the high level function calls in the ASDK; behind these function calls the ASDK provides phantom hardware for 4-way scrolling and double buffering – both screen buffers (the playfield and the virtual world) are comprised entirely of RAM (low and hi system RAM, respectively). The idea behind the phantom hardware is to allow Assembly developers to focus more abstractly on writing fun games just like you could on the 1976 Fairchild Channel F or on any of the 80’s Home Computers instead of focusing on esoteric minutia like counting and squeezing cycles for instructions and addressing modes to maxamise every last bit of performance from the CPU; this is only necessary with the VCS when writing a traditional kernel (the ASDK has two kernels, more on that later) and now that you know advanced Assembly programming you are equipped to look into that if you are so inclined (consider that starting there first would be akin to reading a physics book by starting backwards from the last page – not the best idea). Here’s what the ASDK Memory Map looks like: Low RAM As you probably know, the VCS has only 128 bytes of RAM which is referred to as low RAM since it is in the “zero page”, otherwise know as the first 256 bytes of address space. High RAM High RAM comes in a few different flavours but always as a memory chip hardware enhancement built into the cartridges; the most common is Sara also know as the super-chip which provides an additional 128 bytes of RAM. The second most common is CBS RAM, also know as the Double-Super-Chip, which provides an additional 256 bytes of RAM. Both of these formats usually afford additional ROM as well hence we were able to bank switch with JCVD to get more game code onto the cartridge. Since we are using the Double-Super-Chip we have 256 bytes of high RAM in addition to the 128 bytes of low RAM for a total of 384 bytes of RAM, and three 4K banks of ROM for a total of 10.5 K of ROM. The reason for this discrepancy (10.5 K as opposed to 12 K) is that the 256 bytes of RAM costs us 512 bytes of ROM in each bank as unlike low RAM, it must use separate address space for read (LDA/LDY/LDX) operations and write (STA/STX/STY) operations (Sara does this too but only ½ as much). That’s fine, there’s still plenty of ROM space in the first two banks for your code, and the third bank is completely empty. The Phantom Hardware The phantom hardware leverages 60 bytes of low RAM and all 256 bytes of high RAM as shown and about 2 K of our available ROM space (most of which is out of the way in bank 1) to provide double buffering, 4-way hardware scrolling and also a RAM Doubler, all in software (Johnny will be telling us all about the RAM Doubler presently – it’s a neat trick). The Dual Kernel Because it takes a lot of processor time to emulate physical hardware, a dual Kernel is employed. The primary kernel provides the phantom hardware and has plenty of space for kitchen sink code - it functions more like the game kernels in those other machines! The secondary kernel is tightly packed and full of comments about counting cycles and squeezing instructions - racing the beam like a traditional VCS kernel. Handling Kitchen Sink Code in the Primary Kernel In addition to providing plenty of space for the phantom hardware, the primary kernel can literally handle the kitchen sink – you can put a ton of code in there and never have to worry. This is because the primary kernel eats an entire frame. This results in flicker which can be mesmerising on an antique tube television thanks to phosphor persistence but somewhat annoying on newer LCD displays (though somewhat better on plasma). Not to worry – you can now engage and disengage the primary kernel at will for a flicker free display! Note: If you don’t have the openGL drivers for the Windows emulator Stella, then scrolling will not look very good but this is not an issue stemming from the ASDK; it works just fine on the real hardware and on the Linux emulators (go Linux - it’s a good idea anyway). ASDK Enhancements – Disengaging the Primary Kernel for a flicker free display In the enhanced version of the ASDK, the gameloop for your code has been moved to one of the vertical blanks – nothings changed and you still have plenty of time, just not an ocean of it. Search for the phrase “Kitchen sink” and you’ll find the old gameloop area still intact. You can put any heavy duty routines in there or high overhead code that will execute every time you engage the primary kernel. Of course you’ll also want to engage it for scrolling the display, but flicker is far less noticeable when scrolling anyway because everything is moving! It’s kind of the best of both worlds if you only engage it for scrolling. The code screenshots from Scrollout7 (a scrolling breakout game) below illustrate engaging and disengaging the primary kernel for scrolling, and also illustrate some other things you can do with the primary kernel like sandwiching routines between calls to the twin rendering engines (useful as illustrated for copying the screen to the tiny sprite game screen the mini pong player is using): In the screenshot above, the purple code shows that the variable scrollvirtualworldtoggle is set to 0 to disengage the primary kernel, eliminating flicker. Note the comments above show how the gameloop has been moved outside the sea of time, thought there’s still penty of it for your game code. In the screenshot above, we’ve scrolled down just a bit and the purple code is determining if the player wants to scroll the virtual world (it’s under player control for this game). If they do the primary engines are reengaged by setting the variable scrollvirtualworldtoggle to 1. Note that just below this the code is increasing it’s internal framerate delay (we don’t want the game to take place at hyperspeed so it uses a frame delay) whenever the virtualworld is reengaged; this allows the speed to remain constant because things happen half as fast whenever the primary kernel is engaged (speed is never an issue either way because half of “fast”, is still plenty fast). You can still put “the kitchen sink” in the primary kernel just as before and it will execute whenever the primary kernel is engaged. And you can also still sandwich routines between calls to the twin rendering engines that live in the primary kernel; note how the purple comment shows that the update to the mini pong players screen (with tiny pong pixels) lives there. Johnny Mnemonic Explains the ASDK RAM Doubler Johnny knows about RAM doublers! In the picture above, Johnny is using a 2x RAM Doubler to double the amount of available RAM in the memory implant wet-wired to his brain. This is just like the RAM Doubler in the ASDK except that Johnny’s RAM Doubler can result in severe synaptic-seepage which isn’t any fun; the RAM Doubler in the ASDK is fun! As discussed earlier, the primary Kernel has an ocean of time for your code and, for it’s internal routines which include the RAM Doubler. The intuitive WYSIWYG panoramic bitmaps wouldn’t be possible without the primary kernel design, even a single playfield screen would have to be stored partially flipped backwards and sprites would need to be stored upside down. There wouldn’t be room for the RAM Doubler either which would mean using twice as much memory for the video RAM; the twin rendering engines actually expand (decompress) the 30 bytes of playfield memory in the second display buffer into 60 bytes, and also flip parts of it backwards. Once disengaged, the secondary kernel needs this awkward bloated format because it literally hasn’t much time for anything besides madly racing the beam to paint pixels and push sprites. Consider this: Without the RAM Doubler we would need 480 bytes of high RAM (and we don’t have it!) for the virtual world buffer as well as 480 bytes for each panoramic playfield image stored in ROM (there are three by default and more can be added). As you can see, this approach would quickly eat up way too much memory! More problems would ensure since we can only handle tables up to 256 bytes in size so in addition to flipping some of the data backwards and breaking the intuitive bB style graphics format, we would have to split it up into multiple tables making it less abstract and less fun to work with. Extra Memory exists beyond the edge of the Virtual World For those willing to explore, extra memory awaits in high RAM at the edge of the virtual world: There are four unused bits at the left of each row of pixels; these can be used to store up to 20 4-bit variables or 80 bit variables or any combination thereof; care must be taken not to corrupt the other 4 bits in the target bytes they reside in however since those other bits are actively used as pixels! Note that Reloading the Matrix of the virtual world will white wash this extra memory.

That was an excellent read RT! Great coverage of breakout and arkanoid clones; sometimes a clone is phenommenal like Breakout 2000 for the Jag, or not so much fun like some pictured with the cutesy/busy look. I think you already have a better-than-breakout breakout with the first release of ChipOff which is going to be difficult to eclipse, though the proposed featureset is interesting. Arkanoid is a different genre though and I would much rather have another Arkanoid to play Here's a related Arkanoid question for Loon or anyone who may have played it on the Genesis: In 1989 or 1990 I saw and played an Arkanoid clone on the Genesis and it motivated me to buy one a couple of years later but I could never find the cart - today it's nowhere to be seen in any ROM collection. The article made reference to Sega comming out with the Arkanoid genre first with a game of a different name so perhaps that was it - anyone have any info?

Thanks Spice! Thanks also for the tip about the PNG's, they're considerably clearer; I'm compiling it into a PDF ebook and I wish I had at least increased the detail level in the JPG's - I was trying to keep the JPG's filesize down (have a lot of images) but you really notice how lossy they are when you print it out on paper, I'm going to use PNG for future code shots and should probably redo some of the existing ones.

RT, I don't know - it's a cool effect right now maybe it would be better to have another routine take over to deliver the block all the way down when it's a power up, so that the effect can continue with other blocks, or maybe it would be better if it ceases until the powerup reaches the bottom. Try it and see which plays better. I always find it helpful to have at least one other person (or better yet a few) give it a try and then a bigger test group like the players here

X2! The physics are already there the way RT has the bricks start to fall when hit - some of them could keep falling and turn into special powers

Awesome! We'll be playing that version along with your original release (I have a special pong folder on my Harmony; favourite genre)

Loon, I'm not sure of the answer, but I really like concenating in BASIC and have always wished I could do it in Assembly too I've tried using the linefeed character as a concatenation character and it works temporarily but it vanishes (replaced by CR+LF) whenever I reload the file. asm is so vertical - it would be great to code horizontally too with more than just comments!

RT, you're very welcome! Those are all cool options - I think a smaller paddle option for pong champions to test themselves with would nicely complement that featureset (selecting larger ball and smaller paddle would be an interesting combination). I think you should definitely make the cheat button an option players can select too; having it available all the time makes it too tempting to use

RT, wow I just read that and find your work writing original action games like SeaWeed Assault and superior-to-Breakout Breakout games like ChipOff even more inspiring and motivational given that you've built them despite all of that! Your bB site is also inspiring, and I thought so before I knew you had any disabilties as per my comments urging you not to change the layout around! And btw, you get two thumbs up from me and all of my pong champion friends at my last reto party who tried ChipOut and thought it was fantastic and just the right difficulty level - hard! (we all liked the first one better than the button cheat version for that reason) :) Spice, you're welcome! Very cool, looking forward to hearing your thoughts

Spice, I'm tremendously impressed with not only your Assembly games but also the fact that you wrote a hardcore Assembly routine to hook the interrupt vectors so that BASIC BBS programs could transparently get data on and off the wire in the 80's! That's pretty awesome And that you learned advanced Assembly (as is clear from those apps) using slightly different constructs and interpretations is an excellent illustration of how flexible Assembly is, and also that some of the concepts (many IMO) are completely unnecessary! Tom and Andrew sure wrote fantastic games back then (and now) and I don't know if SvOlli, OmegaMatrix, Tjoppen, RevEng or eshu did but from conversation it certainly looks like they could have. I've spoken to a lot of other excellent Assembly coders here as well and my silly tounge-tied post the other day was a satirical reflection on the conversations we advanced coders sometimes have where no one else can figure out what it is we're talking about! Programmer 1: I put the goop-de-gloop in the glip-dip and adjusted it five glicks. Programmer 2: Ah yes, that's because it's a glark. It's always a glark! One of the hardest things to do is to give someone directions to get to your home, just because it's so familiar. Along these lines I'd love to hear what you all think my streamlined approach using action figures to teach advanced Assembly to the awesome bB coders here (Loon, RT and Cybearg immediately come to mind)

Lesson 6: Addressing Modes with Johnny Mnemonic Topics: Introducing Johnny Mnemonic Johnny trades ROM for more RAM A friendly Dolphin restores Johnny’s ROM Johnny teaches 6502 Addressing Modes Introducing Johnny Mnemonic Here’s Johnny Mnemonic in the Sci-Fi Block Buster, Johnny Mnemonic. He’s going to teach us the Addressing Modes of the 6502, but first here’s a little bit about Johnny, and about Mnemonics: Mnemonics are the actual Assembly instructions/commands that you’ve been writing Assembly with all along! We didn’t bother addressing them until Johnny came on board because you already know what they are and you use them all the time - a mnemonic device is simply a learning technique that allows you to remember something. Think how you used “Roy G. Biv” to remember the colours of the spectrum; it’s exactly the same with Assembly instructions. LDA is the intuitive mnemonic for the target operation Load the Accumulator just as STY is for Store the Y Register. Johnny trades ROM for more RAM Here you can see Johnny using an advanced prototype of the Atari Mindlink (“The State of the Art for the State of your Mind”); you won’t want to try this particular Mindlink prototype though – it’s wet-wired directly into Johnny’s brain (just like that input jack he has in the Matrix) and enough brain tissue was destroyed installing it that Johnny lost a large chunk of long term memory (ROM as we like to call it). What did he gain? RAM, and only a paltry 80 GB at that – you’re better off with a microSD card today but remember this is Sci-Fi and the future, isn’t what it used to be in 1994 A Friendly Dolphin Restores Johnny’s ROM Don’t worry; Jones the friendly Dolphin is sporting an improved version of Atari’s Mindlink, and he links it up to Johnny’s Mindlink to restore all of his lost ROM. Johnny also has a lot of other cool gadgets including a software RAM Doubler that he’s going to teach us about in the next chapter but right now he’s going to teach the Addressing Modes of the 6502! Johnny Mnemonic teaches 6502 Addressing Modes (Johnny using the Atari Mindlink) Addressing is mostly semantics and you can probably figure it out looking at code examples at this point but Johnny is going to share the details anyway. For better transfer, always wear your Atari Mindlink like Johnny is doing. Examples of immediate Addressing Mode: LDA #100; Load the Accumulator (A register) with the number 100 using decimal LDY #%01100100; Load the Y register with the number 100 using binary Immediate addressing means we are literally loading an immediate value. Examples of Zero Page Addressing (optional concept): LDA 100; load the Accumulator (A register) with whatever value is contained in memory variable location 100, using decimal notation. STY %01100100; store the Y register in memory/variable location 100 using binary notation. Zero page explained: The zero page is a “direct page” that allows slightly faster access to low memory on the VCS; this concept is not very important and you can consider it no different than absolute addressing. Absolute Addressing: It functions identically to zero page addressing, just slightly slower and you’ll switch context automatically whenever you address a memory location (RAM or ROM) beyond the direct page (note that the direct page comprises only the first 256 bytes of address space). Again, you really don’t have to differentiate between these two modes; consider that Johnny only cares when he’s got a severe bottleneck! Indexed Absolute Addressing: The X or Y registers are used as an offset to the target memory location. STA 500,X ; puts Accumulator contents in memory location 500+X (useful!) LDA 55, Y ; loads Accumulator with memory location 55+Y* Indexed Zero Page Addressing: Nevermind; it functions just like Indexed Absolute Addressing just a tad faster and the switch is automatic when you target low memory below 256. *Note that example changes from zero page indexed addressing when Y is 200 or less, to Indexed Absolute Addressing when Y is greater than 200 (Johnny doesn't care and neither should you). Indirect Addressing: Johnny has more important things to think about and literally jumps away from this one; Jump (goto) is the only operation that uses it, and transparently at that. Indexed Indirect Addressing: Johnny generally, doesn’t care. Relative Addressing: Johnny doesn’t care; if you get a branch out of range error compiling, you already know what to do. Chapter Review And you do too, especially if you wore your Atari Mindlink for this lesson! Look out for Johnny again in the next (optional) chapter on getting the most out of the ASDK; It’s loads of fun again when Johnny breaks out a RAM Doubler, all in software, for the VCS!