TROGDOR

I was getting concerned that I didn't have enough half-finished Atari projects, so I started another one. Just to be safe. Vista Operating System has chosen you to serve on the game grid. positron08.zip Features: - High-resolution light trace display with pseudo 3D effect, synchronized with the player's cycle. - Fluid cycle motion, one pixel per frame. - Uses standard 128 bytes of RAM. - 8LK displays 2 sprites anywhere in the game grid with no skipped scanlines. - Two songs encoded so far. Use the right difficulty switch to select which song is played on death. - Two cycle steering options. Left difficulty switch selects the steering mode. In amateur mode, press any of the four directions to steer. In pro mode, only left and right are used. - 6 digit retro score display. Detailed Development Log: positron01.asm 09/06/10 - Displays a horizontal/vertical line grid in playfield graphics using 2 bytes per row. - Added joystick control. - Added automatic cycle movement. - Added preliminary collision detection. Still needs work. - Sound Fx for cycle engine and collision - Crash music started. positron02.asm 09/08/19 - Displays 1 player sprite anywhere on the field. - Plays 2 different test songs, selectable with right difficulty switch. positron03.asm 09/08/22 - Displays 2 player sprites anywhere on the field. - Major clean up in the kernel. The 10 line kernel is now an 8 line kernel. - Displays appropriate cycle sprites for each of the 4 directions. - Added delta offset to correctly position sprite after turns. positron04.asm 09/08/24 - Added 2 more grid rows for a total of 19. - Cleaned up top and bottom grid display with pregrid and postgrid processing to prevent artifacts and truncation of player sprites. - Hide the player's sprite after a crash. positron05.asm 09/09/05 - Full rewrite of joystick and position code. In previous versions, the player position was tracked by the playfield lighttrace display, and the sprite graphics was tacked on to the lighttrace. Now, only the position of the sprite cycle will be tracked, and the lighttrace will be determined relative to the sprite cycle. This should make all future coding easier and more accurate, especially on turns. - Rewrote the joystick control to use buffering to make it more responsive. Unfortunately, I don't like the results and will revert back to simple time-based sampling. Given the nature of the game grid, there is no way to make the controls instantly responsive, so they may as well only sample when the cycle sprite is at a grid junction. - There are now 2 different control options, selectable by the left difficulty switch. Amature mode uses all 4 directions. You move in the direction you press. Pro mode only uses left and right turns, which forces the player to focus more on the direction they're traveling. - Added 6 digit score display and some supporting score routines. aapstron06.asm 09/09/06 - Reverted the joystick code back to simple non-buffered. - Added collision detection with the outside walls. - Sanity check in. Going to try reorganizing the grid into 4 sections, Left, Right, Horizontal, and Vertical. aapstron07.asm 09/09/08 - This revision demonstrates that it is possible to move in all 4 directions with fluid playfield drawing so that the playfield never shows on the front of the cycle, and blank space never shows on the back of the cycle. - Reorganized the grid into 4 sections: left, right, horizontal, and vertical. - Added a direction-based offset when translating sprite position to grid location. I may need a more elegant way to handle this. aapstron08.asm 09/09/13 - Bug fix. Moved the Temp1 and Temp2 variables before Vert trace buffer instead of after. This prevents artifacts from the Vert-1 logic in the horizontal trace display logic. - Completed tweaks to the sprite positioning. It's now perfectly in sync with the display of the light traces so that no blank spaces appear, and no partial playfield graphics can be seen. - Added code to ignore the player from pressing in the opposite direction when driving in amateur mode. Known Bugs: - Collision detection is currently disabled. It will only detect a collision with the side of the game grid. - The pro steering mode is sketchy. It's common to make 2 turns when only one is intended. I may have to use joystick buffering for this mode. Development Notes: While attempting to install an old USB scanner on your Vista desktop computer, an unexpected driver failure has digitized you into the system! You are now at the mercy of Vista Operating System. The DRM sub-processes have determined that your executable MD5 matches Britney_Spears-Oops_I_did_it_again.mp3, and you have been targeted for quarantine and deletion. Now you must fight for your life on the game grid. Fortunately, you have commandeered a Write Cycle that will allow you to move quickly through system memory. Can you out maneuver the crafty DRM sub-processes and survive to fight another duty cycle? So far this is just a technology demo. I need to add collision detection and a computer opponent before the game will be playable. I had considered pitting you against VCS. But to be honest, I'd feel safer scanned into an Atari 2600 than a computer running Vista. In the spirit of the game, I digitized myself into an 8K binary called serve.bin. It's included in the zip file. I like the 3D look of the light traces. I will probably reuse that motif in other games, such as a maze game, or something akin to Gateway to Apshai. If you've been following this blog, you may be wondering, TROGDOR, why the hell did you start another project? The awful truth is, I suffer from a chronic disorder called Atari Feasibility Syndrome. I often find myself asking "I wonder if I could do <insert game here> on an Atari 2600." If a particular game sticks in my head long enough, I start thinking about detailed implementation, and I have to code it up in a .asm file to prove it will actually work. In this case, the question was "is it possible to do a Surround style game that doesn't have such a choppy, blocky feel to it? And can I do it in 128 bytes of RAM?" The result is Positron: Write Cycles.

