Need clarification on SPC700 overflow flag

I found this post by byuu regarding the overflow flag: http://board.zsnes.com/phpBB3/viewtopic.php?p=66102&sid=721df8e5c71d20a3bfc62e841fe61257#p66102

He states that there is a weird issue with the overflow flag for ADC. Interestingly, however, looking at the bsnes/higan source for the SMP (see bsnes_src/sfc/alt/algorithms.cpp, search for op_adc), byuu does not implement this behavior for either ADC or ADDW.

On the other hand, looking at the mess source (see src/emu/cpu/spc700/spc700.c) they do implement this behavior but only for the ADDW opcode and not for ADC.

Can anyone help clarify what the proper implementation of the overflow flag is on the spc700 for ADC and ADDW?

Byuu's and my SMP cores pass a stressful CPU instruction test, so the sources of both are a guide. Anomie's docs should be correct as well, as I worked with him on getting them polished off.

A few questions on this...
1) Where can I download this stressful CPU instruction test?
2) Which anomie doc has this information? I thought I had all of them and I don't see anything which mentions anything specific about the overflow flag (except which opcodes modify the overflow flag).
3) So I guess byuu "discovered" this weird behavior and then decided he was wrong?
4) I did check your source in SPC_CPU.h but it wasn't clear to me exactly how the overflow flag was getting set...the code was a little cryptic to me.

Best I've got at the moment, the CPU tests I mentioned (with instructions on how to run): spc-700-cpu-tests.zip

Anomie's SPC700 doc shows flags. He mentions obscure things, like ADDW calculating the half-carry flag based on the high bytes, not the low ones.

Thanks a lot blargg. A couple questions on running these tests...

- The readme says, "Load file's 0x2000 bytes at address 0x400." All of the files only have 0x1000 bytes in them. Is that just a typo?

- The readme says that after loading the file at address 0x400, that I should "Set program counter to 0x400.". However, I notice in all of the test hex files that they all start with a string which is the name of the test. So jumping to 0x400 is going to cause the CPU to start executing the string bytes.

Sorry if these are dumb questions and I'm just mis-understanding something about how they work. Thanks again!

Looks wrong to me. I may have missed something, but I have never heard of a CPU where addition results (or overflow flags) could differ for "x+y" versus "y+x".

Crap, I should have looked more closely. In that case... OK, load to 0x400 as stated, but execute at 0x430. Let me know if you have trouble with them. I'm annoyed because I sent all these to byuu way back, but I couldn't find the archive and docs I wrote for him back then.

Not annoyed or anything, just a pro-tip to any other aspiring SNES emulator developers: if I posted an unsure statement about something in 2005, when my emulator was less than a year old, it's probably not very accurate compared to what I know today. You should rely on the current sources instead =)

Not sure how anomie put up with all my questions back then (it's always so hard to tell if you're wasting your time teaching someone that'll just quit in a few weeks/months), but I'm sure glad he did.

Hey blargg, I finally finished my spc-700 implementation and am about to start running your cpu tests. Quick question regarding this statement in the readme doc:


Do you happen to remember exactly which tests rely on accurate timer behavior? The reason I ask is because I haven't yet implemented the timers for my emulator - so I assume that is going to break some (all?) of them? I suppose I could just implement the timers, but if it's only a couple of the tests that actually require the timers to exist and work properly, then I'd rather hold off and just get the CPU as rock solid as possible first.

Thanks again for these tests.

As I remember just the ones that test the timing of individual reads/writes within an instruction rely on the timers. I'm actually in the process of rewriting my SPC-700 CPU tests. I'll see if I can put up what I've got so far on github. BTW, do you have a SNES emulator around your SPC-700 emulator, or is it just bare?

Cool, thanks for the info.


I don't have a full SNES emulator, it's literally just the processor itself. That's actually one reason why I like this current set of tests because they don't rely on very much outside of just the processor. I just copy it into memory and jump to the proper address and I'm done. If these new tests you're working on will also be able to run with just a bare bones SPC-700 implementation that would be stellar!

EDIT: Relying on the S-SMP internal timers is totally reasonable. They are incredibly trivial to implement...I think I'm just going to go ahead and add them so I can get the most out of the tests.

It's very likely that those timing tests (which are very unimportant in general) simply rely on the timer ticking every N clocks, and clearing when read. I'd have to look to be sure. I'd suggest focusing on logic first, as the timers aren't used for those tests.

My emulator is now passing all of these tests. W00t! It turned out that none of them actually relied on any of the S-SMP internal timers - since I was able to pass all of them and I don't even have any of the timer registers implemented. However, two of the tests do rely on some of the other minor internal registers to be implemented in order to be able to store and read back the same value from them.

Looking forward to your next set of tests Blargg. These really helped me out.