SpiceWare's Blog

Looks good

Do you think you'll eventually be able to have a few different robot destruction animations that the program will be able to choose from using controlled randomness so it won't always have the same pattern?

Thanks!

 

Hadn't considered multiple explosions before. What's there is just something I'd whipped up as a placeholder due to switching the explosions from using 2 sprites to using a single 2X sized sprite

 

If I leave it with 4 frames, and set up 2 different images of each frame, I should be able to randomly pick a frame which would result in 16 possible explosion sequences.

New ROM and source added with revised explosion routines. For testing purposes I just rotated the existing graphics 180 degrees.

Is there a reason to not use that explosion Expire 8 did?

Yep - that fancy explosion espire8 did was from after I dropped the speech routines due to the drop in ARM performance caused by disabling cache (done to work around the ARM bug that kept crashing the game). Eliminating all those digitized samples freed up a bunch of space that I reallocated for graphics so we could have more elaborate animation.

 

I'm planning to add back the speech routines as I learned a number of performance improvements while working on Space Rocks and Stay Frosty 2. One example was I'd been defining C variables using RAM that was allocated in the 6507 code like this:

#define FRAME (*(volatile unsigned char *)(0x40000C00 + 0x98 ))

 

By changing it to this the code runs significantly faster (and takes less ROM to boot!)

#define FRAME (*(unsigned char *)(0x40000C00 + 0x98 ))

 

I'd defined it using volatile as the original code from batari used it (this was back in 2010 when we were designing DPC+ after my DPC experiments) so I thought it was required. While working on Stay Frosty 2 GroovyBee figured out that we didn't need it, so I did a mass find/replace to delete all occurrences of volatile. That one change freed up over 1KB of ROM.

That fancy explosion took up 26 images, each 22 bytes high (572 bytes of ROM). The explosion was 13 frames in length and drawn by placing 2 sprites next to each other for the increased width. The current explosion has 8 frames, so it only needs 176 bytes of ROM.

 

The other issue with that explosion is the programming was more complex as I'd have to search for an unused sprite for the right side (the left side used the sprite that was drawing the robot) and then update 2 sprites for the explosion sequence. Eliminating that extra complexity helps to make sure I'll have CPU time left for the speech processing. Another issue with the 2-sprite explosions was it made the flicker noticeably worse - especially during chain-explosion sequence that would take out a cluster of robots.

Thanks for explanation. 2 sprites for explosions are too much indeed.

Re: volatile

 

That is a weird behavior, I wouldn't have expected that adding the volatile keyword would've increased ROM size like that, especially since removing it didn't appear to have any effect. I wonder if this is just an issue with your particular compiler? It would be interesting to know what is going on here, since your original usage of volatile was appropriate (reading memory that could be changed outside of your code).

That's why it wasn't needed, Nothing else can change that RAM while my code is running.

 

Why it shrank ROM usage is easy, every time it was used it had to load a fresh copy from RAM, so it couldn't keep the value handy in a register.

The volatile keyword is typically used to flag variables / addresses which can be changed by something other than the CPU (i.e. shared RAM) or a variable / address where a read doesn't return the most recently written value (e.g. a memory-mapped PIA). It basically tells the compiler "you can't cache this value in a register, always read/write to RAM".

That's why it wasn't needed, Nothing else can change that RAM while my code is running.

 

Perhaps I misunderstood what you are doing here -- I thought this was a value that the 6507 code was possibly changing and you were reading it from the ARM side, which is exactly the sort of thing you need volatile for.

 

Are you sure you're not just getting lucky with the optimizer? Perhaps the loads are happening too infrequently for it to end up in a register long term and thats why you can leave it out without a problem. If this is something you read once per frame (haven't looked at the actual code in this case), you can probably get away with not having the volatile keyword.

Just like the ARM can't access the TIA chip, the 6507 can't access the ARM's RAM. To make changes in that RAM the 6507 makes a request to the ARM chip via the DPC+ registers.

 

When the ARM is emulating the DPC+ hardware, it's in a very tight loop that doesn't time for anything else. When the 6507 requests the ARM to run the game logic, it does so by writing a value to DPC+ register CALLFUNCTION. When this occurs, the ARM puts a NOP operation onto the cartridge's database, in order to idle the 6507, because the ARM can't emulation the DPC+ hardware while its running the game logic.