TROGDOR

Yes, this will help scramble the random buffer even more. Any user input, including joystick presses and control switch presses, both on the downward and upward transitions, can be used to add a timed factor to the random number buffer. The extent that you need to scramble the random numbers will depend on how the random numbers are used in your game. For maze games and card games it's particularly important to not allow a predictable pattern in the buffer.

Here's the subroutine I use to generate random numbers: RandomBits LDA Rand4 ASL ASL ASL EOR Rand4 ;new bit is now in bit 6 of A ASL ASL ;new bit is now in carry ROL Rand1 ;shift new bit into bit 0 of register; bit 7 goes into carry ROL Rand2 ;shift old bit 7 into bit 8, etc. ROL Rand3 ROL Rand4 DEX BNE RandomBits LDA Rand1 RTS This isn't the most efficient random number generator. A 3, or possibly 2 byte buffer would be faster and use less RAM, and I will likely be switching to a smaller buffer. But this will work as an example. The subroutine is called as follows: LDX #6 JSR RandomBits This will return a 6 bit random number in A. (The 2 high bits can be masked off.) By pulling a bit, I mean running: LDX #1 JSR RandomBits This modifies the contents of the random number generator. If I do this every frame, it makes time a factor for the state of the random number generator. This has worked well as a hardware-independent seeding system. In all the play testing I've done on my games, I haven't had a problem with repetitious patterns showing up. As stated in the previous discussion, the only concern is preventing the player from starting the game on the first frame after power up. This can be solved by forcing the user to make a full button press (or reset switch press), transitioning down and then back up, before the game will start.

If the person hits the start button sometime between 1/10 and 1/5 second after launching the game, there are only going to be about six different starting values with granularity 1/60. On a real system, sampling at the beginning and end of each displayed frame will double the number of possible starting mazes. That's assuming they only want to play level 1. It takes a couple seconds to select any of the other levels. If someone really wants to twitch and start the game on level 1 in the first 1/10 of a second, I'm not going to stop them. Under normal use, there will be a very wide window of start times, depending on the mood of the player. Sometimes I want to play right when I start up, in the first few seconds. Usually though, I will languidly start up the system and poke around on the title screen, taking anywhere from 5 to 20 seconds to start a game, which provides hundreds of possible starting games. Also, this issue only applies to the first maze on the first game after power up. All subsequent mazes will have a completely random seed. I tested this on Hunt the Wumpus, and I can get the same maze every time on level 1 if I hold down the button when the game starts up. I'll have to add the previously mentioned transition check to the button to prevent immediate start up. (But I'm not going to do that now. I'm still working on Stellar Fortress. Honest!)

On a real system, it's possible to read a joystick button with fine timing granularity if one has time within the kernel. On Z26, however, it seems the button is only sampled once per emulated frame. This seeding technique doesn't require intra-frame joystick reading granularity. Joystick polling is done normally, once per frame. The main idea is that a random number of frames will pass before the user starts the game, so it's a great way to seed the random number generator. 60Hz granularity is fine enough that a human won't be able to reliably "pick" a particular starting frame.

The best way I've found to keep a random number generator truly random (or at least make it non-deterministic from the perspective of the user) is to incorporate user input as a seed. For example, in Hunt the Wumpus, I pull a bit out of the random number generator every frame, whether I need it or not. This changes the state of the random number buffer every frame. Then, when the user finally presses the button to start the first game, the game will essentially be seeded by how long the user took to start the game from when the system powered up. So if the user waited 600 frames to start the game, the maze will be completely different than if the user waited 601 frames to start the game. If I didn't do this, the first game would always have the same "random" maze. This has the added benefit that the game will behave exactly the same on an emulator as it does on the real hardware, since nothing in the code is dependent on the initial state of the hardware. The user could potentially cheat this system by holding down the button to start the game immediately on the first frame as the game starts up, but even that can be prevented by only allowing the game to start on the transition of the joystick button (where the previous frame the button is up and the current frame the button is down), rather than just checking if the button is down.

This game begs to be implemented with a Supercharger. Each level could be loaded in individually, similar to the original game. This would allow 4k per level, and plenty of RAM to handle kernel buffering for fancier features like ropes. That's something that has never been done with a Supercharger (to my knowledge). A game with dozens of levels/loads. Loderunner would be another prime candidate. If you can pull this off with the base 128 bytes RAM, I'll be impressed. But the kernel will be so busy I don't see how you could implement asymmetrical PF graphics. I'll check out the bins later tonight.

