nesdev.org

Posted: **Sun Jun 30, 2019 6:41 pm**

Ranger R2 behavior

Cpu 1:
36:852d  cmp $2143  (in = $43)


spc-pre         hc=1072 vc=170 fc=336 || cycle=11472160 target=11472158
36:852D  A=0053 hc=1072 vc=170 fc=336
spc-post        hc=1102 vc=170 fc=336 || cycle=11472160 target=11472160




Cpu 2:
36:8530  bne $852d
...095d  mov a,#$53


spc-pre         hc=1102 vc=170 fc=336 || cycle=11472160 target=11472160
36:8530  A=0053 hc=1102 vc=170 fc=336
spc-post        hc=1124 vc=170 fc=336 || cycle=11472160 target=11472163
...095D  A=06   hc=1124 vc=170 fc=336 || cycle=11472160 target=11472163




Cpu 3:
36:852d  cmp $2143  (in = $43 --> $53)
...095f  mov $0f7,a


spc-pre         hc=1124 vc=170 fc=336 || cycle=11472164 target=11472163
36:852D  A=0053 hc=1124 vc=170 fc=336
...095F  A=53   hc=1154 vc=170 fc=336 || cycle=11472164 target=11472165
spc-post        hc=1154 vc=170 fc=336 || cycle=11472172 target=11472165


** important note: SPC cycle 11472172 is when $0f7 is "officially" committed and done  (8 cycle SPC instruction)
                   Reading any time between 11472164 - 11472171 can be considered stale or unstable



Cpu 4:
36:8530  bne $852d


spc-pre         hc=1154 vc=170 fc=336 || cycle=11472172 target=11472165
36:8530  A=0053 hc=1154 vc=170 fc=336
spc-post        hc=1170 vc=170 fc=336 || cycle=11472172 target=11472167


** error: now we're exiting spin loop too early




Cpu 5:
36:8532  lda #$59  (error: we shouldn't be here yet)


spc-pre         hc=1170 vc=170 fc=336 || cycle=11472172 target=11472167
36:8532  A=0053 hc=1170 vc=170 fc=336
spc-post        hc=1186 vc=170 fc=336 || cycle=11472172 target=11472168




Cpu 6:
36:8534  sta $2143  (error: this is bad. spc will not see old $0f7 = $53 value)


spc-pre         hc=1186 vc=170 fc=336 || cycle=11472172 target=11472168
36:8534  A=0059 hc=1186 vc=170 fc=336
spc-post        hc=1216 vc=170 fc=336 || cycle=11472172 target=11472171


*** note: we could also do something similar for spc in-port.
          spc timing port update.



Cpu 7:
36:8537  cmp $2143
...0961  cmp a,$0f7  ($0f7 = $59, bad bad)


spc-pre         hc=1216 vc=170 fc=336 || cycle=11472172 target=11472171
36:8537  A=0059 hc=1216 vc=170 fc=336
...0961  A=53   hc=1246 vc=170 fc=336 || cycle=11472172 target=11472174
spc-post        hc=1246 vc=170 fc=336 || cycle=11472178 target=11472174


** note: 11472172 SPC cycle reached. Should be safe to update SMP -> CPU port.
         But it's way too late now.



Cpu 8:
36:853a  bne $8537  (start spin loop)


spc-pre         hc=1246 vc=170 fc=336 || cycle=11472178 target=11472174
36:853A  A=0059 hc=1246 vc=170 fc=336
spc-post        hc=1268 vc=170 fc=336 || cycle=11472178 target=11472176




Cpu 9:
36:8537  cmp $2143
...0963  bne $0961


spc-pre         hc=1268 vc=170 fc=336 || cycle=11472178 target=11472176
36:8537  A=0059 hc=1268 vc=170 fc=336
...0963  A=53   hc=1298 vc=170 fc=336 || cycle=11472178 target=11472179
spc-post        hc=1298 vc=170 fc=336 || cycle=11472186 target=11472179




Cpu x:
We're fatally deadlocked. The End.


spc-pre         hc=1298 vc=170 fc=336 || cycle=11472186 target=11472179
36:853A  A=0059 hc=1298 vc=170 fc=336
spc-post        hc=1320 vc=170 fc=336 || cycle=11472186 target=11472181