Hmm, that's the same resolution I was using as well (on a MacBook). It doesn't seem that you should see the "Resized to 100%" bar if the image is actually at 100%. What web browser are you using? Thanks, ..Al Sorry, I just noticed your reply. I'm using Firefox 3.5.3 on Windows XP SP3. Below is a screenshot that I just made a few minutes ago. The browser window in the screenshot is 1298x1018, but the image still isn't shown full size. Another issue I noticed is the automatic tag links in my blog, such as this one, all go to an empty page that simply says "TROGBlog has no entries yet." If you click on the link, you'll see what I'm referring to. I'd recommend a slightly more distinct color difference for links in posts. The difference between the blue text and the black text in the sentence above is barely noticeable. Thanks for you help with this. I'm sure it must be a real pain having to fix all this stuff.

Nice work Adamantyr. The title screen looks great. I poked around on your site, and the game looks like it's coming along nicely. The map screens reminded me of Questron for the C64. You won't have to worry about people asking "why in assembly" or "why a vintage system" here. I had a friend with a TI99 back in grade school, so I've spent many hours on this machine. The TI99's potential as a gaming system was never even remotely realized. It's always good to see more development on this system, particularly in assembly. My favorite game for the system was definitely Hunt the Wumpus, so much so that I made a port of it to the Atari 2600. There is still work to be done for that game, but it's playable. Good luck on your project.

Hi Al, The blog view counter appears to be broken. I got about 40 new views on Sunday, and then none since then. It's more obvious with the new GideonsDad's Blog post, which still says 0 views six hours after it was posted. I looked at it, so the count should at least be one.

Thanks guys. It's slowly but surely making its way towards release candidate. As suggested by the revision number, I only expect a few more versions before it's ready to go into a ROM. Making the manual has been fun, but also a lot of work. I've spent almost as much time on the manual as I did on the game. One other thing that I didn't mention in the blog post is that I finally installed DASM V2.20.10. For the past 6 years I've been using the original 1995 version of DASM. I was forced to seek out the updated version when I started playing with illegal opcodes, which apparently aren't supported by the older versions. I'm liking the new version a lot, especially for faster debug without having to dig through log files. Regarding Hardware Wars, I first saw that movie in 1978 at my elementary school when I was in third grade. I don't think I got the "4Q2" joke back then, and obviously neither did the teachers who showed the movie. My favorite scene is still the creature cantina.

Great! Thanks for the help Al. Changing over to the flash uploader interface resolved my problems. After enabling the flash uploader, I now see "Add to Post" and "Delete" options for each of the attachments, and I removed the redundant attachments. Regarding the images, I'm viewing the page on a notebook running at 1280 x 800 resolution. If I maximize the browser window and reload the blog page, I get the blue tab "Resized to 100% (was 638 x 395)," so as you mentioned, it looks like some kind of tweak will be necessary to prevent this. Thanks again for your help.

Last night I was working on a new entry for my blog, and I'm having trouble adding an attached zip file. When I use the upload interface, it loads for a couple seconds, then just says "Done" in the status down in the bottom left corner of the browser, but doesn't say anything else in the web interface. Because of this, I tried several times to upload the attachment. I posted the entry in draft mode, and now I see 3 duplicates of the same file in the Attached File(s) section. I don't see a way to delete the two extra copies. When I go to "Manage Attachments" in my profile, I don't see the newly uploaded attachments in the list. In the blog editing interface, I don't see any way to insert a link/reference to the attached file inside the post after it's uploaded. Any help with this from Al or other mods/users is appreciated. I'm using Firefox version 3.5.2 under Windows XP SP3. TIA (Thanks in Advance) One more question. A screenshot I included in my blog at size 638 x 395 was automatically reduced, so that another click is required to view at full size. What is the cut off size to prevent this size reduction? 640 x 400 seems like a reasonable upper limit for screenshots, since this is the default 2x size from the Stella emulator, and it's the same size I've been using for 3 years of blog posts (I'd rather not have to go back and resize them all.) Is there a way for me to configure this limit in my preferences, or is this a global limit for the site?

