TROGDOR

I have a habit of checking out the 2600 programming forums every week or so, and two weeks ago I started commenting on the topic Advanced sound techniques: how do they work? My interest in this topic was mostly in sample playback. I've been messing with digital sound samples since 1990, and I was very impressed when I found out a couple years ago that the 2600 was capable of playing back decent quality sound samples. My only exposure to this was the Berzerk Voice-Enhanced, which is a thing of beauty (and a joy forever.) While responding to that topic, I mentioned if I couldn't find a decent program to translate 8-bit PCM wav files into 4-bit Atari format, I'd try writing one myself. Well, tonight after I put the kids to bed, I had a couple beers and set to work. An hour later, I had wav2atari.pl: use Getopt::Long; $result = GetOptions ("wav=s", \$wavfile, "outfile=s", \$outfile, "help", \&usage); sub usage { print "\n$0 -wav <wav_file> -outfile <out_file> -help This program reads in the specified wav file. The sound data is translated into a 4-bit Atari format that is dasm readible. Two samples are encoded into each byte of output. A comment is placed every 256 bytes to denote a new page in Atari ROM. Note that the first of the two samples goes into the lower nibble. This works optimally in Atari code. The first sample can be written directly to AUDV0, since the register will strip off the higher 4 bits automatically. Then the second sample can be written to AUDV0 after 4 LSRs. This prevents the need for temp variables and saves precious cycles during playback. The asm data is written to the specified -outfile. RIFF PCM header information is written to STDOUT. Currently only 8-bit PCM wav files are supported.\n"; exit; } #$wavfile = shift; if ($wavfile eq "") { die "ERROR: Must provide input wave file.\n"; } open (WAV, $wavfile) or die "Could not open wavfile '$wavfile'.\n"; # Read ChunkID read (WAV, $data, 4); if ($data ne "RIFF") { die "ERROR: This doesn't appear to be a RIFF PCM WAV file.\n"; } print " ChunkID = $data\n"; # Read ChunkSize read (WAV, $data, 4); $data = unpack ("V1", $data); print " ChunkSize = $data\n"; # Read Format read (WAV, $data, 4); print " Format = $data\n"; if ($data ne "WAVE") { die "ERROR: This is a RIFF file, but it doesn't appear to be a WAVE file.\n"; } # Read Subchunk1ID read (WAV, $data, 4); print " Subchunk1ID = $data\n"; # Read Subchunk1Size read (WAV, $data, 4); $data = unpack ("V1", $data); print "Subchunk1Size = $data\n"; # Read AudioFormat read (WAV, $data, 2); $data = unpack ("v1", $data); print " AudioFormat = $data\n"; # Read NumChannels read (WAV, $data, 2); $data = unpack ("v1", $data); print " NumChannels = $data\n"; # Read SampleRate read (WAV, $data, 4); $data = unpack ("V1", $data); print " SampleRate = $data\n"; # Read ByteRate read (WAV, $data, 4); $data = unpack ("V1", $data); print " ByteRate = $data\n"; # Read BlockAlign read (WAV, $data, 2); $data = unpack ("v1", $data); print " BlockAlign = $data\n"; # Read BitsPerSample read (WAV, $data, 2); $data = unpack ("v1", $data); print "BitsPerSample = $data\n"; # Read Subchunk2ID read (WAV, $data, 4); print " Subchunk2ID = $data\n"; # Read Subchunk2Size read (WAV, $data, 4); $data = unpack ("V1", $data); print "Subchunk2Size = $data\n"; # Read in all the data. $data_byte_count = 0; $page_count = 0; $output = ""; while (read (WAV, $data, 2)) { @data = unpack ("C2", $data); if ($data_byte_count % 512 == 0) { $output .= "; Page $page_count\n"; $page_count++; } # If there is an odd number of bytes in the sample, drop the last byte. if ($data[1] eq "") { print "Warning: last byte of sound data was ignored because this file\n"; print "contains an odd number of sound bytes.\n"; $data_byte_count++; last; } # Note, the first of the two bytes goes into the lower nibble. This works # optimally in Atari code. The first sample can be written directly to # AUDV0, since the register will strip off the higher 4 bits automatically. # Then the second sample can be written to AUDV0 after 4 LSRs. This prevents # the need for temp variables and saves precious cycles during playback. #strip off the lower 4 bits. $lownibble = $data[0] >> 4; #shift 4 bits to the right, effectively stripping off the lower 4 bits. $highnibble = $data[1] & 240; $condensedbyte = $highnibble + $lownibble; $output .= sprintf (" .byte #%%%08b\n", $condensedbyte); $data_byte_count += 2; } print "$data_byte_count bytes of sound data processed.\n"; close WAV; open (OUTPUT, ">$outfile"); print OUTPUT $output; close OUTPUT; I had expected this program wouldn't be too difficult to write. The guts of the program is only about 10 lines. The rest is just spitting out the RIFF header info. For those who aren't familiar with a .pl file, it's a perl script. You'll have to have a perl interpreter installed on your system to use the script. But it should be easy to translate this program into your scripting language of choice if you don't happen to use perl. My quest to get my own samples working on the Atari started on Google. I quickly found a nice spec for the PCM wave format here. Next I grabbed a small random wav from Google to use as my test subject: hello.wav I'm pretty sure this particular hello is Graham Chapman from Monty Python and the Holy Grail. All the better. After I fed this wav file through wav2atari.pl, I made some modifications to my unsound wave generation demo, and then some more tweaking, and suddenly, it worked! Hearing this sample play back correctly in a 2600 emulator is one of the most satisfying moments I've ever had programming for the 2600. The atari binary still needs work. I just threw this together, so the sample playback rates are not perfectly balanced (the delay between the low nibble sample and the high nibble sample should be exactly the same, but they're not), yet it still sounds pretty good. If I get the time and energy, I'll enhance wav2atari to work on 16-bit samples, and add a downsampling option so you can specify the output sample rate. I also need to clean up the playback asm so the delays are balanced. The zip file I'm including below contains the wav2atari.pl script, the HELLO.BIN Atari binary, the hello.asm dasm assembly file, and the original hello.wav file for comparison. Enjoy! HelloWorld.zip Here's another demo that varies the pitch of the sample: HELLO2.BIN Here's the modified source code: hello2.txt The next thing to do is get a looping 256 byte guitar wave.

I could swear I found a program that could convert pcm to assembly code. The conversion is fairly simple. Let's say your source is an 8-bit sample at 8 kHz. You would grab each sample and strip off the bottom 4 bits, leaving you with a 4-bit sample. You would then do this to a second byte sample. Then you would take the two 4-bit samples and store them into a single byte for the Atari to use. (You'd want to store 2 samples per byte to make optimal use of the ROM.) If you wanted to downsample from 8 kHz to 4kHz, you'd just discard every other sample while processing the input data. All this data would then be written to an output text file in reverse order so it could be read in with a descending loop. This could be achieved with about 40 lines of perl code. If I can't find the original program, I'll try writing one. Playing back sounds during a game is possible, but very tricky. You'd have to have code inside your kernel that would play back a sample every 4 scanlines to play a 4 kHz sample. Even more difficult is the fact that you'd have to do this during the vertical blank and overscan. So you'd have to intersperse these playbacks at the exact cycle intervals throughout all your off-screen game logic. Only the most meticulous coder would be able to pull that off. The unsound code could be enhanced to be a tone generator. In its present state, it loops through 256 different tones. It could be enhanced to produce more tones by adding an extra byte of resolution, so you'd have 1000 or more distinct tones, which would allow for a perfect pitch song. The encoding for the song would be very small, only requiring a few bytes per note. Another possibility with sample playback is altering the playback speed of the sample. This would allow you to, for example, encode a short guitar wav and then alter the playback speed to produce different pitches. This could be used for a very cool intro song to a game, and could probably be done with a short 256 byte looping sample. It could also be used to make a drum machine on the 2600. No, Makebin is a different beast. That program converts starpath wav files directly into binary ROM files. It only expects starpath data recordings as input. I'm looking for a program that converts arbitrary pcm sound files into 2600 asm text.

