cd-w
-
Content Count
2,433 -
Joined
-
Last visited
-
Days Won
2
Blog Comments posted by cd-w
-
-
Excellent work from Nathan as always - the game is really coming along great!
The only thing I don't like is the movement of the ship. It feels a little bit sluggish in acceleration, and the deceleration seems a little too jerky (when friction is enabled). Would it be possible to tweak this a bit to closer match the arcade version?
Chris
-
Fred helped with ARM code? Does this mean Star Castle is able to sneak in a few instructions off onto the ARM or just support for a funky bank-switching/cart type?
The ARM code is just for the bank-switching and high score loading and saving. The game is pure 6502.
Chris
-
Ok. That's better. Will that happen on the real hardware?
The flicker is not very noticeable on a real TV. The phosphor mode in Stella approximately simulates a TV screen. A better simulation is coming soon with the implementation of Blargg filters.
Chris
-
I really like the game Chris but could you do something about the frequency of the blinking rings? It's really is giving me a headache to watch. It's actually making me ill.
You should enable the phosphor effect in Stella (Alt + P on PC, Cmd + P on Mac).
Chris
-
This game will be a definite purchase for me. Will there be a label contest? I think a fresh perspective on the artwork would help set this one apart from the other Star Castle. Even though my entries weren't chosen, I had a lot of fun with the Boulder Dash contest and I'm itching to do more.
Also, any ideas on how to get this to work on the Cuttle Cart II? Is it a matter of copying and modifying the FA.BNK file or is it a bit more involved than that?
DaveD and Nathan are working on the label for Star Castle already. They did a great job for Juno First, and so I didn't feel that a contest was necessary. The FA.BNK file will not work for Star Castle. A new FA2.BNK scheme would need to be created, but I don't know how easy this would be, and I no longer have a CC2 to test.
Chris
-
1
-
-
Thomas is doing a great job at optimising my code, so the next version should be even closer to the arcade.
The plan is to release it as a regular home-brew title through the AA store.
Chris
-
4
-
-
I'm not sure about the ship wrapping behavior. At the moment it is possible to hide at the screen edges. In Star Castle, I draw the ship sprite twice at the top and bottom edges so that it is never completely hidden. However, in the Asteroids arcade version it looks like the ship just jumps completely when it reaches the screen edge.
Chris
-
It looks great - you must have a lot of free time at the moment!
One trick that I use in Star Castle (and Thomas used in Thrust) is to nudge the ship position as it rotates so that it moves around the centre or rotation (rather than rotating within the 8x8 grid). This makes the rotation look a bit smoother.
Chris
-
The game is stealing some of the scan-lines from the display as the ring rotation and collision detection calculations require a lot of cycles.
-
For the color changes (they've grown on me), how about a progression?It starts out Red Orange Yellow. $46, $26, $16How about next Orange Yellow Green, $26, $16, $C6Yellow Green Blue, $16, $C6, $A6Green Blue Violet $C6, $A6, $66?
OK, I've uploaded a version with these colour values to the blog posting (NTSC only for now). This version also contains a fix for the B&W mode and reverses the left difficulty switch.
Can anyone who has an NTSC TV set let me know if the darker ring colours in this version look better for them?
Many thanks,
Chris
-
However, the rings visually expanded outward so that:
- middle ring = new outer ring
- inner ring = new middle ring
- new inner ring is generated
Thanks for testing. I can't do the visual expanding effect, but the rings are copied in that order so that the inner ring is the new one.
Chris
- middle ring = new outer ring
-
Nice work - Asteroids is one of my favourite arcade games. I don't think I've seen so many independently positioned sprites on the 2600 before. The flicker really isn't too bad either. However, I do prefer the look of the vectors from the arcade version, rather than solid asteroids. Thomas managed to duplicate this look nicely in his Asteroids DC+ hack.
Chris
-
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.Thanks - I have found the cause and it will be fixed in the next release. There is also a problem with the B&W mode (invisible outer ring) that will be fixed next time.
Chris
-
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).Hmm, I normally think of the difficulty settings as A = Advanced while B = Beginner. Wouldn't a 1 hit ring segment be beginner?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.
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.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 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
-
Maybe we should open a dedicated thread for this discussion. Because I will continue throwing questions and ideas to you now!
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
-
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
-
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
- The flash memory has a limited number of erase cycles (100,000 I believe).
-
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
-
How is this coming along? I just rememberd this project today.
As Nathan said, it is all done and ready for release. Just waiting for BD to get out of the door first.
Thanks,
Chris
-
1
-
-
It wouldn't work on my machine - just sat there at "Get Ready" and if I hit reset it just sat at "Paused"
This happens if you are using an old version of Stella. You will need to upgrade to the latest version.
Chris
-
Sounds nasty - glad you are doing OK now.
-
Sounds good - I'm looking forward to seeing this completed. There have been far too many homebrew 7800 titles recently - we need to get the 2600 homebrew releases back on track
Chris
-
Nice work as always. The 7800 scene has really come alive these days!
Chris
-
I don't know much about ADPCM, but compressing the speech down so much sounds impressive. If it works out, I'll be tempted to use speech in my own games
How much space is remaining now? It doesn't look like there is too much left to do, other than the title screen and a bit of polishing?
Chris
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
polished large rocks
in SpiceWare's Blog
A blog by SpiceWare
Posted
Very nice - I haven't played this for a few weeks. The ship movement is much better now. I think the acceleration could be very slightly faster, but otherwise it feels spot on. Is there much left to do now?
Chris