Given Al's recent overhaul of the AtariAge website, this seemed like a good time to post the facelift I did for Stellar Overlord. The new look so95.zip New Features: - Completely redid the font graphics from scratch. Wider is better. - Shrunk the planets in the Galactic Display to make them look more like round planets, and less like footballs. (besides, )- There is a new sound effect for the victory at the end of the game. It's based on an idea posted by thegoldenband. Minor Tweaks: - Games now start at the slowest speed. I noticed that every time I played a game, the first thing I did was slow the game down to get my bearings. - Changed the message at the end of the game. Final Enhancements to Do: - Add destroying all enemy fleets as a condition of winning the game. Currently, all that is required is conquering all worlds. - Change ship production to occur on turn multiples of 10, rather than 10+1. - Rewrite the frame-based computational load distribution system. - Fleets should arrive when their ETA count-down reaches 0, not the turn after. - Add a trig table to replace the simple Manhatton distances used for star distance calculations. - Provide acceleration in level selection, similar to acceleration in ship selection. - Tweak the kernel to center the text display. - Reduce RAM requirement for randomization routine. Should only need 2 or 3 bytes. - Save random buffer when the reset switch is pressed. This will provide much better randomization for subsequent games. - Manual - Add joystick control diagrams. (Partially done.) Known Bugs to Fix: - If you are pressing left when the game should end, the victory conditions are not registered correctly. - Streamline the combining of fleets when attacking a world. Two groups of 120 should combine seamlessly into a fleet of 240 ships that attack simultaneously. - If the game ends with a ship landing, the planet where the ship lands is purple instead of color pulsing. - World conquer or loss sounds should have precedence over ship landing or take off sounds. - Spacing between text lines should be uniform throughout the game. Some spacing is still off. Development Notes: I completely rewrote the sound engine for this game. I was lazy when I wrote the original sound engine, and had all the sound effect counters counting up instead of down. After cleaning this up, and using more lookup tables to define the sound lengths and voices, I was able to shave off 40 bytes of ROM, even with additional code for the new phase effect. I did more editing to the user manual, which is included in the download zip. The user manual has been reformatted with 4.25 inch by 5.5 inch pages, which are similar to the page layout of the original Atari manuals. When viewing the pdf, I recommend using View->Page Layout->Facing. If you have an aversion to using Adobe's Acrobat viewer for viewing pdf, I recommend using the free, unbloated Foxit Reader. With a double-sided printout, I can fit 8 of these small pages on a single 8.5 x 11 sheet of paper. So the final manual should be printable on only 5 sheets of glossy paper, which will keep costs down.

I'm curious what is everyone's favorite 6502 instruction reference to use when they're coding. I've been using this one for years and have been very happy with it. It has pretty much everything, except illegal instructions. But I'm wondering if there are any better options out there...

How does the Stella emulator handle the playfield delay? I often use mirrored mode for asynchronous playfield display, which is particularly picky for the center PF2 to PF2 transition. Only a PF2 store that completes at the end of cycle 48 will work. One cycle earlier or later will result in mangled graphics for either the first or second PF2 display. How common are the ripoff machines? I'm having trouble saving that timing image with the new forum interface. When the attachment loads up in my browser, right clicking doesn't provide the usual "Save image as" option. It only allows a save page option. I'm using Firefox 3.5.2. TIA (Thanks in Advance)

