Search the Community

Here is another quick progress update on my Juno First game. I have now implemented the missiles, which were the final missing feature in the game. Up to 8 missiles can be shown simultaneously on screen (using flicker). There is still a bit of tearing when the missiles pass over the grid lines, but I hope this isn't too noticable. The missile firing patterns are rather boring, but I will improve this later. I was originally planning to use one of the missile sprites for regular missiles, and one for homing missiles. However, it looks like I might have to drop homing missiles from the game. The problem is that the missiles can't be distinguished from one another, and I can't work out how to efficiently implement a suitable homing algorithm. The best that I could do was to move the missile directly towards the player, but this didn't look very convincing and was nearly impossible to evade. I have been trying to remain relatively faithful to the arcade game, but there are some features that probably won't be possible. My latest thought is to implement slow and fast missiles instead of homing missiles, unless anyone can think of a better solution? Chris

I am often struck by the similarity between the activities of game playing and game creation. In both cases, there is generally a long sequence of problems to be solved with an eventual goal in mind. These problems can have complex dependencies, and finding a good solution can make the difference between reaching the goal and starting over. As I have previously noted, I actually gain more enjoyment from creating games than I do from playing them. According to some friends of mine in the games industry, this is not uncommon. Many of them suck at playing games, though they are experts at creating them With this in mind, I have made some further progress on my Juno First project. To get this far, I have solved a very long sequence of problems, many of which I didn't think would be possible. Nonetheless, there remain many more problems that will have to be addressed if the game is to be completed. As time progresses, these problems are getting harder to solve as available resources on the Atari are diminished. The main changes to the game this time are: The aliens now move around the screen. They all use the same basic movement pattern at the moment, but I think this looks very cool! The game has now been expanded to an 8K ROM which has thankfully relieved many of the memory pressures. I eventually adopted the scheme that supercat posted last time (thanks!). I'm not quite sure that it will work if the game starts in the wrong bank, so I would be greatful if someone could check the code (just before SEG BANK2). The explosion sprites have been altered and there is now a flame effect when the spaceship moves forward and backwards. Also, the spaceship will explode and then reappear if you collide with an alien. I am very grateful to Nathan for all of his help with this. There are still a few remaining issues in the code. In particular, the spaceship will explode if an alien hits the flame. This is because I am using harware collision between the aliens and spaceship. I think I will need to move to a software region-checking approach, but this is going to take a lot of cycles. If anyone has an efficient techniqe for checking if a moving sprite enters a fixed region then I would be very grateful. The next step is to go through the code carefully to spot possible optimisations as there are now very few cycles remaining anywhere. Chris

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

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

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.

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

It has been a while since my last blog posting, and I haven't been very active on the site recently. This is not because I have lost interest in the Atari - it is just that I haven't had time to do much on my various projects lately. The main distraction has been a book that I have been writing for the past year. The publishers deadline was the end of February, and as usual I ended up writing the majority of it in the last two months! However, now that it is out of the way I should have significantly more free time again. I would really like to produce something for the minigame competition this year, and the deadline for the Stella programming contest is fast approaching. Over the last week I have been working on my Juno First game again, and the latest version is attached to the end of this entry. It probably doesn't look much different than the previous version, but it now contains a completely new kernel, and some fantastic sprites by Nathan. There are still a few small bugs, and it is definitely the most difficult kernel that I have written so far! This difficulty comes from the fact that I wanted the sprite graphics to be updated every line (i.e. a 1-line kernel), but this potentially requires doing all of the following tasks on every line: Display the spaceship sprite. Display the alien sprite. Change the spaceship and alien sprite colours. Display the two missile sprites. Display the laser beam. Display the moving grid. I had to make a few compromises to fit everything in (e.g. the missiles are only updated every other line), but overall I am reasonably happy with the way things turned out. The result is really at the upper-limit of what is possible on the 2600 without any extra memory. It took me many hours of careful unrolling and optimisation, and there were many times that I though it wouldn't be possible. The tightest part is when the ship needs to be displayed at the bottom of the screen. There are absolutely no free cycles at this point, and I can't see any way to squeeze this code further. The entire kernel is written without any illegal instructions, as none of them seemed appropriate. The biggest problem with the current kernel is the HMOVE bars, which cause the gridlines to flicker along the left edge. There are a number of possible solutions, but none of them are ideal: Perform an early HMOVE -> may cause problems on PAL Atari Jr machines. Use the PF to hide the left part of the screen -> will appear in the same colour as the laser beam. Perform an HMOVE on every line -> not enough space kernel cycles. Update COLUBK on cycle 26 -> tricky but not impossible - will make the left border larger than the right border. Ignore the problem -> looks a bit messy and will also interfere with the sprites. I am currently leaning towards the fourth option, but I was wondering if anyone has any better ideas? Also, any more suggestion on how to tighten the code are welcome. The (messy) source code is included in the zip archive. Chris

