It is currently Wed May 22, 2019 2:02 am

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 83 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6
Author Message
PostPosted: Wed Apr 10, 2019 9:21 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1470
Both Circuit USA and Jumbo Ozaki rely on extremely accurate HDMA timing.

I see you implemented the early termination oddity with HDMA indirect transfers.

A fairly major issue in your current implementation is running all eight HDMA channels sequentially. You need to run through all eight channels and perform the HDMA transfers, and then go through all eight channels again to perform the HDMA indirect address fetches. Like so: https://gitlab.com/higan/higan/blob/mas ... ma.cpp#L33

Next, there are actually two parts to HDMA per-frame initialization. Regardless of whether any HDMA channels are enabled, you do this:
Code:
auto CPU::Channel::hdmaReset() -> void {
  hdmaCompleted = false;
  hdmaDoTransfer = false;
}

It takes no CPU time to complete (done in parallel.)

And then only if at least one HDMA channel is enabled:
Code:
auto CPU::hdmaSetup() -> void {
  step(8);  //we assume we've performed CPU->DMA sync already
  for(auto& channel : channels) channel.hdmaSetup();
  status.irqLock = true;
}

auto CPU::Channel::hdmaSetup() -> void {
  hdmaDoTransfer = true;  //note: needs hardware verification
  if(!hdmaEnable) return;

  dmaEnable = false;  //HDMA will stop active DMA mid-transfer
  hdmaAddress = sourceAddress;
  lineCounter = 0;
  hdmaReload();
}


Note the strange case of setting hdmaDoTransfer there. This was a weird edge case that ladida uncovered with HDMA.
That discussion, plus a test ROM, is here: https://forums.nesdev.com/viewtopic.php?f=12&t=16330
It's extremely odd behavior, I know. If you come up with a better theory, please do share.

Lastly, you should also implement the CPU->DMA->CPU sync timing instead of relying on 18 cycles being the average case. It's definitely annoying, and be careful about the edge case where HDMA triggers during DMA, that avoids the need for the DMA sync portion.

I'm fairly confident the above changes will fix those two bugs.

Quote:
Then I still have to figure out why Illusion of Gaia and ActRaiser 2 refuse to boot (almost certain this is SPC-related).


Check your implementation of PCALL/TCALL very closely, especially related to how they interact with the IPLROM enabled or disabled.

EDIT: well I looked it over, and it looks good as far as I can tell ... darn. I did find something interesting, though.