Here's something I should have done ages ago. It's a simple text diagram showing the timing of every pixel on the screen. This makes timing calculations for an async playfield much easier. 2222222222222222222222333333333333333333333333333333444444444444444444444444444444555555555555555555555555555555666666666666666666666666666666777777777777777777 2333444555666777888999000111222333444555666777888999000111222333444555666777888999000111222333444555666777888999000111222333444555666777888999000111222333444555 ................................................................................................................................................................ 6036036036036036036036036036036036036036036036036036036036036036036036036036036036036036036036036036036036036036036036036036036036036036036036036036036036036036 4444555566667777777766665555444433332222111100000000111122223333444455556666777777776666555544443333222211110000000011112222333344445555666677777777666655554444 000000001111111122222222333333334444444455555555 The first 4 rows are a vertically written number. For example, the first number is 22.6, and the last number is 75.6. These numbers are the fractional scanline cycle count at the time each pixel is displayed. There are 160 numbers, corresponding to the 160 pixels of the visible screen. The next row shows all the blocks of the playfield using a mirrored configuration. (PF0 PF1 PF2 PF2 PF1 PF0) The last row is a 6 sprite display, which you can move around as needed. From this diagram, it is clear that the STA PF2 must start at cycle 46 and end at cycle 48 to perfectly synchronize with a reflected playfield. This has been useful for determining exact timing for the other playfield stores as well.

I rented a VirtualBoy system back in 1995 when it came out. I played it for 4 hours. It gave me the worst headache of my entire life, so bad that I had to miss work the next day. The problem with the system was the focus point felt like it was only 4 inches from your face. Try holding your hand 4 inches from your face and focusing on it. For me, that's painful, and I have 20/20 vision. On a modern LCD shutter system, hopefully the simulated depth perception isn't as painful. That said, it's cool you're writing a game for this system. The more obscure the system is, the more it needs game writers. And with only 770k systems produced in its short life, the VB is one of the more obscure systems out there.

Oh, I forgot to mention, happy solstice! In stranger eons, death may die.