The ship explosion sound is standard Atari fare. Just a low frequency white noise with a decreshendo. The explosion for the cannon will be more involved, both in sound and graphics. I'm starting to code up an effect that will make the remaining shield segments implode into the cannon before it explodes, similar to the original Star Castle. There will be 6 shield rings in the final game. 3 will rotate clockwise and 3 will rotate counter-clockwise, alternating every other ring. If you look in the source, you'll see that about 300 bytes of ROM was used to hardwire the logic for the clockwise shield rotation. It doesn't use a loop. The diagonal movement of the bits is too complicated for looping. The whole thing is unwrapped, and it took several hours to code it up. Version 0.16 used square rings, so it was easier to implement in a loop, but it only supported 5 rings because of the extra 28 byte RAM buffer that was necessary. The game level will dictate how many rings are activated. On early levels, there will only be two or three shield rings. On the highest levels, you'll have to blast through all 6 rings. The game will get progressively harder with each level, to keep the player on his toes. Difficulty variations will include the speed of the cannon rotation, the speed of plasma cannon shots, the speed of the missiles, the speed of the shield rotation, the number of rings in the shield, and another feature that will be disclosed soon. Also, on the highest levels, colliding with the shield will be fatal, rather than just causing the ship to bounce off. I'm not a hardware guru but these bits are not used by either console. You can use them for RAM if you would like. Before doing so though you must set the bits data direction. lda #%00110100 sta SWBCNT Thanks for the info, but I probably won't get that squeezed for RAM. If I really need the extra RAM, there are at least 10 more bytes that I can wring out of the current implementation. It will just mean a more efficient use of temp variables, and some nibble encoding. I'm also trying to remove all subroutines from the code, or at least limit the number of nested subroutines to one level, so I won't have to reserve more than 4 bytes for the stack.

My threshold of pain for buying a TV is around $1000. Last year I picked up a 50 inch Vizio plasma for $1200, and I've been very happy with it. The TV industry is in such a state of flux right now that you can only expect to use your TV for 2 to 3 years before something on it is "obsoleted". I get a strong vibe of planned obsolescence coming from this industry. A good example is HDMI. 5 years ago no TVs supported HDMI. But today, if you don't have an HDMI port on your TV you're TSOL, regardless of how much you paid for it.

Here's a follow-up blog on the laser TV. Given the blogger's reaction, it does sound impressive. The original story also mentioned 3D capabilities, which piqued my interest. Unfortunately, from the blog story: Sounds like these TVs will be in the 5 to 10 thousand dollar range. It will be years before us common folk will have access to them, similar to the status of HDTV sets five years ago.

I don't understand why it's so difficult for developers to focus on a single project. Working on multiple Atari projects at the same time is just plain silly. jk

To placate my critics, here is another update for Stellar Fortress, as promised. I'm hit! I'm hit! sf20.zip New Features: sf20.asm 1/10/08 - Major improvements to shield collision detection. Now uses a combination of coordinate checking and collision registers. Allows player to fly closer to the cannon, making the game feel less claustrophobic. - Added 16-bit trig table for linear shots. This is now used for the Plasma ball. It imitates 16-bit motion with proper trig ratios, without the RAM overhead. Allows Plasma Cannon to be fired in 64 directions. - Added ship-to-enemy collision detection. Ship can now be destroyed by missile, Plasma ball, and the Plasma Cannon. - Plasma ball expands as it moves away from the cannon. - Added animated ship explosion with color cycling. Thanks to Nathan for providing the original explosion. I had to stretch it a couple lines to match the size of the ship, but otherwise I like how it turned out. - Lowered pitch of shield bounce sound. Sounds less rubbery. - Added explosion sound and warp-in sound. - Ship count is reduced when a ship is destroyed. - Fixed two bugs that have been around for literally years. The first bug was visual artifacts on the player ship when the game first started. This was caused by an incorrectly initialized graphics vector. The other bug was a volume reset in the thrust code that was affecting all sound effects on audio voice 1. All sound effects now sound more crisp, particularly the player's Ion Cannon, and the shield bounce sound. To Do: - Add artificial intelligence to the evil forces of the Galactic Trade Union. Add a tracker for the missile, and targeting for the Plasma Cannon. - Rewrite the kernel (again.) It currently contains suckage. Should handle the screen in sections, rather than trying to do everything in one kernel. This will open up cycles for a snazzy new game feature. - Change the player shots to use the new trig engine. This will open up more RAM. The current code uses 6 bytes for each player shot: 2 for a 16-bit X position, 2 for a 16-bit Y position, plus one for direction and one for distance. Now I only have to use one byte for X and one for Y, and direction and distance can be combined into a single 2-nibble byte. This will free up another 6 bytes of precious RAM. - Clean up the priorities and channel sharing on the sound effects, especially the thrust sound. The trust is interfering with the bounce and warp-in sounds. - Stop making blog posts at 2 in the morning on a work night. Known Issues: - The player shot to shield collision detection is a little off. Gotta fix that. Development Notes: For the record, I am not anti-union. I understand that not all galactic trade unions are evil.

