Jump to content

Search the Community

Showing results for tags 'Atari Programming'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Atari Systems
    • Atari 2600
    • Atari 5200
    • Atari 7800
    • Atari Lynx
    • Atari Jaguar
    • Dedicated Systems
    • Atari 8-Bit Computers
    • Atari ST/TT/Falcon Computers
  • Gaming General
    • Classic Gaming General
    • Classic Computing
    • Modern Gaming
    • Prototypes
    • Arcade and Pinball
    • Emulation
    • Hardware
    • Gaming Publications and Websites
    • International
  • Marketplace
  • Community
  • Game Programming
  • Site
  • Classic Gaming News
  • The Club of Clubs's Discussion
  • I Hate Sauron's Topics
  • 1088 XEL/XLD Owners and Builders's Topics
  • Atari BBS Gurus's Community Chat
  • Atari BBS Gurus's BBS Callers
  • Atari BBS Gurus's BBS SysOps
  • Atari BBS Gurus's Resources
  • Atari Lynx Programmer Club's CC65
  • Atari Lynx Programmer Club's ASM
  • Atari Lynx Programmer Club's Lynx Programming
  • Atari Lynx Programmer Club's Music/Sound
  • Atari Lynx Programmer Club's Graphics
  • The Official AtariAge Shitpost Club's Shitty meme repository
  • The Official AtariAge Shitpost Club's Read this before you enter too deep
  • Arcade Gaming's Discussion
  • Tesla's Vehicles
  • Tesla's Solar
  • Tesla's PowerWall
  • Tesla's General
  • Harmony/Melody's CDFJ
  • Harmony/Melody's DPC+
  • Harmony/Melody's BUS
  • Harmony/Melody's General
  • ZeroPage Homebrew's Discussion
  • Furry Club's Chat/RP
  • PSPMinis.com's General PSP Minis Discussion and Questions
  • PSPMinis.com's Reviews
  • Atari Lynx 30th Birthday's 30th Birthday Programming Competition Games
  • 3D Printing Club's Chat
  • Drivers' Club's Members' Vehicles
  • Drivers' Club's Drives & Events
  • Drivers' Club's Wrenching
  • Drivers' Club's Found in the Wild
  • Drivers' Club's General Discussion
  • Dirtarians's General Discussion
  • Dirtarians's Members' Rigs
  • Dirtarians's Trail Runs & Reports
  • Dirtarians's Wrenching
  • The Green Herb's Discussions
  • Robin Gravel's new blog's My blog
  • Atari Video Club's Harmony Games
  • Atari Video Club's The Atari Gamer
  • Atari Video Club's Video Game Summit
  • Atari Video Club's Discsuuions
  • Star Wars - The Original Trilogy's Star Wars Talk
  • DMGD Club's Incoming!
  • DASM's General
  • AtariVox's Topics


There are no results to display.

There are no results to display.


  • AtariAge Calendar
  • The Club of Clubs's Events
  • Atari BBS Gurus's Calendar
  • ZeroPage Homebrew's Schedule

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start










Custom Status



Currently Playing

Playing Next

