Mesen-S - SNES Emulator

Discussion of hardware and software development for Super NES and Super Famicom.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Post Reply
topspoon
Posts: 18
Joined: Wed Jun 26, 2019 5:28 am

Re: Mesen-S - SNES Emulator

Post by topspoon » Thu Jun 27, 2019 6:25 pm

Mighty Morphin Power Rangers - The Fighting Edition (USA) = in-game battle arena is glitched
ex. start game -- trial mode -- pick fighter

Code: Select all

00:8C90  sta $420b   hc=1068 vc=223 fc=2167
00:8C93  ldx #$7e80  hc=1098 vc=223 fc=2167

*** error: supposed to run nmi routine first because vc=225 when dma finished

00:8C96  stx $2116   hc=506 vc=225 fc=2168

edit: Running custom build so that might be where I goofed. I get a warning screen after Namco logo, but on other emulators it goes straight to title intro. Look into this sometime.

The demo mode6 layer1 opt effect I was also wondering about but didn't follow up on yet.

edit2:
Super Famista 5 (Japan).sfc
MD5 = C9A6F2140490FBCBA02DDECFD5409EA5
SHA-1 = 276991C3B74E92FF13352025520AD504E644B4AA

It's probably my fault somewhere when compiling. Added a few modifications for own testing, debugging.

lidnariq
Posts: 9300
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Mesen-S - SNES Emulator

Post by lidnariq » Thu Jun 27, 2019 6:52 pm

Sour wrote:The shape of the wave for "mode 6 layer 1" at the bottom is quite different from bsnes, I'm assuming mine is incorrect, but the animation feels broken in bsnes (but maybe it also does this on hardware?)
The hardware has the same OpT behavior for all modes and all layers: it should look like "Mode 2 Layer 1" above.

... or at least that's what I think I remember seeing when I had the logic analyzer clips in there...

Sour
Posts: 796
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen-S - SNES Emulator

Post by Sour » Thu Jun 27, 2019 7:50 pm

topspoon wrote:*** error: supposed to run nmi routine first because vc=225 when dma finished
I might have misinterpreted anomie's docs or higan's code, then - or both.
anomie wrote:If the CPU is halted (i.e. for DMA) while /NMI goes low, the NMI will trigger after the DMA completes (even if /NMI goes high again before the DMA completes). In this case, there is a 24-30 cycle delay between the end of DMA and the NMI handler, time enough for an instruction or two.
So I guess that 24-30 cycle delay is when the "ldx #$7e80" instruction is executed, and the NMI fires after that one, but before the write to $2116. I'll have to recheck what higan does on this and see if I can remember why I came up with the current delay I have.

You're using the same version of the game as me, so either one of your modifications is causing it, or maybe there's some uninitialized variable somewhere that is causing this to happen somewhat randomly.
lidnariq wrote:The hardware has the same OpT behavior for all modes and all layers: it should look like "Mode 2 Layer 1" above.
comparison.png
This is what it looks like at the moment (bsnes-plus and higan 104 are identical). In bsnes, the text scrolls in sync with the mode 5 text, but the mode 6 text's wave effect is diminished (seems like the sine's period is doubled or something akin). In Mesen-S the text's shape is similar to mode 2 & 4, but the scroll speed is halved compared to bsnes (the mode 5 text goes around the screen twice for each time the mode 6 text does). Assuming the scroll speed has a direct impact on this - either mesen-s scrolls too slow or bsnes too fast?

lidnariq
Posts: 9300
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Mesen-S - SNES Emulator

Post by lidnariq » Thu Jun 27, 2019 9:56 pm