A couple years ago I took an interest in advanced Atari sound techniques. Here's a small program that demonstrates high resolution pitch playback on the Atari using delays to alter the frequency of a square wave. With some polish, this could be used to play near perfect pitch music on the Atari, although it would have to be on a blank screen and in a single voice. Binary and source are included. Unsound.zip

Supercat, could you post the code for the playback, or a link to the source? I also know there's a program around that will convert 8K wavs to Atari 2600 asm, but I'm still poking around the forums to find it. Otherwise I'll have to reinvent the wheel and write one in perl.

Sample playback on the 2600 is achieved by setting AUDC0 to 0, which produces a waveform that is always high (does not oscillate.) You then provide the wave pattern by rapidly changing the volume in AUDV0. The quality of the samples you can play will depend on 3 things: - The resolution of the the sample. Atari 2600 samples are 4-bit, which corresponds to the 16 volume levels possible in the AUDV0 register. - The speed of the CPU. The Atari 6507 operates at 1.19 million cycles per second. To produce a 41 KHz sample, you would have 1190000 / 41000 = 29 CPU cycles per sample, which might be possible with a tight assembly loop. - The size of your ROM. A 41 KHz sample would sound great, but it would consume 20.5k bytes of ROM per second, (storing 2 4-bit samples per byte), which is too much for the relatively small Atari ROMs. So, most samples for the Atari are recorded around 1k to 4k per second, depending on how much ROM you're willing to burn. To produce a 4 second sound sample at 1K samples per second, you would need 2K of ROM. Pseudo code to achieve this would look like: LDA #7 STA HiByte LDA #0 STA LoByte PageLoop LDX #255 ByteLoop LDA (HiByte),Y STA Temp ; AND %00001111 This actually isn't necessary. The top 4 bits will be ignored by the AUDV0 register. STA AUDV0 Wait LDA Temp LSR LSR LSR LSR STA AUDV0 Wait DEX CPX #255 BNE ByteLoop DEX HiByte BPL PageLoop I just banged this code out. I can't guarantee it will work, but it should be close. The Wait will burn cycles such that 1/1000 of a second would pass between each sample update. This would use a NOP loop that burns 1190 cycles, minus the cycles consumed for the playback code. This requires exact timing, which is why some games blank the screen when they play a sample. The processor has to focus on playing back the sample at the exact times, so it can't be used to update the screen display. It is possible to play back samples while displaying an image on the screen if you sync up the sample playback with the kernel scanlines. Each scanline uses 76 cycles. 1190000 / 76 = 15657. So if you wanted to sync up a 1kps sample playback with a display kernel, you'd have to update AUDV0 once every 15 scanlines. (The math would be easier if you updated every 16 scanlines.) You'd also have to update AUDV0 at that same interval during the vertical blank and the overscan, to keep the playback in sync. It requires advanced coding to make this work. It's much easier to just blank the screen during playback. Regarding your question about manipulating a signal at faster than 60 Hz, this can be achieved without using samples. You just need to alter the sound registers more than once per screen. If you altered the sound register twice per screen (at even intervals), this would result in 120 Hz signal processing. 3 times per screen would be 180 Hz, etc. Though I've never coded for the Channel F, I've read enough to know that the sound system is very primitive, even by Atari 2600 standards. To play a song, you turn the sound register on and off to simulate a square wave. The interval between turning the sound on or off defines the pitch of the square wave. This requires carefully timed code, so you can't generally do anything else while playing music.

