Jump to content

rropuma07

New Members
  • Content Count

    5
  • Joined

  • Last visited

Community Reputation

1 Neutral

About rropuma07

  • Rank
    Combat Commando
  1. 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.
  2. 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
  3. Ah okay. It makes sense that they would allow the programmer to decide if they wanted to use the TIA instead of the MARIA. This definitely clears up all our questions about the control register. Thanks again for all the help!
  4. Thanks for the quick reply Dan! That explains a lot about what's happening in 2600 mode. I'm still not sure how the lock bit gets set in 7800 mode since the code that is executed before it jumps to the start of the cartridge is: LF7B9: LDX #$16 ; finally, back to something important STX INPTCTRL ; switch out bios and use reset vector TXS ; on cart to start the game. SED JMP(LFFFC) Unless the lock bit is set somewhere else, which wouldn't make sense because that would yield this write to the control register pointless.
  5. Hi guys, I'm new here, but my friends and I are designing a fully functioning Atari 7800 for a college class. Our design will be synthesized on an FPGA. I've looked all over the internet and can't seem to solve my confusion over the Hidden Control Register. I first learned about it on Dan B's post here https://sites.google.com/site/atari7800wiki/7800-control-register Seems pretty simple, but this explanation seems inconsistent with the BIOS code located here http://www.atarihq.com/danb/files/7800bios.asm My understanding is that anytime a value is written to INPTCTRL, it is writing to the Control register. Firstly, many times, the value #$16 is written to the control register, but I thought the control register was a four bit value. What is the purpose of writing a 5 bit value to a 4 bit register? Secondly, during execution of the code located at LF7D4 (though the code is actually executed from the RIOT RAM as part of the Atari 2600 initialization), there are stores and loads to TIA registers even though the lock bit on the control register has not been set. This isn't consistent with the idea that the control register can be written by storing to any address from $00-$1F. Lastly, the control register lock bit never really seems to be set. The only time I can find it set is at LF880, but that is when the self-test fails. I would expect the lock bit to be set in both Atari 2600 and 7800 initialization before we do an indirect jump to the start of the programmer's code. I suppose it's possible that the programmer is expected to set the lock bit, but it doesn't make much sense to require the programmer to do that. Can anybody shed some light on these questions? If not, is there anyone I might be able to contact or any other forum I might be able to post to? Cheers!
×
×
  • Create New...