My New Year's resolution is 160 x 192. As convoluted as that resolution chart is, it's still missing my 1366 x 768 HDTV resolution. That's the most common resolution now for 720p.

Labyrinth makes heavy use of missile graphics to draw the swords. The kernel performs an HMOVE and resize on every line that the sword is drawn, using a 2LK with half vertical resolution. Since the width can vary from 1 to 8 pixels, the sword can rotate 360 degrees to nice effect. In Coastal Chaos, I did a lot of experimentation with using a repositioned and resized Ball graphic to make the cannonball appear round. During this work I discovered the same tip that Michael suggested, using one byte to define both the ENABL and HMBL values. After getting it to work, I decided it wasn't worth it. (I never published the round ball version.) It just uses up too many cycles for what you get out of it. I'd rather figure out tricks to reuse the more versatile player graphics, which would consume similar amounts of kernel time, but provide better graphic effects.

Sure, why not. What!!? I have to put it on a cart too?! Jeeze.

What about adding player four using select/reset to move up/down in the auction screen (otherwise use either button in the land-grab screen, etc.) Yes, that would work. I have a personal pet peeve about using the console switches as controllers. It worked nicely for PhasorPatrol back in the day. But now that my original Atari is almost 30 years old, I treat it like a Fabergé egg. That means no more frying, and no more using the switches as game controllers. The multi-resp trick should allow four pairs of sprites to be shown without too much difficulty, though the amount of temp-RAM required could be a problem in an unexpanded cart (assuming a need for four four-digit numbers on a line). Five scan lines at eight bytes each would be 40 bytes of temp-RAM, assuming you had enough scan lines between numeric readouts to prep each group. The tough part is the total cash display, which could be up to 6 digits per player. I'd change the format slightly. The bottom of the screen would show the four player's total cash amounts, one total per line. Then you'd only need 12 reusable bytes for 6 digit pointers. Simplest approach to easing the graphics display without affecting main gameplay would be to rotate the "format" 90 degrees, so as to be 5 wide by 9 tall. Showing 5 plots across shouldn't be a problem (see Casino). Alternatively, if you use interleaved color for the plot outlines, you could then use 30Hz flicker to show the contents of the plots. The icons wouldn't be colorized, but if the plot outlines are colorized it should be clear who knows what. I agree. The 90 degree rotation will be required if you want to display any kind of detail, especially plot color. To compromise RAM usage, a 5 x 8 lot layout would probably be ideal. The number 8 is easier to work with anyway. RAM will be very tight. But resources are always tight on the Atari 2600. I want to try to do it in 128 bytes. It may not be possible. But I want to try. I have nothing against add-on boards or extra RAM. It's just a personal development preference. For everything I've worked on, the target has always been the base 128 bytes of RAM, and let the ROM be as large as it needs to be. It would certainly be easier to make the game with an extra 512 bytes of RAM, but who develops for the Atari 2600 because it's easy?? If the extra RAM is needed, I'd probably switch to a two load Supercharger CD. (Mostly because I already have a Supercharger.)

The MULE work was done back in July, and was supposed to remain unannounced. Like I said, you guys forced my hand. I have other projects that I tinkered with in 2007 that also have not been announced yet. I'm staying focused on Stellar Fortress. There will be another Stellar Fortress update in the coming week.