Hi all, I have some questions about the parts used for making homebrews. Why are older used components generally used for homebrews rather than new components? I have a systems engineering background, so I understand that there are legacy concerns when designing carts, the most important issues being a match on voltage levels (many newer components are 3.3v or 1.8v, which won't be compatible with the Atari's older 5v standard.), and also cycle time and setup/hold concerns (new chips will operate at higher speeds, which may not be compatible with the slower cycle time and setup/hold timing expected by the Atari 2600.) I'm guessing Albert and others have already done research into using newer parts, and found some reason why they can't be used. I've been wondering about this for some time, but I was prompted to ask when I saw Albert's request for SARA SuperChip carts for use in new homebrews. Are there any newer RAM chips that would match the spec for the SuperChip? Another thing I'm curious about is could AtariAge reduce costs by standardizing on one or two cart designs? Rather than offering 4k, 8k, 16k and other size carts, just buy a larger quantity of the largest EEPROM size, and then don't use the extra EEPROM space if you don't need it for your particular game. Same goes for the RAM. Rather than looking for an exact match for 128 bytes of RAM, it may be cheaper to go with a larger RAM as long as it matches the specs for the Atari. Game designers could decide to limit themselves to only 128 bytes of RAM if they wanted their game to have the same constraints as a SuperChip game, even though the cart would actually have, say, 2K RAM available in a particular bank. It would depend on unit pricing, but it seems larger volume purchases would make up for any price difference in the physical capacity of the chips.

