cd-w

In that case it wouldn't work without scrolling - Chetiry is already pushing the vertical limits. I like the idea of extra levels that take advantage of the scrolling. Perhaps you could extend the climbing sequence at the end of each level also? Will your engine be able to display the sloped girders in the first level? Chris

Very impressive work, but I wish it didn't scroll. There are two tricks I used in Chetiry that may help: By changing NUSIZ mid-line you can display more score digits, as described here. This would let you put the score, bonus, and level on 1 line. You can display more than 192 lines by using the overscan region - Chetiry uses way more (around 220 I think) and I haven't had any complaints yet about the screen being cut off. Chris

Nice work - you have produced a very neat little game. Have you any plans for a) an expanded version b) a cart release in the AA store? Chris

It has been a few years since this thread was updated, but 2012 was another good year for 2600 homebrew releases. The quantity may not be as high as in 2005, but the quality of releases gets better every year: Boulderdash Star Castle (Kickstarter version) Pacman 4K Chetiry Epic Adventure Also, I believe the following are close to a releasable state: Space Rocks Frantic Panky the Panda Omicron DOT 21 Blue Star Castle Arcade Blinky Goes Up Lunokhod 1 Chun Li Apologies if I've missed anything from the list - there are probably some bbasic releases that I haven't seen as I don't follow that forum closely. I'm really hoping the following will also see a release eventually: DK VCS Ballblazer Super Mario Clone World

I think it is sometimes best to keep a bit of distance between your hobby and your career. Having to work 9 to 5 on something can really suck the life out of it, and having management dictate the direction of something that you really care about can be soul destroying. I worked as a programmer in the games industry for a short time and didn't enjoy it. I now work as a web developer and program games in my spare time, which works much better for me. Chris

Very impressive work! I hope you make this into a full game - you clearly have quite a talent for 2600 coding! Chris

Rom Hunters collection is the definitive source for the original titles - they are all marked as NTSC or PAL Chris

The latest version can be found here: http://www.atariage.com/forums/blog/144/entry-9545-star-castle-developments/ Chris

It is a nice idea, but it would be rather complex using this approach. Chris

Here are some technical details about the high-score table saving: The high score table in Chetiry is loaded and saved to an EEPROM chip inside the Melody cartridge. The SaveKey is also EEPROM based, so basically the EEPROM is just like an internal Savekey. The normal Melody cartridge doesn't have an EEPROM, so Batari assembled some boards especially for Chetiry (the EEPROM is present in the Harmony cart). The ERRPOM doesn't require a battery and is good for hundreds of thousands of write cycles. The Melody cart has 32K flash memory which is used to store the game binary. In Star Castle the high score table is stored to this flash memory, so that a separate EEPROM is not required. However, Chetiry requires the full 32K for the game - it also uses the EEPROM to store the game tunes, which take up another 32K. From a programming perspective, the high score table feature is implemented using SARA superchip memory with a special hotspot to save/load the memory to the EEPROM chip. This approach is much simpler than the I2C protocol used by the Savekey and Atarivox. You simply hit the hotspot to load the high score table into memory, then manipulate the table, then hit the hotspot to save it out again. The superchip memory is required because the Melody cart doesn't have direct access to the RIOT memory inside the Atari. To hack existing games to use the high score: The game would need to be modified to leave space for the superchip memory - this takes up 256 bytes in each bank. The end of game would need to be hooked to load the high score table, update it, write it out again, and display it. The code for this would add around 4K to the game, i.e. an extra bank. This approach is not directly compatible with the Harmony cartridge. However, the Harmony cart does have some spare EEPROM space. In theory each game could use a different area of the Harmony EEPROM, so that muleiple high score table could be saved. Chris

The tune was composed by Erik Ehrling. His username is moderntimes99, but he hasn't been on the site for a long time. It is actually based on the tune from the C64 game Silkworm. Chris

There is no definitive collection of hacks and homebrews, but see the following threads: http://www.atariage.com/forums/topic/203218-all-atari-2600-hacks-as-of-september-2012/ http://www.atariage.com/forums/topic/144662-atari-2600-hacks-and-homebrews-rom-collection-v1-2/ Chris

Thanks for the review. The rocket scene at the end comes from the Gameboy version, e.g: http://www.youtube.com/watch?v=a-NgyryrB2U

There are 3 surprises: Small rocket at 100000 Large rocket at 200000 ??? at 500000 Chris

Ah - I see the Space Rocks label contest thread now. I hope you get some good entries (although Nathan will probably win as usual )

There is a demo version available here: http://www.atariage....y-8063-chetiry/ The demo version have a gameboy-style theme, but it is essentially the same game. Chris

Are you aiming for a release at the Houston Arcade Expo? That doesn't leave much time to get things ready Chris

The gameboy colored version was only released as a demo. Unfortunately there wasn't enough space to include it as an extra in the release version. There is indeed still a gameboy style ending in the game though ... Chris

Those mockups look very impressive - I'll look at implementing them after PoP and Project Bruce I haven't played 2600 Turbo yet (no PAL version) so I'm unclear how the corner works. Does it go from a straight road to a curve immediately or are there various intermediate stages of curvature? Chris

So there is a label already?! Chris

Very nice work - I think it is now done! Using the ARM in this way is very interesting - it makes some things easier, but you still have to worry about every byte and cycle just as with normal Atari 2600 programming. I always find the game logic to be a pain to program in 6502, so it is cool to be able to do that in C, while still doing the tricky kernel programming in 6502.

The heartbeat sound perfect to me now. Chris

In the arcade game, the heartbeat speed depends (I think) on the number of remaining asteroids, so it gets faster in every wave, not just depending on your total score: http://www.youtube.com/watch?v=WYSupJ5r2zo Chris

I noticed this code: STA WSYNC ; draw spacing / move STA HMOVE STA WSYNC STA HMOVE This will cause the sprites to be moved twice, e.g. if HMP0 is set to move +2 pixels, then it will be moved +4 pixels by this code. Chris

The game looks and sounds great. I think the heartbeat sound could be more noticeably faster towards the end of each wave, but otherwise I think the sounds are perfect. There is a possible bug with killer satellite. In one game the left half was missing entirely as it moved around the screen (before it had been shot). In another game there seemed to be a column of pixels missing from the right half of the satellite, so that there was a noticeable gap between the halves. In both cases the satellite appeared on the left of the screen moving right. Unfortunately I couldn't find the pause button quickly enough to take a screenshot. Chris