spc-pre         hc=1320 vc=170 fc=336 || cycle=11472186 target=11472181
36:8537  A=0059 hc=1320 vc=170 fc=336
spc-post        hc=1350 vc=170 fc=336 || cycle=11472186 target=11472184

spc-pre         hc=1350 vc=170 fc=336 || cycle=11472186 target=11472184
36:853A  A=0059 hc=1350 vc=170 fc=336
spc-post        hc=8 vc=171 fc=336 || cycle=11472186 target=11472186

spc-pre         hc=8 vc=171 fc=336 || cycle=11472186 target=11472186
36:8537  A=0059 hc=8 vc=171 fc=336
...0961  A=53   hc=38 vc=171 fc=336 || cycle=11472186 target=11472189
spc-post        hc=38 vc=171 fc=336 || cycle=11472192 target=11472189

spc-pre         hc=38 vc=171 fc=336 || cycle=11472192 target=11472189
36:853A  A=0059 hc=38 vc=171 fc=336
spc-post        hc=60 vc=171 fc=336 || cycle=11472192 target=11472191

spc-pre         hc=60 vc=171 fc=336 || cycle=11472192 target=11472191
36:8537  A=0059 hc=60 vc=171 fc=336
...0963  A=53   hc=90 vc=171 fc=336 || cycle=11472192 target=11472194
spc-post        hc=90 vc=171 fc=336 || cycle=11472200 target=11472194

Posted: **Sun Jun 30, 2019 6:58 pm**

Sour wrote:I gave fixing the whole DMA/IRQ timing issue a try, too. Wrote a pretty simple test suite to validate a few scenarios on hardware. Waiting on the hardware results, but for now I'm assuming higan is correct and my implementation gives the same result as higan for the test. It also fixes the power rangers game, too.

You've definitely got the right idea to always confirm on real hardware.

I don't have an actual solid explanation for things like the IRQ lock, and even though I understand the DMA->CPU sync, it makes no sense to me why the CPU would need that to occur. The CPU->DMA sync, sure, I get that part.

I think I made a list of all my known-unknowns already. But it's very possible if you go poking about in the shadier bits, you'll find something I don't emulate or get wrong, so always be suspicious. I'd hate for an error on my part to get repeated everywhere until it becomes 'canon' ^_^

If you or anyone else does find anything I fail, please please let me know.

...

Ranger R2 behavior

Try to match the cycle timings to bsnes' trace logs. That should very quickly reveal any timing misalignments.

The big one is going to be DMA<>CPU sync. If Sour has that, you should get a perfect match by ensuring both emulators use the same CPU<>SMP clock frequencies. Even if they don't *actually* run in sync, as long as they sync up before reads/writes to $2140-7f / $fx, it should be fine.

Mesen-S may need the bus hold delays to 100% match: I loosely simualte the analog nature of the bus holding addresses/data for 6-12 cycles by performing the reads 4 cycles before the end of the actual read (so 2,4,8 cycles in) to simulate the observable difference between latching the PPU counters via $2137 reads and $4201 writes.

Posted: **Sun Jun 30, 2019 7:50 pm**

byuu wrote:I don't have an actual solid explanation for things like the IRQ lock

My implementation is simple at the moment, after a write to $420B, the next cycle reads the next opcode, then the DMA takes over, once the DMA is finished, that instruction resumes as normal. At the very least, it gives the same result as higan for the test I wrote (and the hardware result is identical, too). I'm assuming there is something else in the way I am keeping track of the IRQ flags that makes it so I don't need to do any additional processing for this (or maybe my current implementation is not 100% accurate, either).

byuu wrote:Try to match the cycle timings to bsnes' trace logs. That should very quickly reveal any timing misalignments.

Speaking of which, do you have a build of bsnes/higan I could use to produce trace logs? bsnes-plus is different enough that I would rather be able to compare with higan itself. If I could just somehow make them sync perfectly for the first few hundred thousand operations, then I might be able to figure out what the remaining issues are.

The DMA/HDMA sync is one of the last few things I can see as the cause for the SPC issues, at the moment, but I've already spent a lot of time trying to get it right a couple of months ago, so unsure how much still has to be fixed there. I also made a test rom a couple of months ago that tries to catch errors in dma/hdma/irq timings (by running a bunch of DMAs and IRQs, and running some code during several frames filled with HDMA, etc.):