I played this game several times at a local Pizza Hut back in 1980. I remember the game being very difficult. Of course, I was 9 at the time, so most early video games were tough. I'll have to hunt this down on Mame. The demo is great. The title screen does an excellet job capturing the nostalgia of the original game. The game play and maneuverability are spot on, and the graphics look fine. I've never been a fan of flicker, but between the phosphor option on Stella and the appearance on an actual TV, I don't think it will detract from the game. Good luck with your development.

That's a good suggestion batari, but it has restrictions. That's (x * 1.5) / 15 = x / 10. However, it only works for values up to 170. 171 * 1.5 = 256.5, which would cause an overflow.

Very nice. Here's the original article. It also includes a compact divide by three, and the infamous divide by 15. This technique can be adapted for all n in (2**n)-1, so variants would work for divide by 3, 7, 15, 31, and 63. DIVIDE.BY.THREE LDA BYTE LSR LSR ADC BYTE ROR LSR ADC BYTE ROR LSR ADC BYTE ROR LSR ADC BYTE ROR LSR RTS Does anyone know any tricks like this for dividing by 5? Maybe some kind of (2**n)+1 equivalent? If you can divide by 5, you're only a shift away from dividing by 10.

My usual modus operandi for Adventure is to grab the bat and never let him go. I just use him as an extension of my arm (well, dot in this case.) This is particularly useful for killing the dragons when both difficulty switches are set to A and they run from the mighty arrow. The bat is more than willing to pick up an attacking dragon, at which point I drag the bat and the dragon to where ever I left the sword, and peeeeew, one less dragon to worry about. My four year old son recently got through his first complete game of level 1 with no assistance. Adventure is not only the best game for the 2600, it is IMHO the greatest video game ever written.

I still have my original Heavy Sixer, tucked away in the original box. I never use it. I prefer to do all my gaming on emus to prevent wear and tear on the hardware. I also have my original Intellivision II system. I had a Colecovision system, but I sold that on usenet in the mid 90s.

If you look at the zoomed image, you'll see this is another fine product from Hozer Video Games. Every time I see a Hozer game, I throw up in my mouth and have to go eat a Tums. Please excuse me for a moment.

Back in 2004 I wrote a game called Master of Arcturus for the 2004 minicomp. It was never productized to the point that I could release it on cartridge. Exploring the Galaxy so90.zip 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. Final Enhancements: - Improvements to the color palette. - Add destroying all enemy fleets as a condition of winning the game. Currently, all that is required is conquering all worlds. - Provide acceleration in level selection, similar to acceleration in ship selection. - 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. Development Notes: I'm trying to make this a final, polished product. There are still several bugs that detract from the game. The title of the game was changed to fit into a trilogy of games which will all take place in the same fictional universe: Stellar Overlord, Stellar Fortress, and Stellar Adventure. For the past couple weeks I've been working on the manual. I lost the original MS Word doc for the manual, so all I had was a pdf. I imported it into OpenOffice Writer 3, but it was a mess. So I had to rewrite the whole thing from scratch, which was a lot more work than I was expecting. But most of the work is now done. One major flaw in the original minicomp release was that I didn't explain the levels better, particularly the AI. I've added several pages of info describing the levels in the game, which should make the game easier to understand and enjoy. I contacted an artist, eRe4s3r, from deviantart who was kind enough to contribute some of his CGI spacecraft to the manual and cartridge label. The manual is formatted as 5.5 by 8.5 inch pages, so 8.5 x 11 inch paper can be folded to make the manual. I may reformat it to a smaller page, but that will wait until I do more research on my printing options. The final product will also have a box, using this template. Please let me know if you see any bugs in the game that aren't listed, or if you see any typos in the manual.

It would only work in my specific program. However, it could be used by anyone as long as you add the label "LastFrameOp" in your source code, defined as the final JMP or RTS in your overscan procedure. I didn't realize the same discussion was happening in the topic right below mine.