I have produced another Juno First kernel demo which is attached to this message. This mockup shows the aliens at fixed positions, and you can fire the ships laser. This demo is basically just to check that there is enough time to display the scrolling background and reposition the aliens in a 1 Line Kernel (1LK). The background lines actually skip over the repositioning lines which makes it a bit jerky, but this will be fixed later.The next step will basically require a complete kernel rewrite. At the moment, the sprite repositioning happens on fixed screen lines. However, this will need to change to a system with dynamic repositioning if the aliens are going to move smoothly. At the same time, I also want to incorporate Manuel's excellent flickersort routine to allow more than one alien to be shown on the same screen lines (with flickering). Finally, I need to include the missiles for the aliens shots, and there isn't time in the current kernel. It is going to be tough to do all this and still keep the 1LK! The current plan for the game sprites is as follows:Player 0 - Ship & Laser BeamPlayer 1 - Aliens (Flickered)Missile 0 - Alien Bullet 0Missile 1 - Alien Bullet 1Ball - Alien Bullet 2PF Background = Moving LinesEDIT: As noted in the comments, I have got a bit stuck with the PoP sprites as the artist seems to have disappeared. I will be very grateful for any help with this, as the game will not progress further otherwise. So far, I only have the following walking sequence:EDIT2: Nathan produced a cool logo for Juno First. It looks best using the Phosphorescent option in z26 or Stella: pescoman_v96.zipChris

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

I often seem to have the following motivation problem: whatever task Iam supposed to be working on is the thing that I least want to do,while the thing that I can't work on is the thing that I most want todo! This seems to hold regardless of the tasks that are involved. Iseem to be constantly forcing myself to get on with the essentialtasks, while my mind is pulling me towards the less important tasks.I suppose this is just a corollary to the "shiny object syndrome" thatI described in my blog some time ago!At the moment I am supposed to be writing a textbook (nothing to dowith the Atari), and the publishing deadline is fast approaching.However, what I really want to do is some more 2600 programming. Thishas been exacerbated by watching the rapid progress that others aremaking on their 2600 projects, such as Reindeer Rescue, Strat-O-Gems,and Colony 7. Fortunately, the holiday season has come to my rescueand I have a few days when I don't need to feel guilty about avoidingwork. As a result, I have managed to make some progress on one of theideas that has been distracting me for several weeks, while pretendingto visit my parents In a previous entry, I mentioned that I had already started to thinkabout the 2006 minigame competition. There is a rumour that thecompetition will start in January, and I want to be ready. The gamethat I have been thinking of developing is a version of the classicpuzzle game PipeMania. I think some versions are called PipeDream,but this was later changed to avoid possible drug connotations (Icould be wrong about this?). Anyway, the game was released on avariety of different platforms and was very popular at the time, butseems to have been largely forgotten these days. The version that Iremember most was for the Atari ST. The game-play is somewhat similarto Tetris, although the configuration is rather different.If you are not familiar with the game, then it basically works asfollows. This description is from memory as I haven't managed todownload the game yet or find a version on eBay, so please correct meif I have got any of the details wrong. The game is played on a 10x7grid. Each square can contain a segment of pipe, and one square isdesignated as the "start" square. The idea is to construct a pipelinefrom the start square and make it as long as possible within a timelimit. The pipe pieces are chosen in a random sequence, and you canonly place the piece at the front of this sequence on the grid. It ispossible to replace a piece that has already been placed, but thistakes more time. Once the time limit has run out, the pipeline startsto fill with liquid, beginning from the "start" square. The liquidflows slowly, and you can still place pipe pieces while the liquid isflowing. A second time limit determines how long the liquid flowsfor. If the liquid spills out of the end of the pipeline then thegame is lost. As the game progresses, the initial time limitdecreases, the second time limit increases, and the liquid flows everfaster. Eventually you end up slapping pieces down on the grid madlyin a futile attempt to contain the liquid!Although the basic game mechanics are very straightforward, the gameis difficult to implement on the Atari 2600. As ever, the big problemis with the screen display, i.e. the kernel. I have been giving thissome thought for a while, and I think I have a solution. It isn'tpossible to draw a 10x7 grid using sprites without some seriousflicker (which I hate), and so this leaves the playfield. Early on, Ifigured that all of the pieces could be represented on a 3x3 grid.The screen can accommodate a 10x7 grid of pieces using just PF1 andPF2 (32 pixels width) with my favourite playfield configuration(asymmetric and reflected). However, I quicly ran into problems withthe colours, and so the design as put on hold for a whileTo represent the pipes using the PF, we require 3 colours at minimum:one colour for the pipe, one colour for an empty pipe, and one colourfor a full pipe. Unfortunately the Atari has only 2 colours for theplayfield: the background and the foreground, and there is not enoughtime to change these colours between pieces. To overcome thislimitation, I decided to use a technique that was suggested bysupercat for PoP. If the screen is drawn using alternate yellow andblue lines, then it is possible to generate the appearance of morecolours even though each line is still limited to two colours. Inparticular, a yellow line and blue line next to one another appearswhite. Using this technique, I have implemented a mockup kernel toshow this in action. The source code is attached, though the kernelis rather messy at present.The mockup shows an example pipeline which is partially filled withliquid. What I need to know is whether this looks convincing enough,or if I should just abandon the game now? The problem with theminigame competition is that there are many different platformsrepresented, and a lot are capable of far superior graphics, e.g. theC64. Therefore, if the graphics are confusing or unappealing then thegame will be harshly judged. Honest feedback about this will beparticularly appreciated! Also, any suggestions for improving thekernel are also welcome. The current version required a largeunrolled kernel which will be difficult to modify. Also, I haven'tfigured out how to draw the vertical grid-lines, or the cursor yet.Anyway, I hope everyone has a great holiday season, and I'm lookingforward to seeing what the homebrew community can produce in 2006.The year is a permutation of 2600, so it just has to be special :DChrisInitial Version: EDIT 1:Improved Version: Screenshot of improved version (without gridlines):EDIT2:This version switches colours on alternate frames: cdbypass.zipThe effect works best using the -f switch in z26 (Phosphorescence). There are a few minor timing glitches in this version, but I am not yet sure it is worth continuing or adopting an alternative technique?EDIT3:Slighly more polished version with some timing bugs fixed: jukebox24_20030617.zipScreenshot from this version:jaguar.zip