That's what the results look like atm (right side is koitsu's SNES with a sd2snes). It's not really a conclusive test on anything, but it did help me figure out a number of issues in my DMA logic so far, and it looks like there's something odd about the HDMA timing in mesen-s, but at the same time, I don't think any of the games that freeze really use HDMA before freezing, so...

I loosely simualte the analog nature of the bus holding addresses/data for 6-12 cycles by performing the reads 4 cycles before the end of the actual read (so 2,4,8 cycles in) to simulate the observable difference between latching the PPU counters via $2137 reads and $4201 writes.

Well, that's something I didn't expect...

topspoon wrote:Ranger R2 behavior

Thanks - I'll try comparing some trace logs on my end too over the next few days and see if I can figure out the differences between higan and Mesen-S. There has to be one or two relatively major things that might explain why so many games freeze up at boot.

Posted: **Sun Jun 30, 2019 8:23 pm**

To me, the main kicker is when bsnes-plus updates the 2143 cpu reads:

Code: Select all

..095f mov   $0f7,a           A:53 X:06 Y:0c SP:01fb YA:0c53 nvpbhizc
368530 bne $852d     [36852d] A:0253 X:0001 Y:0005 S:01f1 D:0000 DB:36 nvMXdIzC V: 90 H: 748 F:59
36852d cmp $2143     [362143] A:0253 X:0001 Y:0005 S:01f1 D:0000 DB:36 nvMXdIzC V: 90 H: 770 F:59
368530 bne $852d     [36852d] A:0253 X:0001 Y:0005 S:01f1 D:0000 DB:36 nvMXdIzC V: 90 H: 800 F:59
..0961 cmp   a,$0f7           A:53 X:06 Y:0c SP:01fb YA:0c53 nvpbhizc
36852d cmp $2143     [362143] A:0253 X:0001 Y:0005 S:01f1 D:0000 DB:36 nvMXdIzC V: 90 H: 822 F:59
368530 bne $852d     [36852d] A:0253 X:0001 Y:0005 S:01f1 D:0000 DB:36 nvMXdIZC V: 90 H: 852 F:59
368532 lda #$59               A:0253 X:0001 Y:0005 S:01f1 D:0000 DB:36 nvMXdIZC V: 90 H: 868 F:59
..0963 bne   $0961            A:53 X:06 Y:0c SP:01fb YA:0c53 nvpbhiZC

Notice how spc writes to $f7. Then cpu side still spins a few times afterward. Because it's still reading value $43 from $2143. After 0961 runs, $2143 is updated and cpu can exit.

If you can print the low-level timing logs from bsnes of what happens each cycle in that code block, you'll see exactly when $2143 is updated with the new value $53.

Which is definitely not immediate but enough master cycles away from when "mov $0f7,a" actually starts. By the time "cmp a,$0f7" executes, $2143 is guaranteed to return a clean stable value.

I can't explain this better. Please try getting the low gritty raw timing #s out of bsnes. 1 master cycle at a time. Then you'll see what I'm trying to point out in my previous log.

Note that Mesen-S basically does this:

Code: Select all

mov $0f7,a

cmp $2143
bne $852d
lda #$59
sta $2143

See how emu updates $2143 way too early? CPU doesn't even spin around at all!

You'll need to record a cycle timestamp of when $2143 needs to refresh its new value. And return some stale or mutated value before then.

That's the best of my ability to describe what I'm seeing. Sorry. But I'm confident you'll get a solution put into Mesen-S soon.

edit:
I know there's some Japan games with unusual mappings. Snes9x suggests these but I don't remember the physical names.

Code: Select all


		if (strncmp(ROMName, "SOUND NOVEL-TCOOL", 17) == 0 ||
			strncmp(ROMName, "DERBY STALLION 96", 17) == 0)
			Map_ROM24MBSLoROMMap();
		else
		if (strncmp(ROMName, "THOROUGHBRED BREEDER3", 21) == 0 ||
			strncmp(ROMName, "RPG-TCOOL 2", 11) == 0)
			Map_SRAM512KLoROMMap();

