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

cd-w

Members
 View Profile  See their activity

  • Content Count

    2,433

  • Joined

  • Last visited

  • Days Won

    2

Blog Entries posted by cd-w

  1. cd-w

    Chetiry

    By cd-w,

    As many of you will now know, I have been working on a new Atari 2600 homebrew title called Chetiry. This blog entry should hopefully clear us some of the confusion surrounding the project!
     
    Chetiry is a tetromino matching game that should be familiar to most gamers. The original Chetiry project (Chetiry means 4 in Russian) was started by Zach way back in 2006. However, Zach retired from Atari 2600 homebrewing in 2009 with the Chetiry project still unfinished. I had been hoping to see Chetiry completed, and so I contacted Zach to ask if he would allow me to continue his work. Fortunately he agreed, and so I have been working on the project in my spare time over the last year, mostly on airplanes while travelling for my work!
     
    There have been several other tetromino matching games for the Atari 2600. However, I wanted Chetiry to be as close to the original Gameboy version as possible, as this is my favourite version. The new Melody hardware also inspired me to include digitized music throughout the game, based on the Pitfall-2 technique.
     
    I originally thought the project could be quickly completed, as Zach had already done a lot of the coding. However, I ended up rewriting the game code several times over to support the digitized music! The only original code remaining now is the neat 10 color kernel that Zach designed. The core game code is a little under 8KB, but with all of the music and artwork, the game now occupies around 48KB of cartridge space!
     

     
    The awesome artwork for Chetiry was designed by the prolific Nathan Strum. At one point in the project, he suggested doing a Gameboy-themed version of the game! This seemed like a good idea for a demo version, as the full game cannot be played in Stella. The Gameboy-style artwork was completed shortly before the beginning of April, and so one thing lead to another
     
    The Gameboy-themed version of Chetiry will not be developed further, and so I have attached the source code and binaries to the end of this entry. The full version of Chetiry will have (at least) the following enhancements:
     

    Full color game grid
    Hiscore tables saved directly on the cart
    4 game modes (Marathon, Sprint25, Sprint40 and Ultra)
    6 digitized tunes
    Easter eggs!

    Nathan has kindly produced a video of the current (full) version of Chetiry:
    http://www.youtube.com/watch?v=ACsEhqHKbzA
     
    Chetiry should be released on a cart sometime later this year. There is still a bit of programming required, and the cart label and manual have yet to be designed. As always, it will be released when it is ready
     
    Chris
  2. cd-w

    Perfect Harmony

    By cd-w,

    A couple of entries back I was pondering which project to do next after Juno First. Since then, I have been working on the semi-secret Harmony/Melody cart project. This project is now close to completion, and so I think it is safe to write some details about it here. To keep things simple, I'll only talk about the Harmony cart. The Melody cart is the same, but without the SD card and USB options.
     
    The Harmony cart project was started by batari around a year ago. As I understand it, there were several main motivators:

    To make it easier and cheaper for Al to assemble homebrew games. The Harmony cart provides a single PCB that can be pre-assembled into a cart and then flash-programmed for a specific game. This does away with the need for different PCBs, depending on the bank-switching type, and the need for programming and soldering EEPROMs.
    To provide a cart capable of running Batari Basic games that use the SARA superchip. The SARA superchip provides 128K extra RAM for games, but these chips are difficult to obtain and require a special PCB. The Harmony cart emulates the SARA superchip in software, which allows homebrew SARA games to be mass-produced for the first time.
    To develop a novel hardware platform for the 2008 holiday cart. The holiday cart didn't get done in the end, but the hardware is now available for future years.
    To produce a cut-down version of the Chimera cart. The Chimera has some common elements with the Harmony cart, but was much more ambitious. Unfortunately the Chimera project has stalled, but the Harmony will provide some of the same features.

     
    The hardware of the harmony cart is very straightforward. It is basically just an ARM7 micro-controller (an LPC2103) connected directory to the cartridge port of the Atari. Batari discovered that this chip was fast enough to service requests from the Atari and emulate all of the different bank-switching types entirely in software. The ARM micro-controller contains 32K flash memory, which can be used to store the game binary permanently, and also 8KB RAM, which can be used to do the bank-switching and store any game data. The LPC2103 costs only a few dollars, and so Harmony carts can be produced more cheaply than carts which require CPLDs.
     
    The software on the harmony cart is also very straightforward. It doesn't attempt to synchronize clocks with the Atari. Instead, it just sits in an permanent loop, servicing requests from the Atari as follows:

    1) Wait for an address request from the Atari (A12 high). 2) Read address bus (A0-A11). 3) Fetch data from flash memory at the requested address (may perform bankswitching here). 4) Assert data on the data bus (D0-D7). 5) Wait until there is a change of address (A0-A12). 6) Repeat forever.
    This approach is necessary as the cartridge port doesn't output the 6502 clocks (phi1 and phi2) and also doesn't have a R/W line to distinguish between reads and writes. The wait for A12 at the beginning has the effect of keeping the ARM and Atari loosely synchronized.
     
    The ARM processor runs at 70MHz and the Atari runs at 1.2MHz, which sounds like the ARM would have plenty of overhead. Unfortunately this is not the case. The flash memory of the ARM takes 4 cycles to access, and the ARM can only perform I/O at a fraction of the full clock speed. Also, the data must be placed on the Atari data bus within a short time of A12 being asserted. It works out that the ARM is only just capable of keeping up with the Atari. If the Atari were any faster, then this approach would not work. Fortunately it does work, and batari has managed to implement all of the main bank-switching schemes on the Harmony.
     
    I got interested in the Harmony project around the time batari had the basic hardware implemented and working. My interest was sparked by the SPI bus on the LPC2103 chip. This bus enables a range of peripherals to be connected to the chip, including an SD card slot. I decided to attempt to write an SD card driver for the Harmony. This is non-trivial as the driver has to fit into the 8KB of memory (since the 32K of flash is used to hold the actual game). The driver needs to be able to read data from the SD card (across the SPI bus), parse the FAT file system, display a menu on the Atari, load the game from the SD card into flash, and auto-detect the bankswitching type.
     
    I'll save the actual implementation details of the driver for another entry. For now, here are some photos, which show the progress on the project.
     

    My first Harmony cart (which I built from batari's schematics). It is basically an Olimex LPC2103 prototyping board wired up the the Atari. Most of the early SD driver development was done on this board:

    My first Harmony PCB. This is an early revision of the Harmony PCB, assembled by batari. I wired it up to an SD card socket and an LED for debugging:
    The near-final Harmony cart. This is the final (hopefully) prototype of the Harmony cart, assembled by batari:

    A screenshot of the Harmony SD card menu on an old CRT TV that I use for Atari development. This version of the menu was written by Thomas Jentzsch.


  3. cd-w

    AtariVox

    By cd-w,

    When I first heard about the AtariVox I wasn't too impressed with the sound quality, and decided not to bother getting one. However, I changed my mind after seeing a demo of Man Goes Down at the vgXpo a few years ago. I realised that the sound quality was a perfect match for the Atari, being broadly equivalent to the quality of speech chips back in the day. I now think it would sound "wrong" if the Atari were to produce high-quality speech, just as it would sound unnatural if Stephen Hawking were to upgrade his speech unit.
     
    I bought an AtariVox when they became available again (in the new casing), but didn't actually use it until today. The main reason being that my Atari gear has been in storage since I last moved, and I'm about to move again. I was able to use the AtariVox now due to the acquisition of the handy AtariVox USB adapter, pictured below:
     

     
    The USB adapter enables the AtariVox to be used from a normal PC, without the need for an Atari console. This might seem rather pointless, but the main reason for using this adaptor is that it makes AtariVox development much easier. Since the AtariVox is not (yet) supported by any of the emulators, it was previously necessary to write a test program and then upload it to the Atari, e.g. using the Krokodile cart. With the USB adapter, the AtariVox can be programmed directly from the PC. Incidentally, I was grateful for Nathan's review of the AtariVox, since my unit was indeed set to maximum volume. Using the USB adapter is simple - just plug it into the PC, and Windows recognises it as a serial USB device (Mac and Linux users will not be so lucky). The AtariVox can then be programmed using the hacked PhraseALator software or VoxPlay.
     
    It turns out that the AtariVox is not particularly easy to program. It is capable of making a wide range of sounds, but assembling these sounds into recognisable speech can take a lot of trial and error. Fortunately the PhraseALator software has a reasonably large dictionary that can be used in many cases. I also found that I got rapidly better at figuring out the necessary sounds after a bit of practise. Here is a reasonable approximation to "Juno First":
     

    \JH \UW \NO \OWWW \P1 \FF \AXRR \SE \TT
     
    I now think that the AtariVox is quite a cool bit of hardware, and the USB interface makes it much easier to develop for. I'm planning to use it in my future software projects, though I'm not sure I will be able to use it in Juno First, since it requires rather a lot of cycles - perhaps just a few bits of speech during the title screen. Now, if only it was as easy to develop for the Savekey ...
     
    Chris
  4. cd-w

    Taking a break

    By cd-w,

    I'm going to be taking a break from Atari 2600 homebrewing for a while due to real-life considerations. I will still be lurking around the forums, but I won't have any time for coding for some time. Fortunately the various projects that I have been involved in are in good hands:
    Chetiry will be released at the PRGE later this month and will be available in the AA store shortly after.
    Star Castle is being partially rewritten by Thomas Jentzsch - he has made excellent progress and should have something to show soon.
    LS_Dracon has made some awesome progress on the PoP sprites recently.
    Batari will be proceeding with Harmony 2, but neither of us have had any time for it recently.
    My contributions to project "Bruce" are on hold for now, but it was always going to be a multi-year project.

    I'll hopefully be back to coding in a year or so, but I don't want to make any promises at this point.
     
    Chris
  5. cd-w

    Star Castle Playable

    By cd-w,

    Here is another Star Castle update. The game is now playable, although more tuning is required and there are some rough edges.
     

     
    There are too many changes to list, but some of the highlights:
    32 waves of increasing difficulty
    More awesome graphics by Nathan - especially the title screen and ring explosion!
    Mines can now detach and reattach to the rings as in the arcade
    NTSC, PAL60 and B&W colours (press SELECT on the title screen)

    As before, you need Stella 3.5.5 or above to play. I haven't yet produced a version that is playable on the Harmony cart.
     
    The biggest issue remaining is the sound effects. I'm not very good at manipulating TIA audio, so if anyone can produce a closer match to the arcade effects then I'll be very grateful for the help!
     
    I've included the source code this time, although it is still a mess!
     
    Let me know if you have any comments, suggestions, bug reports, etc.
     
    Chris
     
    starkernel9.bin
    starkernel9src.zip
     
    EDIT: Fred (batari) has now created a version that should work on the Harmony cart: http://www.atariage.com/forums/topic/156500-latest-harmony-cart-software/page__view__findpost__p__2486706
  6. cd-w
    There has been a lot of buzz recently about Scotts Star Castle kickstarter (just a few days remaining to grab a copy). It has prompted some people to speculate about this effort, so I thought I would post an update of where things are.
     
    This project is still very much alive, and the plan is to eventually release it through the AtariAge store. The main development is that Thomas Jentzsch (Thrust+, Boulderdash) is now involved, and the coding will now be a joint effort between him and myself. As I stated elsewhere, this is very much a team effort, and the following people have all been involved in the process so far:
    Nathan Strum produced the awesome sprites and artwork and spent a lot of time play testing the code.
    David Dries (and Nathan) are working on the label and manual for the game.
    Ivan Machado produced the awesome arcade style sound effects.
    Richard 'Kulor' Armijo produced the cool title tune.
    Fred Quimby helped with the ARM code to make the game work on the Harmony cart.
    Stephen Anthony extended Stella to support the Star Castle bank switching scheme.

    The RC1 version that I posted had more-or-less reached the limits of the Atari 2600 frame timings. This meant that certain compromises had to be made, such as a reduced screen height. Thomas is now rewriting the core game logic to use time-slicing, instead of trying to do everything on every frame. Time-slicing was previously used to good effect in Boulderdash. The basic idea is that you have a queue of tasks that need to be done, and on each frame you do as many tasks as can be accomplished within the available time. When the game is very busy, some tasks may be deferred until the following frames, but this is unlikely to be noticeable (at 60 frames per second). Essentially it will free up more time to more time to allow us to improve the game, and make it even closer to the arcade version.
     
    Moving to time-slicing requires a major rewrite of the game logic, and so it is likely to be some time until the RC2 version is released. I have also started a new job recently, and so my spare time is very constrained at the moment. However, Thomas is making excellent progress and has come up with an improved version of time-slicing from the one in Boulderdash.
     
    I don't know exactly when the game will be released in the AA store, but it should hopefully be later this year or early next year.
     
    As always, let me know if you have any comments or suggestions for improvements.
     
    Chris
     
    tl;dr - project still alive and undergoing major changes
  7. cd-w

    Star Castle RC1

    By cd-w,

    Star Castle is basically feature complete now, so here is the first release candidate for testing.
     

     
    Please note that you must upgrade to the latest Stella 3.6.1
     
    The main changes this time are:
    New sound effects by LS_Dracon
    Title screen music by Kulor
    High score table (will only work on Harmony cart)
    Improved collision detection
    Different ring colours on each wave

    During the game, the following can be changed:
    Pressing SELECT will skip to the next wave (this is for testing and will be removed in the final version).
    Setting the LEFT DIFFICULTY to A will cause the ring segments to be destroyed with 1 hit (instead of 2).
    Setting the RIGHT DIFFICULTY to A will cause the ship to be destroyed by the rings (instead of bouncing off).

    I'm still trying to figure out the Harmony CU bankswitching format - I'll post up a Harmony version once this is done.
     
    Please let me know if anything is broken, buggy, or just plain annoying!
     
    Thanks,
    Chris
     
    starRC1.bin
    starRC1_src.zip
     
    EDIT: Harmony version now available. Make sure that you have BIOS 1.05 on your Harmony cart, then unzip and drop the starRC1.cu file onto your SD card. Note that the high score table is not stored to flash in this version, so it will be deleted when you switch off your Atari.
     
    starRC1_harmony.zip
     
    EDIT2: Alternative ring colours version: star_altcols.zip
  8. cd-w

    Star Castle Update

    By cd-w,

    Here is a quick update on my Atari 2600 Star Castle port:
    Awesome new sprites supplied by Nathan
    Basic sound effects - will improve in future versions
    Stars in the background
    2 bullets on-screen
    Ring segments turn to dots after 1 hit (disable using Left difficulty switch)
    Bullets wrap around the screen edges

    This version uses a new bankswitching type, so you will need to upgrade to Stella 3.5.5 to make it work. It doesn't work on the Harmony cart yet - but it will soon.
     

     
    I haven't included the source this time as it is a mess, but I will post the source to future releases.
     
    Chris
     
    starkernel8.bin
  9. cd-w

    Star Castle Brainstorming

    By cd-w,

    Here is another minor update to Star Castle:
    The rings can now move at variable speeds - I have slowed them down a bit in this version.
    The ring segment now disappear immediately when they are hit.
    The rings will regenerate when the outer ring is removed.
    The gun will fire projectiles at you when the inner ring is breached.


     
    The big question now is how closely the 2600 version should match the arcade version. There are two sticking points, where I think it might be better to deviate slightly:
    In the arcade version, the ring segments take 2 hits to be destroyed. After the first hit, the ring segment increases in brightness to indicate that it has been hit. Unfortunately this effect isn't possible on the 2600. As a result, I am thinking that it might be better to remove the ring segments after a single hit. Otherwise the player is going to have difficult remembering which segments have already been hit, and it may make the collision detection appear flawed if nothing (visible) happens when a ring is hit. This will naturally simplify the gameplay a bit, but I think this may be offset by the second change.
    In the arcade version there can be 3 bullets on-screen at the same time (fired from the ship). However, in the 2600 version there can currently only be one. Increasing this number means that far more collision detection operations will be required. This can be handled by making the collision detection less precise (e.g. by checking the bullets on alternate frames). However, I'd prefer to keep the collision detection as accurate as possible as poor collision detection can really ruin a game. Having only 1 bullet on screen makes the game slightly more difficult, since the player will need to conserve bullets to deal with approaching mines.

    I think this increase in difficulty in 2) may offset the decrease in difficulty in 1). However, these changes do take the game away from being arcade perfect. Some compromises are going to be necessary, as they were when I programmed Juno First, but I want to keep the underlying gameplay intact. Let me know if you think these changes are too much, or if you think they are acceptable?
     
    Thanks,
    Chris
     
    starkernel7.bin
    starkernel7.zip
     
    EDIT: Here is a version where each ring segment takes 2 hits to destroy:
    starkernel7_twohits.bin
     
    EDIT2: Here is a version that changes the segments to dots after the first hit:
    starkernel7_dotted.bin
  10. cd-w
    After much head-scratching and code optimisation, I finally have collision detection working! In this version you can shoot the ring segments. For now they only take one hit, but this can easily be changed.
     

     
    I think I now have all of the pieces necessary to make the game. However, I now need to put it all together and rewrite significant parts of it, such as the kernel. The main issue now is running out of ROM space as all the unrolled code has nearly used up the full 12KB.
     
    Let me know if you have any suggestions, or if you find any collision detection bugs.
     
    Chris
     
    P.S. Remember to hit Alt-P in Stella to avoid the flicker.
     
    starkernel6.bin
    starkernel6.zip
  11. cd-w

    Star Castle Mines

    By cd-w,

    Here is another small update to my Star Castle demo on the 2600:
    The mines now follow you around the screen. They will reset to the centre if they go off screen.
    You can shoot the mines, and collisions between the ship and mines are detected (the screen will flash).
    Ship rotation is now much slower.

    There are still a few issues with the ship and mines at the edges of the screen, but I'll fix these later. The mines are flickered at 20Hz so that 3 can be displayed. The flicker would be less annoying if the size was reduced (to the same size as the bullets), but then they would be nearly impossible to shoot. Let me know if you think the mines are too large and/or annoying?
     

     
    I have done a lot of code optimising in this revision. Hopefully I now have enough spare cycles to do the collision detection between the bullet and rings as this is the main missing piece. I have cut the game down to 1 bullet on screen. This may increase later, but for now it makes the collision detection more manageable.
     
    The (very messy) source code and binary are included below. Let me know if you have any suggestions?
     
    Chris
     
    starkernel5.bin
    starkernel5.zip
  12. cd-w

    Star Castle Improvements

    By cd-w,

    I have made a little more progress on my 2600 Star Castle demo:
    Ship rotation is slower.
    Ring colours now match the arcade version.
    Player bounces off the rings.
    Centre gun tracks the player position.

    The main issue now is collision detection between the bullets and the rings. I haven't yet worked out an efficient way to detect when a ring sector is hit by a bullet, and the code is starting to get tight for cycles.
     

     
    Let me know what you think?
     
    Chris
     
    starkernel4.bin
    starkernel4.zip
  13. cd-w

    Star Castle Ship Movement

    By cd-w,

    I have made a little more progress on my Star Castle demo. You can now move the ship around the screen and fire bullets, although there is no collision detection yet. The controls are:
    Joystick Left/Right - Rotate
    Joystick Up - Thrust
    Fire - Fire Bullets

    I have been trying to match the ship movement with the arcade version (by comparing with the MAME version). I think it is now reasonably close, but let me know if you think it needs improvement?
     

     
    The ship sprite is temporary (apologies to Thomas for copying the Thrust+ sprite) and will be replaced in the near future. There are also a few wrinkles, such as firing not working at the edges of the screen, and the bullets being fired from the centre of the ship. These issues should be easy to fix.
     
    The next step is to get the mines following the ship (the green blob at the bottom is what the mines will look like). Then the collision detection, which I'm not looking forward to!
     
    The source code is included below, but it is a big unoptimised mess at the moment. As always, let me know what you think. Unfortunately further progress will be slow now that the holidays have come to an end.
     
    Chris
     
    starkernel3.bin
    starkernel3.zip
  14. cd-w

    Star Castle Colour Kernel

    By cd-w,

    I figured out how to make my Star Castle kernel display in colour. I think this looks much better than the monochrome version posted in my previous blog entry.
     

     
    The technique was inspired by supercats kernel, but as before I am only using a single sprite to draw the rings. This leaves the other sprite and missile/ball free.
     
    The kernel uses a number of advanced tricks, such as updating the colour registers while the sprite is being drawn. Hopefully it will work on a real 2600 as I haven't tested it outside Stella yet. In Stella, it looks best if you enable the phosphor (Alt-P) mode.
     
    I've included the source code for the curious. Let me know what you think?
     
    Chris
     
    starkernel2.bin
    starkernel2.zip
  15. cd-w

    Star Castle Kernel

    By cd-w,

    The recent threads on Star Castle for the Atari 2600 have been rather annoying, so I decided to see how difficult it would be to write my own version.
     
    It turns out not to be too difficult - I was able to write a basic kernel with rotating shields in a single weekend. I just went for a simple implementation using extra RAM (FA bank-switching) instead of pre-calculating all the ring data. The advantage of this approach is that the rings can be made to spin at different speeds.
     

     
    It isn't quite as advanced as the kernel that Supercat posted, but it avoids some flicker by using only a single sprite to draw the rings. I also used the size calculations that Thomas posted previously. Note that it looks best on a real TV, or using the phosphor (ALT-p) mode in Stella.
     
    I'm not sure if I'll take this further or not. I have posted the binary and source in case anyone else is interested.
     
    Let me know what you think?
     
    Chris
     
    starkernel.bin
    starkernel.zip
  16. cd-w

    New PoP Kernel

    By cd-w,

    I have started to look at the Atari 2600 PoP project again now that the Harmony software is essentially done. I am making no promises on getting it finished, but I intend to do a bit more work on it to see where it goes. At the very least, I want to include the excellent sprites that LS_Dracon has produced. The first thing that I have done is to completely rewrite the kernel:
     

     
    From the screen-shot, it looks almost identical to the old kernel, but there are two important differences.

    The old kernel had only a single ball sprite for the sword, which I intended to flicker between the player and guard. The new kernel displays separate missile sprites for the player and guard, and so it can display the swords flicker-free.
    The old kernel had blank lines for repositioning above and below the floors. The new kernel displays the playfield without any gaps at all.

    This new PoP kernel is probably the most complex Atari 2600 kernel that I have written so far. It doesn't use any self-modifying code or extra RAM, yet it displays an asymmetric playfield with two player and two missile sprites in full colour (glitch-free). It also uses my favourite mid-kernel repositioning trick to display the playfield without any gaps. Note that both the player1 and missile1 sprite are repositioned mid-kernel. The only restriction is that the player missile sprite can't be drawn on the same lines as the floor, but we probably don't need the missile on these lines anyway.
     
    I have attached the binary and source for the new kernel. You can move the player (no animation) with Joystick 0, the guard with Joystick 1 (keys G & J on Stella), and change the playfield colours with Fire.
     
    The next step is to merge this kernel with the previous PoP code. I will probably also convert the game from Supercharger format to another bankswitching type. The Supercharger 6K format is quite limited, and the Harmony cart can now support many other types.
     
    Chris
     
    kernel.bin
    newpopsrc.zip
  17. cd-w

    Looking Forward

    By cd-w,

    The 2600 scene is still alive and well, and there are quite a few of exciting projects currently in development. I have probably forgotten some, but the ones that I am looking forward to the most are:
     
    Hardware:
     

    AtariVox+ - I think this has been delayed by the difficulty in getting hold of SpeakJet chips.
    Project Unity - a nice project to build a portable 2600 with integrated Harmony cart.
    Flashback 3/Portable Flashback - actually I would settle for a PAL version of the FB2!
    Cybertec Pro A/V Mod - any A/V mod for my PAL 2600 and 7800 consoles would be nice!

     
    Software:
     

    KO Cruiser - a very nice arcade port.
    Duck Attack - an extremely quirky and novel game from a new 2600 developer.
    Ballblazer - it is hard to believe that the demo is running on an unmodified 2600 console.
    Panky The Panda - a highly polished platformer.
    Circus Galacticus - a hugely ambitious project, but it looks great.
    Charge - a very promising bBasic game.
    Steam Tunnel Bob - still hoping this will be finished, although Propane13 seems to have moved over to 7800 development.
    Boulderdash - really hoping that this will be finished some day, particularly as it is very close to completion and runs on Melody hardware.
    Prince of Persia - this one is up to me, if only I could find more free time!

     
    Chris
  18. cd-w

    My Personal Top 10

    By cd-w,

    Like most people on AtariAge, I have been playing computer games for a long time, since the late 1970s. However, I have always been more interested in how games work, rather than the games themselves. I tend to play each game for a short time, until I have figured out the mechanics and mastered the controls. Once I know that I can beat the game, I tend to lose interest and move on. Every now and again though, a game comes along that I really enjoy playing. These games hold my interest long after I have mastered them, and I tend to return to them again and again. I have created a list of these games below, together with a brief explanation of why I find them so fascinating. So, in no particular order, here is my top 10:
     
    1 - Dungeon Master (Atari ST)
     

     
    I tried hard to get into role-playing for a while. I played D&D, AD&D, Warhammer, Cthulhu, etc. However, every game inevitably descended into arguments over distance measuring, rule interpretations, and personal skills (i.e. typical nerd arguments). Dungeon Master was the first game that captured the pure dungeon-crawling experience for me, without all of the petty squabbles. I was instantly hooked, and I packed away my dice forever.
     
    2 - Super Mario Bros (NES)
     

     
    I wanted to hate Super Mario Bros. At the height of its popularity, I was playing games on the Atari ST and Amiga. The NES seemed primitive by comparison, and the cutesy Mario graphics seemed to be designed for kids. Eventually though, I reluctantly played the game and was quickly hooked. It is difficult to say why the Mario games are so appealing. I think it is because they give you so much freedom, both in terms of the movement of the player, and the ability to explore the environment. The controls are simple, the movements are fluid, and the collision detection is perfect. When you die, you know that it is entirely your own fault, and this keeps me going back for more.
     
    3 - Frogger (Atari 2600)
     

     
    This isn't my favourite Atari 2600 game (it is probably Stargate), but it has a place here as it was one of the very first video games that I ever played. At the time. a friend had an older brother, who owned an Atari 2600. He reluctantly let us play a game of Frogger, in order to demonstrate his own game-playing superiority. We were never allowed another game after we both crushed his best score. At the time it seemed impossibly hard as my twitch reflexes hadn't yet been honed from years of game playing - there was always something about to kill you! I now find the game rather simple, but I still enjoy playing it regularly.
     
    4 - Castle Quest (BBC Micro)
     

     
    I doubt many people here have played this game. It was only released for the BBC Micro, which was the computer used in all British schools in the 1980s. At the time, there were two main BBC Micro software houses (MicroPower and Superior Software) - neither of which still exist. The competition between them was fierce, and some great and original games were produced as a result. Castle Quest is my favourite of these games. It is a platform game, set inside a castle, with complete freedom to explore. The puzzles in the game are very complex, not just key collecting, and it also requires twitch reflexes. I played this game endlessly back in the day, until I had solved all of the puzzles, and I still find it enjoyable to play. Unfortunately the game was clearly rushed for release, and so there is no proper ending, but it is fun just to solve all the puzzles one more time.
     
    [Edit: The screenshot above shows the depth of the puzzles in Catle Quest. At this point in the game you have been imprisoned in a cell. To escape, you need to throw the stool upwards to get the torch. You can then use the stool to jump on to the ledge over the door. You then throw the torch onto the bed to set it on fire. At this point the guard will rush into the room, and you can hop down from the ledge behind him to escape. By moderns standards, this isn't too advanced, but back in the day this level of detail was very rare.]
     
    5 - Doom (PC)
     

     
    Doom wasn't the first fully-immersive 3D game (e.g. there were those dreadfully-slow FreeScape games), but it was the first that really sucked me in. There is no need to say much about this game, as I'm sure everyone has had a similar experience. However, the feeling of anticipation and terror, while playing Doom late at night in a darkened room, is one that few other games will ever capture.
     
    6 - Prince of Persia (PC)
     

     
    Before Prince of Persia, most games seemed to have either great graphics, or great gameplay. Prince of Persia was one of the first to combine great gameplay, awesome graphics, and eye-popping animation. The ability to jump a gap, miss, but still manage to cling on to the edge with your fingertips, was something that had not been done before. These days, the graphics look primitive and the gameplay seems simplistic, but it is still an enjoyable game that I play regularly.
     
    7 - Super Mario 64 (N64)
     

     
    I was very late to the 3D console revolution. For a long time, it seemed (to me) that all 3D games were just FPSs or dubious 3D translations (like 3D Tetris). Super Mario 64 was the first game that convinced me that 3D could be used to produce truly original games. The beauty of Mario 64 is that it captures all of the elements of the previous Mario games, but adapts them perfectly to 3D. The controls are still fluid, there is still freedom to explore, and the puzzles are still devious.
    8 - Tempest 2000 (Atari Jaguar)
     

     
    In case you think this list is entirely platformers and dungeon-crawlers, I do also enjoy a good shooter. In my opinion, the master creator of the shooter genre is the British programmer Jeff Minter. You can argue that he hasn't done anything that wasn't already done by Eugene Jarvis. However, he has consistently managed to capture the pure zen of the shooter, in a way that is totally immersive and engaging. My favourite of his games is Tempest 2000 for the Atari Jaguar, and until recently I owned a Jaguar purely for this title.
     
    9 - Goldeneye (N64)
     

     
    Movie tie-ins are usually rubbish - designed for parents and grandmothers to purchase for their offspring around the holiday season. They frequently bear little resemblance to the movie, and are just any old game with some movie branding added. However, there are exceptions, and Goldeneye is definitely my favourite. It actually manages to capture the essence of the movie on an almost scene-by-scene basis, without feeling forced. It also requires puzzle solving, in addition to the gun-and-run FPS formula. Its sequel (Perfect Dark) is arguably a better game, but Goldeneye remains my favourite.
     
    10 - Ikari Warriors (C64)
     

     
    I really enjoy this game, but I am not sure why. It is devilishly hard, but also rewarding. A long time ago, I spent nearly a whole summer playing the C64 version until I finally completed it. I have never completed it again, but at least I know it can be done! The C64 version remains my favourite, as it is a near perfect arcade port. The 2600 version is unfortunately rather poor, and I haven't played the 7800 version yet.
     
     
    This list is nowhere near complete, but I think it gives a good idea of the kind of games that I enjoy, i.e. mostly games that give you lots of freedom to explore. Also, many of them are favourites because of the situation that I was in when I first played them (e.g. I doubt that I would enjoy Frogger so much if I only discovered it now). There are also many games that nearly made this list, but I wanted to include only those that I have actually played recently. Also, I certainly have not played all of the games on every platform. There are still many games even on the Atari 2600 that I have not played. I'm sure there are many games that I would enjoy, but have never played - feel free to make suggestions!
     
    Chris
  19. cd-w

    Harmony Memory

    By cd-w,

    The pre-release version of the Harmony cart is now finished and is being sold at the Portland RetroGaming Expo. I expect that the bug reports and feature requests will start arriving soon! Before they do, I though I would write a little more about how the Harmony driver software works.
     
    The Harmony driver is written using a mix of C and ARM assembly language. The ARM assembly is used for the performance critical stuff, like feeding the Atari with instructions, while the C code is used for slower stuff, like reading from the SD card. I used the free GNU ARM cross-compiling tools under Linux to write the code. This produces a binary file, which can then be downloaded and run on the Harmony cart. Debugging was done through a serial port using the Olimex development board, rather than the actual Harmony cart.
     
    The main challenge of programming the Harmony driver was fitting everything into memory. The Harmony has three kinds of memory, each of which has advantages and disadvantages:
     

    8KB SRAM memory - this is the fastest kind of memory (1 cycle per access). The contents are lost when the power is switched off, just like normal computer RAM.
    32KB Flash memory - this memory is much slower than SRAM (4 cycles per access). Code can be executed from Flash memory, but it can only be written in 4KB chunks. The contents of the Flash memory are preserved when the cart is powered off.
    512KB EEPROM memory - this is the largest and slowest of the memory types. Code cannot be run direct from the EEPROM, and the memory can only be loaded and stored in blocks of 512 bytes. The contents of the EEPROM are preserved until erased.

    The SRAM and Flash memory is actually part of the LPC2103 ARM microprocessor, while the EEPROM is a separate device, wired up to the ARM chip via the SPI bus. The SD card is also connected over the SPI bus, and a pair of chip select wires are used to select between the SD card and EEPROM. For safety, the EEPROM is kept write-protected during driver execution to prevent accidental overwriting.
     
    The complete driver code is stored in the EEPROM memory and is approximately 100KB in size. The driver code is executed using from the SRAM memory, and the game is loaded from the SD card into the Flash memory region. The SRAM is only 8KB and so this requires a rather difficult juggling act to fit everything in. The driver is split into lots of separate parts (between 4KB and 6KB each), and each part is loaded separately into SRAM as required.
     
    When the Harmony cart is powered on, it starts executing code at the beginning of the Flash memory. A small 1KB bootloader script is always kept in the Flash memory to set things up. The following steps are then required to load and execute a game off the SD card:
     

    The bootloader initialises the Harmony cart and stalls the Atari console.
    The first 6KB of the driver code is copied from the EEPROM into SRAM.
    The driver code begins executing and copies the Atari menu system (4KB) from the EEPROM into Flash memory.
    The SD card is initialised and scanned for files.
    The first 10 directory entries are copied from the SD card into SRAM.
    The Atari is resumed and fed the menu system from the Harmony flash memory.
    The user selects the game to be loaded from the menu (this may involve returning to the driver to load more directory entries).
    The Atari is stalled again and the driver loads the game from the SD card into flash (overwriting the menu system).
    The bankswitching detection code is loaded from the EEPROM into SRAM (overwriting the driver).
    The game type is automatically detected.
    The bankswitching code that corresponds to the game type is loaded from the EEPROM into SRAM (overwriting the detection code).
    The Atari is resumed and the game begins ...

    If the game is 32KB in size, then there is not enough space in the Flash memory, as the 1KB bootloader must always be stored in Flash. For 32KB games, the last 1KB of the game is loaded in SRAM, overwriting part of the driver.
     
    I will post more details about the driver in another entry. I'm not sure if the driver code is going to be made public yet. It works nicely at the moment, but there is definitely scope for improvement. The menu system has recently been updated by Thomas and now looks even better.
     

     
    I'm hoping that the Harmony cart will be a big success. A lot of people have put a lot of effort into the cart (see the credits above), and it has taken around a year of development effort. It should make home-brew game development on the Atari 2600 much easier, and it will make it possible for everyone to keep and play a large library of Atari 2600 games.
     
    Chris
  20. cd-w

    Pssst! Kernel

    By cd-w,

    It's been a while since I posted anything here, so here is a quick entry about a recent Atari 2600 project of mine.
     
    I had an idea for a holiday-cart based around the Ultimate game Pssst! for the ZX Spectrum. For those unfamiliar with the game, here is a flash version of Pssst!, and a YouTube video of Pssst!.
     
    The aim of Pssst! is to protect the flower growing in the centre of the screen from a variety of different bugs. The bugs are destroyed by spraying them using the aerosols positioned at the edges of the screen. To make things harder, different bugs require different sprays. If the bugs reach the flower they start eating it up until they are destroyed. You lose a life if the flower gets eaten entirely, or if you run into a bug. A new level begins when the flower finishes growing. The number, speed, and variety of bugs increases at the game progresses.
     
    My idea was to make this into a holiday game, based around protecting a Christmas tree (instead of a flower). However, I didn't take it further than a small demo for a number of reasons:

    I discussed the game with Nathan and we agreed that it wasn't holiday-themed enough. Shooting bugs doesn't really have anything to do with holidays!
    I enjoyed this game a lot when I was young, but I found it quite annoying when I played it recently. There isn't really enough variety in the gameplay, and the game gets ridiculously difficult very quickly. It may be possible to fix these issues by having different stages or by tweaking the gameplay.
    As usual, things got very hectic at work around the holidays and I had no free time to progress the game beyond a simple demo.

    The kernel demo of the game (and source code) for Pssst! should be attached at the end this entry. The demo isn't quite playable, but you can move around the screen, pick up aerosols (with fire), and kill the bugs (which don't move). The player and bug sprites are completely temporary and would be replaced in a real version of the game (they are monochrome in the demo, but the kernel allows a different colour on each scanline). A sample screenshot is shown below:
     

     
    I probably won't take this any further unless the gameplay issues can be solved. However, I'm interested to know what people think of the game and the demo, and for any suggestions.
     
    Chris
     
    P.S. I don't know either when Juno First is coming out on a cart, but I'm sure it won't be long now! The game and manual have been finished for some time.
  21. cd-w

    Next Project

    By cd-w,

    With Juno First nearly done, I have started to think about my next Atari 2600 game project. I don't have anything decided yet, but these are the various projects that I have been considering:

    Prince of Persia - I wrote a reasonable kernel for this a few years ago. However, the main issue is that it requires extra RAM and there aren't any such carts available yet. The other issue is the massive sprite requirements of the game. Le Geek made a good start on the sprites a while back, but there doesn't seem much point continuing until the hardware issue is resolved.
    JetPac - my earlier Jetman 1K game was a limited attempt at a port of JetPac. However, a full port should be possible on the 2600 (probably with a lot of flicker).
    Millenium 2600 - I am a big fan of the game Millenium 2.2 on the Atari ST. I should be possible to do a similar simulation on the 2600 using an AtariVox/SaveKey to hold the game state. However, it would probably be a text-only game, and I think that might put people off?
    Juno Second - I've got various ideas that might make for a good Juno Second, e.g. more aliens, aliens attacking from behind (with rear shooting), two-player mode, missions. However, Juno First already pushed the limits of the hardware, and any extension would likely require extra RAM.
    Armor Attack - A port of the Vectrex game Armor Attack should be possible, with a bit of creative sprite work and some AI. However, I'm a bit concerned that it is too similar to Combat?
    Hunchback - A full port of the Hunchback arcade game should be possible, but it will be rather similar to my existing Hunchy minigame.
    Pssst - A port of the Spectrum game Pssst may be possible with a bit of creativity.

    I haven't made any decision yet, so let me know if you have any preference from the above list, or any more ideas for games?
     
    Chris
  22. cd-w

    Batari Kernel

    By cd-w,

    Now that the Juno First release candidate is out, I have a bit more time to look at other 2600 programming. I have been interested in batari basic for a while as I have several game ideas that could be done with a custom kernel strapped on. However, until recently I hadn't really looked at batari basic properly.
     
    One thing that has been bothering me is that batari basic doesn't have a way to load playfield data directly from ROM. There are several games (e.g. Cave In) that have a high resolution playfield, but this requires extra superchip RAM. To cut a long story short, I have now written a prototype batari kernel that can load playfield data directly from ROM, without the need for the superchip. This should make several new kinds of games possible, and allow some existing superchip games to be released on regular carts.
     
    The new kernel works by copying a single line of the playfield into RAM at a time. When a new playfield line is required, the kernel performs a bankswitch and copies the next line into RAM. The key to the technique is the following code which is placed in each bank. To make this code work, X is set to the bank containing the PF data, pfptr points to the start of the data, and pfoffset holds the current playfield offset from the start:
     

    BS_loadPF ; Switch To Playfield Bank & Copy Data lda bankswitch_hotspot-1,x; [9] + 4 ldy pfoffset; [13] + 3 lda (pfptr),y; [16] + 5 sta aux1; [21] + 3 iny ; [24] + 2 lda (pfptr),y; [26] + 5 sta aux2; [31] + 3 iny ; [34] + 2 lda (pfptr),y; [36] + 5 sta aux3; [41] + 3 iny ; [44] + 2 lda (pfptr),y; [46] + 5 sta aux4; [51] + 3 iny ; [54] + 2 sty pfoffset; [56] + 3 ifconst bankswitch if bankswitch == 8 lda $FFF9; [59] + 4 endif if bankswitch == 16 lda $FFF9; [59] + 4 endif if bankswitch == 32 lda $FFFB; [59] + 4 endif endif jmp EndLoad; [63] + 3
     
    This code requires 57 cycles, so an extra blank line is required between PF rows. However, I think it still looks good (compare the attached Cave In screenshots below to see the difference). Let me know if you can see any improvements to this technique? Obviously it could be improved if the playfield data was always in the same bank as the kernel, but this isn't practical for many games.
     


     
    Because the PF data is loaded from ROM, it could technically support more than the 31 PF rows of the superchip kernel, though I haven't tried this yet. The kernel is still at a prototype stage and I could use a bit of help to improve it and integrate it properly into batari basic. The files that I have changed from the standard 1.0 release of batari basic are attached (in batarifiles.zip).
     
    The main issues are:

    There isn't enough RAM left to support various kernel options, e.g. pfscore, pfheighttable, pfcolortable, lives, etc. This can probably be fixed by reorganising things a bit.
    The colour data for the player 1 sprite is off by one line (not sure why).
    It should probably be integrated as a new kernel, rather than a hack of the standard kernel.
    It is relatively tolerant of page boundary crossings in the playfield data, but this could be improved.
    There are some weird issues display missile and ball sprites (occasionally it craps out completely).

    I have been using the Cave In source code as a testbed for this kernel. However, I don't want to post the code here as I haven't heard from Atarius Maximus yet. I can only compile pre-RC1 versions as the new kernel requires a bit of extra space in each bank and this is pushing things over the limit. Hopefully this issue can be fixed in later versions.
     
    Anyway, let me know what you think? I'm not sure of the status of the superchip boards, so this kernel might not be necessary, but I still think it would be nice to avoid using the superchip if it is not strictly required.
     
    Chris
  23. cd-w

    Flashing Cockpits

    By cd-w,

    There is a discussion currently in the homebrew forum about adding a flashing cockpit to the Juno First ship. One approach would be to use the ball sprite overlaying the player sprite. The ball sprite is used for the laser and is already correctly positioned (horizontally), but I can't find the spare cycles to enable and disable it at the correct time. The main loop where the ship is drawn is a 1LK as follows (the actual code is in kernel1.h in the zip attached to the previous entry):
     

    A_ShipLoop ; Calculate Pointer to Alien Sprite Data (aliens are 8 pixels high) tya ; [45] + 2 sbc ALIENY ; [47] + 3 bcs A_NoDraw ; [50] + 2/3 adc #8 ; [52] + 2 bcc A_NewSprite ; [54] + 2/3 adc TYPE ; [56] + 3 tax ; [59] + 2 ; Preload Ship Data lda (SPTR),Y ; [61] + 5 sta GRP0 ; [66] + 3 VDEL'ED ; Draw Alien & Ship lda A_Aliens,X ; [69] + 4 sta GRP1 ; [73] + 3 > 75 lda A_AlienCols,X; [0] + 4 sta COLUP1 ; [4] + 3 > 75 < 23 ; Set Ship Colour lda (CPTR),Y ; [7] + 5 sta COLUP0 ; [12] + 3 < 23 ; Draw Bullets (using PHP stack trick) tya ; [15] + 2 lsr ; [17] + 2 cmp B2 ; [19] + 3 php ; [22] + 3 cmp B1 ; [25] + 3 php ; [28] + 3 = 16 ; Reset Stack Pointer ldx #ENAM1 ; [31] + 2 txs ; [33] + 2 ; Check End of Kernel dey ; [35] + 2 bmi A_EndShipKernel ; [37] + 2/3 ; Check If Grid Line Should Be Drawn cpy LINE ; [39] + 3 bcs A_ShipLoop ; [42] + 2/3 ; ... Draw Grid Line, Alien & Ship and Return to Loop
     
    The y register holds the line count, and there are variants of this loop for drawing background lines, calculating a pointer to the next alien, and repositioning the alien sprite. In these variants the bullets are not drawn, which frees up the necessary extra cycles.
     
    To get a flashing cockpit, the ball sprite needs to be enabled and disabled at the correct time. One approach would be to use the lowest bit of the colour data, but would require 5 extra cycles as follows:
     

    lda (CPTR),Y sta COLUP0 asl sta ENABL
     
    Unfortunately I can't see any way to accomplish this. Unrolling the loop is not really possible as this would require 40 copies of this code (and all of the variants for repositioning etc.). I was wondering if any of the optimisation wizards around here could spot any way to fit this in. If not, it doesn't matter too much as this feature is not exactly essential to the game!
     
    Chris
  24. cd-w

    Juno First Betas

    By cd-w,

    I had a holiday yesterday and was able to spend some time finishing Juno First. I have now posted a beta version in the homebrew forum for general testing.
     

     
    There are quite a few changes since the last version that I posted, namely:

    There are now 32 unique waves, and I have made many changes to the previous set of 16. The game actually has 64 waves in total, but the second 32 are the same as the first with a higher speed setting.
    The fuel gauge now empties at twice the speed, which means that there is only 45 seconds to complete each wave.
    I have finally added the explosion sound effects and an effect at the beginning of each wave.

    EDIT: the source code is attached below (binary versions are in the homebrew forum). As usual, let me know of any problems.
     
    Chris
  25. cd-w
    I have been slowly working my way through the Juno First to-do list that I posted in the last entry. The SaveKey support turned out to be a real pain to get right. Fortunately I managed to unearth my Krok Cart from storage, but it was still very difficult to find the bugs. However, the game now has working SaveKey and AtariVox support (fingers crossed). There is a little bit of AtariVox speech at the beginning and end of every game, and the high score table is stored on the SaveKey.
     

     
    I have attached the latest version of the game to this message. The main changes this time are:

    Setting the Player 0 DIFFICULTY to A speeds up firing and limits the number of consecutive shots to 5.
    Pressing SELECT in the game takes you to the next wave (just for testing).
    Sky changes colour, and flashes when nearing the end of hyperspace.
    Removed the flickering colours in hyperspace.
    Hyperspace scoring should be fixed.
    Collision detection should be improved.
    PAL60 colour support added.
    SaveKey support enabled.
    AtariVox speech added.

    My plan is to post a beta version on the Homebrew forum in the next week or so for testing. The only things left to do before then are to add a load more waves and a few more sound effects. As usual, let me know if you find any problems in the game, particularly any screen rolls.
     
    Chris
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...