I figured out a way to do it. I just create a label that marks the final JMP in my overscan code. When that jump is reached, it must be scanline 262, because the JMP is the last operation in the frame. So a check would look like: breakif { pc == LastFrameOp && _scan != #262 }

Thanks Thomas. After a little RTFM, I tried this: breakif _scan==#263 Which flagged a bad frame. This will detect if the frame goes over 262. How would I detect if the frame completes at less than 262 frames?

Most emulators have a way to display the number of scanlines per frame. But do any emulators support the ability to flag a frame that goes over 262? I'd like to use that event as an interrupt trigger, so I can ensure that all the frames in my games never deviate from the expected 262 scanlines.

You need help. But your demo is amazing. Nicely done.

I play about 15 minutes a day of Adventure with my son, right before his bath time. He refers to it as "the dragon game." He's 4, and he can get all the way through level 1 by himself. When I get him set up with a joystick, I'll unleash him on level 2. His other favorite game is "the two eyes monster game." Hunt the Wumpus. He can't really play that game; he just watches me play a couple rounds. The majority of my Atari game time is spent play testing homebrews. (Unfortunately it's often play testing when I should be coding.) Just got done playing an hour of Stellar Overlord. Stellar Overlord is what Master of Arcturus will become, if anyone remembers that game. I owe you guys a blog update.

The mockups look very nice, but I honestly don't think this is feasible on a 2600. I count 6 playfield updates + p0 graphics update + p0 color update + p1 graphics update + p1 color update + missle in one scanline. Optimally, that's 42 + 17 + 8 + 17 + 8 + 13 = 105 cycles, not including loop overhead. That's not possible, even in RAM. Even with a 2LK, which this appears to be, you'll still have 42 + 17 + 8 + 13 = 80 cycles. Edit: I reread the posts, and see that you're trying to minimize the playfield refresh. That's a good start to making this feasible. But keep in mind is that even with a double-height display, you still have to update the playfield each scanline if it's asynchronous. That's why asych playfields are so tough to implement on a 2600, and usually require venetian blind implementations for complex backgrounds. The graphics translation for Simon is impressive. Well done.

LEHMANBROS01.BIN Overview In this game, you control the CEO of a distressed investment firm. The game takes place at the firm's headquarters. Your objective is to collect as much cash as possible for your severance package before the company collapses. As you are collecting money, a variety of opponents will hinder your efforts. The Federal Regulator (turtle) - Slow and easily avoided. But be careful. If a Federal Regulator catches you, your CEO's severance package is capped and he must be replaced by new federally-appointed CEO. The SEC Investigator (crab) - Quick and tenatious. The SEC Investigator will become enraged if you obstruct his investigation. If he catches you, your CEO must step down, embroiled in an ongoing criminal investigation. The Angry Investor (fly) - He's hopping mad! If an Angry Investor catches you, your CEO is subjected to a multibillion dollar class-action lawsuit, and must resign. The Investigative Reporter (ice block) - A general nuisance. If the Investigative Reporter catches you, your CEO will find himself on the front page of the New York Times, busted for cooking the books. The Board of Directors will compensate you for thwarting these enemies. While you are conducting day-to-day business, flaming subprime mortgage-backed securities will fly across the screen. You may find yourself tempted to grab one, with their promise of asset-backed low risk and attractive long-term yields. But don't be fooled. If your CEO touches one of these, he'll get burned. If you manage to survive a few fiscal quarters, you will be rewarded with a bonus round. During this round you meet with the Board of Directors to reevaluate your compensation package. It's basically a money grab. Take as much cash as you can before the timer runs out. This can significantly increase the size of your package. When you lose a CEO, he will be replaced with an interim CEO. The new CEO will come flying in from the top of the screen, strapped to a golden parachute. The game ends when you run out of viable replacement CEOs. The company files for bankruptcy, the Fed and the SEC return to Washington, all the investors jump from tall buildings, the reporters move on to other troubled firms, and you are forced into a cushy retirement with the severance package you managed to secure. Score is displayed in thousands of US dollars. A respectable score is 50 million dollars (50,000 x 1k). Anything less than that and you'd be embarrassed to show your face at the yacht club. 2 player mode - In this mode, player 1 controls the CEO and player 2 controls the CFO. You can either work together or competitively to secure the company's assets for your severance packages. The Bush Administration gets credit for providing the concept for this game. Development Notes This is my first hack. Normally I'm not a big fan of hacks, but when I heard that Lehman Brothers went bankrupt, thoughts of Mario Brothers were floating around in the back of my mind. On Friday I decided this needs to be a game. The first step was getting a good hex editor. It was no surprise that vim has built-in hex editing support, so that's what I've been using so far. I've also gotten my first experience of bricking a hacked ROM. At some point during my edits I changed the wrong byte somewhere and everything stopped working. I've been more careful about maintaining revisions since that happened. The only modification I've made so far is to the title screen. Other modifications will include transforming Mario into a bald-headed gray suit with a tie, changing each of the enemies into their respective new forms, and adding the golden parachute if possible. Otherwise, the gameplay will remain the same. The ROM is tightly packed. There isn't much room for new code. As such, I'd like to get a disassembly for this cart, so I can move the data around and tweak the code. Trying to do this in the raw binary is proving to be painful. If anyone knows where I can find a disassembly of this game, please let me know.