Check out Treasure of Tarmin for the Intellivision. I hated this game when I first got it (back in 1983), almost returned it, but after playing it a couple times, I was hooked. It has a lot of the features you're looking for, including a good variety of monsters, loot, randomized mazes, turn-based combat, etc. Considering that the Intellivision only had 160 bytes RAM, a similar game should be possible on the 2600. I'm not suggesting a port, but rather as an example of good RPG implementation on a first generation system. Treasure of Tarmin is 3D. That's obviously not essential for an RPG, but it is impressive on first generation hardware. The one part that was lacking was story line. But you can embellish that by using a large ROM footprint (at least 16k), to add storyline. Paul's work, though incomplete, sets the gold standard for RPG on the 2600. Another superb example is DragonStomper.

You've forced me to play my hand. MULE01.BIN I started working on M.U.L.E. in July of this year. I was not planning on announcing it until it was much farther along. This is only version 0.01, so there's not much to it. However, I have spent hours researching the feasibility of this game on the 2600. My intention is to make this game work with a standard 8k or 16k ROM, and no expanded memory. Other people are obviously welcome to develop their own versions of the game, but I wanted to disclose my development so you are at least aware that I've also been working on this. For player control, the players would use 1 joystick and 2 paddle controllers. This would allow 3 simultaneous human players. The control would be similar to the C64 implementation, where players would take turns using the joystick for mule placement, but during trade, all three players could trade at the same time using the joystick and 2 paddles. Because of limited RAM, I was thinking about limiting the game to only 3 players. If possible, a 4th player would always be controlled by the computer. The trade screens are very easy to implement, with a triple copy wide spaced sprite, and bg graphics for the trading bars. The trading value displays could be shown in a similar fashion. For the main screen, I considered two possibilities. Either reducing the total number of land lots to simplify the display and RAM requirements, or using a multi-screen solution, similar to Hunt the Wumpus, where there are actually 4 screens displaying all the land lots, rather than 1. Or maybe even making the mule placement similar to Adventure, where each land lot has it's own screen. A consolidated screen would be used for the land grab phase. I've spent over 200 hours playing the C64 version of this game over the past 20 years, and I consider it possibly the greatest video game ever written. Unfortunately it's very late and I need to go to bed. I'll look through my dev notes tomorrow.

Yes, but "look forward" is the operative term. All the ladies say I have a disproportionately large, um, development cycle. It's going to be a while. I would like to release all my games, if I can ever finish them. However, I do know they will be released individually. Although I plan these three to be set in the same universe, each game is distinctly different from the others, and deserves its own manual and cart (and box, if a reasonable box solution is ever devised.) As for Stellar Adventure, that is my planned Magnum Opus Atari. I mentioned it a while back in this blog entry. But I forbade myself from starting any more projects until I finish some of my existing projects.

For clarification, figa is my brother in New York. He also knows assembly programming, and should, in principle, be writing Atari games as well. What is your excuse for not manifesting your God-given geek powers?! He's right though. I'm sick. The whole family has either a bad cold or a mild flu. But being shut in with the kids has given me ample time on the laptop, alternating between coding and yelling at my dear children. Nathan, I promise Stellar Fortress will be completed before Duke Nukem Forever is released. In fact, I'm finally coding up those pretty explosion graphics that I asked permission to use way back in April 2006.