The start of a New Year is one of my favourite times. In Scotland, the beginning of the year (called Hogmanay) has traditionally been the most important celebration of the year. The city of Edinburgh (where I live) has a huge street party every year to celebrate Hogmanay, which involves fireworks, music, dancing, and excessive drinking! It is a time that can be appreciated by anyone, regardless of their religious beliefs or cultural calendar. From my own point of view, I like the opportunity to draw a line under the previous year and say "that last year was a bust, but this year will be much better" The month of January is named after the Roman God Janus who has two heads, one looking forward and the other looking backward. As a result, lots of people use this time to reflect on what they have done in the previous year and make plans for the future year. I intend to follow that trend here, as I notice others have done the same in their blogs. However, I will skip most of the reflection part as that is already covered by past blog entries, and outline my plans for this year from an Atari programming perspective. It is now almost exactly a year since I first found out about the Atari homebrew programming scene. As previously noted here, I happened to read about it in an issue of the Retro Gamer magazine and decided to look into it. This led to me quickly to the AtariAge website, and the 101 programming guide by Kirk Israel. After a lengthy reading process, I took my first tentative programming steps. For some reason this didn't frighten me off, and shortly after I became a regular visitor to the AA website. As they say, the rest is history...The year 2006 promises to be a good year for the 2600, and not just because the year is a permutation of the console number There are already several homebrews that will be released shortly, and clearly many more ideas in the pipeline from other developers. I am very keen to get started on more programming, but I have a number of work-related projects that must be finished first. However, this doesn't stop me from making plans in the meantime. One of the best ways that I find to beat the "shiny object syndrome" is to aim for deadlines. This forces me to stay on track and finish the project. Therefore, my future programming efforts will all be focussed on two programming contests. The first of these is the Stella Programming Contest", and the second is the 2006 minigame contest (yet to be announced). My plans for these contests are outlined below, though things are not quite going at the moment: My main project is an implementation of Prince of Persia (PoP) for the 2600. This is a Supercharger game aimed at the Stella Programming Contest. The main kernel has been designed, and I think I have solved (or can see my way to solving) most of issues concerning the game mechanics. However, the big challange remaining is simply the scale of the game. I'm not sure that it will be possible to pack even a single level into the 6K available, and actually implementing all the levels will be a huge task. There is also the issue of the large number of sprite animations which are essential to the game. Unfortunately I haven't heard from jussts in a long time, and I think that the scale of the game may also have got to him. However, at this point I am still cautiously optimistic that something good can be produced in time for the deadline, even if it is not the full game. I have also been giving some thought to the Minigame Contest as the deadline for this will presumably be some time after the Stella Contest. Currently I have four possibilities, though I am not sure which (if any) I will take further: Pipemania - I discussed this at length in the previous entry. However, I have now essentially decided not to go further with this. I don't think the screen looks good enough without some major kernel surgery, and I don't think the game is original enough in any case. I may revive this in the future as I like the game concept, but for now it is firmly on the back burner. Jetman Deluxe - The Jetman minigame that I previously wrote seems to be surprisingly popular. As a result, I am considering producing a 4K version which is more faithful to the original. My previous version was hardly pushing the Atari, so it should be possible to include a lot more variety in the gameplay. Hunchy 3 - I have recently become quite fond of the Supercharger (SC) despite its quirks. I think that I could write an improved version of Hunchy 2 for the SC as a 4K minigame. In particular, this would let you move between rooms rather than completing each screen in sequence. I would also like to be able to include multicolour sprites. The original kernel that I wrote still has scope for more interesting levels with different tilesets, but this may require more than 4K. There is nothing preventing me from using the extra 2K once the game is loaded though. Sopwith - This idea is based on a CGA PC game that I enjoyed playing a long time ago. It requires sideways scrolling, but there is not much on action screen so it might be feasible. I haven't done any work on this yet, but I like the idea. So that it how things stand for me at the moment. I doubt that I can equal my 4 game total of last year as the projects are all considerably larger this time. I don't think I will do any more 1K games for the time being as I have got used to the luxury of space. Hopefully some of the other homebrewers will fill this space. I am also looking forward to seeing what can be done with batari basic this year as things should get very interesting when the new kernels and bankswitching are in place - it might even tempt me to have a go. Anyway, I hope you all have a great 2006, and thanks for all the kind words about Hunchy 2!ChrisP.S. Retro Gamer has recently returned from the dead - horay:

It has been rather quiet for me on the Atari front lately, after all of the excitement of the show. Since I returned the other facets of life have been taking up all my time, leaving little room for anything Atari related. It is that time of year when an endless succession of parties and engagements fill up the weekends, and work becomes hectic trying to meet all of those arbritrary end-of-year deadlines. I suspect that I won't have much time now to work on PoP until the New Year, though there has been some minor progress: I have started the code cleanup in earnest, and there is a new implementation of the swords, thanks to the suggestions of several folks here. However, none of these changes are visible on-screen yet, so I will save this for another entry.The real news for me at the moment concerns programming work that I did in the past, namely my minigame competition entries. Just before the vgXpo show there was a mad scramble to release the 2005 minigame multicart containing a selection of Atari 2600 minigames from this years competition, which included three of my own games. There was some concern that the cart wouldn't be ready in time, as there were so many different people involved, and a lot of last-minute tweaks required. However, in the end the cart and manual turned out great, and I am very grateful for the hard work of everyone involved. Nonetheless, I was still eager to see the outcome of the competition itself, and after what seemed like a very long wait, the results were finally revealed yesterday.There were a large number of Atari 2600 entries (15 in total) to the competition this year, possibly inspired by Atari success in previous years. Personally, I used the competition as an opportunity to learn and develop my Atari programming skills. I was delighted to see that my first ever Atari game (Hunchy) was ranked 5th in the 1K competition! My other entires also achieved respectable rankings, despite my fears at the presence of another Hunchback-inspired competition entry! The highest-ranked 2600 entry (2nd) was Fred Quimby's "Zirconium" which he thoroughly deserves as it is a great game (and also appeared on the minigame multicart). The majority of the other 2600 entries also achieved reasonable rankings, though I personally think that Strat-O-Gems, Marble Jumper, and SDI were underrated, while AStar was possibly a little overrated. Nonetheless, it was a good showing for the Atari 2600, and a great effort from everyone involved. One of the good things about a competition such as this is that it generates feedback from outside the Atari 2600 community. I think there is sometimes a tendancy within the community to concentrate primarily on the technical aspects of game creation, as the Atari is so hard to program. Also, there is often a reluctance to critically evaluate the work of others, when it is clear how much hard work they have put into a project. However, in this competition the games are evaluated purely for "fun", and the resulting comments are often brutally honest! Based on these comments I can see that both of my Hunchy games could be improved, e.g. removing the sound effects, and tweaking the difficulty curve. I was also surprised at the positive comments about Jetman, and I am now considering an extended 4K version as a future project. On this note, my own comments do not seem to have appeared on the website yet, but I have mailed the administrator and hopefully they should appear soon. Enerything considered, I think the competition was a good motivating experience for me, and I am looking forward eagerly to next year.EDIT: My comments have now appeared on the minigame results pages.Chris