Nicely done, eh! You can find an mp3 of the Canadian anthem here.

Thanks Nathan. Horizontal ship motion can't be done without more RAM. I'm currently using 36 bytes of RAM to display the ship. Scrolling the ship across the bottom of the screen would require at least 60 bytes of RAM (5 x 12), and would only be possible with a dedicated kernel that wouldn't allow any other movable objects on the same scanline, because I'd have to refresh all 3 playfield registers twice on every scanline. I'm already using up most of the RAM, so I've punted on the idea of a moving ship. I have considered clouds, but they wouldn't be moving clouds. An aysnc moving cloud in the area where the planes fly would use too many cycles. The current kernel is updating all 5 movable objects on every scanline, so there aren't a lot of free cycles. But I'm thinking about adding a static cloud using a mirrored playfield that would appear on harder levels.

Thanks Bob. The vertical plane wrapping will be gone after a few more enhancements. When I upgrade the computer AI, the Zero will have flight patterns and boundary checks that will prevent it from flying off screen. For the player, if you fly too low, you will be shot down by the capital ship. If you fly too high, your plane will stall out. You'll then have to restart the engine before your plane crashes. (Similar to the biplanes in Intellivision's Triple Action.)

This is the first release of the game that is minimally playable. You can actually sink the ships now. Mission Accomplished tbom21.zip New Features: tbom18.asm 8/3/08 - Removed HMOVE artifact from title screen using cycle 73 HMOVE. - Time-based high-res physics engine for Zero. - AI to control Zero flight patterns. (preliminary) - Crash animation and sound Fx for Zero. - Multiple vectors for AA fire. - Detects a hole in the ship, and when the ship has been sunk. - Added preliminary sound Fx for sinking ship. tbom19a.asm 8/6/08 - Kernel cleanup. Changed the main kernel from a 2LK to a 1LK that makes proper use of VDEL0. tbom19b.asm 8/7/08 - Kernel Cleanup. Changed the main kernel to use quick load masks instead of skipdraw. tbom20.asm 8/15/08 - Preliminary ship sinking effect. - Unwrapped the ship display kernel loop to open up 15 cycles. - Added WaterLevel variable to display water transition in ship kernel. - Added random changes to water level to simulate waves. (3 levels) tbom21.asm 8/18/08 - Prevent AA fire when capital ship is sinking. - Flashing background while ship is sinking. - After ship sinks, new ship is displayed. - Levels implemented. Odd levels have the Yamato Battleship. Even levels have the Akagi aircraft carrier. If you sink both capital ships, you start back at the Yamato, but you will have to bomb two holes all the way to the water to sink the ship. This pattern continues. For every two ships you sink, the next two will require that you bomb one more hole to sink it. To Do: - Proper physics engine for player plane, to allow for engine stalling. - AI targeting for AA fire and Zero fire. - Better transition between ship sunk and new ship. - Better end of game sequence. - Display the game level somehow. Probably in between ships. - Squadron attacks with alert klaxon. (triple sprite enemy planes.) - Improve sound channel multiplexing. Known Issues: - If you collide with the Zero, after your planes crash your new plane will be hit as soon as it appears. This should be an easy fix. I'm missing a collision register reset somewhere. - If a bomb is falling and you press reset, the falling whistle will continue to play during the title screen. Development Notes: An early version of the instruction manual is included with this release. It's recommended reading if you download the binary. The game now has levels. Here's the description of the levels from the manual. <> Progressive Difficulty Each time you sink a capital ship, you will advance to the next level. The level determines the type of capital ship you must sink, and the number of holes required to sink it. Level Ship Holes to sink 1 Yamato 1 2 Akagi 1 3 Yamato 2 4 Akagi 2 5 Yamato 3 6 Akagi 3 7 Yamato 4 8 Akagi 4 There are still several features that need to be added. The game will get a lot more challenging. There will be at least two phases to the game. In the first phase, you will defend your own capital ship from enemy bombers. You will have to shoot the bombers down before they can drop their bombs on your ship. In the second phase, you will attack the enemy ship, which will be similar to the current demo.