I know others will eventually bring up the multi-carts and other fun stuff in the no$cash archive.

If I see anything else that interests me, I'll chime in. Probably not since the details are getting too low-level technical.

Posted: **Mon Jul 01, 2019 12:15 am**

Speaking of which, do you have a build of bsnes/higan I could use to produce trace logs?

Ah yes, I still need to make that for you ... can you compile from source? If so, it'll save me some effort making a Windows binary on my other dev box. I'll use bsnes v107, which is identical to higan once you disable all the speed hacks (eg scanline-based renderer.)

I've already spent a lot of time trying to get it right a couple of months ago

It'll be essential to match my timings exactly, so I guess we'll find out soon ^-^;

Well, that's something I didn't expect...

When my hands feel better, I'm going to write an article about this. But here's the basics:

Say the SNES CPU executes an instruction, and one instruction reads from $7e2000. What actually happens is the CPU sets the 24 address bus pins to $7e2000, and then sets the /RD (read) pin. Since $7e2000 is normal speed ("SlowROM"), it then waits 8 master clocks. Anything on the bus will be watching the address pins, seeing the /RD signal, and if they choose to, they can drive the eight data bus pins. The SNES WRAM chip is what responds in this case (technically the CPU probably does it, but I digress.) After the eight cycles, the CPU stops driving /RD, and then it samples the current data bus pins for the resultant value.

Writes are similar: it sets the address bus, sets the data bus, sets the /WR pin, and then waits eight cycles. Any chip that cares will have eight master cycles to copy the data bus value. And things do: the S-DD1 watches $43xx DMA register writes to do its magic.

The key here is: the CPU doesn't read or write exactly after the 6, 8, or 12 cycles to whatever address is pointed at.

Things come into play like propagation delays, waiting for bus values to stabilize, etc.

If we want to get even more pedantic, the Game Boy and Z80 are known for having behaviors that occur on either the rising or falling edge of clock cycles. bsnes has some careful ordering of operations (DMA, ALU, etc) that is likely hiding what is in reality differences between rising and falling edges (or perhaps just 1hz differences ... internally bsnes steps its CPU at 2hz at a time over the 21.47MHz master clock.)

This pedantry comes into play in many cases:

For the SNES, $2137 reads latch the counters four clocks before $4201 writes. If you just emulate the read/write at the end of the 6, 8, 12 clock cycles, the counters would latch the same value, and that would be incorrect.

For the Game Boy, writes to the wave RAM trigger take effect two clock cycles after writes to wave RAM. If you don't emulate that, you will have to do crazy latching to pass blargg's dmg_sound tests.

For the Mega Drive, lots of chips share the same bus and assert "acknowledge" and "refresh" pins (eg /DTACK, /RAS) that cause the CPUs to pause until those pins stop being driven.

Of course, an operation doesn't have to 'complete' by the end of a write cycle, it only has to latch a copy of what's on the data bus by that point, lest the data bus change soon after. So it could be that a read from $2137 happens after 6 cycles, but a write to $4201 latches counters after 10 cycles.

How do we know the difference? We don't! And short of some hardware god analyzing chips decaps, we can't!

All we can really do is emulate these differences as we find ways to observe them. I suspect if and when get get really deep into PPU cycle timings, we're going to find that my current model of reads at cycle_count-4, writes at cycle_count-0 is too simplistic.

But for now, with the knowledge I have, I base all of my timings as stated above. The real hell though is, change those values and all of my carefully constructed timing values break. Perform reads at cycle_count-2, and now when the PPU sets the Vblank and Hblank bits are off by two clocks, etc.

I have no real solution for this mess right now.

You'll need to record a cycle timestamp of when $2143 needs to refresh its new value. And return some stale or mutated value before then.

As I stated earlier, Rendering Ranger R2 is one of many games that absolutely requires cycle-level synchronization of the SMP to the CPU. If the CPU is calling the SMP, and the SMP is executing entire instructions before returning, then it's not going to work. It will work in much less accurate emulators by futzing with the timings (as in ZSNES and older Snes9X versions), but it will break when you get more cycle accurate timings (as in bsnes and Mesen-S. I also wrote a cycle-accurate SMP core that Snes9X uses now.)

Posted: **Mon Jul 01, 2019 4:04 pm**

