Oh yeah! I caught on to changing speed with L/R, although admittedly I completely forgot to look at the controls on the actual game submission page and instead just simply went impromptu. Also, as far as the solar panels go, I'd have to figure out how exactly to figure out how well they charge, since I know I can upgrade them in theory... and my method of waiting for them to charge the slow way to deal with a dead battery ran into a problem when the dialogue kept coming up (leaving me to auto-fire the B button) before ultimately deciding to abort anyways, partially because I didn't know how quickly it would actually charge... and partially because if I were constantly under attack, it wouldn't work too well anyways depending on the charging rate.
KungFuFurby
Recent community posts
Surprisingly I haven't run into the boss yet. I'm just mostly doing exploring and crystal collecting. And yes, I know of the lots of enemies on screen case: surprisingly, I have decided to decline to attack any of them and instead just tank and/or avoid the hits. It also means I find the shields to be practical for this scenario.
If you don't want to deal with a missed VBLANK, then I recommend the scanline check approach to avoid that edge case. Either that, or both the SPC700 and SNES-side programming need to be modified to avoid that entirely.
I'll join in on the discussion. Khaz is explaining a crash that occurs due to a fault in SNESGSS's communication protocol (Yes, I know what sound driver this game uses. I've known it for many years.): namely, it sends out the last command ID ran to $2140/$F4. However, it then clears the latches some time afterwards, which zeroes out both sides. The SNES can miss the read (with VBLANK being a plausible cause), thus causing an infinite loop. (We were discussing this on the SNES Development Server Discord, actually.)
There are a couple of solutions running through my head per our discussion: the first is to disable vblanks (or other interruptions) entirely while a command is being sent through. The second is to keep track of what vertical scanline you're on (the value to check will be NTSC/PAL dependent, and I see you're targeting NTSC) and wait for vblank if the vertical scanline count is too high, then run the code in question that communicates with the SPC700.