Code:
switch(addr) {
case 0xF0:
   if(!CheckFlag(SpcFlags::DirectPage)) {
      ...
      _state.WriteEnabled = value & 0x02;
      _dsp->setEchoWriteEnabled(_state.WriteEnabled);


I'm not sure nocash's fullsnes is entirely accurate here, or based on real hardware testing. I've never heard any confirmation that the SMP TEST register flags affect the DSP. If that's true, then value & 0x04 (RAM disable) would completely cripple the DSP.

I suspect this is not the case. The DSP controls the RAM and clock, and gives the SMP interleaved access to it. It doesn't make sense for the DSP to be inspecting the state of SMP I/O registers for its own RAM accesses.

It really doesn't matter in practice since no games ever write to this register, of course.


Last edited by byuu on Thu Apr 11, 2019 6:15 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Thu Apr 11, 2019 1:01 am 
Offline

Joined: Thu Feb 07, 2013 1:15 am
Posts: 129
Location: Sweden
This looks great! I couldn’t help myself from starting to muck around with a MacOS port...

The core library was easy enough to compile with a bleeding edge clang and some compiler flags (the dummy input manager drop-in dummy will need to actually do something, at some point). The big issue is the sorry state of Windows.Forms on MacOS; the current mono distribution only ships with a 32-bit Carbon version. So yeah. There are some signs of that being rectified “soon”. I’ll dig around a bit more.


Top
 Profile  
 
PostPosted: Thu Apr 11, 2019 8:01 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 668
byuu wrote:
A fairly major issue in your current implementation is running all eight HDMA channels sequentially.
Ah yea, I kept meaning to fix that, but forgot about it every time.

I've improved the start/end sync timing as well (wait until end of next cpu cycle, sync to multiple of 8, then sync back to a multiple of the CPU speed when stopping). It's probably still not quite perfect, though, but lo and behold, it actually fixed both Circuit USA and Jumbo Ozaki! (I actually went into this assuming that there was also probably more timing-related stuff that would need to be fixed for those games).

I also implemented the "DoTransfer" flag quirk, which makes that test you linked to work as expected.
FYI (just mentioning this since that other thread gave no firm answer on this), the "DoTransfer" flag does need to be reset to false during HDMA init, not doing so breaks both Ghouls 'n Ghosts and Aladdin.

Thanks for the help! I would never have even guessed that the games relied on near-perfect HDMA timing to work properly.

byuu wrote:
I'm not sure nocash's fullsnes is entirely accurate here, or based on real hardware testing
To be honest, I'm unsure why I left that part in. It was most likely part of my attempts to fix SPC issues while I was still rewriting it, though nocash's docs might have been the inspiration for this. Since you're saying the hardware most likely doesn't do this, I'll take it out.

Thanks for taking the time to check the SPC's code, btw. Currently have 4 games that seem to be having SPC-related issues: Illusion of Gaia, ActRaiser 2, Hiouden, Kishin Douji Zenki. Gaia/ActRaiser freeze during their opening sequences, Hiouden produces a screech and then freezes, Kishin doesn't boot at all. If I double the SPC's clock rate, they all boot and play sound normally, and changing the clock rate a little bit can cause some of them to get further or work normally.

Edit: Had forgotten about it, but Tales of Phantasia also has similar SPC-related issues.

Optiroc wrote:
I couldn’t help myself from starting to muck around with a MacOS port...
Yea, the whole Mono situation on macOS is a pity - wish it worked better. There was some related development done early last year, but I'm not sure if anything was actually improved as a result? At the moment the simplest way to use Mesen(-S) on macOS is probably via a VM (either Windows or Linux work, though Windows works better), at least if the main intent is to have access to the debugging tools.

I did manage to get a couple of builds (of Mesen) running in a macOS VM last year (the Linux build via Mono, and a modified Windows build via Wine), but both had issues (Wine had UI performance issues in the debugger tools, Mono just had all-around issues in the UI). If you do find a good way to get it running natively on macOS, please let me know!


Top
 Profile  
 
PostPosted: Thu Apr 11, 2019 8:47 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1470
Quote:
Ah yea, I kept meaning to fix that, but forgot about it every time.


No worries, it's regrettably something that wasn't known before anomie left, so it's not documented. I forgot which game that fixed, but it was definitely important for something.

Quote:
It's probably still not quite perfect, though, but lo and behold, it actually fixed both Circuit USA and Jumbo Ozaki!


We basically both solved these two games in opposite directions. I had CPU<>DMA sync first, and we found out about the indirect transfer short-circuit later. Once I had both in place, the games started working. Good to know both are required.

If I had all the time in the world, I'd love to know why these games break over such an infinitesimal difference in timing. Theoretically DMA<>CPU sync should average out to the same number of cycles anyway.

Quote:
the "DoTransfer" flag does need to be reset to false during HDMA init, not doing so breaks both Ghouls 'n Ghosts and Aladdin.


Ah, so that's still the case after adding this quirk. Good to know, thanks.
I'm still not 100% certain I have the rule right for when to set DoTransfer=true. It's quite the unfortunate behavior, because it misaligns your HDMA table reads, which is disastrous. But that test ROM clearly shows it's happening somehow, and I can't think of any other conditions that allow that test ROM to work properly.

Quote:
Since you're saying the hardware most likely doesn't do this, I'll take it out.


I can't prove it, and the SNES is often illogical. He could have verified this and just never told me, or I missed it. Mea culpa if that turns out to be the case.

But, with all respect to nocash ... he doesn't always clearly state what's verified on hardware versus what's speculation. He speculates often on unknowns, and some of it goes really far sometimes.

Still, the idea that the SMP is controlling the DSP's interaction to the RAM the DSP is directly connected to seems ... very unlikely.

Quote:
Thanks for taking the time to check the SPC's code, btw.


Sure, no problem. We could try producing trace logs. Log the cycle counts with each instruction, and see where our timings don't match up. I can patch my emulator to make such a trace log if you want to try that.


Top
 Profile  
 
PostPosted: Mon Apr 29, 2019 6:16 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 668
byuu wrote:
We could try producing trace logs. Log the cycle counts with each instruction, and see where our timings don't match up. I can patch my emulator to make such a trace log if you want to try that.
Sorry for the super late reply!

I actually spent a few days trying to figure this whole thing out, but haven't managed to quite yet. In the process I made a small test rom that runs a bunch of stuff (thousands of DMAs, HDMAs, IRQs, etc.) and checks the H/V counters at various points during the execution to try and catch any major timing issues in my code. I fixed a pretty large number of DMA-related timing issues and some other stuff (like the idle cycle that becomes a read cycle when an IRQ is pending, etc.). I've been getting results pretty close to the latest higan/bsnes (and much closer than the results I get in snes9x/no$sns), but it still hasn't fixed the SPC freeze issues, sadly. Also haven't managed to pass most of your irq/nmi/hdma timing tests either.

If you have a build that I could use to generate CPU+SPC trace logs, that would be helpful - I've been comparing the bsnes-plus', but I'd be much better to be able to compare w/ higan directly.

In the meantime, I ended up putting that problem aside for now and focused on adding some more debugger features (sprite viewer, labels/comments/CA65 integration, improvements to some of the existing tools, etc). Will probably keep working on some debugger tools & misc features for the next 2-3 weeks until I clear out the basic list of features I had written down when I started writing this whole thing, and after that I'll probably get back to trying to fix the remaining emulation issues.


Top
 Profile  
 
PostPosted: Mon Apr 29, 2019 10:02 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1470
No rush, I've moved onto Sega CD emulation lately, so I've kept busy meanwhile ^-^;;

Quote:
Also haven't managed to pass most of your irq/nmi/hdma timing tests either.


They are absolutely brutal tests. It took me months to get them working myself.

They are based around my creation of a function that, once run, it returns with Vcounter=0,Hclock=0,InterlaceField=0 and another function that steps by exactly the cycle count stored in A. You can see how with the two combined, I can make any operation occur at any clock cycle (at 21.47MHz/2). You'll want to make sure the first function works (if it does, so will the second) by looking at a tracer that also logs the H/V counters per instruction. If that doesn't work, most of my tests won't ever pass.

just know that they're not too important to 100% compatibility, and that I didn't release these tests for years because I didn't want them gamified. There's nothing more displeasing than people judging the value of a complex, 100K-line emulator based on whether it passes an arbitrary edge case test ROM.

I'll try and explain the NMI/IRQ behaviors I discovered when I have some time.

Quote:
If you have a build that I could use to generate CPU+SPC trace logs, that would be helpful


I have a built-in disassembler, and I compile a branch of higan/bsnes with them selectively enabled when I debug games.

Understood, I'll put together a trace logger version for you, please give me a few days.

Quote:
and after that I'll probably get back to trying to fix the remaining emulation issues.


Awesome, keep up the great work, and remember to take rests when you need them ^-^


Top
 Profile  
 
PostPosted: Fri May 17, 2019 6:00 pm 
Offline
User avatar

Joined: Thu Jul 13, 2017 5:17 pm
Posts: 51
Am I helping when I say this?...
Anyway:
DKC2's Copy protection screen triggers when you reset the game.
Proof is at the bottom.
Also is there a way to update the emulator? I keep getting an exception "System.Net.WebException".
With all that said, This is the best news I've heard. Sour making a sequel to the most advanced NES emulator? This could be legendary. With time and a lot of work, this could be on par with higan with better Debugging than No$sns!


Attachments:
copy.PNG
copy.PNG [ 46.06 KiB | Viewed 236 times ]

_________________
In Progress:
Tengu Tales (MMC3 Test first)[Tori & Shiro's "movement"]
Baseball Brawlers (MMC5 full features, "Yoshi's Island")[Vertical Scrolling]
Smash ("port",MMC5 )[On hold]
STH 1 (VRC7 On hold)
Top
 Profile  
 
PostPosted: Fri May 17, 2019 6:38 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 668
I'm guessing you're using 0.1.0? Both issues should be fixed already (but there hasn't been any other "official" release yet).
You can grab the latest dev builds with the fixes here: https://ci.appveyor.com/project/Sour/me ... /artifacts

I've fixed a pretty decent number of emulation issues since 0.1.0 (though some still remain) and a lot has been added/improved w/ regards to the debugger tools, too.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 83 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 12 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group