JetSetIlly Posted June 18, 2021 Author Share Posted June 18, 2021 9 minutes ago, SpiceWare said: All the drivers use MAM mode 2 for driver itself for performance reasons. The driver code is running in RAM, which does not trigger the bug. Yes. 9 minutes ago, SpiceWare said: In DPC+ projects the game's code sets MAM 1 to prevent the crashing. From Stay Frosty 2: Right. This might be where my confusion has arisen. Many DPC+ARM ROMs I have seen do as you describe. However, there are some which do not. For example, the ROM I have of DK Arcade (link below) does not do this. So are we saying that this ROM may crash on the hardware if it triggers the bug? Either way, I understand now. 9 minutes ago, SpiceWare said: In BUS, CDF, and CDFJ the driver's code sets MAM to 1 before it calls main(), so main() no longer changes it. 9 minutes ago, SpiceWare said: As of CDFJ+ the driver no longer sets MAM because the bug is not a factor in the newer boards. I think, but am not sure, that @johnnywc has a one-off build of the CDFJ which does not change MAM to 1. Right. So it remains in MAM mode 2. That tallies with what I've read in the Turbo demo thread. Let me summarise my understanding: 1. The DPC+ driver does not change the MAM mode from mode 2 1a) The Thumb program must therefore change to MAM mode 1 or risk a crash 1b) The Thumb program must change back to MAM mode 2 before exit 2. The CDF and CDFJ drivers handle the MAM changes (so the Thumb program doesn't have to) 3. The CDFJ+ driver leaves MAM in mode 2 Thanks. Quote Link to comment Share on other sites More sharing options...
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.