Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store

TROGDOR

Members
 View Profile  See their activity

  • Posts

    279

  • Joined

  • Last visited

 Content Type 

Blog Entries posted by TROGDOR

  1. TROGDOR

    wav2atari.pl

    By 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.
  2. TROGDOR

    Porting Elite to the 2600

    By TROGDOR,

    After spending a couple days researching Elite, I'm convinced this game could be ported to the Atari 2600 and still retain most of its original look and feel. Here's what the original Elite looked like on the Commodore 64:
     

    And here's a prototype screenshot on the Atari 2600 (this is from an emulator, not a mockup):
     

    The Bitmap
     
    The first challenge of the port is implementing a high-resolution bitmap. This can be achieved by using the 30Hz text display from Stellar Track. The 12 characters from this display provides a resolution of 12 x 8 = 96 pixels per scanline. The next question is how tall should the display be. This is defined by how large of a video buffer can be provided and maintained by the hardware. I chose a 1K buffer as a reasonable target. 1024 / 12 bytes per line = 85 scanlines. This would fit nicely in the 96 scanline resolution of a 2-scanlines-per-pixel Atari display. Using square pixels also simplifies the rendering math.
     
    To simplify the kernel code, it would be preferable to keep each column of buffer bytes in its own page. 84 x 3 = 252, so using 84 scanlines you can fit 3 1-byte columns in a single page. Multiply that by 4, and you've got 12 characters spanning 84 scanlines, so the final resolution is 96 x 84 pixels. The size of the bitmap can be seen inside the yellow border in the prototype image.
     
    The Hardware
     
    The 2600 only has 128 bytes of RAM, so it's going to need some help. The only current options for hardware that would provide a 1K RAM buffer are the Supercharger and an M-Network cartridge. The Supercharger only allows for a 6K game without multi-loading, and I don't think 6K would be sufficient to do an Elite port justice. Writes to Supercharger memory are also slower, if my conclusions from studying the Supercharger are correct.
     
    The M-Network architecture, on the other hand, is just about optimal for this scenario. The 16K of ROM provides plenty of room to make a detailed game. The 1K continuous block of RAM is perfect for the high-resolution buffer, and allows quick read and write access to the entire buffer. The extra 1K of split RAM would be useful as scratch memory for the 3D calculations, and also as extra memory to store details about your ship configuration and cargo.
     
    Another hardware consideration is the CPU. The main processor for the Commodore 64 is a MOS 6510 running at 1.02 MHz. The Atari CPU is a MOS 6507 running at 1.19 MHz. It's surprising that the Atari CPU, released in 1977, is clocked 19% faster than the Commodore CPU, which was released 5 years later in 1982. Other than the I/O port and the extra address pins, I'm not aware of any 6510 feature that would make it more powerful than a 6507. So the Atari starts out with a 19% advantage over the Commodore.
     
    The big disadvantage for the Atari is having to process the kernel. This effectively excludes 192 of the 262 scanlines from any kind of render processing, resulting in a (192/262) = 73 percent loss of processing power. So only 27% of the processor can be dedicated to rendering. When the faster Atari clock is factored in, you get 27 * 1.19 = 32 percent speed relative to the Commodore processing. So it can only handle about one third the processing load.
     
    Video Buffer Sizes
     
    The upside of the small Atari video buffer is that there are fewer pixels to render. The Commodore buffer used 256 pixels by about 140 pixels, for a total of 4480 bytes. The Atari is using less than 1024 bytes, so it has less than a quarter of the pixels to render. This matches well with the one-third processing power.
     
    Rendering
     
    The main functions needed to display the images are:
     
    3D Rotation
    Projection from a 3D object to a 2D plane
    Hidden surface removal
    Line drawing
    Circle drawing
     
    I found some online resources that could really help with these functions. The most authoritative source is one of the original authors, Ian Bell, who posted the entire source code for Elite! This source was written for a BBC Micro, which also uses a MOS 6502. The only problem is there are very few comments in the code, and it's written in some kind of BASIC wrapper around the assembly code.
     
    While googling for 6502 3D algorithms, I happened upon a great 3D tutorial written specifically for the 6502. If you scroll down to the "art of 3d" section, you'll find three links to C= Hacking issues. It's a 3 part study titled "A Different Perspective: Three-Dimensional Graphics on the C64." It includes a very detailed discussion of projections, rotations, line drawing, circle drawing, and hidden surfaces. It also provides full assembly implementations of these algorithms, and optimizing suggestions. I highly recommend it.
     
    Code Organization
     
    Using the M-Network bankswitching scheme, here's how I think the implementation would work.
     
    ROM bank 7 (slice 1)
     
    On system boot, the code would immediately bankswitch to bank 0. Bank 7 would be entirely reserved for only routines that need to access the 1K RAM buffer. This is necessary since none of the other banks can access this RAM directly, and it would be far too slow to use bank switching to set the video buffer or read it for kernel processing. So, the only code that would go here is the bit-mapped section of the kernel (which is actually very small, less than 200 bytes,) and the line drawing and circle drawing routines, which would need direct buffer writing access. Hopefully they could be squeezed into 1.5K.
     
    ROM banks 0-6 (slice 0)
     
    All the other routines, including projection, rotation, and surface removal, would go here. The only data that would have to be passed to slice 1 is an array of line and circle definitions that need to be drawn to the screen. This array could be stored in one of the 256 byte RAM sections, which are also available to slice 1. Other ROM banks would include system boot, sound effects, text display, trade interfaces, and all the 3D data for the various ships. It would also include the non-bitmapped bottom portion of the ship kernel, which would include radar and ship status meters.
     
    Concessions
     
    I think the Atari could keep up on the Video RAM drawing routines. I'm not so sure it could keep up on the 3D rendering. I don't know what the ratio of necessary compute power is between these two functions. However, there are several concessions that could be made to reduce the 3D rendering load on the Atari. The most obvious is to reduce the number of lines and polygons on the ships. For the ship displayed above, the rear of the ship consists of an 8-sided polygon, plus 4 4-sided polygons for the thrust ports. The 8-sided polygon could be reduced to a 6-sided or even 4-sided polygon (a trapezoid) and still retain the look of the original ship. The two smaller thrust ports could also be removed. Small alterations like this could save significant processing time.
     
    Another optimization is to greatly reduce the polygon count when the ship is farther away. I'm not sure if the original Elite games did this, other than turning them into dots when they are very far away. For the Atari version, any ship that is sufficiently far away can be reduced to just 4 points, essentially a pyramid, of varying shapes and sizes to match their corresponding ship.
     
    Other Platforms
     
    There are two other systems that came to mind while I was doing this study. The first is the Channel F. Oddly enough, its hardware setup is great for 3D rendering. It already has dedicated RAM for a screen buffer, and its resolution of 102 X 58 is comparable to the Atari buffer, minus the flicker. Plus, its CPU operates at 1.79 MHz, so it has the most processing power and the smallest video buffer to render. I know that video RAM access is slow in the Channel F, but this still sounds like a possibility.
     
    The other system of interest is the Vectrex. This system is begging to have an Elite port. Graphics rendering would be a breeze on this system. The Vectrex is powered by a Motorola 68A09 at 1.5 MHz, which is far more powerful than the Commodore CPU. Elite ported to this system could look better than any of the original 8-bit versions. A Google search produced no evidence of any effort to port Elite to the Vectrex.
     
    The Prototype
     
    elite_study.zip
     
    The prototype binary I'm posting here is quite simple. It doesn't contain any 3D rendering. The ship is just a static image loaded from ROM. What it does demonstrate is the size and appearance of the bitmap, and the simplicity of the kernel. The only difference between this bitmap kernel and an actual M-Network bitmap kernel is that it would point to a different location in memory, corresponding to the M-Network RAM, rather than ROM. The VideoRAM[0-11] addresses in the source would become RAM pointers.
     
    I haven't implemented this in an M-Network bankswitching scheme yet. That will require more research, since the M-Network switching method is fairly complicated.
  3. TROGDOR

    Death of a Laptop

    By TROGDOR,

    My main laptop died last month. It was a Dell Vostro 1400, and I was very happy with it up until the video card fried. Its best feature was the Nvidia Geforce 8400GS video card, which had its own dedicated video memory. Regrettably, that feature was its undoing.
     
    The system died a couple months after the 1 year warranty expired. I did some research on the problem, and found that graphic card failures due to overheating were a common problem for this particular laptop model, common enough that Dell has supposedly extended the warranty for an extra year if it fails for this reason. Hopefully I can get it fixed under warranty.
     
    Unfortunately I had all my Atari development code on that system. The good news is that the harddrive is still intact, and the system still boots. I just can't see the display at all. The main laptop display is blank, and the external display port is also blank. I'll have to work with Dell to figure out how I can get the data off that harddrive without voiding my warranty. I have an external SATA disk reader. If I can pull the diskdrive out of the system, I can backup all its contents. There is no way I'm shipping off a system for repair work without backing it up entirely. I've heard too many horror stories.
     
    I'm now back on an old laptop that I haven't used in two years. It was so old, it had Stella 2.1 installed. Since I can't access any of my existing Atari work, that has left me with a clean slate to spend a few hours yesterday doing a 2600 port feasibility study. I'll post the results soon, probably tomorrow. Here's a snapshot of what I have so far:
     

  4. TROGDOR
    I'm an avid fan of robotic technologies. Over the past several years I've been following the progress of advances in robotics, including mechanical dexterity, sensor implementation, and software AI. I'd like to share these advances with the AA community and discuss their implications. I think the robotic industry is on the verge of a profoundly significant break through, where robots will start to become ubiquitous in our lives. (As I am typing this post, there are two robots cleaning my kitchen, and they're doing a great job. But I'll get more into that later.)
     
    I'm going to break this discussion up into several parts, so it's not one long post. In this first installment, I'll present the state of the art in robotics, which is best demonstrated by an assortment of videos.
     
    http://www.youtube.com/watch?v=Q3C5sc8b3xM&NR=1
    Asimo
     
    Asimo is the gold standard in the world of robotics. Honda has been working on this model for over 20 years, with the first demonstration in 1986. This robot hosts many features, including advanced environmental recognition, excellent balance and motor skills, and the ability for both feet to leave the ground while running, which allows for significantly faster movement. The above video focuses mostly on Asimo's motor skills.
     
    I'm taking my family to Disneyland next week. One of the highlights for me will be the chance to see an Asimo robot in person at the Tomorrowland exhibit.
     
    http://www.youtube.com/watch?v=Yh7xssnhoXM&NR=1
    Toyota's Partner Robot
     
    Toyota is also investing in robotic R&D. They have some nice musical demonstrations, but I get the impression they are behind Honda in this field.
     
    http://www.youtube.com/watch?v=qyPAIpXm-nU
    Toyota's Partner Robot II
     
    This is another Toyota demo, this time playing a violin.
     
     
    http://www.youtube.com/watch?v=CETUmThm8Rg
    Twendy-One
     
    This robot was designed at Waseda University in Tokyo. The video demonstrates precise manual dexterity.
     
    Japan in general has been investing far more money into humanoid robotics than the United States. Their primary motivation for this investment is the long-term goal of providing care and companionship for Japan's growing elderly population.
     
    http://www.youtube.com/watch?v=MY8-sJS0W1I
    Repliee Q1
     
    A related field that the Japanese have been working on is building life-like humanoid robots. Repliee Q1 is capable of fairly life-like eye and mouth movement, and upper body gestures. Her facial construction has a realistic appearance, even when the camera is zoomed in.
     
    http://www.youtube.com/watch?v=M3tcSlWLS_g
    Actroid DER2
     
    Kokoro's Actroid DER2 Female Robot is the most realistic android I've seen so far.
     
    http://www.youtube.com/watch?v=aQS2zxmrrrA
    Nexi MDS
     
    Continuing on the theme of human interaction robots, here is a video of Nexi MDS, developed by MIT's Media Lab. This robot's specialties are facial expression and manual dexterity. But I'll let her speak for herself.
     
    http://www.youtube.com/watch?v=SSkG5xf_ytQ
    R Daneel
     
    This robot, designed by the University of Tokyo ISI Lab, is human-sized and has the impressive ability to stand up on its own, using a familiar martial arts technique.
     
     
    http://www.youtube.com/watch?v=rSKRgasUEko
    Nao
     
    Designed by the French company Aldebaran Robotics, Nao is an impressive little robot with many capabilities. This is the first robot I've seen that can bend over and pick up an object off the ground. It can also lift itself up when it falls over.
     
    http://www.youtube.com/watch?v=WZmWjfRJtyU
    More Nao
     
    This is another Nao demonstration which shows its excellent sense of balance. Note that this video shows Nao using a different technique to get up from lying on its back. In the previous video, it was lying on its front.
     
    The blog software won't let me post any more videos, so this is a good stopping point. I'll post more on this topic in the future. Feedback and comments are welcome.
  5. TROGDOR

    Stellar Overlord v0.95

    By TROGDOR,

    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.
  6. TROGDOR

    Stellar Overlord v0.90

    By TROGDOR,

    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.
     



  7. TROGDOR

    Lehman Bros. v0.01

    By TROGDOR,

    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.
  8. TROGDOR
    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.
  9. TROGDOR

    Nort.exe

    By TROGDOR,

    If I had infinite free time, I would write the game Nort.exe for the 2600.
     
    In Nort.exe, you are a computer program, trying to survive deep in the bowels of the Vista Operating System. The game would consist of 4 phases:
     
    Phase one: DRM
    Due to an errant MD5 checksum calculation, Vista's DRM has incorrectly matched your program file with "Britney_Spears_-_Baby_One_More_Time.mp3". Your program file is now targeted for deletion. Use your tank process to destroy the DRM subprocesses and escape.
     
    Phase two: Windows Defender
    Windows Defender has misidentified your program as an ActiveX virus. Your program has been targeted for quarantine and deletion. You must drive your instruction cycle to out maneuver the Defender subprocesses attempting to quarantine you within their paging boundaries.
     
    Phase three: Rootkit
    A Sony Rootkit has installed itself on the system's boot sector. It has decided that your program was installed by a competitor, and has targeted your program file for deletion. You must escape to the safety of the L2 Cache before the rootkit's self-replicating code consumes you.
     
    Phase four: Out of Memory
    The Kernel has locked up, and is now consuming memory at an alarming rate. A thrashing swap file is threatening to overwrite your program. You must blast through the incoming write packets and seize control of the Kernel to prevent total system failure.
  10. TROGDOR
    With the Atari movie coming up, I've had some motivation to do more coding. I took another look at The Battle of Midway this weekend, and here are the results.
     

    More entitlement.
     
    tbom17.zip
    New Features:
    tbom16.asm 7/13/08
    - Removed unnecessary procedural subroutines, freeing up some ROM and cycles.
    - Expanded the ROM out to 8k. VSync and Overscan are in bank1, Kernels are in bank2.
    - Displays title with fade-in effect and player's plane.
    - Integrated include files into the main .asm file.
     
    tbom17.asm 7/14/08
    - Added score display in playfield graphics.
    - Added scoring: Bombing the ship 10 points, hitting the enemy Zero, 50 points.
    - Added sound effects for crashing airplane.
    - Added player life count, and game end when all lives are lost.
    - Resets the bomb and bullet when they hit.
     
    To Do:
    Remove HMOVE artifact from title screen.
    Multiple vectors for AA fire.
    Time-based high-res physics engine for Zero.
    Proper physics engine for player plane, to allow for engine stalling.
    AI to control Zero flight patterns.
    AI targeting for AA fire and Zero fire.
     
    Known Issues:
    - None so far.
     
    Game Controls:
    - Press fire to start the game.
    - Left and right control the pitch of the plane. (As in aviation pitch. Ironically, it does also change the pitch of the plane's engine, to represent stress on the engine.)
    - Fire button fires the machine guns. The machine guns will overheat if you hold the button too long. I'll probably pull the overheat feature, since it eats a byte of RAM and doesn't add much to the game.
    - Pressing down on the controller will drop the bomb.
     
    Development Notes:
    One benefit of having all these open projects is I'm getting tons of code reuse. Building 8k ROMs is second nature now, and it only took about half an hour to expand this ROM from 4k to 8K. I also dropped in the score display code from Hunt the Wumpus and from Stellar Fortress to compare them. For now, I'm going to use the Stellar Fortress playfield score display, but it may change back to player graphics before I'm done. My main concern when displaying the score is using as little of the screen realestate as possible, so I try to keep it in 5 scanlines. Either implementation will allow me to display a 7 digit score and a one digit life count.
     
    I had wanted to clear up that HMOVE artifact before posting this, but it's proving troublesome. This is my first attempt at using a cycle 73 HMOVE, which is that much harder when trying to implement it with a 48 bit display. The pixel movement wasn't happening as expected, and the title came out completely garbled. I have two questions about this:
     
    - When it says HMOVE at 73 cycles, does that mean the HMOVE write starts at the 73rd cycle, or ends at the 73rd cycle?
     
    - I'm guessing that all the move registers have to be set to 8 to prevent any motion. This makes the HMCLR register useless in this mode.
     
    So I punted for now, and just displayed the title with the artifact.
     
    As a demo feature, the game will randomly pick one of the two enemy capital ships when you press the reset switch, so you'll see the battleship Yamato more often.
     
    Here's the cartridge label mock-up I posted some time back:
     

  11. TROGDOR
    Entitlement.
     
    sf23.zip
    New Features:
    sf22.asm 3/2/08
    - Added preliminary title music.
    - Reorganized bank data. All kernels will now live in bank 2. Bank 1 contains the VBlank and Overscan.
     
    sf23.asm 5/24/08
    - Changed cannon graphics. Uses lower vertical resolution. Cannon is larger. Now has 16 rotational animation positions instead of 8.
    - Added Title Screen mode. Press the fire button to begin the game.
    - Added Title graphics.
     
    To Do:
    - Rewrite the kernel to squeeze out more cycles and allow for some extra features.
    - Improve the Plasma Cannon graphics. Currently only 8 directions are implemented. This will be expanded to 16, as was done with the player's ship.
    - Design the Stellar Fortress destruction animation.
    - Title screen and title music.
    - Targeting computer for missiles.
    - Add starting level selection and gradual difficulty increase per level.
     
    Known Issues:
    - There seems to be a glitch in the title music. It misses a beat every few seconds. Gonna have to figure that out.
    - The mapping for player shot collisions with the fortress shield are still off by a couple pixels.
    - The final game will not have the fortress cannon shooting all the time (at least, not on most of the lower levels...) I need to implement a feature that will detect when a hole has been poked in the shield so the cannon can fire out.
     
    Development Notes:
    I broke a lot of game features when I moved the banks around and added the title mode. Most of the work I did for the last 3 months was cleaning up everything that was broken. But the original functionality is back, and the reorganization will make future development cleaner.
     
    I also beefed up my copyright notice, so none of my games will get Hozed. For clarification, the games that I post in this blog are not open source, nor are they public domain. I will retain all copyrights. People are welcome to look through the code for ideas, and can reuse individual subroutines if they find them useful. But I don't want any of these games placed on a ROM cartridge or CD without my permission first.
  12. TROGDOR

    Stellar Fortress v0.20

    By TROGDOR,

    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.
  13. TROGDOR

    Stellar Fortress v0.19

    By TROGDOR,

    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.
  14. TROGDOR

    Hunt the Wumpus v0.18

    By TROGDOR,

    Are you up to the challenge of level 4?
     
    cc2_cd_zip.zip
    Features:
    htw18.asm 09/27/06
    - Added level display and selection on the title screen.
    - Implemented 4 difficulty levels. The level defines the ratio of rooms to tunnels:
    Level 1: 40 rooms, 24 tunnels
    Level 2: 32 rooms, 32 tunnels
    Level 3: 24 rooms, 40 tunnels
    Level 4: 20 rooms, 44 tunnels
     
    To Do:
    - Expand Wumpus clues so they appear in all rooms that are within 1 or 2 rooms of the Wumpus.
    - Add cut scenes for Wumpus death, Pit death, arrow shooting, and victory.
    - Add title screen and music. (started)
    - Add in-game sound effects.
    - Add difficulty levels and level selection.
     
    Known Issues:
    - I've verified a bug when moving at the top of the screen. This is possibly the bug that Supercat was talking about. If you get close to the top of the screen, you will explore the room on the screen above, without moving into it. This can cause unexpected death, if the room above is a pit or Wumpus. The fix isn't simple. I'll probably have to revamp the room transition code to resolve this.
    - Firing the arrow at the Wumpus is still quirky.
    - There is still one scanline of unwanted black lines at the top of the screen that I haven't cleared out yet, but the rest of the lines are gone.
    - Most of the scanline bounce has been cleaned up. There are still a couple frames in the death scene that are not 262 scanlines.
    - There are artifacts in the teeth of the death scene that need to be cleaned up.
     
    Development Notes:
    Level 4 is tough. My best score out of about 20 games was 4780, which amounted to 3 Wumpus kills. All the previous versions were the equivalent of level 2, with about 32 rooms and 32 tunnel tiles.
     
    Over the next few revisions I will be adding more difficulty features. There will be at least 16 difficulty levels in the final game.
  15. TROGDOR
    Features:
    tbom14.asm
    - Added Akagi aircraft carrier. The left difficulty switch determines which ship is displayed. A=Yamato B=Akagi. Press reset to see the selected ship.
    - Fixed bomb loop error. When the bomb is droped, an offset is added to the X position. On the right side of the screen, this can result in a value larger than 160. I was checking for X=160 to wrap. Now I'm checking for X>=160.
    - Multiplexed machinegun fire in with explosion sounds.
    - Added shorter and higher pitched explosion for plane impact.
    - Added moveable object collision detection.
    - Added player plane crash routine when the player collides with the enemy plane or AA fire.
    - Added splash sound when bomb lands in the ocean.
     
    tbom15.asm
    - Added title music.
    - Started using the random number engine. The ship's AA fire now fires from a random location on the ship.
     
    Known Issues:
    - There's an HMOVE bar in the upper left side of the screen. It's coming from the horizontal positioning code. I need to move this up higher in the vblank.
    - The title music mode is preliminary. If you drop a bomb in the middle of the music, it will stop the music. When the game is finished, you won't be able to control the plane during attract mode, which is when the music plays.
     
    Todo:
    Add the aircraft carrier Akagi.
    Add sprite collisions (missle to plane, plane to plane, bomb to plane)
    Add shot down plane effects.
    - Add score display
    - Add replicated sprites for enemy plane squadrons.
     
    Development Notes:
    The title music is an adaptation of the title music from the movie Patton. General Patton was not involved in the battle of Midway. I just like the music.
     
    I spent an unusually long time working on the splash sound. I'm still not happy with it. The Atari white noise generator has a flange that doesn't sound right for a splash sound effect. If anyone as a suggestion for a better sound, I'm all ears.
  16. TROGDOR

    Coastal Chaos V0.05

    By TROGDOR,

    Blog is not dead which can eternal lie. My blog has been dormant for over 6 months, but I'm finally doing more Atari development.
     

    Incoming!
     
    Use the fire button to fire the cannon.
     
    cchaos05.zip
     
    Features:
    cchaos03
    - Added on-screen positioning of both ship sprites.
    - HMOVE every line to prevent comb-effect.
    - Reduced size of island by removing 6th row of castle.
    cchaos04
    - Added demo cannon ball in ball graphics that moves down middle of screen.
    - Implemented pseudo 3D cannonball effect by making the ball larger as it flies higher.
    - Split main kernel into left-side and right side, based on ShipX. Only right side is implemented.
    cchaos05
    - Cleaned up ship display to properly align both sprites. (Or so I thought. See issues below.)
    - Added sound engine, splash sound, and cannon fire sound.
    - Added Joystick button support.
    - Added preliminary AI to move the pirate ship.
     
    To Do:
    - Add cannon rotation angles.
    - Add cannonball trajectory angles.
    - Add whistle when cannonball is falling (similar to bomb sound in The Battle of Midway.)
    - Design a 3D physics engine to properly calculate the x,y, and z coordinates of the cannon ball.
     
    Known Issues:
    - The cannon ball starts well below the cannon. I need to update the coastal rendering kernel to support the cannon ball. Also, 2 scanlines of ocean are used to position the ship. This needs to also support the cannonball. It may require 2 different kernels; one when the ship is on the left side of the screen, and one when the ship is on the right.
     
    - I've run into a major issue with the emulators. The display is different between Z26V2.13 and Stella 2.3.5. The game runs as expected in Stella. In Z26, the second player sprite, used to draw the cannons and sails on the pirate ship, doesn't align correctly with the bottom of the ship. Normally I would try to clean this up before posting, but I figured it would be more useful to the Atari community to demonstrate a clear emulation discrepancy between these two emulator versions. I'd also be interested to know which one is "right", as in which one matches the actual hardware.
     
    Development Notes:
    Another thing I'm wondering about is how to properly read the scanline count in Stella. It starts on scanline "0", and when I press the back-tick to pause the game, it says it's on scanline 261. Does this mean there are 262 scanlines? When I run with -n in Z26 (the only reason I use Z26, other than to cross check against another emu,) Z26 says there are only 261 scanlines.
  17. TROGDOR

    24 Character Display

    By TROGDOR,

    Ack. Has it really been 2 months since I've posted?
     
    I got a chance to do some coding the last couple days, and I've come up with something that I've always wanted to implement: a 24 character display for the Atari 2600. Behold, the wannabe Atari 2600 home computer!
     

     
    tesoro_bas.zip
    Features:
    - Displays 24 characters per line, and a max of around 18 lines per screen.
    - Character set can contain 52 unique characters. More, if byte sharing is used.
    - Only uses 26 bytes of RAM.
    - Only uses 512 bytes of ROM for the character set.
    - Works on a standard Atari, with a standard 4k cart.
     
    Development Notes:
    The idea for this display came from the classic 12 character text display. My display breaks each of the 12 sprite copies in to two nibbles, allowing for 24 characters total. The character set uses 5 bytes per character, and there are effectively 2 copies of every character, one defined in the left nibble, and one defined in the right nibble. This requires extra processing time, since the left and right nibbles have to be assembled into a single byte for each scanline. This is achieved with:
     
    LDA (Buffer0),Y
    ORA (Buffer1),Y
    STA GRP0
     
    This requires a whopping 13 cycles, which would make it impossible to squeeze 6 of these into a single 76 cycle scanline. To work around this, I only use this technique for the first 4 sprites. For the last 2, I preload the display data into a separate RAM buffer, so they can be displayed quicker. The total RAM requirements are 16 bytes for 8 2-byte addresses, which point to 8 nibble characters, which are displayed in 4 sprites, and then 10 bytes to hold the raw display data for the remaining 4 nibble characters, which are displayed in the remainting 2 sprites.
     
    The original 12 character display code used a pseudo interlacing technique which is nice on the eyes, but unfortunately requires extra cycles. Instead, I ditched the interlacing model, and just horizontally shift the sprites on alternating frames. So, sprites 0, 2, 4, 6, 8, and 10 are displayed on even frames, and the other 6 are displayed on odd frames. This saves me the trouble of implementing HMOVES. It also saves RAM. The 12 character display code required 24 bytes of RAM, because all 12 characters are displayed each frame.
     
    My only concern about this implementation is whether the flicker will make it too painful to look at. I've tested the binary in Stella 2.2 and Z26, and both displays look great, as long as the emulator is running at 60 Hz. I haven't tested it on real hardware with a TV. Anyone who can test this out, please let me know how it looks.
     
    If you've ever used a Vic-20, you'll recognize the text in the screenshot.
     
    I've only spent about 3 hours total on this code, so there's still plenty of optimization that could be done. One thing that would save ROM space is an end-of-line character. Currently, all 24 characters have to be defined for each line, which wastes a lot of ROM.
     
    If the flicker is acceptable on a real Atari, this code will eventually become Stellar Adventure 2600, an interplanetary space trading game that will use a lot of text, and yes, it will be yet another Atari project for me to work on.
     
    The binary is 8k only because I used my 8k source template when I started this project. It's really using less than 1k ROM.
     
    Using the 6k RAM of the Supercharger, this display code could be enhanced to create something very similar to a Vic-20 programming environment.
  18. TROGDOR

    Hunt the Wumpus v0.15

    By TROGDOR,

    A shot in the dark.
     
     
    Features:
    htw14.asm 08/24/06
    - Added arrow shot cut scene.
     
    htw15.asm 08/28/06
    - Added footsteps
    - Added arrow shot sound FX.
     
    To Do:
    - Expand Wumpus clues so they appear in all rooms that are within 1 or 2 rooms of the Wumpus.
    - Add death music and victory music.
    - Add cut scenes for Wumpus death, Pit death, arrow shooting, and victory.
    - Add title screen and music. (started)
    - Add in-game sound effects.
    - Add difficulty levels and level selection.
    - Add bank switching code to allow 8K ROM.
     
    Known Issues:
    - Firing the arrow at the Wumpus is still quirky.
    - There is still one scanline of unwanted black lines at the top of the screen that I haven't cleared out yet, but the rest of the lines are gone.
    - Most of the scanline bounce has been cleaned up. There are still a couple frames in the death scene that are not 262 scanlines.
    - There are artifacts in the teeth of the death scene that need to be cleaned up.
     
    Development Notes:
    This is growing into an 8K game, so I can add a lot more detail into the cut scenes, music, sound FX, etc. 4K is getting too crowded.
     
    I'm not sure about the footsteps. I'll leave them in there and see if they grow on me. Your player is supposed to be an expert beastie exterminator, and all this thumping around seems out of character for a ranger. I may make the footsteps more subtle.
     
    I want to focus on cleaning up the teeth in the death scene so I can have a nice screenshot for the game. It's time to make a formal AtariAge In Development submission.
  19. TROGDOR

    Hunt the Wumpus v0.13

    By TROGDOR,

    Score!
     

    Features:
    htw12.asm 08/20/06
    - Added score display.
    - Added scoring for cave exploration.
    - Lightened the cavern color based on user feedback.
     
    htw13.asm 08/21/06
    - Added ability to shoot at Wumpus, and victory / death detection.
    - Added previous game score display on title screen.
    - Added buffering to fire button to detect state changes.
     
    To Do:
    - Expand Wumpus clues so they appear in all rooms that are within 1 or 2 rooms of the Wumpus.
    - Add the ability to shoot your arrow at the Wumpus, so you can actually win the game.
    - Add death music and victory music.
    - Add cut scenes for Wumpus death, Pit death, arrow shooting, and victory.
    - Add title screen and music. (started)
    - Add in-game sound effects.
    - Add difficulty levels and level selection.
     
    Known Issues:
    - Firing the arrow at the Wumpus is quirky. See notes below.
    - There is still one scanline of unwanted black lines at the top of the screen that I haven't cleared out yet, but the rest of the lines are gone.
    - Most of the scanline bounce has been cleaned up. There are still a couple frames in the death scene that are not 262 scanlines.
    - There are artifacts in the teeth of the death scene that need to be cleaned up.
     
    Development Notes:
     
    The following sections have been added to the instuctions.
     
    Scoring:
     
    Exploring a tunnel: 5 gold
    Exploring a cavern: 10 gold
    Slaying the Wumpus: 1,000 gold
     
    Winning the Game:
    When you think you know where the Wumpus is, you can shoot your magic arrow at him. Be careful. You only have one magic arrow, and if you miss, the Wumpus will pounce on you.
     
    You can fire the arrow by pressing in a direction with the joystick and then pressing the fire button. (This order is important. If you press the button first, and then push the direction, the shot won't be detected, and you will likely end up running into the room you were targeting. This will be fixed in a later version.)
     
    The arrow will travel one room in the direction pressed. If the Wumpus is not in the target room, you will be killed, and the game is over. If the Wumpus is in that room, you win, and you are awarded 1,000 gold. You will then enter a new, unexplored maze, to hunt another Wumpus.
     
    I had to add the arrow firing cludge because the victory cut scene hasn't been implemented yet. Without the cut scene, holding the button was causing the code to load a new maze and then fire a second arrow shot immediately, which resulted in instant death.
  20. TROGDOR

    Hunt the Wumpus v0.11

    By TROGDOR,

    I see you.
     

    Features:
    htw09.asm 08/08/06
    - Added ominous death sound.
    - Start player in a safe cavern with no clue.
     
    htw10.asm 08/11/06
    - Added title screen mode.
    - Dropping title effect.
    - Glaring, blinking red eyes randomly move around the title screen.
     
    htw11.asm 08/12/06
    - Added preliminary title music. (Funeral March of a Marionette by Charles Francois Gounod)
     
    To Do:
    - Expand Wumpus clues so they appear in all rooms that are within 1 or 2 rooms of the Wumpus.
    - Add the ability to shoot your arrow at the Wumpus, so you can actually win the game.
    - Add death music and victory music.
    - Add cut scenes for Wumpus death, Pit death, arrow shooting, and victory.
    - Add title screen and music. (started)
    - Add check to prevent player from starting in a hazard room.
     
    Known Issues:
    - There is still one scanline of unwanted black lines at the top of the screen that I haven't cleared out yet, but the rest of the lines are gone.
    - Most of the scanline bounce has been cleaned up. There are still a couple frames in the death scene that are not 262 scanlines.
    - There are artifacts in the teeth of the death scene that need to be cleaned up.
     
    Development Notes:
    This release includes the source code, and a new README file that will eventually turn into the instruction manual. Please read the README file to understand how to start or restart a game.
  21. TROGDOR

    Hunt the Wumpus v0.08

    By TROGDOR,

    Death awaits you all, with nasty sharp pointy teeth!
     
     
    Features:
    htw08.asm 08/05/06
    - Added Death by Wumpus cut scene.
    - Added death detection (walking into rooms with pits or the Wumpus.)
     
    To Do:
    - Expand Wumpus clues so they appear in all rooms that are within 1 or 2 rooms of the Wumpus.
    - Add death detection (walking into room with Wumpus or Pit)
    - Add the ability to shoot your arrow at the Wumpus, so you can actually win the game.
    - Add death music and victory music.
    - Add cut scenes for Wumpus death, Pit death, arrow shooting, and victory.
    - Add title screen and music.
    - Add check to prevent player from starting in a hazard room.
     
    Known Issues:
    - There is still one scanline of unwanted black lines at the top of the screen that I haven't cleared out yet, but the rest of the lines are gone.
    - Most of the scanline bounce has been cleaned up. There are still a couple frames in the death scene that are not 262 scanlines.
    - There are artifacts in the teeth of the death scene that need to be cleaned up.
  22. TROGDOR

    Hunt the Wumpus v0.07

    By TROGDOR,

    I smell a Wumpus.
     
     
    Features:
    htw06.asm 07/29/06
    - Switched to 4LK, freeing up even more cycles in the kernel.
    - Optimized ball display decoder.
    - Integrated maze buffer preloader to prevent black line artifacts.
    - Added clue display in GPR0, GPR1, M0, and M1.
     
    htw07.asm 08/03/06
    - Improved player-to-playfield collision handling to act more like "Adventure". Rather than always moving you back to your original position, you can slide along a surface using diagonal movement, which makes traversing the maze much easier.
    - Added Wumpus and Pit placement routines.
    - Added clue placement routine for Wumpus and Pit clues. This routine automatically traverses through tunnels to find all connecting rooms.
     
    To Do:
    - Expand Wumpus clues so they appear in all rooms that are within 1 or 2 rooms of the Wumpus.
    - Add death detection (walking into room with Wumpus or Pit)
    - Add the ability to shoot your arrow at the Wumpus, so you can actually win the game.
    - Add death music and victory music.
    - Add cut scenes for Wumpus death, Pit death, arrow shooting, and victory.
    - Add title screen and music.
    - Add check to prevent player from starting in a hazard room.
    - Add clue display.
     
    Known Issues:
    - There is still one scanline of unwanted black lines at the top of the screen that I haven't cleared out yet, but the rest of the lines are gone.
    - I didn't test the scanline count before uploading this, so it's possible that it doesn't add up to 262. I'll check that tonight.
     
    Development Notes:
    The game is now minimally playable. On reset, a fresh maze is generated, populated with 1 Wumpus and 2 pits, and clues are assigned for the 3 hazards. You won't die if you walk into a room with a Wumpus or a pit (yet). They'll just show up as clue markers. But this is enough for you to get a feel for what the game play is like. Try to figure out which rooms contain the Wumpus and the 2 pits, without going into those rooms.
     
    For those of you who are not familiar with the original game, the green dots represent pools of slime, and are clues that one of the connecting rooms is a slime pit. The red dots represent pools of blood, and are clues that one of the connecting rooms contains the Wumpus' lair. The object of the game is to use the process of elimination and logical thinking to deduce which room contains the Wumpus, without going into said room.
     
    I'm surprised at how little code was necessary to make this game. It only used about 1.5 K, and could be optimized smaller. With some work, a 1K version of this game might be possible. But I'm more interested in producing a 4K or 8K version that will have nice cut scenes.
     
    I don't want to even think about what a Wumpus would smell like.
  23. TROGDOR
    Features:
    htw02.asm 07/22/06
    - Added random number generator.
    - Mazes are randomly created. Hold down the reset switch to generate a new maze.
    - Unexplored caverns are concealed.
     
    htw03.asm 07/23/06
    - Added screen wrapping so all 64 cells are displayed across 4 screens.
     
    htw04.asm 07/24/06
    - Switched to 2LK, freeing up many cycles in the kernel.
    - Added delay to joystick read to slow down player.
     
    htw05.asm 07/27/06
    - Added compensation for playfield mirroring so displayed tunnel graphics always match what's in the maze data (left turning tunnels vs. right).
    - Added partial display of tunnel graphics, so the upper and lower portions of a tunnel tile have to be discovered independently.
     
    To Do:
    - Add clue display.
    - Hide tiles that haven't been explored yet.
     
    Known Issues:
    - There are black lines on the screen at the top of unexplored tiles. This is coming from the kernel preloader for each row of tiles. I should be able to integrate the preloader into the guts of the kernel so it can be removed, and with it, the lines.
     
    Development Notes:
    My source code has become a convoluted maze of calculations. But it works.
     
    When I switched to a 2LK, I had to go from 5 scanlines per cell block to 4 scanlines per cell block. So the maze portion of the screen is noticeably smaller. This will leave me plenty of room for information displays, and I'll figure out a way to expand the maze if necessary.
  24. TROGDOR
    This is the first Atari game I ever worked on. The project was started back in October of 2003. This was far too ambitious for a first project, but now that I've gotten more kernel coding experience, I revisited the idea, rewriting the entire program from scratch.
     
    Hunt the Wumpus is one of those games that absolutely belongs in the Atari 2600 catalog of games, and I'm amazed that it's never been implemented. The tough part is displaying the clues, which in this implementation will require 4 icons appearing on the same line. My plan is to use the 2 player graphics and 2 missles to display the 4 icons without having to fiddle with placement inside the kernel. There are dozens of ways to implement this game. The screenshot shows the implementation I've chosen.
     
    The game will have 64 tiles in an 8 x 8 array. This will be displayed on 4 screens, 4 x 4 per screen. A more advanced version may have vertical scrolling, which would only require 2 screens. A highly advanced version could have horizontal scrolling, but I'm fairly sure that would be impossible without using Supercharger RAM. A Supercharger version with larger rooms would look sweet, similar to Advanced Dungeons and Dragons for the Intellivision.
     
    My requirements for the current game are stringent. I don't want to have any flicker or skipped lines in the playfield graphics unless absolutely necessary.
     
    Anyhow, this is just another background project. My main focus is still on Stellar Fortress and The Battle of Midway.
     
    Features:
    htw01.asm 07/22/06
    - Displays asymetric maze in playfield graphics.
    - Displays player in ball graphics.
    - Added joystick control.
    - Added collision detection with playfield.
     
    To Do:
    - Add clue display.
    - Hide tiles that haven't been explored yet.
     
    Known Issues:
    - None
  25. TROGDOR

    Labyrinth v0.08

    By TROGDOR,

    kart_fighter.zip
    Kenjutsu has mutated into the game Labyrinth.
     
    Labyrinth is a fantasy adventure where you become a valiant knight on a quest to rescue the fair princess from the clutches of an evil dragon. You control the actions of a daring adventurer finding his way through the castle of a dark wizard who has enchanted it with treacherous monsters and obstacles. In the mysterious caverns below the castle, your odyssey continues against the awesome forces that oppose your efforts to reach the dragon's lair. Lead on, adventurer. Your quest awaits!
     
    Yes, some concepts from Dragon's Lair will be integrated into this game. I liked the premise of Dragon's Lair, even if the gameplay was dry. The idea was you are presented with a series of rooms, and each room contains a challenge that must be overcome before you can move on. I've already come up with ways to implement the gas trap room, the whirling hall of knives, and the black knight encounter. But there will be a lot more to this game. Here is a planned list of features:
     
    - Randomly generated mazes of rooms.
    - There will be a challenge in each room. Complete the challenge to get a key and gain access to other rooms.
    - Find your way to the stairs to decend to the next level.
    - A variety of traps and puzzles. Pressure plates and trip wires that fire darts from the wall. These traps can be detected by observant players. And the 3 trap rooms from Dragon's Lair mentioned above. Also a multi-button puzzle at the end of each maze.
    - A wide variety of monsters. Goblins, Skeletons, DeathKnights, Berzerkers, Doppelgangers, Zombies, Wights, Blobs, and Bats, to name a few. Each creature will have its own fighting style.
    - Treasure chests, gold, and health packs to restore health.
    - Probably a hitpoint system for you and the monsters.
    - Progressive difficulty. As you go deeper into the maze, the speed and reaction times of your opponents will be faster. You will also encounter larger quantities of enemies.
    - The game will have an end goal, so you can "win" the game.
     
    This game is in no way associated with the 1986 Jim Henson / David Bowie movie of the same name.
     
    As for the storyline of the game, I may move away from the "kill the dragon and save the princess" plot, but so far that's undecided.
     
    Features:
    l05.asm 07/12/06
    - Reworked kernel to use 2LK and half vertical resolution. This will free up many cycles for other effects.
    - Added animated warrior.
     
    l06.asm 07/12/06
    - Added enemy goblin player.
    - Updated kernel to display both players and swords on same scanline.
    - Added preliminary dungeon wall.
    - Added goblin AI.
     
    l07.asm 07/13/06
    - There are now 4 enemies. Select an enemy by holding down the select switch. The enemies are:
    - A green Goblin.
    - A grey DeathKnight.
    - An orange Berzerker.
    - A blue Doppelganger.
    - Each enemy has a different fighting style.
     
    l08.asm 07/14/06
    - Added sword-to-player collision detection.
    - Added sound queue and rudimentary sounds for victory and defeat in a sword battle.
     
    To Do:
    - Make the sword rotation of the DeathKnight more fluid.
    - Add a vulnerability to the Doppelganger so he can actually be killed.
    - Implement the background graphics for the labyrinth.
     
    Known Issues:
    - None.
     
    Development Notes:
    There was no escaping the HMOVE bars. I need HMOVE motion in both directions for the sword effects, so I'll just have to live with it. I tried a brown background, but that provides much less contrast to the players, so they're harder to see. The black background seems to fit nicely with the Labyrinth theme, so I'll probably stick with it, and it allows me to ignore the HMOVE bars entirely.
     
    If anyone has ever played Swords and Serpents for the Intellivision, you'll notice some similarites. However, my game will have a lot more variety of fighting styles.
     
    I'm pretty sure it's impossible to kill the Doppelganger. Let me know if you figure out a way to kill him. I'll be adding a weakness to his attack method in a later revision.
     
    As is the case in real life, if you tie in a sword battle (you and your opponent simultaneously skewer each other), you still lose.
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2023 AtariAge

×
×
  • Create New...