I attended my first computer show ever yesterday: the vgXpo in Philadelphia (formerly PhillyClassic). I thought I would post my impressions and experiences here just in case anyone is interested Unfortunately I didn't take a camera to the show, but hopefully there will be some pictures by other AA member soon.I have been visiting the AA site for a bit over a year now, since I first got into the Atari 2600 homebrew scene. During that time I have read about various computer shows in the USA on the site, and they always seemed like fun. However, I didn't expect to be able to attend myself, as it would be very expensive to come over from the UK. Of course, there are computer shows in the UK and Europe that I could attend, but there wouldn't be an AA booth or contingent of AA members. Anyway, by a happy coincidence it turned out that I would be visiting Washington DC for work in the week before the vgXpo this year. By using some of my holiday time, I was able to extend my stay in the USA by a week so that I could attend the show, while my work paid the cost of the flight and some of the hotel bills! The additional motivation for me was that two carts containing my games (Hunchy 2 and the Minigame Multicart) were being released at the show.Getting to the show itself was a bit of an adventure. The trouble that I always have when visiting the USA is that it is difficult to get around by public transport. I have never learned to drive, and I don't find this a problem in the UK (or Europe) as the public transport is excellent. However, the USA is the land of the automobile, and this makes it difficult for me to venture outside of the city centers. To get to the show, I had to travel from Washington DC to Fort Washington in Philadelphia and back again in one day, as I was flying out the next morning. Fortunately there was an Amtrak train service from Washington to Philadelphia which took about 2 hours. However, things were not so straightforward after that. There is a regional rail system in Philadlephia that runs from the main train station to Fort Washinton, but it only runs once an hour at the weekend, and there were severe delays for some unspecified reason. I eventually reached the Fort Washington station, where I was hoping to take a bus or taxi to the show, but it turned out that the station was in the middle of nowhere and the bus service did not run at weekends! As a result, I had to hike around 2 miles to the show along the side of the road, which involved a bit of jaywalking! Fortunately I had a hard copy of the Google map, and I eventually reached the expo center! Total elapsed time was around 4 hours of travel to get there from Washington DC: I set off from DC around 6am, and arrived at the expo center around 10am. Naturally I had to do all this is reverse to get back again!The vgXpo was held in conjunction with the NBC consumer expo this year for the first time. This decision caused quite a bit of controversy on the foums, with many people and exhibitors threatening to pull out. At one point I thought I would also cancel as it looked like a train wreck, but I decided to go after Albert said he would attend with the AA stand. Also, it was going to be very expensive to change my travel arrangements at the last minute. The consumer expo part of the show was rather strange with a whole assortment of different areas, and no obvious connection between them. The various areas included a rally simulator, a battlebot contest, some college recruiters, some public talks, some competitions, a popcorn maker, several groups in fancy dress, and people attempting to sell various services and gadgets! I didn't spend much time in these parts and headed straight for the vgXpo which was located right at the back of the hall. This area was by far the busiest and got steadily more crowded thoughout the day. The consumer expo was very quiet by comparison, and in my opinion they should have kept it as just a games event. Naturally there were various NBC camera crews, and I am sure that I will now appear in the background of various TV shows!The first thing that hit me when I entered the vgXpo was the quantity of games and peripherals on offer. There were at least half a dozen stands which were stacked high with boxed consoles, and rare games. In the UK, I am continually scouring car-boot sales and charity shops, and I consider myself lucky to find a Combat cart However, there were literally thousands of Atari games for sale, and for almost every other platform (particularly the NES). I should have expected this of course, but I immediately realised that I had not done my homework properly and didn't have a clue what to buy! I am not a collector by any means, primarily because PAL region carts are essentially worthless, but there are various NTSC-only games that I would like to obtain. Unfortunately I didn't make a list beforehand, and so I ended up only buying a couple of boxed NTSC-only 7800 games that I knew I didn't have. I was also hoping to pick up some Vectrex titles, but the prices were similar to those on eBay back in the UK. I also intended to pick up an FB2 console, but nobody was selling them, though there was one on display. As a result, I spent most of my money in the AA homebrew section. It was clear that vgXpo was primarily intended as a classic gaming event, though there were some modern games games on show (which I ignored). Fortunately, despite what I had previously heard on the forums, there was a large range of classic arcade machines available, all set to free-play. I had just visited the Smithsonian a few days before, where they had a single Pac-Man arcade encased in perspex, but here you could actually playit for real, along with Space Invaders, Missile Command, Donkey Kong, Defender, Tempest, Pole Position, and all the other favourites. There was even an original Pong machine, though it didn't seem to be playable. My favourite was the Asteroids machine which I haven't seen in many years - presumably because of the special vector monitor that is required. Unfortunately I soon realised that my game playing skills had withered over time, and I sucked badly at every game that I tried I had a great nostalgic trip though, and despite the crowds it was still possible to get to play most of the machines without too much waiting.The AA stand was definitely the highlight of the show for me. It was great to finally meet Albert and the others, which I had previously only talked to on-line. The amount of effort that Albert had put in was immediately obvious, and it truly must be a labour of love for him! There were little plastic stands and printed summaries for all of the homebrew carts, and lots of leaflets and posters explaining what it was all about for the uninitiated. The quantity of homebrew titles was also surprising. I had played them all previously by emulation, but seeing several tables completely covered in homebrew titles was very impressive. The AA stand was the only one attempting to keep classic gaming alive by producing new content. - all of the others were just peddling the old stuff. There were at least a dozen machines set-up with the latest homebrew titles, and they seemed to be occupied for most of the day. It was great to finally play Boulderdash, and many people were asking to buy it (along with Man Goes Down and Reflex). I saw many kids enjoying Hunchy 2 and the minigames, which was a really great experience for me. I had to resist the urge to go up to them all and say "I wrote that", and instead I watched the enjoyment on their faces from a distance! This experience has definitely encouraged me further to produce more Atari games in the future.Unfortunately I only had four hours at the show, and it was over all too quickly! I had to leave around 2pm as it was a long journey back, and I had to go to the airport in DC. I doubt that I will be able to attend another show for a long time, but it was a great experience for me. If anyone here hasn't been to one of these shows then I would definitly recommend it. I don't really have anything to compare it with, but the vgXpo seemed like a great success to me. I hope that Albert sold a lot of games, and that next years show will have even more games on offer. As a result I have decided not to start programming for the Vectrex in the near future and to stick with the 2600. I need to start thinking about the minigame contest for next year already, as I think it will start in January, and then there is PoP to finish ...Chris

