| 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 |
| Fixed in Git Commit | Github Pull Request # | ||||
| Summary |
 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. | ||||
| Github Commit | |||||
| Flags | |||||
| Regression Version | |||||
| Affected Sets / Systems | SNES | ||||
|
Attached Files
|
|||||
 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? |
|---|---|
 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. |
|
No.10000
jwdonal Tester
Nov 18, 2013, 06:08
|
Awesome. Thanks for closing them and thanks for the info on attachments! |