I always have extra free time around Christmas, and this inevitably leads to more Atari development. In a renewed effort to actually get another game completed, I've gone back to working on Stellar Fortress. The rings are more, um, ring-like. sf19.zip New Features: sf18.asm 12/28/07 - Optimized ROM usage. Opened up another 1k of free space. - Fixed bug in ship-to-shield collision detection. Detection code was only running once every 4 frames. Changed to every frame. - Fixed another bug in ship-to-shield collision detection. Ship must be moved outside collision detection area after impact, to prevent getting "stuck" to the shield. - Major change: hard-coded shield rotation to allow octagon-shaped shield. Currently, only even shield shells are implemented with clockwise rotation. - Added 4 extra bytes to shield. It's now 16x16 instead of 14x14, which also allows a total of 6 rings instead of 5. - Updated shot-to-shield and ship-to-shield collision detection to accommodate the larger shield. - Removed shield RAM buffer, freeing up 28 bytes of RAM. Rotation will be handled in 2 frames, one for clockwise shell rotation, one for counterclockwise shells. Only a 3 byte buffer is needed with this technique. sf19.asm 12/31/07 - Added variable to keep track of number of charged blocks in the shield, used to set the pitch of the shield drone. As shield blocks are destroyed, the shield pitch increases. - Expanded ROM to 8k footprint. Overscan activities now reside in bank2. The kernel will likely be moved to bank2 as well. - Added sound for boucing off shield. Development Notes: I've started working on the story behind Stellar Fortress. The games Master of Arcturus, Stellar Fortress, and Stellar Adventure all take place within the same game universe. Master of Arcturus covers the Galactic Civil War of 2600 A.D. Stellar Fortress takes place after the war, in 2620. Stellar Adventure, a space trading game, starts in 2623, a few months after the resolution of the conflict in Stellar Fortress. Selected entries from the official log of Senator Tramiel, Honorable Representative of the Vega System: CCW Senate Entry - Stardate 267.565, Year 2616 It is now one full year since the Confederacy of Civilized Worlds achieved victory in the Great Civil War. The Reconstruction Initiative is underway. Government corruption, rampant in the years prior to the War, is now in check, and there is a palpable sense of unity and hope throughout the CCW. Two months ago, I was approached by high ranking officers of the Pan-Galactic Trade Union with an offer to contribute to the reconstruction effort. The Confederate battlefleet is still at less than half strength, due to the devastating costs and casualties of the War. As such, deep space patrols are minimal at this time. The PGTU presented me with alarming statistics; most notably, a three fold increase in pirate attacks on PGTU registered freighters since the end of the War. According to the PGTU, an estimated 80 percent of these attacks occurred in deep space, in the proximity of wormhole jumpspace. In response to this threat, the PGTU has requested permission to build security checkpoint stations in 12 interstellar wormholes. The PGTU has asked me to sponsor a bill that will authorize this request. It will be addressed in the next Interstellar Commerce Committee meeting. CCW Senate Entry - Stardate 328.279, Year 2616 The PGTU proposal has led to heated debate in the Senate. Their request was unusual in that they wanted to build the checkpoints inside wormhole space. Wormhole space is covered by the Galactic Peace Treaty of 2477, forbidding any bases or weapon systems to be permanently stationed inside a wormhole. However, the piracy problems cited by the PGTU are very real, and are threating an already unstable galactic economy that is still recovering from the devastation of the Great War. And the CCW itself is facing crushing debt from the War. We do not have the resources necessary to provide effective wormhole patrols. The PGTU's offer of security assistance can not be easily dismissed. CCW Senate Entry - Stardate 332.428, Year 2616 The PGTU legislation has prevailed. The Senate narrowly approved an amendment to GPT2477.63b, allowing the establishment of temporary security bases in wormhole space, that shall be fully financed, constructed, and maintained by the PGTU. The amendment will be reviewed in three years, to evaluate its effectiveness and necessity at that time. CCW Senate Entry - Stardate 84.336, Year 2618 I have just completed a Senate inspection of a PGTU security station, located inside the Psi-Epsilon wormhole connecting the Vega and Capella systems. This security checkpoint is quite amazing, and goes far beyond the specifications that were presented to the Senate two years ago. The station is more like a stellar fortress. The base is protected by the most advanced plasma shielding system that I've ever seen. But even more impressive are the offensive capabilities of the fortress. The plasma shield generator is integrated with a mass accelerator, capable of launching an awesome salvo of plasma energy. It is also equipped with multiple batteries of Diatomic Anti-Starcraft Missiles. Thanks to the PGTU's efforts, deep space piracy will soon be a thing of the past! CCW Senate Entry - Stardate 89.356, Year 2619 All PGTU security stations are now online. In the 3 weeks since the bases were brought online, there have only been 2 incidents of attempted deep space piracy. In both cases, the attacking pirate vessels were completely vaporized. The Senate is most pleased with the PGTU's results. CCW Senate Entry - Stardate 251.842, Year 2619 It has been brought to my attention that two new PGTU stations are being constructed in wormholes that were not authorized by the original legislation. While we appreciate the enthusiasm of the PGTU in defending its trade routes, expansion of the original security plan cannot continue without proper authorization. This misunderstanding will be addressed at the next Interstellar Commerce Committee meeting. CCW Senate Entry - Stardate 270.821, Year 2619 The PGTU has refused to stop construction on the unauthorized security stations, and has begun unauthorized construction in a third wormhole. The Senate has made it clear to the PGTU that they are overstepping their authority, regardless of any security concern. Some senators are now threating to revoke the Treaty amendment and withdraw authorization of all the security stations. Given the effectiveness of the existing stations in deterring piracy, I think such action would be hasty. Negotiations continue. CCW Senate Entry - Stardate 328.659, Year 2619 Negotiations have collapsed. After weeks of openly defying the Senate and refusing to wait for legal authorization of expansion of the PGTU security plan, the Senate has now voted to completely revoke the GPT2477.63b Treaty amendment. With the backing of the CCW military, the PGTU has been ordered to vacate all wormhole security stations. The PGTU has, so far, refused to comply. CCW Senate Entry - Stardate 337.005, Year 2619 There have been terrible developments. Not only has the PGTU refused to dismantle their wormhole security, they have delivered a decree that no wormhole jump from any system will be permitted without prior authorization of the PGTU! Furthermore, this decree applies to all ships, even official CCW diplomatic and military ships. The Galactic Defense Committee is in an emergency meeting now to discuss a response to the decree. CCW Senate Entry - Stardate 338.312, Year 2619 The PGTU's charter as a trade union has been officially rescinded. They are no longer legally recognized by the CCW. We are attempting to freeze the assets of the PGTU, but this is proving difficult. The union is expansive, and has many industry allies. Complicating issues further, the Intelligence Ministry has pointed out that most PGTU assets were covertly moved into colonial accounts that are not accessible by the CCW, as if they anticipated this action. The Intelligence Ministry has also found evidence that the PGTU has been secretly building its own military fleet, through multiple equipment purchases made on the black market. The location of this fleet is currently unknown. The Senate enacted a resolution stating that if the PGTU does not evacuate all security stations within 3 days, military force will be used to reclaim all wormhole space. CCW Senate Entry - Stardate 339.911, Year 2619 We are at the brink of another war. At .817, the Confederate Destroyer Pegasus was annihilated by a PGTU stellar fortress while jumping through wormhole Delta, from the Polaris system to the Vega system. 227 souls were aboard that ship. A CCW military response is imminent. CCW Senate Entry - Stardate 340.497, Year 2619 I am at a loss for words. At .462 today, a CCW military assault was initiated against the PGTU stellar fortress in the Delta wormhole. I am told our attacking fleet consisted of 2 Battle Cruisers with 6 supporting Destroyers, and a class-4 Assault Carrier with a complement of 30 Cobra Fighters. Contrary to previous intel reports, none of the Confederate weapon systems were effective against the fortress' plasma shielding. And the offensive capabilities of the fortress were at least two orders of magnitude more powerful than expected. The battle lasted less than 3 minutes. All CCW vessels were completely destroyed. An emergency meeting of the Galactic Defense Committee is underway, to consider our options. All interstellar travel has been suspended until further notice.

