I called it "Radio Mode" because it had the nifty effect of freezing everything except the music. Even the stepcounter didn't run. The randomizer kept running because it's handled by interrupts. It finally bugged me that I was calling it "Radio Mode", so I decided to play with it.
I discovered its effect by locking it at #01. It never occurred to me to lock it at #00. At first, it seemed to be a pointless variable, maybe used for debugging.
I was looking at the overall code structure of CV3 and noticed "Radio Mode" was always getting whenever the PPU needed to be updated. And yet, it was always cleared before moving on to the gameplay logic. It clearly had something to do with PPU logic.
I had the bright idea (self-deprecating sarcasm here) to see if the variable was ever actually still set when read. I theorized the behavioral code for all the floating spores in the Forest stage, coupled with the parallax scrolling clouds in the background, might be too much for the CPU. I locked the variable at #00, then within seconds, the status bar glitched. Almost immediately, the entire game freaked out. I killed it! I looked at the RAM and saw the audio data freaking out.
I had successfully caused a stack overflow. Byte $001C thus prevents stack overflows by skipping gameplay logic if the Pre-Draw phase takes too long. I still like the idea of the game having a "radio mode" for the devs to just pause the game on their favorite song, though.