Code optimization on the Atari 2600 is the art of balancing 3 limited system resources. The three resources are RAM, CPU time, and ROM size. You can think of them as three points on the corners of a triangle. The goals are usually mutually exclusive, in that striving to optimize one resource will usually be at the expense of the other two. Here are some examples of the tradeoffs. RAM Memory is the most precious of the three resources, if you are designing within the constraints of the original 128 bytes of RAM. The most common way to preserve RAM is to compress multiple pieces of information into a single RAM byte. For example, if the direction a player is facing is represented as a number from 0 to 15, I could store 2 direction values in a single byte of RAM by using the top nibble for one value, and the bottom nibble for another value. This sacrifices CPU time, because it takes extra cycles to read each nibble (an AND %00001111 to access the bottom nibble, and 4 LSRs to access the top nibble.) This also requires extra ROM code. CPU Time CPU Time is the middle of the three resources. 5320 cycles per frame may seem like a long time, but if you have to traverse a complex datastucture to make an AI decision, you'll find the loops eat up your cycles quickly. The kernel is particularly time sensitive, especially when you factor in the timing necessary for an asynchronous playfield, or the careful timing required to define player sprites before they are displayed. An extreme example of a memory sacrifice for timing is defining kernel code in RAM. This will consume 30+ bytes of RAM, but it will also allow you to do very fast instructions that would be impossible in ROM, such as dynamically defining immediate LDA values in 2 cycles, rather than the 3 cycles required to load the value from a zero page temp variable. An example of saving time with ROM is lookup tables. Dividing an 8-bit number by 3 can take many cycles if logic is used. But it can be achieved in just 4 cycles using an X register lookup table. This would be at the cost of 256 bytes of ROM to define the table. Unwrapping loops is another common way to save cycles. This is particularly common in the kernel. An 8 scanline kernel (where 8 scanlines are defined consecutively in code, without looping), will eat extra ROM, but it will save many cycles for extra object processing that would otherwise be consumed executing the loop logic. ROM I consider ROM to be a virtually unlimited resource. The ability to use bank switching to access 16k or 32k of ROM makes this resource abundant enough that it requires a considerable effort to use it all up (there are very few 32k Atari games.) Because of this, I have become more and more prone to solving programing problems with ROM tables, such as quick divide tables, large masking tables for sprite display, and trig tables to define fractional pixel movement. These types of tables are not always wasteful, either. Sometimes it can be more ROM efficient to define a state machine in a lookup table than to define a calculation using sequential logic. For example, you could efficiently translate the upper nibble of SWCHA into a 3-bit (0-7) direction code using a 16 byte lookup table. It would be faster and smaller than decoding the 4 bits using logic. Lookup tables can also save ROM when writing music. If you use lookup tables to define the pitch, duration, and voice of a note, you can write songs that only require one byte to define each note. The longer the song is, the more ROM you save. If you are trying to write a game with a limited ROM constraint, such as 4K, or even 1K, there are many tricks to save ROM. Loops are a common method to save ROM. If you need to position both sprites, both missiles, and the ball, this can be achieved with a 5 pass loop. It will save considerable ROM, at the expense of a few extra cycles to control the loop. Subroutines can also be used to save ROM, by reusing common code. This costs extra cycles to perform the subroutine jumps, and also costs 2 bytes of RAM that must be reserved for the stack. The Human Factor Now that that I've explained the three points of the resource triangle, I can make the model a little more complex by adding a fourth point: time and maintainability. In this case, time refers to the programmer's time, rather than the CPU. These two factors would represent the top point of a 3-dimensional pyramid, with the 3 system resources representing the 3 points at the base of the pyramid. Like the other resources, programming time and maintainability are usually sacrificed whenever you do code optimization. Programming Time Optimization takes time. Lots of time. Any of the games that I've worked on for the Atari would have taken a fraction of the time to write using a modern CPU and a high level programming language like Java or perltk. That's because optimization is all but irrelevant in modern programming. I would guess that for any game I've worked on, half the time was spent designing and coding the game, and the other half was spent optimizing and rewriting existing code (several times over.) Code Complexity / Maintainability Another luxury you will often sacrifice when optimizing code is maintainability. Many optimization tricks make your code more difficult to read, and can turn your code into a house of cards, where moving a single instruction can brick your ROM. A common practice for saving ROM is a simulated BRA. There is no BRA instruction (branch always), but if you know the state of one your registers, you can use it to simulate a BRA. For example, lets say you LDA a value and then perform an LSR on it. This will, by definition, result in a 0 in bit 7. If you need to branch unconditionally after this instruction, you can use BPL (branch plus), because a 7-bit value is always positive. This will save you a byte, because BPL is only 2 bytes, whereas JMP is 3 bytes. However, this reduces the maintainability of your code. If, at some point in the future, you decide to remove the LSR, but don't change the BPL command, you'll find your code execution taking unexpected branches. This can be particularly nasty if the branch only fails some of the time. These kinds of bugs can take a long time to detect and isolate. I try to minimize this risk by carefully commenting my code. Any time I make status assumptions in my branches, I always add ";Careful! This assumes A is less than 128," or something similar, to the comments. It is difficult, if not impossible, to have good object-oriented code that is efficient. Most modern object oriented code implies lots of methods (i.e. subroutines) Subroutines are not your friends in Atari 2600 code, especially nested subroutines. Each nested subroutine will consume 2 bytes of RAM for the stack, and eat 12 cycles for the routine jumps. So you should only do subroutine jumps for code reuse, not for code organization. Again, I use commenting to help keep my code visually organized without the use of subroutines. Dividers, like: ;------------------------------------------------------------------ ; Joystick Decode are great for visually distinguishing blocks of functional code. All of this only scratches the surface of assembly code optimization (I didn't even mention illegal operations.) But hopefully this will serve as a high level guide to optimizing Atari assembly code.

Quest for the Rings was a very fun game on the Odyssey. With a 16k cart, you could integrate the board game into the actual game, and even make it a single player option instead of the 2+ players that were required for the Odyssey version. (Although admittedly, the 2 player cooperative strategies were a large part of what made this game so fun.) With 30 Hz flicker, you could fit plenty of orcs and nightmares on the screen. The nightmares were seriously creepy. (As creepy as an 8-bit character can be.) Here's a nice youtube demo. Separated at birth? Dune's Thufir Hawat, the Mentat Master of Assassins And the Wizard of Odyssey!

This game shows excellent potential. I particularly like the inertia when when you stop pressing the controller. I vote for 16K. Make it an epic adventure.

Hubba hubba hubba! So, when do we get the Atari 2600 port? We have the necessary technology. itsart.zip

The advanced sound techniques are generally reserved for title screens, since they require precious cycles inside the kernel. For the sound engines I've written, I've found that one size does not fit all. It's better to customize your engine to the particular sound Fx and music required for a particular game. I only require 3 bytes of RAM per channel for music. One byte points to the song/sound effect, another byte points to the current note, and the third byte points to a note length count-down clock. For ROM usage, I've so far been able to make my songs use only one byte per note, by using lookup tables. The definitions of the bit fields will vary depending on the needs of your song, but here is an example implementation: 12223333 1 = voice 2 = note duration 3 = pitch For each of these 3 fields, I read the value into X, and use that as an index into a ROM table. So there is a table with 8 different note lengths, and the values can be completely independent of each other. This allows me to define a song with whole notes, half notes, dotted eighths, sixteenth notes, and even triplets, in only 3 bits per note. This could be used instead of a multiplier system. The voice bit can map to any 2 AUDC values. If the entire channel only uses one voice, this bit can be freed up for other uses, and the voice setting can be tied directly to the song/sound effect value. The pitch field allows any 16 pitches, which will be sufficient for most songs. I usually reserve the zero value as a rest note. This is probably obvious, but song and note counters should always count down. When I wrote my first sound engine, I got lazy and had the counters counting up, and this ended up wasting about 40 bytes of ROM throughout the code by the time the game was done. I've finally gone back and cleaned that up so the clocks count down. Sound engines can also apply extra processing to improve the quality of the tones. A soft attack (ramping up the volume) and decay (ramping down the volume) will make the notes sound less shrill. This can be applied to all the notes in the song without requiring extra info in the note data. This is particularly easy for the decay. At the last 8 frames of any note, apply the countdown value to the volume, and it will fade to zero.

Thanks B00daW. I'd suggest getting a small, simple sample working first, and then grow from there. I've discovered that it's tough to do anything longer than 2 seconds without bank switching. I squeezed out another sample last month. EricBall, thanks for the info. I'll do more research on it as time allows. The Hello sample seemed reasonably clear, even though it was down-sampled from 8 bits to 4 bits.

There's nothing that I'm aware of, but I agree, this is essential. Come to think of it, the first survival horror game wasn't Alone in the Dark. It was Haunted House. It has all the elements: - You are too weak to kill anything in the game. - You're constantly running from things that are trying to kill you. - It's scary as hell. Haunted House would be a good foundation to design a Lovecraft game on, either as a hack, or better yet, a modified 8k or 16k game with more detail and a variety of mythos monsters. Imagines 8-bit green tentacles coming out of the floor. BTW, if you haven't played , I highly recommend it. I'm in the process of buying a set of 5.1 surround sound headphones so I can freak myself out properly. What was that noise? They're coming. They're coming to get me!

How is binary formed? how is binary formed how programer get ROMs They need to do way instain programer> who execute thier binarys. becuse these binary cant dissasemble back? it was on the forum this mroing a programer in Homebrew Discussion who had execute his three ROMs. they are taking the three binarys back to Atari 2600 Programming forum too disgust further my post are with the programer who lost his code ; i am truley sorry for your lots A simple fix to the min size issue in stella is to add horizontal and vertical scrollbars if the window won't fit in the minimum space. I could see the min size being a real problem on netbooks.

IAAWOW.BIN

Thanks Chris. Playfield display with samples is possible, but you'd have to have a separate block of code to handle the kernel and the off-screen code to keep everything in sync. Note also that this would work for constant-rate samples, but would not be possible for variable-rate playback, unless you do something complex like wave tables. I've been working on making a song with a guitar sample, but I'm finding a surprising amount of aliasing coming from the 16-bit to 8-bit downsampling. I expected aliasing from a reduction in sample rate, but I wasn't expecting it from a reduction in bit resolution. I'm going to consult some audiophile forums to see if any pre- or post-processing is possible to prevent this downsample aliasing. It adds too much distortion. (Then again, this wouldn't be a problem if your goal was a distorted guitar. )

Thanks Impaler. I've added a variant that demonstrates high resolution variations in pitch. This uses a NOP jump table to create delays with 2 cycle resolution. If necessary, it's also possible to get single cycle resolution using a C9 jump table. These subtle variations in delay change the playback rate of the sample, which alters the pitch of the sample. I couldn't figure out how to attach it to this comment, so I put it at the end of the blog post above.

Wow, that is a great effect! I like it. I was trying to think where I've heard that before. There was a similar phased sound at the end of . You'll also hear this effect on when the ship lands. But I don't remember any phased sound effects like that on the Atari. The code looks very simple. It looks like AUDV0 and AUDV1 are inversions of each other, oscillating based on the frame count. What's going on with AUDF0 and AUDF1? I wrote a perl program to convert wavs to Atari dasm code. You can find it on my blog. There's also a couple ROMs demonstrating sample playback.