byuu wrote:As I stated earlier, Rendering Ranger R2 is one of many games that absolutely requires cycle-level synchronization of the SMP to the CPU. If the CPU is calling the SMP, and the SMP is executing entire instructions before returning, then it's not going to work.

And you sir, were completely right! I'm amazed that something like this has a major impact, but it actually does, heh.

Spent the morning trying to come up with a timestamp solution - I thought it worked, all the games were fixed. ..Except it broke a ton of other games. So I scrapped that, and figured I'd just give in and rework the code to be able to run a single SPC cycle at a time. And lo and behold, it works! Just doing that fixes Hiouden, Illusion of Gaia, ActRaiser 2 and Tales of Phantasia.

Rendering Ranger R2 boots, but freezes right after the first screen. Kishin Douji Zenki doesn't boot at all. However, overclocking the SPC by just ~2% makes both of these work, so I'm guessing there might be some small details left that need to be fixed to fix these.

With this (mostly) fixed, I can finally start focusing on reworking the PPU code to fix the few games that rely on the tile prefetch and fix the mosaic effect, too.

byuu wrote:Ah yes, I still need to make that for you ... can you compile from source?

Depends what the requirements are, really, but I can probably manage - if you have a modified source with built-in tracing features that'd be great (or is this just part of the regular code, behind a compiler switch?)

byuu wrote:For the SNES, $2137 reads latch the counters four clocks before $4201 writes. If you just emulate the read/write at the end of the 6, 8, 12 clock cycles, the counters would latch the same value, and that would be incorrect.

Didn't expect the timing of the read/write within the cpu cycle to be different. Though I can't quite recall if the NES is the same or not.

topspoon wrote:If I see anything else that interests me, I'll chime in. Probably not since the details are getting too low-level technical.

Thank you so much for all your help until now! If you find anything else, please let me know and I'll take a look!

Posted: **Mon Jul 01, 2019 9:02 pm**

This could be wrong, but I tried this:

Code: Select all

static uint8_t prev[4];
uint8_t Spc::CpuReadRegister(uint16_t addr)
{
	Run();
	return prev[addr & 0x03] | _state.OutputReg[addr & 0x03];
}


void Spc::Run()
{
	uint64_t targetCycle = (uint64_t)(_memoryManager->GetMasterClock() * _clockRatio);
	while(_state.Cycle < targetCycle) {
		if(_opStep == SpcOpStep::ReadOpCode) {
			_opCode = GetOpCode();
			_opStep = SpcOpStep::Addressing;
			_opSubStep = 0;
		} else {
			for(int lcv=0; lcv < 4; lcv++) prev[lcv] = _state.OutputReg[lcv];
			Exec();
		}
	}
}

and Rendering Ranger R2 + American Tail also works. But no Kishin Douji Zenki - Tenchi Meidou.

Above hack introduces bad luck?

Posted: **Mon Jul 01, 2019 10:07 pm**

Sour wrote:Rendering Ranger R2 boots, but freezes right after the first screen. Kishin Douji Zenki doesn't boot at all. However, overclocking the SPC by just ~2% makes both of these work, so I'm guessing there might be some small details left that need to be fixed to fix these.

Did you have it at 32,000 Hz before, or 32,040?

Posted: **Tue Jul 02, 2019 5:05 am**

Code says:

Code: Select all

_clockRatio = (double)2048000 / _console->GetMasterClockRate();

_masterClockRate = _region == ConsoleRegion::Pal ? 21281370 : 21477270;

Don't know how to convert to audio rate.

Posted: **Tue Jul 02, 2019 5:44 am**

2,048,000 / 64 is 32,000. The audio sample rate was determined to be ~32,040 though:

https://forums.nesdev.com/viewtopic.php?f=12&t=17644
http://helmet.kafuka.org/byuubackup2/vi ... =1455.html

Posted: **Tue Jul 02, 2019 2:07 pm**

creaothceann wrote:Did you have it at 32,000 Hz before, or 32,040?

Either value behaves the same, unfortunately.
Also, anomie's docs claim his SPC ran at 1026900Hz = 32090Hz, so it looks like the range on the actual clock speed is pretty wide. I'm fine with changing it to 32040Hz, though, if that's what's been determined to work the best? But was just a bit curious.

