Jump to content





Star Castle RC1

Posted by cd-w, 12 April 2012 · 3,775 views

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

Attached Image

Please note that you must upgrade to the latest Stella 3.6.1

The main changes this time are:
  • New sound effects by LS_Dracon
  • Title screen music by Kulor
  • High score table (will only work on Harmony cart)
  • Improved collision detection
  • Different ring colours on each wave
During the game, the following can be changed:
  • Pressing SELECT will skip to the next wave (this is for testing and will be removed in the final version).
  • Setting the LEFT DIFFICULTY to A will cause the ring segments to be destroyed with 1 hit (instead of 2).
  • Setting the RIGHT DIFFICULTY to A will cause the ship to be destroyed by the rings (instead of bouncing off).
I'm still trying to figure out the Harmony CU bankswitching format - I'll post up a Harmony version once this is done.

Please let me know if anything is broken, buggy, or just plain annoying!

Thanks,
Chris

Attached File  starRC1.bin (28KB)
downloads: 420
Attached File  starRC1_src.zip (69.51KB)
downloads: 214

EDIT: Harmony version now available. Make sure that you have BIOS 1.05 on your Harmony cart, then unzip and drop the starRC1.cu file onto your SD card. Note that the high score table is not stored to flash in this version, so it will be deleted when you switch off your Atari.

Attached File  starRC1_harmony.zip (13.87KB)
downloads: 226

EDIT2: Alternative ring colours version: Attached File  star_altcols.zip (27.34KB)
downloads: 179




Nice to see full Harmony Cartridge support.
  • Report

Nice to see full Harmony Cartridge support.


The final version will actually save the high scores to the Flash memory of the Melody cart. I've got this tested and working on my Harmony cart, but I don't want to post it here yet as it completely replaces the Harmony firmware (which can be restored by reflashing the BIOS).

Chris
  • Report

High score table (will only work on Harmony cart)

What are the limitations here? How much space in total is available?

This would open a ton of options (e.g. dump and later reload RAM and registers)!
  • Report

What are the limitations here? How much space in total is available? This would open a ton of options (e.g. dump and later reload RAM and registers)!


I'm using a modified version of the CBS RAM+ (FA) bank switching. The normal FA scheme gives 12KB ROM and 256 bytes RAM. I've extended this in FA2 to give 28KB of ROM (hotspots $1FF5 through $1FFB) and added a facility to store and restore the 256 bytes of RAM to the Harmony Flash memory using a hotspot at $1FF4. Stella 3.6.1 supports the extra FA2 ROM, but doesn't (yet) support saving and loading of the 256 bytes of RAM.

There are some limitations with writing to the Harmony flash memory:
  • The flash memory has a limited number of erase cycles (100,000 I believe).
  • The flash memory takes a second or two to erase and write, so the Atari must be stalled during writes (by executing a code loop in RIOT RAM).
  • The flash memory can only be erased in 4KB chunks, so I'm erasing 4KB every time even though I only use 256 bytes.
  • Harmony does not have access to RIOT RAM and registers, so these would need to be stored/restored from the 256 byte RAM area.
This facility could certainly be used for more than just the high score table.

Chris
  • Report
Crap! I thought I had the latest version of Stella, but it looks like I'm 2 billion versions behind already. I'll try your game tonight. Thanks.
  • Report
I am looking forward to trying this on hardare! Very impressive.
  • Report

Stella 3.6.1 supports the extra FA2 ROM, but doesn't (yet) support saving and loading of the 256 bytes of RAM.


I look forward to adding this functionality to Stella at some point, so it can more properly emulate the full functionality of a Melody/Harmony cart. Of course, if someone can point to documentation on how you actually do this in hardware, then it will make things much easier on my end.
  • Report

The flash memory takes a second or two to erase and write, so the Atari must be stalled during writes (by executing a code loop in RIOT RAM).

So the write is initiated by the game itself, right?

The flash memory can only be erased in 4KB chunks, so I'm erasing 4KB every time even though I only use 256 bytes.

