Viewing Issue Advanced Details Jump to Notes ]
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)
Status [?] Resolved   Driver
Version 0.151 Fixed in Version 0.152 Build Normal
Summary MESS-specific 05371: SNES: SPC-700 sets B flag when pushing PS register to the stack during execution of the BRK instruction
Description 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):

.title "brk_bug"

.fill 0200h-*,000h

start:
  brk
  jmp start

brk_vec:
  reti

.fill $FF84-*,$00
.fill $FFC0-*,$FF ; 60 bytes of $FF for SPC2ROM

.fill 010000h-*,000h

; Start of TCALL vector space
.org $FFDE
.dw brk_vec

.end
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.
Flags
Regression Version
Affected Sets / Systems SNES
Attached Files
 


-  Notes
User avatar
No.09996
jwdonal
(Tester)
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?
User avatar
No.09997
NekoEd
(Senior Tester)
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.
User avatar
No.10000
jwdonal
(Tester)
Nov 18, 2013, 06:08
Awesome. Thanks for closing them and thanks for the info on attachments!