Sour wrote:Assuming the scroll speed has a direct impact on this - either mesen-s scrolls too slow or bsnes too fast?
Here's a picture from a 1-1-1 SNES:
mIMG_6760.JPG
mIMG_6760.JPG (69 KiB) Viewed 3578 times
Other than one mistake I guess I made ("Mode 0 Layer 1" through "Mode 4 Layer 1" are two screens wide, while "Mode 5 Layer 1" and "Mode 6 Layer 1" are only one screen wide ... because they're all 512 pixels wide), "Mode 6 Layer 1" is supposed to look just like "Mode 2 Layer 1".

byuu
Posts: 1545
Joined: Mon Mar 27, 2006 5:23 pm
Contact:

Re: Mesen-S - SNES Emulator

Post by byuu » Fri Jun 28, 2019 5:37 am

If the CPU is halted (i.e. for DMA) while /NMI goes low, the NMI will trigger after the DMA completes (even if /NMI goes high again before the DMA completes). In this case, there is a 24-30 cycle delay between the end of DMA and the NMI handler, time enough for an instruction or two.
The 24-30 cycle note is a rough ballpark of one CPU instruction. higan implements this with the "IRQ lock" flag. It's just one cycle, but since interrupts are only tested on the last work cycle (one bus cycle before opcode fetch), it effectively bumps things another instruction ahead.

Wild Guns relies on this behavior to not flicker like crazy in-game.
Here's a picture from a 1-1-1 SNES:
Jesus. That is a very impressive tech demo to test this but, any chance you could please make that a little (okay, a lot) less noisy?

I have no idea what I'm supposed to be seeing or what's supposed to be happening ^-^;;

I don't know what's supposed to happen but if there's a bug in higan I'd like to fix it~

Sour
Posts: 796
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen-S - SNES Emulator

Post by Sour » Fri Jun 28, 2019 6:33 am

Managed to fix it - the offset-per-tile for mode 6 had a couple of issues regarding the scroll position, etc.
ppubusact_000.png
This seems to be pretty identical to your screenshot. Although now I noticed that the sprites on top of everything are completely different in your screenshot vs all emulators I've tested? Any ideas on why?
byuu wrote: it effectively bumps things another instruction ahead.
According to anomie's docs, writing to $420B (DMA enable) allows the CPU to continue up to the point where it reads the next instruction's op code before DMA starts. So is it just that the partially-read instruction resumes after DMA and after that it jumps to NMI/IRQ if needed?

topspoon
Posts: 18
Joined: Wed Jun 26, 2019 5:28 am

Re: Mesen-S - SNES Emulator

Post by topspoon » Fri Jun 28, 2019 9:40 am

byuu wrote:I don't know what's supposed to happen but if there's a bug in higan I'd like to fix it~
In bsnes-plus, Mode2 and Mode4 layers do the sine wave up and down. But Mode6 doesn't move like 2/4.


Warlock -- in-game status bar has a flicker.

Code: Select all

2108 (BG2SC) / 210b (BG12NBA)
00:E9F5  LDA $E4    hc=976  vc=0 fc=20
00:E9F7  STA $2108  hc=1000 vc=0 fc=20
00:E9FA  LDA $E5    hc=1030 vc=0 fc=20
00:E9FC  STA $210B  hc=1054 vc=0 fc=20
00:E9FF  LDA $1835  hc=1084 vc=0 fc=20

1104 = h-dma
1112 = draw

00:EA02  DEC A      hc=1116 vc=0 fc=20
00:EA03  STA $2110  hc=1130 vc=0 fc=20
00:EA06  STZ $2110  hc=1160 vc=0 fc=20
Game changes bg2 nametables mid-scanline during active draw. bsnes-plus executes same timing but does not pixel flicker.

Does real hardware lock nametable addresses at start of scanline during rendering? Wondering why bsnes-plus doesn't have the glitch.

lidnariq
Posts: 9300
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Mesen-S - SNES Emulator

Post by lidnariq » Fri Jun 28, 2019 10:27 am

Sour wrote:Although now I noticed that the sprites on top of everything are completely different in your screenshot vs all emulators I've tested? Any ideas on why?
Because evidently I forgot I'd made a newer version of the same test locally, with the sprites moved so that they don't overlap.

Sour
Posts: 796
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen-S - SNES Emulator

Post by Sour » Fri Jun 28, 2019 10:42 am

topspoon wrote:Does real hardware lock nametable addresses at start of scanline during rendering?
I think this might be the same issue as NHL 94 & Air Strike Patrol - if the PPU was loading tile data ~16 dots before rendering it, it would probably be just enough to avoid the glitch in Warlock, I think.
lidnariq wrote:Because evidently I forgot I'd made a newer version of the same test locally, with the sprites moved so that they don't overlap.
Oh, I guess I can assume my implementation of this is more or less ok then. Thanks!

topspoon
Posts: 18
Joined: Wed Jun 26, 2019 5:28 am

Re: Mesen-S - SNES Emulator

Post by topspoon » Fri Jun 28, 2019 11:37 am

Sour wrote:if the PPU was loading tile data ~16 dots before rendering it, it would probably be just enough to avoid the glitch in Warlock, I think.
It looks to be ~16 pixels worth of garbage.

Code: Select all

00:E9E8  LDA #$00
00:E9EA  INC A
00:E9EB  CMP #$07
00:E9ED  BCC $FB

00:E9EF  LDA #$00
00:E9F1  LDA #$00
00:E9F3  LDA #$00

00:E9F5  LDA $E4    hc=976  vc=0 fc=20
00:E9F7  STA $2108  hc=1000 vc=0 fc=20
00:E9FA  LDA $E5    hc=1030 vc=0 fc=20
00:E9FC  STA $210B  hc=1054 vc=0 fc=20
00:E9FF  LDA $1835  hc=1084 vc=0 fc=20
Although I tried changing cmp #$07 to cmp #$01 and tested bsnes-plus again. No pixel garbage.


American Tail and Rendering Ranger R2 won't boot. I'll look into R2.

Sour
Posts: 796
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen-S - SNES Emulator

Post by Sour » Fri Jun 28, 2019 1:30 pm

topspoon wrote:Although I tried changing cmp #$07 to cmp #$01 and tested bsnes-plus again. No pixel garbage.
I think you might be using the "performance" build of bsnes-plus? In the accuracy build, the glitches do appear (and are bigger if you switch $07 to $01). I checked on higan, there is a tiny glitch on the right side, too (about 8 or so pixels) - so changing the tile load logic in Mesen-S to fetch the tiles ahead of time will probably give a result similar to what higan gives at the moment, I think.
topspoon wrote:American Tail and Rendering Ranger R2 won't boot. I'll look into R2.
It looks like both of these are also related to the SPC vs CPU issues that I haven't been able to figure out. Running the SPC 20-40% faster than normal allows them to boot. I've really run out of ideas on this one - I've double-checked and triple-checked a bunch of timing related things, and for the most part it should be pretty close to higan's, but somehow these games refuse to boot. If you manage to find the source of the problem, that'd be amazing.

I took a look at American Tail specifically: the SPC initialization timing being slightly different causes the CPU to take more time to get the SPC init loops done, which causes the PPU to trigger an IRQ too early in the code, which crashes the game.

topspoon
Posts: 18
Joined: Wed Jun 26, 2019 5:28 am

Re: Mesen-S - SNES Emulator

Post by topspoon » Fri Jun 28, 2019 7:28 pm

Rendering Ranger R2:

Code: Select all

bsnes-plus

..ff2a mov $0f4,#$ff          A:ff X:ff Y:00 SP:01ff YA:00ff nvpbhizC

-- spc700 writes ff to 2140

36812b cmp #$ff               A:0b00 X:0000 Y:0bb6 S:01f2 D:0000 DB:36 nvMxdIZc V:104 H:1248 F:34
36812d bne $8128     [368128] A:0b00 X:0000 Y:0bb6 S:01f2 D:0000 DB:36 nvMxdIzc V:104 H:1264 F:34
368128 lda $2140     [362140] A:0b00 X:0000 Y:0bb6 S:01f2 D:0000 DB:36 nvMxdIzc V:104 H:1286 F:34
36812b cmp #$ff               A:0b00 X:0000 Y:0bb6 S:01f2 D:0000 DB:36 nvMxdIZc V:104 H:1316 F:34

-- port 0: smp -> cpu still shows 0x00
-- 65816 reads 2140 = 0x00

..ff2d mov a,$0f4             A:ff X:ff Y:00 SP:01ff YA:00ff nvpbhizC

-- port 0: smp -> cpu now shows 0xff

36812d bne $8128     [368128] A:0b00 X:0000 Y:0bb6 S:01f2 D:0000 DB:36 nvMxdIzc V:104 H:1332 F:34
368128 lda $2140     [362140] A:0b00 X:0000 Y:0bb6 S:01f2 D:0000 DB:36 nvMxdIzc V:104 H:1354 F:34
36812b cmp #$ff               A:0bff X:0000 Y:0bb6 S:01f2 D:0000 DB:36 NvMxdIzc V:105 H:  20 F:34

-- 65816 reads updated 2140 = 0xff (good!)

..ff2f mov $0f4,#$fe          A:fe X:ff Y:00 SP:01ff YA:00fe NvpbhizC

-- note that A = 0xfe (control code)

Code: Select all

Mesen-S

36:8123  lda #$fe       A=0B00 hc=760 vc=103 fc=34
36:8125  sta $2140      A=0BFE hc=776 vc=103 fc=34

-- important error: spc700 never sees 0xfe control code

...FF26  nop            A=FF   hc=806 vc=103 fc=34

36:8128  lda $2140      A=0BFE hc=806 vc=103 fc=34

...FF27  nop            A=FF   hc=836 vc=103 fc=34

36:812B  cmp #$ff       A=0B00 hc=836 vc=103 fc=34
36:812D  bne $8128      A=0B00 hc=852 vc=103 fc=34
36:8128  lda $2140      A=0B00 hc=874 vc=103 fc=34

...FF28  nop            A=FF   hc=904 vc=103 fc=34

36:812B  cmp #$ff       A=0B00 hc=904 vc=103 fc=34
36:812D  bne $8128      A=0B00 hc=920 vc=103 fc=34
36:8128  lda $2140      A=0B00 hc=942 vc=103 fc=34

--- port 0: smp -> cpu still reads 0x00

...FF29  nop            A=FF   hc=972 vc=103 fc=34
...FF2A  mov $0f4,#$ff  A=FF   hc=972 vc=103 fc=34

--- port 0: smp -> cpu now shows 0xff (too early!)

36:812B  cmp #$ff       A=0BFF hc=972 vc=103 fc=34
36:812D  bne $8128      A=0BFF hc=988 vc=103 fc=34
36:812F  lda #$00       A=0BFF hc=1004 vc=103 fc=34
36:8131  sta $2140      A=0B00 hc=1020 vc=103 fc=34
36:8134  lda #$6f       A=0B00 hc=1050 vc=103 fc=34
36:8136  sta $2143      A=0B6F hc=1066 vc=103 fc=34

...FF2D  mov a,$0f4     A=FF   hc=1096 vc=103 fc=34

36:8139  cmp $2143      A=0B6F hc=1096 vc=103 fc=34

...FF2F  mov $0f4,#$fe  A=00   hc=1126 vc=103 fc=34

36:813C  bne $8134      A=0B6F hc=1126 vc=103 fc=34
36:8134  lda #$6f       A=0B6F hc=1148 vc=103 fc=34
36:8136  sta $2143      A=0B6F hc=1164 vc=103 fc=34
36:8139  cmp $2143      A=0B6F hc=1194 vc=103 fc=34
36:813C  bne $8134      A=0B6F hc=1224 vc=103 fc=34
36:8134  lda #$6f       A=0B6F hc=1246 vc=103 fc=34
36:8136  sta $2143      A=0B6F hc=1262 vc=103 fc=34

...FF32  cmp a,#$fe     A=00   hc=1292 vc=103 fc=34
...FF34  beq $ff43      A=00   hc=1292 vc=103 fc=34

36:8139  cmp $2143      A=0B6F hc=1292 vc=103 fc=34

 ** error: should be FF43 (A = FE); spc700 never sees this value and breaks
 
...FF36  A=00   hc=1322 vc=103 fc=34

topspoon
Posts: 18
Joined: Wed Jun 26, 2019 5:28 am

Re: Mesen-S - SNES Emulator

Post by topspoon » Fri Jun 28, 2019 8:30 pm

Sour wrote:According to anomie's docs, writing to $420B (DMA enable) allows the CPU to continue up to the point where it reads the next instruction's op code before DMA starts. So is it just that the partially-read instruction resumes after DMA and after that it jumps to NMI/IRQ if needed?
I wonder the same thing now after reading.

1. cpu: sta $420b
2. cpu: 1 cycle delay = fetch next opcode from memory (6,8,12)
3. cpu: halt, bus locked

4. dma: reset = align to next dma cycle boundary (2,4,6,8)
5. dma: controller init = 8 cycles
6. dma: channel init = 8 cycles
7. dma: transfer = 8 cycles * x bytes
8. dma: repeat 6-7 for more channels

9. cpu: reset = align to next cpu cycle boundary (2,4,6)
10. cpu: un-halt, resume bus operation
11. cpu: start internal operations, memory operations, etc.
12. cpu: process pending nmi, irq before next opcode fetch

topspoon
Posts: 18
Joined: Wed Jun 26, 2019 5:28 am

Re: Mesen-S - SNES Emulator

Post by topspoon » Fri Jun 28, 2019 8:59 pm

Axelay -- brightness + subscreen addition saturation problem
-- start new game, stage 1

See here:
https://github.com/snes9xgit/snes9x/issues/512
Last edited by topspoon on Sat Jun 29, 2019 6:08 am, edited 1 time in total.

topspoon
Posts: 18
Joined: Wed Jun 26, 2019 5:28 am

Re: Mesen-S - SNES Emulator

Post by topspoon » Sat Jun 29, 2019 4:58 am

cgram 2122 writes should be latched -- on high (odd) address, it commits both data.

Post Reply