OK, I know I said that the last entry would be my last update for a while. However, I couldn't resist tweaking the PoP code just a little more before I leave! I came up with a nice way to animate the objects in the game, so this update contains flickering torches and bubbling potions. The sprites were done in a hurry and will be improved later, but you should get the idea. I have done some initial work on the spikes in this version (see screenshot): they spring up when you get near, but they don't yet drop down again unless you leave the screen. I have also started the first phase of code cleaning, and the program data is now defined in external macros. This will make it much easier to move the data around in the code. The next step is to optimise the code itself as it is getting rather tight for space now, and there is a lot of klunky code in there. On another note, I won myself a Vectrex console on eBay and it arrived today! Up until about a year ago I had never even heard of this machine. However, reading through various classic gaming sites (such as this one) I came across the name repeatedly and it became clear that this machine was held in high regard in the community. After doing some research, I was not surprised that I had never heard of it, as it was only sold for a couple of years and never really took-off in the UK. Nonetheless, it was apparent that the machine had a significant following, and an active homebrew scene, much like the 2600. The problem was that I didn't know anyone who had a Vectrex, and the prices that they fetch on eBay were rather high. But out of curiosity, I put a low bid on a boxed console a few weeks ago, and amazingly I won the auction. I wasn't holding out too much hope as the machines are rather fragile, and I had read stories on the web about broken screens and duff controllers. However, I was pleased that the machine arrived in great condition and with a perfect controller. After a few hours of play I can see why the machine generates so much enthusiasm The vector display is amazing, and is very similar to the old arcades such as Asteroids. The games also have a pure-arcade quality about them, and the sound is surprisingly good. I'm not too keen on the screen overlays, but at least they are optional. The screen flicker is much less pronounced that I was expecting, and only becomes apparent when there is lots going on. I have only got 3 games at the moment, but hopefully I will be able to obtain some more at the vgXpo. Anyway, if you haven't seen this console before, then I would definitely recommend it. I think that after I finish PoP I am going to have to have a go at homebrewing for the Vectrex!Chris

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

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

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!

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

Another quick PoP update:Following on from last time I have now managed to connect the switches and doors together. The attached demo shows the results with three switches and two doors. The upper switch opens the left door on a timer (it closes again after a delay), the lower right switch opens the right door, and the lower left switch closes the right door. There were an unbelievable number of special cases to consider, e.g. closing a door that is half open, but I think I have got them all now. The code is a bit rough in places, but this will be fixed soon. I think I have now captured all the required switch and door interactions from the original game, but let me know if you can think of any more. There probably won't be any updates for a bit as I have been putting other things on hold again to get this done! Chris

Just a quick update on my PoP project:In my last entry I outlined a complex scheme for implementing the doors and switches. After a weekend of programming I have now implemented the doors part (see attached) and it appears to work. I have also coded most of the switches part, but it isn't linked to the collision detection yet. The attached code shows two doors being animated. The cool part is that if you go off the screen to the left or right then you see the same doors moving. The next part is to link these doors up to the switches, and then we will really be getting somewhere!I am starting to get a bit concerned that the game will be too similar to the original, and this is going to cause copyright and/or licensing issues down the road. I had originally assumed that the limitations of the 2600 would result in a rather different game, but it is increasingly clear that the game is going to closely resemble the original. I am planning to change the name (to something like Sultan of Syria), but this probably won't be enough. If anyone has any suggestions of experience in this area, then I would be interested to know. I don't want to end up in a situation where the game cannot actually be released!Chris

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!