Found 56 results

  1. It seems that nobody was impressed with my 16 character kernel last time - the main problem being the introduction of unnecessary flicker! I wasn't entirely happy with it myself, but I couldn't think of a better solution at the time. However, based on batari and Manuel's comments I decided to have another look at the no-flicker 13 char text demos. The 13+2 char demo uses a neat trick of rewriting NUSIZ during a scanline to squeeze in an extra two characters (in addition to using the ball and missile sprites to draw the 13th character). This trick provides exactly what I need for my high score table: The first part of the kernel arranges the sprites like this (P0 is set to 3 copies medium and P1 is set to 3 copies close): 0--101-10 Using the NUSIZ trick it is possible to display another copy of P1 (by setting it to 3 copies medium after the third sprite is drawn). This gives the following sprite layout: 0--101-10--1 This layout provides the necessary four-part display (Position, Score, Initials, Wave) that I was after! The spacing between the columns isn't perfect, but I think it looks good enough in the screenshot. The attached code demonstrates this technique. I haven't actually tested this on real hardware, so I hope the NUSIZ trick works in practise (it works fine in Stella and Z26)? Hopefully everyone will agree that this kernel looks much better than my previous attempt! Chris
  2. 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
  3. cd-w

    Juno Integration

    I've now integrated the Juno title screen and main game together into a 32K ROM (see attached). There isn't anything really new here, but I have sorted some long-standing issues in the code. In particular, the scanline count should now be stable at 262 in the main game - let me know if you see any screen jumps (except between the title screen and game). The main things left to do now are: Add a lot of levels. In-game sound effects. SaveKey support. Tune the gameplay and add more polish. Chris
  4. cd-w

    Text Kernel Take 2

    I've done a little more work on my text kernel. It still displays only 12 lines of text, but the code is cleaner and it now shows lower-case letters and numbers (the text is from "The Hunchback of Notre Dame"): I can get this up to 14 lines by overlapping the buffer creation code with the display code (there are lots of free cycles in the kernel). The problem is that this requires four versions of the copying and kernel code, which takes up nearly the whole 4K and leaves very little room for the actual text. This could be solved by copying the text into zero page memory and then doing a bank-switch into the kernel code. However, the copying code would require 24 iterations of the following code (24x10 cycles = 240 cycles = 3.2 scanlines), which would negate any savings with this method! lda (TEXTPTR),Y sta BUFFER+? dey This is probably as good as I can get the code without pre-computing character pairs (as in supercats method), but this would be difficult with lower-case characters ... Chris
  5. cd-w

    Juno First Betas

    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
  6. cd-w


    Well, it has been 5 months since my last blog entry! A lot has happened to me in this time, including finishing a book, getting engaged, moving house, and changing jobs. Most of these have been good things, and I will try to write about them in more detail in the future. However, it has all left me with very little time to do any Atari programming. I started the year with big ideas (i.e. PoP) and planned to enter the 8K minigame competition (with Juno First), but this has not been possible. It also looks like I will be busy for some time to come, and as a result I haven't been able to help out with this years' holiday cart. However, there is one small Atari project that I have managed to make some progress on, and I though I would post the initial results here. A feature that is missing from most Atari games, but is ubiquitous in the Arcades, is the "high score" table. Now that the SaveKey is available there seems to be no good excuse for this omission. I though it would be a good idea to try and write a generic Top-10 highscore routine that people could include in their games. I also wanted to include a highscore feature in Juno First, should I ever find time to finish the game. It turns out that it is quite difficult to design a high score routine as there are lots of exceptions that can occur, e.g. if the savekey is removed, or errors occur during reading or writing. As a result, I first designed a state chart which covers most of the possibilities: The main difficulty of developing for the Savekey is that it isn't currently emulated in either Stella or Z26. I had hoped that it might be possible to use the Savekey with the Stelladapter, but this doesn't seem to work. My Atari stuff is still in deep storage since I moved, so I haven't been able to test my code properly, but I have written some initial code that follows the state chart above. The code is completely unoptimised and takes up a full 4K, but I wanted to check that it works before I start shaving cycles. Also, I figured that anyone else using this code would probably want to customise it themselves, and any heavy optimising would get in the way. Edit: Minor code update - fixed some obvious bugs and optimised a bit - still untested on real hardware: controllerpics.zip The initial code and binary is attached above. In Stella, it gets stuck waiting for you to attach the Savekey, while in Z26 is acts as if the Savekey were connected. I have attached a couple of screenshots below so you can see the main screens. I will be grateful if someone could try this on a real Savekey, although it may corrupt any data that you have on there, so be very careful! Let me know if you find any bugs or have any suggestions for improvements. The text kernels are just for demonstration purposes and will be improved later. Chris
  7. Guest

    Juno First

    There has been some discussion on these blogs lately about good arcade games to port to the 2600. In particular, Manuel posted a list of obscure titles in his Planet Bob blog. Since I hadn't heard of most of them before, I decided to fire up MAME and try them out on my new X-Arcade stick. The game which I enjoyed the most is probably Juno First, which is a bit like a vertically scrolling version of Defender. I am surprised this game isn't more popular as it seems very similar to the classic Williams games, and is great fun to play. It looks like a Juno First port would be possible on the 2600 with a bit of effort, as it is not too graphically demanding. As noted elsewhere, the game plays a bit like Beamrider on the 2600. However, in Beamrider you can't move backwards, and you are fixed at a particular speed. As a result, I decided to hack up a quick kernel which uses a Beamrider-style display, but enables you to change speed. The result is attached to this entry, and I think it gives a good feeling of motion. I was rather surprised to see that Supercat also posted a Juno First kernel today in his blog! His solution uses the ball sprite to draw a dotted play area which is more faithful to the original game. I haven't decided if I want to take this any further yet, but I think the two versions should provide a good starting point for discussion of the best approach for the 2600.Chris
  8. Guest


    I am not very good at multitasking. I find it difficult to switch from one project to another, and so I tend to give a single project my full attention for some time while ignoring the rest. My problem is that I have a lot of projects, including redecorating my house, writing a book, developing several websites, and learning to drive. I guess that my girlfriend should also be included in that list! As a result, my Atari projects tend to move along at a relatively slow pace, with occasional spurts when they have my full attention. By an unhappy coincidence, it turns out that the Atari 2600 is not very good at multitasking either. There are times when it becomes painfully clear how little time there is between screen updates to actually get any work done. For my PoP game, at least the following tasks will have to be done during this time period: Check which directions the player can move in. Check if the player has reached the screen edge. Check if the player is falling and/or dead. Check if any floor switches have been pressed. Check if any loose tiles have been stepped on. Read the joystick & console switches. Move the player. Update the player sprite animations. Animate the visible objects, e.g. flickering torches, bubbling potions, loose tiles. Open and close any moving doors. Move and animate any visible guards (enemy AI). The PoP game currently does steps 1, 2, 6 and 7 and things are starting to get tight. I have optimised the collision detection routine that I posted last time and it still only leaves 7 scanlines free in the overscan region in the worst case. Fortunately it is not going to be necessary to perform all of these tasks on every frame, so I am still confident that the game will be possible. However, it might eventually be necessary to perform time-slicing, as described by Andrew Davie in his Boulderdash project.The task that I am currently wrestling with is how to implement the floor switches. It turns out to be a bit more complex than I had anticipated as the switches can open doors which are not visible on-screen. I think I now have a reasonable way to do this, but I haven't implemented it yet. The basic idea is as follows: All of the switches and doors will be given a unique index, and there will be a maximum of 15 doors and switches on each level. The status of these doors and switches will be stored in a table in Supercharger RAM. If this is not enough, then to doors and switches could be separated into separate tables. There are around 28 positions on a screen where a door or switch can appear. To avoid the need to store an ID for every possible position, I will restrict each screen column to a single door or switch. The alternative would be to restrict each row, but in examining the original game levels it appears that doors and switches often appear on the same row, but only rarely in the same column. The levels will have to be altered slightly, but I don't think this will be a big problem. There are 4 columns on a screen (for the 4 PF registers), so this means that we need 4 IDs per screen to represent the doors and switches. Since each ID is in the range 0->15, each screen will require only 2 bytes extra storage. When the player steps on or off a switch, the status table will be updated. It should be easy to determine which entry needs to be updated as the column can be trivially calculated from the players X position. The status table will be checked regularly and updated, e.g. a closing door will be closed by 1 step per check. The screen data needs to be updated to reflect the status of the doors and switches, so this will be done by directly modifying the level data. This is the only step which I am concerned about. A single door will usually appear on 2 screens, so we need to search through the level data to find these screens, then find the correct position, and then perform an update. Fortunately the doors move slowly, so this can probably be split between frames. I hope this makes some sense? If anyone can think of a better way, then I will be happy to hear it. This appears to be the point at which the game will require the extra Supercharger RAM, and could not be done simply by using a large ROM. ChrisP.S. I appreciate that everyone has different music tastes. However, I think that the track "Twisted Logic" by Coldplay (X&Y Album) makes an excellent Atari programming anthem!
  9. Guest

    Running to Stand Still

    There are some times in programming, particularly on the 2600, that you have to expend a lot of effort to achieve relatively little. The last few days working on the PoP kernel have been like this for me. Having now become convinced of the safety and benefits of the undocumented 6502 instructions, I decided to use them to improve the efficiency of my code. In particular, I wasn't happy with the self-modifying code used in the kernel. Although this code was working fine, it was taking 14 cycles per write, and there were 44 of these writes in the kernel, which adds up to a lot of cycles (616)! Also, these write instructions will only work on the Supercharger and this would make the code difficult to port to other cartridge formats. To remove the self-modifying code, it was necessary to use indirect addressing. I had previously tried this and failed, but this was before using undocumented instructions. I figured that the LAX instruction might help things out, since it allows the X register to be loaded in the indirect mode without costing any cycles. To cut a long story short, after several days of effort I was able to make it work. The result is a very convoluted kernel (always the best kind!) which uses indirect addressing and has no spare cycles in the main loop. This kernel will now work on a regular 2600 without Supercharger, and should be easy to port. However, from an external perspective, the kernel just looks exactly the same on the screen! I therefore made a few cosmetic changes, just to convince myself that I had actually achieved something. I have attached the new version (and code) to this entry. The main changes this time are: The doors are now drawn using PF graphics (instead of sprites). Although this means that they don't look so good, it will allow multiple doors on the same horizontal line, which I think will be important later. Also, it will simplify the collision detection process. The player now walks in front of the pillars. I was initially trying to copy the original, but this doesn't look good on the 2600 as the player was showing through the pillar in places. I have added a colour gradient to the platforms. The cleanup process is not yet complete. I have removed the self-modifying code from the kernel, but have just replaced it with SLEEP instructions for now. I am not entirely sure what to put in place of this code yet, and I don't want to shrink the size of the platforms. I think the next step is to try and reduce the usage of the precious zero page memory in the kernel, but for now I am going to take a break!Chris
  10. 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
  11. cd-w

    28 Char Text

    I finally understand how supercats 26-character text kernel works (I think)! As a result, I have written my own version which displays 28 characters on a line. Unfortunately I could only do this by flickering at 20Hz and using a 6-pixel high font, so it doesn't look all that good. However, I think this is the first ever 28-character kernel on the 2600? It only displays one line of text at the moment, but it should be possible to display 12 or 13 lines using the same techniques as my previous text kernels. I will be very grateful if someone can run this on a real 2600 as my own equipment is currently buried in storage. I'd like to check that it actually works, and if the flicker is acceptable on a real TV? Chris
  12. cd-w

    Text Kernel

    It has been nearly a year since I updated this blog, and just about as long since I did any Atari programming. However, things are a bit quieter for me at the moment and I decided to write a text kernel as a way to refresh my 6507 programming knowledge. My first attempt is attached to this message and is an extension of the Juno First title screen technique in my previous blog entry. The screen-shot below shows the results - I have managed to get 12 lines of nearly flicker-free text (24-chars wide) on the screen: I would be happy with this if it weren't for a much better text kernel that supercat posted recently, which gets nearly twice as many lines of text on-screen. As a result, I'm going to try to improve this code to see if I can squeeze in a few more lines. I'll post the results here if I manage to make any improvements. Chris
  13. cd-w


    Last week I received a shiny new Krokodile Cartridge (KC) in the mail. I had been on the waiting list for some time, so it was great to finally get hold of one. It came at a good time, as I needed some way to test my Juno First game on real Atari hardware since exceeding the limits of my Supercharger (SC). In addition to permitting binaries over 4K, the KC has a number of other advantages over the SC: it doesn't require the weird audio setup that I was using to transfer game images, it has a lot more RAM than the SC, it permits multiple games to be stored, and it keeps its content when the power is switched off. As a result, my old SC will now be retired from game development duties, unless I am actually developing for the SC itself, e.g. if I revive my PoP game. There is one small problem with the KC though: it doesn't have a Linux driver. This is an issue for me as I do most of my computing work under Linux. I do have a Windows installation, as it is sometimes unavoidable, but I would prefer not to have to use it everytime I need to write to the KC. As a result, I decided to investigate the Mac OS-X driver to see if there was some way to port it to Linux, since the two systems have many similarities. SpiceWare was kind enough to send me the source code for his OS-X driver, and a copy of the KC serial transfer protocol document. It quickly became apparent that the protocol was very straightforward, and it wouldn't take too much work to port the driver across. However, as my C coding is rather rusty these days, I thought I would have a go at porting it to Java instead. The advantage of this is that the same code would work across multiple platforms, and it would be easier to build a GUI. To cut a long story short, I have spent the last couple of days rewriting the KC driver in Java. The serial port communication is accomplished using the Java Communications API. I am actually using the RXTX implementation of this API, as it is available on many more platforms than the Sun version, and seems to be more actively developed. The latest version of my Java code is attached to the bottom of this entry, and there are basic instructions in a README file. It can already download a single file to the KC under Linux, and I have tested it with a variety of different bankswitching schemes. This is actually all that I need, as it lets me test my Juno First game on the KC, but I am planning to clean it up a bit and add multicart support in the near future. I haven't tested it on other platforms, but the Java code should work fine if the correct RXTX implementation is used. Anyway, let me know if this is useful to anyone, or if I am the only Linux hacker around here? At the moment the code is really only intended for experienced Java hackers, but I will improve it further if there is any demand. I don't have any plans to add a GUI at the moment, but I may do this in the future (or someone else might volunteer ). Chris
  14. Guest

    A Brighter Outlook

    This will probably be my last entry for a while as I am off next week to Washington DC for a conference, and then on to the vgXpo in Philadelphia the following weekend. Fortunately things are looking better for the vgXpo now as many people on the forum have said they are still going, and AA will have a stand there after all. The Hunchy 2 carts have now been soldered by Al, and should be available for sale at the show. If there are any bugs still remaining in Hunchy 2 then it is too late! I have attached the latest version of the PoP code to this entry. This version fixes the collision detection with the doors, which (for once) was not as hard as I was expecting I have also added some self-modifying code to enable the lives indicators (at the bottom of the screen) to be changed, but this won't be noticable until later. The prince sprite is back as I was getting tired of the big white blob, but he won't be animated until I sort out all the remaining issues with collision detection. The next task is to clean up the code using the suggestions that were posted in response to my last entries (thanks supercat and vdub_bobby), and then I can start implementing the various falling tile solutions. Chris
  15. Guest

    Highs & Lows

    The Highs:Juston has finished the label for Hunchy 2 and it looks amazing (see below). My first Atari cart release looks set to happen real soon, and I can't wait to see the finished product. The 2005 minigame multicart is also coming along nicely, and will contain some of my minigames (Hunchy, Jetman & Nightrider). The deadline for the minigame competition is also nearly here and I hope my games will do well, though the competition is tough.The Lows:I have booked my flights and accomodation from the UK to attend the vgXpo (formerly PhillyClassic), but it seems they have now turned it into some kind of family entertainment event. The classic arcades museum won't be there, and it looks like AA might be pulling out as well. This is a major pain as it will probably be my only chance to attend a large US classic gaming show, at least for a few more years. I will probably still be going as it is too late to cancel, but it isn't what I was expecting. I am also still stuck on the PoP falling tiles problem. I implemented the solution outlined last time, using the ball sprite to show the tile briefly falling, but there was an obvious flaw in the plan that I don't spot until it was done. The floor tiles are 16 pixels wide, but the ball can only be stretched to 8 pixels, meaning that the falling tiles were too small! I can't use the missile sprites (stretched double) as this will affect the player and object sprites also, so this just leaves the playfield (PF). The problem here is that the wall tiles are 32 pixels wide (8 PF pixels), so there may be an overlap between a wall segment and a falling tile, even though the falling tile will not actually overlap the wall (if this makes sense!). What this means is that I would need to define each wall tile twice: once as normal, and a second time to show the falling tile. The second one could then be substituted briefly for the first to show the tile falling. However, this will require a lot of memory (12 tiles * 27 bytes * 2 = 648 bytes!). I could reduce the wall tiles to 16 pixels wide (4 PF pixels), but then the screen data would require a lot more space, and the kernel would become more complex. Neither of these solutions sounds appealing. Therefore, I am steering towards one of the following: Just make the tiles disappear (as in the current version). Draw the falling tile using the 8-pixel ball sprite, but flicker the left/right sides on alternate frames, or draw the tile in two halves like this: ----___ Don't attempt to draw the falling tile in the wall area, just flash the floor tiles on/off in the floor rows underneath. The third one sounds the best compromise, so I will try this out in the next release unless anyone has any more suggestions? In the meantime I think I am going to switch off the computer and have a well-deserved break from it all!EDIT: The following mockup shows what option 2b would look like:Chris
  16. Guest

    Limits of Scale

    As someone who has been taught Software Engineering, there is something both refreshing and frightening about assembly programming on the Atari. On the one hand, all of the standard rules about abstraction, modularity, generic data structures and exception handling go out of the window as there is simply not enough memory or cycles. On the other hand, the resulting code ends up becoming increasingly complex and tangled in the quest for space and efficiency!My PoP project is now the largest assembly program that I have ever written, much larger already than Hunchy II. However, I am also finding it increasingly difficult to make changes to the game. The problem is that the code is strewn with magic numbers and bits, and changing one part of the code can have unforseen consequences in another part. Sometimes, even changing the length of a particular bit of code can cause breakage due to memory alignment problems. The result is that updates to the code are becoming slower and slower. I am also rapidly running out of space for the code - the 6K provided by the Supercharger doesn't go all that far in a game like this.Anyway, I don't want to be too negative as things are not desperate yet! It is just that I can see a big code optimisation and reshuffling phase will be required soon if the game is going to progress much further. The latest update to PoP is attached to this blog entry. The new features this time are that the falling tiles now disappear when you step on them (after a short delay), and the switch in the final room now opens the door (see image below). I haven't yet fixed the collision detection with the doors, but I have a possible solution worked out.Up to now I have been modelling the game around the SNES version (probably the best conversion). However, this is not the ideal version to use as it contains extra levels and graphics not found in the other conversions. I have now aquired the Gameboy Color version of the game (thanks to eBay) and I will be using this instead. The Gameboy version is probably the least advanced, and is a much closer fit to the capabilities of the Atari. The switch to the Gameboy version is already yielding some useful clues. It contains a possible solution to the falling tile problem that I described last time. Instead of showing the tiles falling the whole way down the screen, the falling tile is shown briefly at a fixed position under the original, and then removed entirely. This effect shows that the tile is falling without requiring any complex animation, and it also appears reasonably convincing. I am planning to implement this in my next release to see how it looks - I just need to decide if I want to use the sprites, missiles, ball, or PF. As discussed previously, all of these have advantages and disadvantages, and I'm not yet clear which will be the best compromise.ChrisP.S. Looking back at my earlier "Multi-Tasking" entry it appears that some good progress has been made, although it doesn't always feel like it! I have basically accomplished tasks 1,2,4,5,6,7, and 10. The big issues remaining now are really just the animations and guard movements, but I know these are going to be tough!
  17. Guest

    Tile Trouble

    I have been spending the last week getting Hunchy II into shape for the PhillyClassic show. I think I have the final binary (barring some possible tweaks to the tile screen), jussts is nearly finished the label, and the manual text is written and being compiled by Tony Morse. With luck, my first Atari 2600 cart game will soon be released, and I can't wait to play it!As part of the testing process for Hunchy II I unpacked my Supercharger from storage. At the same time I decided to see if PoP actually worked on the real hardware for the first time, and fortunately it does! There was a small sprite positioning problem, which I believe is due to the TIA in my weird 2600Jr, but this is now fixed.The last PoP update contained rather a few bugs, so I have attached a new version to this entry which should hopefully fix most of them. I have implemented all of the doors and switches on the first level, so it is now possible to do a complete walkthrough. The collision detection on the doors is not yet there (you need to wait for the door to open fully before approaching), but I think I know how to fix this. The other change to this version is the inclusion of the health bars at the bottom of the screen (see image below). This was done with the help of a 2x4 score routine by Thomas Jentzch. It still requires some self-modifying code to alter the bars, but this should be straightforward.The next challange in PoP is going to be the falling floor tiles. I don't yet have a real idea of how to do this, so any ideas will be welcome! It is easy enough to detect when the player has stepped on a falling tile, but I am not sure what to do next. The problem is that the screen is divided into rows of floor and wall segments. It is not possible to draw a floor tile in the wall region (or vice-versa), so it is not straightfoward to show the tile falling. A possible workaround would be to use the sword sprite to draw the falling tile in this region, but there would be a colour mismatch. It will also be very difficult to draw multiple falling tiles this way, and this won't work if the sword is in use at the time. As a result, I am very tempted to make these tiles into dissolving tiles. However, the are several puzzles in the original game where it is necessary for a falling tile to land on a switch to keep a door open. Any suggestions?Chris
  18. Guest


    I am a perfectionist in may areas of my life. To others, I probably come across as somewhat of a pedant, but I remain unapologetic! I think this quality is present, and necessary, in almost any gamer and programmer. It is this quality that drives one to collect every gold coin in Mario, to achieve the highest score, or squeeze every last byte and cycle out of the Atari 2600. However, there are times when this quest for perfection can get in the way, or it becomes increasingly unclear what "perfect" means in a given situation.One particular quandry with perfection that I am having relates to the use of modern technology in 2600 programming. Following on from my last entry, an important motivating factor for me is that I want to behave as if I were an Atari (or Activision!) programmer back in the day, fulfilling a long standing ambition of mine. For this reason I have so far stuck to producing games with exactly the same limitatations as these programmers had: 4K ROM, 128b RAM, no illegal-op codes, etc. I am acutely aware that I am using modern tools (e.g. emulators) to produce these games, but I can rationalise this as these programmers had dedicated development machines. However, there has now come a point where I would like to go beyond these limitations, as many other Atari homebrew authors have.The problem is really deciding how far I want to go in this direction. At the extreme end, it would probably be possible to develop a cart which contained a powerful processor, and simply used the 2600 as a slave unit. However, although this would be interesting to see, it wouldn't feel like 2600 programming to me. Less severe, it is possible to augment the Atari with certain features to expand the capabilities of the machine, such as the AtariVox add-on. Nonetheless, while this is an impressive feat, it still feels a lot like cheating to me. If the capabilities are expanded beyond what was available at the time, then my opinion is that it might just be better to start with a more powerful console such as the 7800 instead. At this point we enter a grey area for me: RAM and ROM expansion. From a programming perspective, I can immediately see the benefits here. With more ROM it becomes possible to create games which are much larger in scope, such as the fantastic Thrus+. Similarly, more RAM opens the possibility for larger games, using a number of new programming tricks. However, I am again nagged by doubts as to wether this is real 2600 programming or not, and if it really matters.In light of this, I am currently taking my first programming steps with the Starpath Supercharger add-on. This was available at the time of the Atari, though only a few games were ever developed. The Supercharger is a monster of a cartridge (in size) and gives you 6K of RAM in three 2K banks and a cassette tape interface. The Supercharger opens the door to such things as self-modifying code, and the improvement in graphical quality is evident in the few titles that are available. Programming the Supercharger is nicely convoluted, which feels like proper 2600 programming should be! Also, there are probably a great many Supercharger programming tricks that are waiting to be discovered. So far, the experience has been a positive one, and I think I can live with this compromise. However, the real downside is that any games that I develop cannot be released in cartridge form. I am still not sure how far I will go with this, but we shall see. I will post the fruits of my labours here soon, once I have something to show for my efforts.Chris
  19. Guest

    The Beginning

    Hi Folks,I though I would start this blog to chronicle the development of my various Atari 2600 programming projects, and to avoid cluttering up the main site threads. So far, I have developed the following four games, all of which are now fully playable, but none of them are entirely complete yet: Hunchy Jetman Nightrider Hunchy2 I also intend to punctuate this with some of my own insights into the differences between British and American culture, which I have observed while travelling. I have managed to resist creating any kind of blog until now, so we shall see how far this goes before I get bored and give up!Chris
  20. cd-w

    The Next Step

    I spent the weekend working on my Juno First game, so here is another update. The main changes this time are: There is now an explosion animation for the aliens, and some of the sprites are animated at their largest size. The alien spawning code is in place, so the aliens appear one by one at the beginning. The length of the laser beam shortens as it goes up the screen (I know I said this wouldn't be possible ) There is now a basic 6-digit score at the bottom of the screen. The main problem now is that the game has reached the 4K ROM limit, so I haven't implemented the velocity on the spaceship yet (this will require a large table of values). The only kind of bankswitching that I have done so far on the Atari is the Supercharger scheme. I am tempted to make a SC version of Juno First for a certain competition as this would enable a more colourful kernel and possibly multiple sprite copies. However, before I go down this route, I would like to implement a standard 8K version using F8 bankswitching. If anyone has some template code or knows of a good method then I would be grateful for advice. If there are any bugs or issues with the game, then let me know. Also, if the screen turns red at the edges then let me know as this means that the game has run over the cycle limit. Chris
  21. cd-w

    Flicker Fest

    This is just a quick update on my Juno First game. I hope people don't mind me using this blog as a beta testing area. However, I find it useful to post these development versions as the folks here are quick to spot bugs and problems that I might not notice otherwise. The previous versions had a number of serious bugs, but I hope that most of these have now been resolved. The main features this time are: All 20 possible sprites are now displayed on screen. This causes some serious flickering, but this should not be so bad in the final game as the sprites will be moving and the maximum number will only rarely be reached. The flickersort routine uses almost all of the vblank area, so let me know if you see any screen rolling. I have started to implement the collision detection code, so it is now possible to shoot the aliens. An explosion effect will be added later. The sprite movements should be a bit smoother, and the spaceship velocity decreases if you do not hold the joystick foward or backwards. Some of the sprite sizes and colours have been tweaked thanks to suggestions by Nathan. Anyway, let me know if you sport any problems, or have any suggestions? The source code is included in the ZIP file as usual. Thanks, Chris
  22. cd-w

    Two's Complement

    The Atari 2600 is a difficult machine to program, but the 6502 assembly language in which this programming is done is relatively easy to understand. Nonetheless, there are certain features of this language that I still don't completely understand. One of these is the indexed indirect mode that I taked about in a previous entry, but this is not a particularly useful feature. The other issue for me is two's complement binary arithmetic which I view as a necessary evil. Two's complement is not specific to the 6502, but this is the only context that I regularly come in direct contact with it. I undertand the principles behind the notation, but something always seems to go wrong when I attempt to put it into practice. Two's complement notation allows you to represent numbers in the range 0->255 or -128 to +127. The numbers 0->127 are represented the same way in both schemes. Similarly, if you only need to deal with positive numbers then there is no real difficulty. However, negative numbers get a bit more tricky! In this case, the upper bit of the number represents the sign, e.g. 0xxxxxxx is a positive number and 1xxxxxxx is a negative number. You might think that -1 would simply be represented as 10000001, but this is not how things are done as there would be two zero values (+0 and -0). Instead, to convert a number into its negation you invert the bits and add 1, so -1 becomes 11111111, which is 255 in the normal way. This scheme is very clever as it does not require any extra hardware to cope with negative numbers, but can be a pain from a programming perspective. The problem that I have with two's complement is that you have to be very aware of the ranges of your numbers or nasty things will happen, e.g. 130-5 can give you unexpected results if you are not careful! Also, if you try to mix numbers of both kinds, or do signed comparisons on unsigned numbers then you are likely to end up with a headache. In the past, I have usually avoided these problems by sticking to positive numbers, but in my Juno First project the complexities of two's complement have been unavoidable. In particular, the speed of the spaceship is represented as a number from -16->16, and the coordinates of the aliens are represented as numbers from 0->255 which wrap around. I have spent the last week trying to get the aliens to move forward and backwards properly. This has been significantly complicated by the fact that the aliens move at different speeds depending on where they are on the screen, i.e. aliens in the distance move slower than those in the foreground. The results of my efforts are attached to this message. The aliens are stationary (for now), but move forward and backward according to the movement of the spaceship. In Juno First, the top of the screen acts as a kind of scanner which shows the aliens far in the distance. If you move backwards, then these aliens appear from behind, i.e. the play area wraps around. The movement of the aliens is slighly jerky, but I hope that the illusion of perspective is there. Let me know if you think this looks OK, or if this could be done in a better way, also let me know if the flicker is acceptable (using the phosphor option on Z26 or stella helps a lot). The code for the alien movement is not yet complete. In particular, if you change direction some of the sprites will disappear for a bit until the flickersort code moves them back into the right order. I haven't yet figured out completely how to avoid this, but I think that it can be addressed using a circular buffer. I am still using a sprite index in this version, but I have implemented Manuel's cool suggestion, where the index values are the same as their positions within the index. Thanks for all the other suggestions - I still haven't completely decided on the final solution. However, the flickersort and index creation are now done by the same code which saves a lot of cycles. I realised that the values in the index were precisely those that were not swapped during the flicker sort routine The game is still coming along nicely, but I really could use some extra memory! There are now just four main parts of that have to be done in the core before the game will become playable: Finish the sprite sorting/disappearing issue, so that the sprites are always drawn in the correct order. Implement collision detection, so that the aliens can be destroyed. Implement procedural movements for the aliens, so that each type of alien moves in a different way. Figure out how to spawn new aliens, so that they appear in the correct place at the right time. Chris :!: EDIT: After various comments yesterday about jerky sprites I went back and looked at the alien movement code. A bit of searching revealed an implicit assumption that the sprite positions were in a strictly increasing order, though this is not always the case when using flickersort. I have now removed this assumption and posted the new version below. Unfortunately this change is rather computationally expensive, so there are less sprites on the screen. However, I hope that this now removes most of the jerkiness from the sprite movements? If so, then I will work on optimising this solution.
  23. cd-w

    Programming on Paper

    I have always preferred programming on paper for some reason. I think this is because I didn't have a computer at home when I first learned to program. The only computer available to me for a long time was in my school, and its usage was strictly controlled and very limited. As a result, I used to write out my programs by hand in exercise books, and spend my precious computer time typing-in these listings and attempting to debug them. At the end of the session, I would print out what I had done and then spend the time away from the computer working out the bugs. These programs seldom worked, but they were a great learning experience. This is still the way that I prefer to work, though I don't generally write out the initial program listings by hand anymore. Instead, I type up a rough version of the code directly onto the computer, and print out a copy that I then study for optimisations and bugs. I think the main problem that I have with programming directly onto the computer is that you only get to see a small part of the code at once. With paper, you can spread out all of the different parts on your desk and get a real picture of how it all fits together. There are various IDEs and folding editors that attempt to address this problem, but I prefer to use a standard text editor (xemacs) and printer paper. The best kind of paper listings were the old fanfold kind, where each listing was essentially a continuous sheet of paper. You could spead it out on the floor and follow the control flow up and down the paper. When I first started at University, the lab had an old chain printer which printed out listings on 160-column fanfold paper. Actually I think it was a dot-matrix printer, but it was still called a chain printer as this is what it had replaced. This printer was managed by a supervisor who would put each listing into a pidgeon hole for later collection. The advantage of the 160 column format was that you had a huge amount of space next to your listings in which to make notes, draw diagrams, and document your code. Unfortunately this printer and the supervisor were replaced by a laser printer around 10 years ago now. I still think that I would be a better programmer if I had this printer, but these days I make do with 2-up laser printed listings. The point of this nostalgic trip is that for the last week or so I have been carrying around a listing of my Juno First kernel. Every time I have had a few spare minutes, usually on the bus or train, I have taken out the latest listing and started tightening the code. Occasionally I will spot a neat trick, or solve a difficult timing problem, which generally causes a big smile to appear on my face, and probably causes those around to question my sanity! At times like this my girlfriend usually makes comments about geeks and the reason they have trouble finding women Anyway, I think that the Juno First Kernel is now nearly complete, though obviously this is just the first step of the game itself. The latest version is attached to this message (the source code is in the ZIP archive). This code fixes many of the bugs in the previous version, and includes a variant of Manuels flickersort routine for displaying multiple sprites within the same horizontal region. The flicker will be much less noticable in the actual game as the sprites will be moving and should only occasionally overlap. Also, it will look better on an actual TV (use the phosphor option in Z26 or Stella to see this). The alien sprites do not move yet, but this is my next task. I still haven't come up with a solution to the HMOVE problem outlined previously, though I might just live with the lines as they are not too distracting. Overall I am very pleased with the way that the game is turning out so far ... Chris
  24. cd-w

    Pssst! Kernel

    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.
  25. cd-w

    Next Project

    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
  • Create New...