A little help with Kevtris nestest.nes?

A little help with Kevtris nestest.nes?
by jwdonal on 2010-07-08 (#63912)

Can someone help me figure out what's wrong with my CPU flags register? I am now passing all of kevtris' "Normal Ops" tests from his nestest.nes except for the Flag tests.

I am getting the following error code:
013h - PHP/flags failure (misc bit states)

That's not very descriptive/specific...especially "misc bit states"?? I'm reviewing my code now, but thought maybe I'd just put up this post in case someone had a quick answer. All PHP does is push the status register to the stack right? I don't see how I could be mucking up something so simple...

Does nestest take into account that the BCD flag is not used in the NES version of the 6502? I'm wondering if that's the problem...?

Re: A little help with Kevtris nestest.nes?
by tepples on 2010-07-08 (#63914)

jwdonal wrote:

All PHP does is push the status register to the stack right?

PHP pays the doctor and runs this web site. It also pushes the status register to the stack. It might have something to do with bits 5 and 4, which aren't very well understood among programmers because they aren't really used on an NES. Bit 5 seems to always be 1, and bit 4 has something to do with the BRK instruction.

Quote:

Does nestest take into account that the BCD flag is not used in the NES version of the 6502? I'm wondering if that's the problem...?

The BCD flag (bit 3) is still stored; it's just not used by ADC and SBC.

by blargg on 2010-07-08 (#63916)

The wiki covers this well

by jwdonal on 2010-07-09 (#63932)

tepples wrote:
and bit 4 has something to do with the BRK instruction

The BRK instruction is very useful for software debuggers (e.g. gdb) as it allows for "software interrupts" to create what are commonly referred to as "breakpoints".

tepples wrote:
The BCD flag (bit 3) is still stored; it's just not used by ADC and SBC.

Whoa dang. That I did not know. I was not even storing the BCD bit. I was just keeping it at 0. Thanks for the fix! But alas, I'm still getting error 13h.

blargg wrote:
The wiki covers this well

That site states: "The status register doesn't implement bits 4 and 5."

I know that bit 5 is always '1' - this is true even in all 6502's. But is it correct to say that bit 4 (the BRK or "software interrupt" flag) is not implemented?? I'm pretty sure it is implemented even in the NES' version of the 6502. And the site even contradicts itself just below that when it says that bit 4 is set when a BRK instruction is executed (which is correct).

Can someone clarify?

by blargg on 2010-07-09 (#63944)

Bits 4 and 5 do not exist in the status register. Almost every book incorrectly documents there being a break flag, but there is none. It's exactly like it says on the Wiki.

by Bregalad on 2010-07-09 (#63945)

Haha, the bit doesn't exist in the status register, it is just set when a BRK interrupt put the status register on stack, and clear when a true interrupt or a php instruction puts it on stack. So it depends on the definition of "implemented".

by blargg on 2010-07-09 (#63946)

The status register remembers the values of the various flags. Whenever an NMI, IRQ, BRK, or PHP occurs, bits 4 and 5 of the byte written to the stack are set to values based entirely on whether it was an NMI/IRQ, or BRK/PHP that is occurring. Bits 4 and 5 aren't based on anything else, nothing that occurred before that has any effect, thus there is nothing to remember in the status register. To talk of these bits existing in the status REGISTER would be like saying that the status register also has a million other hidden flags that it remembers, but that you can't ever actually examine in any way. All the books and web pages that document the Break flag as existing in the status register result in regular confusion for people trying to examine that non-existent flag by using PHP and then PLA.

by jwdonal on 2010-07-09 (#63948)

Holy cow, that is some crazy esoteric shiznit! And you're right, all the 6502 documentation that I have definitely refers to those bits as if they physically exist in the processor status register. So my CPU is definitely wrong then. Now I just need to fix it...

Thanks a lot guys!!

by jwdonal on 2010-07-09 (#63954)

Okay, so while I'm working on this status register problem I have another question. I am failing _all_ of kevtris' "Illegal Ops" tests. :'( And yes, I know it should really be called "Unofficial ops".

Problem is...where the heck do I find the documentation for each of these undocumented opcodes?! Haha. I would need to know the exact number of cycles required for each instrux and exactly what is supposed to happen during each of those clock cycles. Does this document exist??

Thanks!

by tepples on 2010-07-09 (#63957)

jwdonal: This is illegal, you know.

by jwdonal on 2010-07-09 (#63958)

Awesome!! Thanks tepples!

by jwdonal on 2010-07-13 (#64177)

So I've implemented bits 4 & 5 as directed on the website. Bit 5 doesn't exist but is always pushed to the stack as '1'. Bit 4 doesn't exist but is pushed to the stack as '1' during PHP/BRK and pushed as '0' otherwise. Since I made this change I now pass all of the Nestress.nes ROM's CPU tests. It didn't used to pass the status register test but now it does. This is good. But I cannot for the life of me get Kevtris' "Flag tests" to pass in his nestest.nes ROM. No matter what I do it keeps giving me the 13h error. What the heck?? Does anyone have any ideas? Because I'm fresh out.

Are there any other CPU test ROMs that will test the status register and give me a more detailed error message?

Thanks

by blargg on 2010-07-13 (#64179)

What instructions do my CPU tests say are failing? If it's just ADC and SBC, for example, you know it's the V flag.

by jwdonal on 2010-07-13 (#64180)

SUCCESS!!! So I remembered that someone had made that nestest run log file that I could compare to my CPU cycles and register statuses. So I did that and noticed that the ALU was clearing a flag bit that it should not have been. It was a design flaw and an incredibly idiotic error on my part - the erroneous HDL was actually the result of a Vim regex search and replace that I did a while back in my ALU. Tsk tsk. And I'm usually always so careful when I do that kind of thing. Oh well, at least it works now and thanks so much to whoever made that log file.

@Blargg, even though your suggestion wasn't the actual problem I really appreciate your reply and trying to help.

Pz

Jonathon =D

by jwdonal on 2010-07-29 (#65130)

minor bump - sorry

Can someone tell me what the CYC and SL numbers in the nestest.log file are, and (if it's not obvious) how they should be generated? They seem to count up for a little while and then reset sometimes. I am working on having my emu generate an identical type of log file so that I can compare my CPU and to allow for _significantly_ easier debugging.

http://nickmass.com/images/nestest.log

Thanks!

Jonathon

by tepples on 2010-07-29 (#65134)

CYC and SL are an indication of elapsed time from the NTSC PPU's perspective. Three CYC make one CPU cycle, and 341 CYC make one SL. When SL is 261 (the pre-render scanline), it is set to -1.

by jwdonal on 2010-07-29 (#65137)

Very cool! Thanks for the info tepples!

And, it goes without saying, but that is an _awesome_ idea to include those too little bits of information in a NES trace log. Kudos to whoever thought of it.

by blargg on 2010-07-30 (#65153)

jwdonal wrote:
I am working on having my emu generate an identical type of log file so that I can compare my CPU and to allow for _significantly_ easier debugging.

Go at it the other way: remove those values from the log so that it's in the same format as your emu. Automate removal (with a regexp/grep) and you can trust that the log wasn't otherwise altered.

by jwdonal on 2010-07-30 (#65229)

blargg wrote:
Go at it the other way: remove those values from the log so that it's in the same format as your emu. Automate removal (with a regexp/grep) and you can trust that the log wasn't otherwise altered.

Agreed. Def safer that way.

---

One comment. I've finally got some minimal processor status output being printed. The first thing I noticed was that my processor status value did not match the nestest log. On the very first line the value in my P register was $04 and the nestest log shows it as being $24. The errant bit is the unimplemented flag that is always '1'.

So, technically speaking, isn't the nestest log incorrect? Bit 5 (and bit 4) of the P register only really "exist" when they are pushed to the stack (see http://wiki.nesdev.com/w/index.php/CPU_ ... g_behavior). Is this a bug in the emulator that generated this log (or rather just a result of the standard confusion surrounding bits 4 and 5 of the P register)? In my opinion bit 5 of P should be '0' in the nestest log - it just seems more accurate to me.

Thanks!

by blargg on 2010-07-31 (#65232)

Yeah, it should be $04. The fix is to change your logging functionality to always set bit 5 in the printed value. No change to the emulation necessary.

by jwdonal on 2010-07-31 (#65233)

blargg wrote:
The fix is to change your logging functionality to always set bit 5 in the printed value.

Okay, kewl. That's what I did. But it's good to know someone agrees with me that it's wrong. Pz!

by tepples on 2010-07-31 (#65235)

My best guess is that the value in the P field of the log is, by convention, what you'd get in A if you PHP PLA.

by blargg on 2010-07-31 (#65238)

If you did PHP PLA, you'd always find bit 4 set as well, which is not set in the log.

by jwdonal on 2010-07-31 (#65240)

Haha, very nice catch.

It might be worth putting a link to this post on the Wiki (in the nestest test rom description) to help clarify this for other users. Just a thought.

by NickMass on 2010-07-31 (#65268)

If anyone happens to have a better more accurate nestest.nes log that is as easy to read as the current one used for comparison I will gladly overwrite the current one. http://nickmass.com/images/nestest.log is just some log I found in a post on these forums made ages ago that I happened to use when developing my emu, and then was recently linked to in a few places. I could use a log from my emulator but I'm sure it would have issues of its own.

by jwdonal on 2010-07-31 (#65270)

I'd be happy to donate my log but I'm only currently passing the official instructions. And my log also doesn't have the "pretty-printed" listing format that the current log does.

Don't get me wrong - I'm not complaining about the log - it's actually really good. There's just a minor discrepancy in the P bits that could lead to some confusion - haha, like it did for me. Which is why I suggested making a small link to this post from the Wiki. May not even be worth - it's really not a big issue.

by tineras on 2010-07-31 (#65271)

NickMass wrote:
If anyone happens to have a better more accurate nestest.nes log that is as easy to read as the current one used for comparison I will gladly overwrite the current one. http://nickmass.com/images/nestest.log is just some log I found in a post on these forums made ages ago that I happened to use when developing my emu, and then was recently linked to in a few places. I could use a log from my emulator but I'm sure it would have issues of its own.

Well, thanks to you I got everything working properly and a ton of problems went away. The only issue I had was trying to easily compare the two documents (my output and the 'gold' nestest.log). Making minor edits to have similar formatting was easy, but it would have taken quite a bit more work to add all of the opcode names and their respective addresses and return-data (ex. 'ADC ($80,X) @ 80 = 0200 = 69'). I also didn't have timing setup just yet and I'm still not sure what 'SL' is. This made the Compare in Notepad++ take almost 5 minutes for each change that I made (being nearly 9000 lines and all).

To fix this (for me), I just used Notepad++ to remove those blocks altogether from the master log file.

I ended up with something more simple like this:
C5F5 A2 A:00 X:00 Y:00 P:24 SP:FD

I think it's safe to assume that anyone who is far enough along to run this test has setup these register and values. After doing this and comparing with the master document, the searches only took seconds and I was able to hammer out all the remaining issues in a matter of hours instead of days.

Anyway, I'm not sure why I'm saying all this, but I am really grateful. So, thanks again!

by jwdonal on 2010-07-31 (#65273)

tineras wrote:
I ended up with something more simple like this:
C5F5 A2 A:00 X:00 Y:00 P:24 SP:FD

LOL, that is _exactly_ how I formatted my output too!