rropuma07 Posted November 11, 2015 Share Posted November 11, 2015 Hey Guys, My friends and I are designing an Atari 7800 on an FPGA using modern digital design methods. Right now, we are not terminating the BIOS code, and we have traced it to an NMI (Display list interrupt) being raised by the MARIA while the BIOS_en bit in the Control register is set to 1 (and therefore the BIOS is disabled). This leads to the Core trying to execute the cart's DLI which naturally crashes the program because it causes the program to do an indirect jump through an uninitialized value in RAM. My question is how did the original system circumvent this problem? Looking at the design specification, I don't see anything that would cause the MARIA not to trigger an NMI while the ctrl register is unlocked and the BIOS is disabled. My theory is that the BIOS was specifically timed so that an NMI would not be raised during times when the BIOS is disabled, but that seems like a risky move in my opinion. We did find that our core was running slower than the actual system core, so it is possible that it was supposed to be done with that part of the BIOS when the NMI was triggered. Can anyone shed some light on this? Thanks! For your convenience, here are some links: Control register page: https://sites.google.com/site/atari7800wiki/7800-control-register BIOS: http://www.atarihq.com/danb/files/7800bios.asm Schematic: https://atariage.com/7800/archives/schematics_ntsc/images/Schematic_Atari7800_NTSC_2000.jpg Quote Link to comment Share on other sites More sharing options...
RevEng Posted November 12, 2015 Share Posted November 12, 2015 Yeah, there's some carefully timed code running that periodically enables and disables the cart, in time for the NMI. The RAM based bios code at $2422 uses $F0 as a counter to do so. Not sure if that's risky, so much as knowing pretty much where the cycles are going. They could have avoided it by not having an interrupt in their display, but then we wouldn't have as pretty a boot screen. You can see it all in action in the MAME debugger, if you set watchpoints for the relevant registers. Quote Link to comment Share on other sites More sharing options...
CPUWIZ Posted November 12, 2015 Share Posted November 12, 2015 I now don't even remember, but I don't think I added crap like that to my SpeedBIOS. Quote Link to comment Share on other sites More sharing options...
RevEng Posted November 12, 2015 Share Posted November 12, 2015 I didn't look that deeply at the assembly, but I believe it doesn't start the cycling between cart and bios until the signature check. Guessing that you skipped all that. Quote Link to comment Share on other sites More sharing options...
rropuma07 Posted November 13, 2015 Author Share Posted November 13, 2015 Thanks for the reply RevEng. Right now we're starting at the mem copy portion at $FB17. I figured it was a matter of timing. Our core should be cycle accurate, so hopefully the fact that we fixed our cpu speed should mean that we won't have this problem anymore. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.