Bummer! So you have no ability to define slots which could be assigned to different games. :(
Hm... How about games storing the 4K in their own RAM (or ROM?) and overwriting the whole 4K themselves? Or some more logic to Harmony to handle that?

Harmony does not have access to RIOT RAM and registers, so these would need to be stored/restored from the 256 byte RAM area.

If you could store a defined "restart" vector, games could handle that easily.

This facility could certainly be used for more than just the high score table.

Definitely.
  • Report

So the write is initiated by the game itself, right?

Yes, the load/save operation is initiated by polling hotspot location $1FF4. The Harmony will return 1 (in bit 6 of this location) while it is busy and 0 when the operation has completed.

Bummer! So you have no ability to define slots which could be assigned to different games. :(Hm... How about games storing the 4K in their own RAM (or ROM?) and overwriting the whole 4K themselves? Or some more logic to Harmony to handle that?

I wrote this feature assuming that the game would have the whole Melody cart to itself. On the Harmony cart, the flash memory is overwritten when the next game is loaded. If you want data to persist, it would need to be stored in the Harmony EEPROM, which is a different kind of flash memory (and is not normally present on the Melody).

Chris
  • Report
So can this be burned onto a cartridge? I've never seen a 28k VCS game before. Excuse my stupidity, but why not just go for a 32k game? Anyway, I love the intro music! Any chance for sheet music or musical notes or something, as I'd like to make a MIDI of this.
  • Report
Maybe we should open a dedicated thread for this discussion. Because I will continue throwing questions and ideas to you now! :D

I couldn't find it in the code, so I figure that currently you game somehow (accessing a hotspot?) triggers to store the 256 bytes into the upper 4K of the flash RAM. And it can also somehow (accessing another hotspot?) trigger to load it again. How about giving the Harmony more information? E.g. store from (address, bank) n bytes to (address in 4K flash). The changed 4K would have to be merged with the existing 4k (no idea how yet).

As long as the game you load is not larger than 28k, the storage area should be safe, no?
  • Report

Excuse my stupidity, but why not just go for a 32k game?

There's only 32K of flash memory. 4K is used for the high score table(because of that 4K erase limitation) leaving 28K for the game.
  • Report
I now have preliminary code in Stella to handle load/save of the 256 bytes of RAM (to a file, which emulates saving to the Harmony flash). Internally in Stella, this is exactly the same as doing a state load/save, so you're free to expand it to include other stuff in the 4K space you have available. I should be able to emulate that pretty easily too.
  • Report

Maybe we should open a dedicated thread for this discussion. Because I will continue throwing questions and ideas to you now! :D

Feel free to start a new thread to discuss this!

I couldn't find it in the code, so I figure that currently you game somehow (accessing a hotspot?) triggers to store the 256 bytes into the upper 4K of the flash RAM. And it can also somehow (accessing another hotspot?) trigger to load it again.

Have a look in bank6.asm at the DoOperation and DoStall subroutines. The operation type (1 = load, 2 = store) is stored into the final location of RAM+ memory, and address $1FF4 is accessed to tell the Harmony to perform the operation.

How about giving the Harmony more information? E.g. store from (address, bank) n bytes to (address in 4K flash). The changed 4K would have to be merged with the existing 4k (no idea how yet). As long as the game you load is not larger than 28k, the storage area should be safe, no?

The problem is that the game will become corrupt if someone switches off the Atari during erasing or writing. On the Harmony this approach is actually used, but it isn't an issue because the BIOS can be reflashed if anything goes wrong. On Melody this isn't really an option (Albert would kill me if people kept returning their corrupted games to the store!).

EDIT: I didn't read your reply properly. I guess you are proposing multiple 256 byte save areas within the 4K? Data corruption could still be an issue, but as long as nothing vital is stored there it would be doable. The entire 4K would be read into RAM, the 256 bytes updated, and then the entire 4K programmed again. The upper 4 bits of the operation could be used to indicate the address within the 4K, i.e. operation = XXXX000Y (XXXX = address, Y = read/write). That would be completely compatible with the current scheme.

One further issue that I haven't yet mentioned is that the ARM code for bankswitching also needs to be stored in the 32K flash memory. For that, I'm stuffing the ARM code into the 512 bytes that must be kept clear at the beginning of each bank (it currently takes three 512 byte areas).

Chris
  • Report

I guess you are proposing multiple 256 byte save areas within the 4K?

Any size actually. For saving a single high score you only need ~3 bytes. This could work as an replacement for the SaveKey, which not many people have and is not available (anymore?).

For that, I'm stuffing the ARM code into the 512 bytes that must be kept clear at the beginning of each bank (it currently takes three 512 byte areas).

So still more than half of the available space left. Right?

We would need some code (e.g. using a hash to test if anything has changed in the 4K before rewriting it) which prevents killing the flash memory due to programming errors.
  • Report
I'd suggest that for "Setting the LEFT DIFFICULTY to A will cause the ring segments to be destroyed with 1 hit (instead of 2)" that this would also limit you to one shot on screen at a time, to help keep the difficulty from getting too easy.

Noticed a bug - if you and the enemy ship shoot each other simultaneously and you keep firing, after you die your shots will appear out of nowhere and travel up the screen.
  • Report
Hmm, I normally think of the difficulty settings as A = Advanced while B = Beginner. Wouldn't a 1 hit ring segment be beginner?
  • Report
Just played a couple games on my Harmony and ran across something that seemed odd - I shot out all of the middle ring segments but it didn't regenerate until I also shot out the outer ring.
  • Report

Hmm, I normally think of the difficulty settings as A = Advanced while B = Beginner. Wouldn't a 1 hit ring segment be beginner?

That's why I suggested halving the amount you can shoot. That would make the game harder (since it will make the little sparky things hard to kill at higher levels).

Just played a couple games on my Harmony and ran across something that seemed odd - I shot out all of the middle ring segments but it didn't regenerate until I also shot out the outer ring.

I'd have to re-check MAME, but I think that's the correct behavior. It only regenerates rings when the outer one is shot away. I could be remembering it wrong though.
  • Report

Hmm, I normally think of the difficulty settings as A = Advanced while B = Beginner. Wouldn't a 1 hit ring segment be beginner?

That's why I suggested halving the amount you can shoot. That would make the game harder (since it will make the little sparky things hard to kill at higher levels).


I did it this way so that the default switch values in stella (both B) would match the arcade version. However, I agree that the left switch should be reversed. I'll make this change in the next release. I'm not sure about having jut 1 shot - it might make the game too hard and I wanted the 1 shot option to make the game easier.

Just played a couple games on my Harmony and ran across something that seemed odd - I shot out all of the middle ring segments but it didn't regenerate until I also shot out the outer ring.

I'd have to re-check MAME, but I think that's the correct behavior. It only regenerates rings when the outer one is shot away. I could be remembering it wrong though.


I believe this is the same behaviour as the arcade - only the outer ring forces a regeneration. However, I could be interpreting the behaviour wrongly.

Chris
  • Report

November 2014

S M T W T F S
      1
2345678
9101112131415
16171819202122
2324252627 28 29
30      

Recent Entries

Recent Comments

Search My Blog