|Viewing Issue Advanced Details|
|ID||Category [?]||Severity [?]||Reproducibility||Date Submitted||Last Update|
|05371||Core||Minor||Always||Nov 17, 2013, 21:45||Nov 18, 2013, 09:51|
|Tester||jwdonal||View Status||Public||Platform||MESS (Official Binary)|
|Assigned To||AWJ||Resolution||Fixed||OS||Windows Vista/7/8 (64-bit)|
|Version||0.151||Fixed in Version||0.152||Build||Normal|
|Summary||05371: SNES: SPC-700 sets B flag when pushing PS register to the stack during execution of the BRK instruction|
When the PS register is pushed to the stack during execution of the BRK instruction the B flag is getting set. This should not happen. The B flag is only set _after_ the PS register is pushed to the stack (mess is doing this part correctly). Setting the B flag before writing the PS to the stack happens on both 6502/65816 (i.e. NES/SNES processors) so I'm guessing this is an incorrect carry-over from one of those processors.
The bug is located in \src\emu\cpu\spc700\spc700.c line 703. The "GET_REG_P_BRK" should be replaced with just "GET_REG_P".
Just to re-iterate, the B flag _should_ be set _after_ the PS register is pushed to the stack (mess is already doing this properly). But the B flag should _not_ be set _before_ pushing to the stack.
I marked this bug as minor since I don't think there are many games that even look at the B flag at all. But I could be wrong...maybe there are lots of games that use it...?
|Steps To Reproduce||
Load any ROM which causes the BRK instruction to be executed on the SPC-700. I just wrote a small test ROM myself. The source for the test rom follows (compile with tasm and convert to sfc with spc2rom):
.fill $FFC0-*,$FF ; 60 bytes of $FF for SPC2ROM
; Start of TCALL vector space
|Additional Information||I tested the instruction running on a real SNES using a logic analyzer and watched each cycle of the instruction as it executed. I can provide you the logic analyzer trace if you like, but I don't think that's necessary. You could test the same thing without a logic analyzer by executing the BRK instruction on a real SPC700 and then popping the last byte off the stack within the BRK service routine - you will see that the B flag was not set before it was written to the stack.|
|Affected Sets / Systems||SNES|
Nov 17, 2013, 22:42
|Yeah, so apparently the stupid mantis created 4 identical bugs for the one bug i reported. I was trying to attach an asm source file to the bug but it kept giving me an error saying "file type not allowed". So i tried multiple file types and it kept giving me an error and saying I should click the "back" button in my browser to correct the problem. So i finally just attached a blank PNG and it went through. But apparently mantis was creating a new bug for each time it was reporting these errors (telling me to go back and fix the problem. Bugs 5368, 5369, 5370, 5371 are all identical bugs and now i can't delete them - only 5371 should exist. Can someone with delete privilege delete bug IDs 5368, 5369, 5370?|
Nov 18, 2013, 00:00
|Oh, yeah, I've run across that before. I'll close the other ones and I'm sure one of the Admins will wipe them. In the future, there's a slim list of file types that are accepted, if you need to attach any kind of text or a patch or anything that's not a picture, zip it up first.|
Nov 18, 2013, 06:08
|Awesome. Thanks for closing them and thanks for the info on attachments!|