klurey wrote:This could be wrong, but I tried this:

I'm not sure myself - does anybody (byuu?) know if the OR behavior on simultaneous read+write from the SPC+CPU is something that some licensed games are known to rely on?

Posted: **Tue Jul 02, 2019 2:24 pm**

Sour wrote:Also, anomie's docs claim his SPC ran at 1026900Hz = 32090Hz, so it looks like the range on the actual clock speed is pretty wide.

Ceramic resonators, like used with the SPC700, just don't keep time very precisely. We should expect to find SPC700s running at ±0.5% of the nominal rate, and it should drift over time. +90Hz is only 0.3%...

For maximal programmer/ROM hacker adversity, I'd say it should pick a random rate ±160Hz of nominal on emulation start, and should slowly drift over ±32Hz of that while it's running

Posted: **Tue Jul 02, 2019 9:09 pm**

I'm fine with changing it to 32040Hz, though, if that's what's been determined to work the best? But was just a bit curious.

I found that d4s' Breath of Fire II (German) fan translation's streaming HDMA audio engine was extremely timing sensitive, and didn't work well at 32000hz. qwertymodo reverted Snes9X from 32040hz to 32000hz, and it ended up breaking a few titles and had to be reverted back to 32040hz.

It's an annoying wart that only applies to systems with more than one oscillator. But most tests come back at 32040hz, so I went with that rather than the canonical clock rate. I think we've confirmed the quartz CPU NTSC clock rate is good, and judging by that, the CPU PAL clock rate is likely good as well (eg not exact, but nowhere near as fluctuating as the ceramic SMP clock.)

As it stands now, with frequencies that not only vary per console, but depending on their temperature (they change at runtime, by the way), that makes creating any kind of reliable test for behaviors like ORing during simulatneous accesses near impossible.

Something I'm hoping for is to get a modded SNES console that replaces the two oscillators with a single, faster oscillator and then uses dividers to get approximately the original SNES rates.

I would also probably have to bring my USART board out of retirement, because my two 21fx units aren't designed to handle multiple insertion cycles to move them between consoles.

I'm not sure myself - does anybody (byuu?) know if the OR behavior on simultaneous read+write from the SPC+CPU is something that some licensed games are known to rely on?

I don't emulate it and at this time, and I have 100% (known) compatibility.

I would still like to emulate it anyway. As well as (if it turns out to be true) the errata mentioned around performing 16-bit writes to the ports.

For maximal programmer/ROM hacker adversity, I'd say it should pick a random rate ±160Hz of nominal on emulation start, and should slowly drift over ±32Hz of that while it's running :P

I'm seriously running out of headroom, but that's the kind of pedantry I'd love to emulate if computers were faster :c

Posted: **Tue Jul 02, 2019 10:22 pm**

byuu wrote:Something I'm hoping for is to get a modded SNES console that replaces the two oscillators with a single, faster oscillator and then uses dividers to get approximately the original SNES rates.

How hard would it be to build an 8:7 PLL to turn the 21.47 MHz master clock into 24.55 MHz to give 31960.2 Hz output?

Posted: **Tue Jul 02, 2019 11:02 pm**

Silicon Labs makes a part (Si5351) that will divide your choice of UHF oscillator frequency (chosen in the 600-900MHz range, and phase-locked to an external reference clock) by almost any rational number. It even has some amount of nonvolatile storage so you don't need anything to configure it at runtime. Getting the two nominal frequencies for the SNES would be straightforward.

nesdev.org

Mesen-S - SNES Emulator

Re: Mesen-S - SNES Emulator

Re: Mesen-S - SNES Emulator

Re: Mesen-S - SNES Emulator

Re: Mesen-S - SNES Emulator

Re: Mesen-S - SNES Emulator

Re: Mesen-S - SNES Emulator

Re: Mesen-S - SNES Emulator

Re: Mesen-S - SNES Emulator

Re: Mesen-S - SNES Emulator

Re: Mesen-S - SNES Emulator

Re: Mesen-S - SNES Emulator

Re: Mesen-S - SNES Emulator

Re: Mesen-S - SNES Emulator

Re: Mesen-S - SNES Emulator

Re: Mesen-S - SNES Emulator