It's been a year and a half, but I thought about this problem again last night, and came up with an optimal solution. Here's what the 256 byte lookup table would look like in a loop: LDX #27 CLC CountShieldBits LDY Shield,X ; 4, 2 LDA count8bits,Y ; 4, 3 ADC BitTotal ; 3, 2 STA BitTotal ; 3, 2 DEX ; 2, 1 BPL CountShieldBits ; 3, 2, 19 cycles per pass, 15 + 256 bytes = 271 bytes 19 cycles is fast, but 271 bytes consumed is unacceptable. If I can just remove one bit, I can halve the size of the lookup table: LDX #27 CountShieldBits LDA Shield,X ; 4, 2 LSR ; 2, 1 Carry holds one bit. TAY ; 2, 1 LDA count7bits,Y ; 4, 3 ADC BitTotal ; 3, 2 STA BitTotal ; 3, 2 DEX ; 2, 1 BPL CountShieldBits ; 3, 2, 23 cycles per pass, 16 + 128 bytes = 144 bytes 23 cycles per pass is still very fast, and 144 bytes is more acceptable ROM use. In the end, I will likely use jbane's idea. This is used to count the bits in the shield for Stellar Fortress, so I'll just maintain a counter, adding to it when the shield is recharged, and subtracting from it when the player shoots holes in it. Otherwise I'll have to give up 736 cycles to add up all the bits. (I expanded the shield to 32 bytes from 28 since writing the original question.) The strength of the shield will determine the pitch of the shield hum, similar to the original Star Castle game.

