The reposition routines have now been rewritten to support updating the missiles. The 2 missiles are flickered at 30 Hz to provide a maximum of 4 shots in flight.

I've also added test routines to move the 4 shots around the screen. 1 shot will be used for the humanoid, up to 3 for the robots. The shots can be displayed in 1 of 3 shapes: horizontal, vertical and small square. The small square will be used for a new robot-smart-missile feature I'm planning to add to compensate for fewer shots on-screen. The smart-missile will have the ability to redirect itself 1 time in flight.

There was a small tradeoff - repositions of Player 0 don't update AUDV0 (for digital sample playback) during the 2 scan lines that it takes to reposition the sprite. Player 1 takes 3 scan lines, so I was able to update AUDV0 in those routines. I planned to rewrite Player 0 routines to take 3 scan lines if needed, but the sample playback sounds fine to me.

batari found something on the errata sheet for the ARM chip. The problem occurs when the MAM (cache) is used and is dependent on the code and it's alignment in memory. If we disable MAM the crashing stops, but at the cost of decreased performance (plus it stops working on my 7800). The crash can also be made to stop by rearranging code in the hopes that the new layout causes the alignment to change. It's not a fun work around, but it is doable.

We're hoping to get more information on this bug (the errata doesn't specify what instructions/alignment cause the problem). If so we could have something parse the ARM compiler's output, or modify Stella to detect it, so that we can get information on where the crash will occur to make it easier to work around the ARM bug.

ROM

frantic_harmony20110809.bin

Source

Frantic20110809.zip