Nestest and SRAM

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
Undubbed
Posts: 24
Joined: Sun Aug 09, 2009 7:46 am

Nestest and SRAM

Post by Undubbed » Sun Aug 09, 2009 7:59 am

Well, I've been trying to debug my cpu with nestest but I guess my CPU emulation is so buggy I can't even get nestest to work... So I have to keep looking in a log for what's wrong :(

Now I've kinda hit a wall and I can't find why nestest.nes tries to access the SRAM? Was I supposed to load the SRAM portion with something? Nestest tries to access $6056 which has the RTS instruction according to FCEU's log. But on my Emulator the value at that address is zero so it causes a BRK and therefore halts everything :(

FCEU's log:

Code: Select all

$AB85:60        RTS                        A:36 X:FF Y:A9 P:nVUBdIZC
$6056:60        RTS                        A:36 X:FF Y:A9 P:nVUBdIZC
$FF01:00        BRK                        A:36 X:FF Y:A9 P:nVUBdIZC
$C5F4:40        RTI                        A:36 X:FF Y:A9 P:nVUBdIZC
$FF03:63        UNDEFINED                  A:36 X:FF Y:A9 P:nVUBdIZC
$FF05:3B        UNDEFINED                  A:19 X:FF Y:A9 P:nvUBdIzC
$FF08:00        BRK                        A:19 X:FF Y:A9 P:nvUBdIzC
$C5F4:40        RTI                        A:19 X:FF Y:A9 P:nvUBdIzC 
My Log:

Code: Select all

AB85: 60 RTS 		A=37 X=FF Y=A9 P=01000101

6056: 0 BRK 		A=37 X=FF Y=A9 P=01000101

06C5: 0 BRK 		A=37 X=FF Y=A9 P=01000101

06C5: 0 BRK 		A=37 X=FF Y=A9 P=01000101

06C5: 0 BRK 		A=37 X=FF Y=A9 P=01000101

06C5: 0 BRK 		A=37 X=FF Y=A9 P=01000101

06C5: 0 BRK 		A=37 X=FF Y=A9 P=01000101

06C5: 0 BRK 		A=37 X=FF Y=A9 P=01000101

06C5: 0 BRK 		A=37 X=FF Y=A9 P=01000101

06C5: 0 BRK 		A=37 X=FF Y=A9 P=01000101
P register also seems off but that's another issue I guess :?


EDIT: Now I'm starting to think it might have something to do with the 'undefined' opcodes. I haven't really bothered to implement them yet. But I thought I wouldn't really need them?

tepples
Posts: 22361
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Nestest and SRAM

Post by tepples » Sun Aug 09, 2009 9:56 am

Undubbed wrote:Now I've kinda hit a wall and I can't find why nestest.nes tries to access the SRAM? Was I supposed to load the SRAM portion with something?
Most discrete boards, such as NROM, C*ROM, U*ROM, A*ROM, and B*ROM, don't have PRG SRAM at $6000-$7FFF unless they're specifically modded to have it. It's not guaranteed to be present on even the ASIC-mapper boards (S*ROM, T*ROM) either. Low G Man in particular depends on the absence of SRAM.

Without SRAM, nothing asserts the data bus signals when the address bus is $6000-$7FFF. In this case, the data bus's inherent capacitance will keep the last byte that was on the data bus still on the data bus. Here are two examples:

Code: Select all

JMP $6056
The last three bytes that cross the data bus are 4C 56 60. When the CPU tries to read $6056, nothing gets chip-selected, and $60 (the last byte of the JMP instruction) stays floating on the data bus. The CPU interprets this as RTS.

Code: Select all

LDA #$60
PHA
LDA #$55
PHA
RTS
The CPU pulls $55 then $60 from the stack. (At this point, the last thing on the data bus is $60 from the stack.) It then treats it as an address $6055, adds 1, and then jumps to $6056. Again, nothing gets chip-selected, and $60 is on the data bus.

Undubbed
Posts: 24
Joined: Sun Aug 09, 2009 7:46 am

Post by Undubbed » Sat Aug 15, 2009 4:13 am

Thanks a ton for that! I was able to get around it but now I've run into a new 'feature' that I've never heard of :(

It seems when the second call to RTS is made it's supposed to jump to $FF01. Well, in FCEU it seems that every 5 bytes there's 4 bytes of $FFs and that's how $FF01 gets loaded, but my emulator isn't doing that. It's all zeroes so it jumps to address $0001 :/

Would you or anyone know why FCEU has to do that?

User avatar
Zepper
Formerly Fx3
Posts: 3248
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Post by Zepper » Sat Aug 15, 2009 8:41 am

@tepples:

- If there's no WRAM 6000-7fff and a read is performed, I suppose it's a "dummy" read. Well, perhaps _not_ exactly that dummy read, but the return value is the last byte fetched by the last instruction..?

User avatar
Banshaku
Posts: 2398
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: Nestest and SRAM

Post by Banshaku » Tue Aug 18, 2009 7:54 pm

tepples wrote:Most discrete boards, such as NROM, C*ROM, U*ROM, A*ROM, and B*ROM, don't have PRG SRAM at $6000-$7FFF unless they're specifically modded to have it. It's not guaranteed to be present on even the ASIC-mapper boards (S*ROM, T*ROM) either. Low G Man in particular depends on the absence of SRAM.
I know for an emulator it won't make much difference but the cart can have sram on it and low g man will work. As long as the sram is not active, it will not make low g man fail. The game must activate the sram to see it. I tested it on my dev cart with sram. Since low g man doesn't activate it, the game doesn't fail even with the ram there.

Sorry to be nit picky ;)

tepples
Posts: 22361
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Nestest and SRAM

Post by tepples » Wed Aug 19, 2009 2:41 pm

Banshaku wrote:As long as the sram is not active, it will not make low g man fail. The game must activate the sram to see it. I tested it on my dev cart with sram. Since low g man doesn't activate it
Just because a game doesn't activate the SRAM doesn't mean that it de-activates it. I seem to remember that some mapper revisions start up with the RAM activated.

User avatar
Banshaku
Posts: 2398
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: Nestest and SRAM

Post by Banshaku » Wed Aug 19, 2009 7:22 pm

tepples wrote:Just because a game doesn't activate the SRAM doesn't mean that it de-activates it. I seem to remember that some mapper revisions start up with the RAM activated.
The dev-cart I used for testing was using a MMC3A so there is good chance in that revision that the sram is not active by default. And I didn't say the game de-activate it too. I just said that you can have sram on the cart and the game will still run. For an emulator, it doesn't matter much since you're not using the real cart to emulate it.

I may have tested it with an MMC3B too but I don't remember clearly. I could re-test it someday with all mapper revisions when I have too much time but it may not bring much to this conversation except to become a more geeky hardware buff ;)

Post Reply