Has anyone ever compiled a library of Atari 2600 sound effects? I did some google searches, and also poked around on AA, but didn't find anything. If it doesn't exist, I'd like to at least make an ad-hoc collection here, in this post, which could possibly be compiled into a more formal collection later. Ideally, I'd like to have wave files of the sounds to go with the code, or perhaps a ROM that demonstrates all the sounds. In the meantime, the sounds I'm including below can be heard by playing the games from my blog. Each of my sounds assumes a SoundClk variable that starts at 0 and counts up once per frame. Splash - splashing sound from The Battle of Midway, when a bomb lands in the water. SplashSound LDA SoundClk CMP #16 BEQ DoneSound CMP #8 BCC SplashCreshendo EOR #%11111111 SplashCreshendo STA AUDV1 LDA #$08 ;Standard issue white noise. STA AUDC1 LDA #1 STA AUDF1 The Ominous Grumble - This is one of my favorite trademark sounds that I've used in Master of Arcturus and Hunt the Wumpus. In Hunt the Wumpus, you'll hear this sound when the Wumpus eats you. ComputerConquerSound LDA #$03 ;Ominous grunge tone. STA AUDC0 LDA #$1F ;Lowest possible note. STA AUDF0 LDA SoundClk CMP #255 BEQ DoneSound CMP #128 BCC Decreshendo1 Creshendo1 LDA #255 SBC SoundClk Decreshendo1 LSR LSR LSR STA AUDV0 JMP OverScanWait Launching and Landing - From Master of Arcturus. LaunchLandSound LDA #8 STA AUDC0 LDA SoundClk CMP #64 BCC ContinueSound0 CMP #96 BCS DoneSound EOR #%11111111 ADC #96 LSR STA AUDV0 OverScanWaitHop JMP OverScanWait ContinueSound0 LSR STA Temp4 LSR STA AUDV0 LDA Temp4 LDX SoundPtr CPX #2 BEQ LandingSound LSR ;Launching sound alteration. EOR #%11111111 ;Makes tone go up instead of down. ADC #32 ;Converts 64 -> 96 to 32 -> 16. LandingSound STA AUDF0 JMP OverScanWait Rubber band / Bow Firing - The bow sound when an arrow is fired in Hunt the Wumpus. PlayArrowShot LDA #7 STA AUDC0 LDA SoundClk CMP #8 BEQ DoneSound CLC ADC #4 STA AUDF0 EOR #%11111111 STA AUDV0 JMP DoneSoundCheck The Ion Pulse Cannon - From Stellar Fortress. This has a nice beefy sound to it. I wanted something more powerful than the pea-shooter from Asteroids. ; Sound 1: Ion Pulse Cannon. ; Volume fades as pitch goes from high to low. LDA #$0F STA AUDC1 LDA SoundClk CMP #32 BEQ DoneSound STA AUDF1 EOR #%11111111 AND #%00011111 LSR STA AUDV1 INC SoundClk JMP EndSoundQueue Here are sound ideas I'm currently working on. Suggestions are welcome. - Realistic water dripping. - A cricket chirping. - A frog croaking. - A person stumbling over rocks in the darkness. - A dragon breathing. Similar to the dragon breathing sound from AD&D for the Intellivision. - A rubber ball ricochet sound. I may be able to produce this sound by tweaking the pitch of the bow sound. Feel free to post your sounds here. You're welcome to use my sounds in your code, as long as you give credit in the comments.

Major Havoc would make a nice port to the 2600, using vertical scrolling, and walking off the screen for multiple horizontal maze sections. I'd love to do it myself, but I'm already buried in projects.

Very nice. Gotta love instructables. I get pretty girl-friend from instructables. I like the Stones, and the G&R cover, but I'm partial to Skrew's cover. One of the most severely mangled remakes ever.