I'm going to be taking a break from Atari 2600 homebrewing for a while due to real-life considerations. I will still be lurking around the forums, but I won't have any time for coding for some time. Fortunately the various projects that I have been involved in are in good hands:
Chetiry will be released at the PRGE later this month and will be available in the AA store shortly after.
Star Castle is being partially rewritten by Thomas Jentzsch - he has made excellent progress and should
There has been a lot of buzz recently about Scotts Star Castle kickstarter (just a few days remaining to grab a copy). It has prompted some people to speculate about this effort, so I thought I would post an update of where things are.
This project is still very much alive, and the plan is to eventually release it through the AtariAge store. The main development is that Thomas Jentzsch (Thrust+, Boulderdash) is now involved, and the coding will now be a joint effort between him and myself.
Star Castle is basically feature complete now, so here is the first release candidate for testing.
Please note that you must upgrade to the latest Stella 3.6.1
The main changes this time are:
New sound effects by LS_Dracon
Title screen music by Kulor
High score table (will only work on Harmony cart)
Improved collision detection
Different ring colours on each wave
During the game, the following can be changed:
Pressing SELECT will skip to the next wave (this is for te
Here is another Star Castle update. The game is now playable, although more tuning is required and there are some rough edges.
There are too many changes to list, but some of the highlights:
32 waves of increasing difficulty
More awesome graphics by Nathan - especially the title screen and ring explosion!
Mines can now detach and reattach to the rings as in the arcade
NTSC, PAL60 and B&W colours (press SELECT on the title screen)
As before, you need Stella 3.5.5 or above
Here is a quick update on my Atari 2600 Star Castle port:
Awesome new sprites supplied by Nathan
Basic sound effects - will improve in future versions
Stars in the background
2 bullets on-screen
Ring segments turn to dots after 1 hit (disable using Left difficulty switch)
Bullets wrap around the screen edges
This version uses a new bankswitching type, so you will need to upgrade to Stella 3.5.5 to make it work. It doesn't work on the Harmony cart yet - but it will soon.
Here is another minor update to Star Castle:
The rings can now move at variable speeds - I have slowed them down a bit in this version.
The ring segment now disappear immediately when they are hit.
The rings will regenerate when the outer ring is removed.
The gun will fire projectiles at you when the inner ring is breached.
The big question now is how closely the 2600 version should match the arcade version. There are two sticking points, where I think it might be better to devia
After much head-scratching and code optimisation, I finally have collision detection working! In this version you can shoot the ring segments. For now they only take one hit, but this can easily be changed.
I think I now have all of the pieces necessary to make the game. However, I now need to put it all together and rewrite significant parts of it, such as the kernel. The main issue now is running out of ROM space as all the unrolled code has nearly used up the full 12KB.
Here is another small update to my Star Castle demo on the 2600:
The mines now follow you around the screen. They will reset to the centre if they go off screen.
You can shoot the mines, and collisions between the ship and mines are detected (the screen will flash).
Ship rotation is now much slower.
There are still a few issues with the ship and mines at the edges of the screen, but I'll fix these later. The mines are flickered at 20Hz so that 3 can be displayed. The flicker would
I have made a little more progress on my 2600 Star Castle demo:
Ship rotation is slower.
Ring colours now match the arcade version.
Player bounces off the rings.
Centre gun tracks the player position.
The main issue now is collision detection between the bullets and the rings. I haven't yet worked out an efficient way to detect when a ring sector is hit by a bullet, and the code is starting to get tight for cycles.
Let me know what you think?
I have made a little more progress on my Star Castle demo. You can now move the ship around the screen and fire bullets, although there is no collision detection yet. The controls are:
Joystick Left/Right - Rotate
Joystick Up - Thrust
Fire - Fire Bullets
I have been trying to match the ship movement with the arcade version (by comparing with the MAME version). I think it is now reasonably close, but let me know if you think it needs improvement?
The ship sprite is tempora
I figured out how to make my Star Castle kernel display in colour. I think this looks much better than the monochrome version posted in my previous blog entry.
The technique was inspired by supercats kernel, but as before I am only using a single sprite to draw the rings. This leaves the other sprite and missile/ball free.
The kernel uses a number of advanced tricks, such as updating the colour registers while the sprite is being drawn. Hopefully it will work on a real 2600 as
The recent threads on Star Castle for the Atari 2600 have been rather annoying, so I decided to see how difficult it would be to write my own version.
It turns out not to be too difficult - I was able to write a basic kernel with rotating shields in a single weekend. I just went for a simple implementation using extra RAM (FA bank-switching) instead of pre-calculating all the ring data. The advantage of this approach is that the rings can be made to spin at different speeds.
As many of you will now know, I have been working on a new Atari 2600 homebrew title called Chetiry. This blog entry should hopefully clear us some of the confusion surrounding the project!
Chetiry is a tetromino matching game that should be familiar to most gamers. The original Chetiry project (Chetiry means 4 in Russian) was started by Zach way back in 2006. However, Zach retired from Atari 2600 homebrewing in 2009 with the Chetiry project still unfinished. I had been hoping to see
The 2600 scene is still alive and well, and there are quite a few of exciting projects currently in development. I have probably forgotten some, but the ones that I am looking forward to the most are:
AtariVox+ - I think this has been delayed by the difficulty in getting hold of SpeakJet chips.
Project Unity - a nice project to build a portable 2600 with integrated Harmony cart.
Flashback 3/Portable Flashback - actually I would settle for a PAL version of the FB2!
I've been doing a bit more work on the Harmony project recently (together with batari and Thomas Jentzsch).
It was a bit of a struggle, but it actually seems to be working now - teaser shots below:
I have started to look at the Atari 2600 PoP project again now that the Harmony software is essentially done. I am making no promises on getting it finished, but I intend to do a bit more work on it to see where it goes. At the very least, I want to include the excellent sprites that LS_Dracon has produced. The first thing that I have done is to completely rewrite the kernel:
From the screen-shot, it looks almost identical to the old kernel, but there are two important differences.
Like most people on AtariAge, I have been playing computer games for a long time, since the late 1970s. However, I have always been more interested in how games work, rather than the games themselves. I tend to play each game for a short time, until I have figured out the mechanics and mastered the controls. Once I know that I can beat the game, I tend to lose interest and move on. Every now and again though, a game comes along that I really enjoy playing. These games hold my interest long after
The pre-release version of the Harmony cart is now finished and is being sold at the Portland RetroGaming Expo. I expect that the bug reports and feature requests will start arriving soon! Before they do, I though I would write a little more about how the Harmony driver software works.
The Harmony driver is written using a mix of C and ARM assembly language. The ARM assembly is used for the performance critical stuff, like feeding the Atari with instructions, while the C code is used f
A couple of entries back I was pondering which project to do next after Juno First. Since then, I have been working on the semi-secret Harmony/Melody cart project. This project is now close to completion, and so I think it is safe to write some details about it here. To keep things simple, I'll only talk about the Harmony cart. The Melody cart is the same, but without the SD card and USB options.
The Harmony cart project was started by batari around a year ago. As I understand it,
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 positi
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 t
Now that the Juno First release candidate is out, I have a bit more time to look at other 2600 programming. I have been interested in batari basic for a while as I have several game ideas that could be done with a custom kernel strapped on. However, until recently I hadn't really looked at batari basic properly.
One thing that has been bothering me is that batari basic doesn't have a way to load playfield data directly from ROM. There are several games (e.g. Cave In) that have a high r
There is a discussion currently in the homebrew forum about adding a flashing cockpit to the Juno First ship. One approach would be to use the ball sprite overlaying the player sprite. The ball sprite is used for the laser and is already correctly positioned (horizontally), but I can't find the spare cycles to enable and disable it at the correct time. The main loop where the ship is drawn is a 1LK as follows (the actual code is in kernel1.h in the zip attached to the previous entry):
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,
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.