In my opinion, one of the hallmarks of a successful game design is that the player should feel fully immersed in the experience. That is, rather than the player simply feeling that they are controlling the game character remotely, they should feel as if they ARE the character itself. All of the great games that I have played have given me this feeling. For example, when playing Super Mario Bros, I soon start to feel the out-of-body effect and I become Mario himself. I stop noticing the control pad and it is as if I were in the game world itself, jumping on platforms and collecting coins. While I suspect that this doesn't happen to everyone, I believe that it is the duty of the game designer to aim to create this experience if possible.There are many factors which can spoil this feeling of total immersion. A big one is the game controls. If the controls "feel" wrong, or there is a delay in response, then the experience can easily be ruined. I have played lots of games like this, where the concept appeared great, but the controls were so poor it felt like they were coated in glue. With 3D games, the camera is often the problem. There are many games where the camera swings out of control and obscures the view at a critical point. If this happens too often, then I will usually give up in disgust. However, for me the biggest issue is with collision detection in a game, and this is the one that I focus on in this entry.In almost every game genre, an attempt is made to create a game world that has a feeling of realism, even if the rules don't match those found in the real world. In a game world, the player should die when hit by bullets, should be blocked from walking through walls, and should fall when walking on air. If these rules are broken, then the feeling of immersion is rapidly lost. These rules are largely enforced by the collision detection routines in a game. The collision detection should prevent the player performing illegal actions, but should punish the player when they have made a mistake. However, the player should never feel cheated by the collision detection. There is nothing worse than dying when the bullets clearly missed by a couple of pixels. As a result, collision detection is one of the most important parts of a game design, and getting it right is crucial.Returning to the topic of Atari 2600 programming, I think that collision detection is one of the hardest parts of game programming, after the design of the kernel. The Atari does give you some help in this area, e.g. it can tell you when two sprites have overlapped, of if the player overlaps the background. However, in many cases, such as when dealing with multiple sprite copies, then it is necessary to revert to software techniques. Creating a software routine that works properly, and does not take up too much time is often a difficult task. However, as previously discussed, a buggy collision detection routine can ruin the game - see Miner 2049er for a good example. I have been spending some time recently working on the collision detection for my PoP game. The hardware collision detection provided by the Atari is almost useless in this game as the player must be able to walk over pillars and doors (in the background), and the sprites are used for many different things, e.g potions, torches, enemy guards, and effects. Therefore, I was anticipating problems right from the start of the project. Since the PoP character will be animated in many different ways, I was originally planning to do a pixel-based collision detection scheme, where I would overlap the player with nearby game objects and do a comparison between the pixels. However, my attempts to put this into code clearly showed that this was going to be too time intensive. Therefore, I have now reverted to a region-based collision detection scheme, which I previously wrote for Hunchy 2. The idea is that the player is surrounded by a rectangular region, and this region is used for the collision calculations. This is much less time intensive that the pixel-based scheme, as you simply need to check if the regions overlap. In Hunchy 2 the region was fixed in size as the player was roughly rectangular in shape, but in PoP the region will vary in size depending on the animation frame. There will clearly be some frames where parts of the player will fall outside this rectangle, but I am hoping that this will not be too much of an issue.To illustrate the region-based collision detection in action, I have attached my latest coding attempts to this entry. This demo lets you move a rectangle around the screen, and will not permit this region to overlap the walls or floors. There are still a few bugs, e.g. you can move diagonally into the floors, but this should be easy to fix later. The routine will need to be extended when the new animations are done, and there are still the complex fight scenes to do, but this should all be possible as there is still plenty of spare time remaining in the code. I am now reasonably confident that the collision detection is going to feel realistic, and is not going to be a show-stopper in this game project.ChrisP.S. I was working on the game during a slow afternoon this week and someone (not the boss) accidentally saw the screen display in z26. Without any prompting they immediately said "Are you playing Prince of Persia?". This was encouraging for me as I think it shows that I have managed to capture the look of the original well enough to be instantly recognisable. Needless to say - I went back to my proper work after that

