Page 7 of 26
Re: Mesen-S - SNES Emulator
Posted: Thu Jun 27, 2019 6:25 pm
by topspoon
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.
Re: Mesen-S - SNES Emulator
Posted: Thu Jun 27, 2019 6:52 pm
by lidnariq
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...
Re: Mesen-S - SNES Emulator
Posted: Thu Jun 27, 2019 7:50 pm
by Sour
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.
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?
Re: Mesen-S - SNES Emulator
Posted: Thu Jun 27, 2019 9:56 pm
by lidnariq
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 (69 KiB) Viewed 5096 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".
Re: Mesen-S - SNES Emulator
Posted: Fri Jun 28, 2019 5:37 am
by Near
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~
Re: Mesen-S - SNES Emulator
Posted: Fri Jun 28, 2019 6:33 am
by Sour
Managed to fix it - the offset-per-tile for mode 6 had a couple of issues regarding the scroll position, etc.
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?
Re: Mesen-S - SNES Emulator
Posted: Fri Jun 28, 2019 9:40 am
by topspoon
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.
Re: Mesen-S - SNES Emulator
Posted: Fri Jun 28, 2019 10:27 am
by lidnariq
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.
Re: Mesen-S - SNES Emulator
Posted: Fri Jun 28, 2019 10:42 am
by Sour
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!
Re: Mesen-S - SNES Emulator
Posted: Fri Jun 28, 2019 11:37 am
by topspoon
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.
Re: Mesen-S - SNES Emulator
Posted: Fri Jun 28, 2019 1:30 pm
by Sour
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.
Re: Mesen-S - SNES Emulator
Posted: Fri Jun 28, 2019 7:28 pm
by topspoon
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
Re: Mesen-S - SNES Emulator
Posted: Fri Jun 28, 2019 8:30 pm
by topspoon
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
Re: Mesen-S - SNES Emulator
Posted: Fri Jun 28, 2019 8:59 pm
by topspoon
Axelay -- brightness + subscreen addition saturation problem
-- start new game, stage 1
See here:
https://github.com/snes9xgit/snes9x/issues/512
Re: Mesen-S - SNES Emulator
Posted: Sat Jun 29, 2019 4:58 am
by topspoon
cgram 2122 writes should be latched -- on high (odd) address, it commits both data.