Odd behavior playing Stellar 7

[dhgoss]

Hi everyone,

  This is an awesome project Mark! Very nice work.  I built a couple of VGA boards for my Apple IIe and the graphics look fantastic.  I had one question though.  While playing Stellar 7 the screen blanks out between levels.  Normally, when you finish a level, a 'gate' comes down and then after the next level is loaded from the floppy the gate rises and you begin play.  When using the VGA card, the gate starts to come down and then everything is black.  The screen does not come back on again until the next level is loaded.  I tried on 2 different monitors but it does the same thing.  However, when I turn the sound off from the menu of the game, CTRL-S, the game plays normally between levels just as it would on a composite monitor.  I know very little about C programming, but I found the file that sets the pico speed and gradually raised it to 200 Mhz and recompiled each time, thinking that the Pico was lagging behind the Apple bus but that didn't change anything.  I've only tried a few games and this is the only one so far that has some glitch but wondered what could be causing the screen to blank out between levels. Any ideas anyone? Thanks!   

Dan

[markadev]

Hey Dan, I'm glad you got some boards working and thanks for reporting this! I'd have to take a deeper look but from what I saw when I tried it looks like the card thinks that text mode is supposed to be active during the gate sequence, so there's a bug somewhere in handling the mode soft-switches.

I have no idea how the sound effects could be causing this though 😂 . I'll see if I can take some time to inspect this disassembly to see if anything stands out.

[dhgoss]

Thanks Mark!Sent from my iPhoneOn Sep 7, 2023, at 8:29 PM, Mark Aikens ***@***.***> wrote: Hey Dan, I'm glad you got some boards working and thanks for reporting this! I'd have to take a deeper look but from what I saw when I tried it looks like the card thinks that text mode is supposed to be active during the gate sequence, so there's a bug somewhere in handling the mode soft-switches. I have no idea how the sound effects could be causing this though 😂 . I'll see if I can take some time to inspect this disassembly to see if anything stands out. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[markadev]

OK, this should be fixed now in the latest firmware. Try it out and let me know if it works for you too!

I'm not 100% sure why it was being triggered by Stellar 7 here but there was a regression in the way the firmware detected CPU resets, so it thought the CPU had reset and then reset all its internal soft-switches (back to text mode). I did see that Stellar 7's code was using bits of ROM data for "randomness" in the sound effects, so my best guess is that the warp sound was causing the ROM data at the reset vector to be read, which would have triggered the bug.

[dhgoss]

Thanks Mark. Works great!Sent from my iPhoneOn Sep 9, 2023, at 9:32 AM, Mark Aikens ***@***.***> wrote: OK, this should be fixed now in the latest firmware. Try it out and let me know if it works for you too! I'm not 100% sure why it was being triggered by Stellar 7 here but there was a regression in the way the firmware detected CPU resets, so it thought the CPU had reset and then reset all its internal soft-switches (back to text mode). I did see that Stellar 7's code was using bits of ROM data for "randomness" in the sound effects, so my best guess is that the warp sound was causing the ROM data at the reset vector to be read, which would have triggered the bug. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[xotmatrix]

I follow this project but I'm not greatly familiar with how it works. However, I do have a suggestion for more robust reset detection. The Apple //e MMU doesn't have a reset pin, which means it also has to do some careful monitoring to detect a system reset. What it does is look for three consecutive accesses to page one (the stack) followed by $FFFC on the address bus. This means the MMU can be deliberately fooled but it's very reliable in general.

// MMU reset if three Page 1       UtAIIe, fg. 5-13a
// accesses are followed by                pg. 5-29
// $FFFC on the address bus.
//
// This is to detect a physical system RESET' because
// the MMU doesn't have a dedicated pin for it. When
// the CPU is reset, it performs three pseudo stack
// operations (three pushes without R/W' being low)
// and then a JMP ($FFFC) jump through the reset vector.
//
// This means a MMU reset could be falsely triggered.
//
//    ; TRIGGER MMU RESET (must run on page 1)
//    ; CONFIRMED Proof of Concept: 2022/03/29
//    ; Ian Brumby: "Doesn't work on the IIGS."
//    *100: 2C FC FF   ; BIT $FFFC
//    *103: 60         ; RTS
//    *C007: 0         ; Enable Internal ROM
//    *C800L           ; Confirm Enabled
//    *100G            ; Trigger Reset
//    *C800L           ; Confirm Disabled

See Understanding the Apple IIe fig. 5-13a, pg. 5-29

[markadev]

Oh interesting... I didn't realize one of the IIe chips had to do the same sort of reset detection. Compatibility would definitely be better by using the same algorithm. Thanks for the tip!