If you read any discussion on Atari 2600 game programming you will soon come across the term "kernel". For the uninitiated, the kernel is the part of the code responsible for getting a picture on the screen. In any game, the Atari spends around 3/4 of its time in the kernel, so getting this code right is crucial. The reason that a kernel is required is a quirk in the design of the Atari. Memory (RAM) was expensive at that time, and so the console was designed without any video memory. Your latest whizz-bang PC graphics card probably has around 128MB of video memory, but the Atari has none at all! With video memory, the picture is constructed by writing values to this memory at positions which correspond to points on the screen. On the Atari, the TV must be controlled directly, and the picture is displayed by setting various registers in real-time as the TV scans from left to right. This code must be properly synchronised with the TV, or the picture will not appear properly. However, it is not all bad news - the Atari has many features which help you write the kernel, and it is possible to get the timings right with a bit of practice. The use of a real-time kernel also means that you should not see any slowdown or jitter when there is lots happening on the screen, and if the kernel is well constructed, everything will happen at a silky-smooth 60Hz.You might be wondering why it is necessary to construct a new kernel for every game. Surely once a kernel has been written, there is no need for another? However, things are not so simple in the Atari world! The problem is that the TIA chip which controls the screen is capable of many great things, but it can only do a few of these at the same time. For example, you can have lots of sprites on the screen at once, but then you probably won't have time to draw a background. As a result, it is necessary to decide which features are required for a particular game, and write a kernel for this set. Often, it is necessary to divide the screen into different vertical regions, and write a special kernel for each of these separate regions. It is also usually the case that there is not quite enough time to do all that you want in the kernel, and so a large number of tricks must be employed to make everything work as planned. The ability to construct a good kernel separates the great Atari programmers from the rest. In the right hands, the Atari is capable of things way beyond anything the designers could have imagined! The reason for all of this talk about kernels is that I think I have now finished the main kernel for my Prince of Persia (PoP) game project. It is probably not the best kernel ever written by a long way, but it fulfills all of my personal criteria for a good Atari kernel: There are no spare cycles in the main loop, and only 14 spare cycles outside the loop. WSYNCs are only used at the beginning of the kernel, and after sprite repositioning. The rest of the kernel is synchronised entirely by cycle counting. The kernel code uses a lot of tricks and is contorted to the point of bewilderment! The code is relatively compact, and fits into 2 pages of ROM. There is no flicker, except on the sword which is used infrequently. It looks good on the screen! Following on from my last blog entry, I eventually decided to reduce the number of wasted cycles by making the floor tiles thinner, and to change the floor colours every line. I think the few spare cycles remaining are acceptable as this will allow me to make minor changes at a later point, but for now I think it is done. As usual, I have attached the latest version and the source code to this entry. It doesn't look much different, but I have included a static sword sprite just to illustrate all of the kernel features. I also managed to reduce the data required to describe each screen down to 20 bytes. The bottom of the screen is currently highlighted to show how much screen space is remaining. This space will eventually be used to display the health of the player and the guard, but this will require the design of yet another kernel!Chris

I have been dropping hints for some time about a new Supercharger project that I have been working on. However, I am now finally ready to reveal some details about this project. The main reason for the delay was that I had some difficulties getting my head around the oddities of the Supercharger. On reflection it doesn't appear too complex now, but the lack of clear documentation (now fixed thanks to Eric), and the way you have to read memory to write caused me some big headaches. I ended up rewriting the code several times over to get around the various problems I faced. The project is an attempt to produce something for the Stella Programming Contest. It is a joint project between myself and jussts, where I will take on the coding and he will produce the graphics. The project can also be seen as a continuation of this long running thread. If you haven't already guessed, the basic idea is to produce a Supercharger version of the first Prince of Persia (PoP) game. This has been one of my long-standing favourite games, and judging by the comments on the forum, many other people have fond memories of it also. Obviously, some relatively severe compromises will have to be made to produce a 2600 version, but that is what I hope to do. I can't promise to finish the project as it is clearly a very big undertaking, and my time is limited by other demands. However, I am hoping to move things forward from where the project stalled before. I think one of the main problems was that there was nobody to do the graphics, but this should not be an issue now.In my opinion, the game is ideal for a multi-load supercharger game. The multi-load feature will allow the different levels to be loaded on-demand, and the extra memory means that we will be much less restricted (over a regular 2600 version). I was originally intending to take the kernel that Thomas Jentzsch wrote and modify it for the Supercharger. However, I eventually rewote the kernel from scratch as too many things had changed. I also devised a new way of representing the screens which is very similar to the technique used in Hunchy 2 (thanks to supercat). The source code and binary should be attached to the top of this entry. The binary (pop.bin) can be run in either Stella or Z26 - I haven't tested it on a real Supercharger yet. As usual for a project at such an early stage, the source code is in a bit of a mess, and is likely to contain many bugs. I have encoded all of the screens from the first level of the game in this demo. If you walk off the edge of the screen, you will be taken to the next screen. Here are a few notes about the demo in no particular order: There are 22 screens in total, and most elements of the original game are represented (apart from the palace guards). The kernel has code for displaying the sword, but it hasn't been tested yet. Some of the prince sprites will be wider than 8 pixels. To overcome this problem, a missile sprite is drawn next to the player, which should permit a few extra pixels width. However, this is also not used in the current version. There are still some spare cycles in the kernel. I would like to put a missile sprite next to the P1 sprite, but I haven't managed this yet. The texture on the walls is generated by using a bit of self-modifying code. Looking at the kernel now, it might have been possible to do this another way, but it is a Supercharger project! Anyway, I how that you enjoy the demo! There is still a great deal of work to do, but I have to start somewhere. Any suggestions for improvements and feedback will be most welcome.Chris

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