It is currently Tue Jul 16, 2019 12:59 am

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 206 posts ]  Go to page Previous  1, 2, 3, 4, 5 ... 14  Next
Author Message
PostPosted: Mon Apr 01, 2019 11:51 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2303
Location: Fukuoka, Japan
Good to see that it finally came out! I will give it a try on linux but will completely ignore mac testing for now (never restored the partition and don't feel like it :lol: )


Top
 Profile  
 
PostPosted: Tue Apr 02, 2019 5:35 am 
Offline
User avatar

Joined: Mon Jan 23, 2006 7:47 am
Posts: 189
Location: Germany
Some minor things:
- You could mention on the website that spc700.rom can be found in higan's source code archive as ipl.rom :D
- In the key bindings window, Shift is not differentiated. Also, the program disappears from the Alt+Tab list when the window is open. (Win7)
- Copy protection screen in DKC is triggered.

byuu wrote:
[...] and time consuming ^^;
Yeah...

_________________
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10


Top
 Profile  
 
PostPosted: Tue Apr 02, 2019 9:09 am 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 706
AxlRocks wrote:
Mega Man X's copy protection is getting triggered.
Looks like this was a mirroring issue, tepples' explanation on mirroring ROMs that aren't powers of 2 seems to have fixed it. Will try to setup appveyor dev builds tonight & commit the fix for it.

byuu wrote:
The CPU NMI and IRQ timing is based off of the Vblank and Hblank pin outputs from the PPU, and it keeps its own internal counters, which means that IRQ timings are not affected by long dots.
This (and well, your whole post really) is actually very important information, thanks!

I was actually already using a slightly modified older version of your heuristics that you had posted on the zsnes boards like a decade ago, actually. It's been working pretty well (far better than what I had done initially), but I haven't gotten to implementing Ex-HiRom and the like at all yet. The database info will definitely be useful whenever I need to confirm if the default mappings might be an issue or not. I might stick to heuristics for now (especially if they work for the vast majority of games), but might try incorporating the database eventually just for the sake of having accurate mappings for known boards.

SGB is probably not something I will end up supporting (or at least, not anytime soon), Sufami Turbo I hadn't even ever heard of yet!
But still, I think ~30 somewhat complex boards (e.g coprocessors, etc.) is probably more manageable than the NES' 300+ comparatively simple boards. Or at least, they're most interesting to work on when compared to implementing the 150th slight variation of an MMC3 clone :|

Banshaku wrote:
I will give it a try on linux but will completely ignore mac testing for now
It's essentially the same framework as Mesen uses, so it probably won't work too well on macOS anyway. Still hoping to find a proper solution someday, though.

creaothceann wrote:
- In the key bindings window, Shift is not differentiated. Also, the program disappears from the Alt+Tab list when the window is open. (Win7)
- Copy protection screen in DKC is triggered.
Shift not being differentiated is a bit of a limitation to the way keys are processed in both Mesen & this one. I can't remember the exact details anymore, but I know I did actually try to fix this at some point in the past.. (did not find a viable solution, though)
I had assumed the whole disappearing from Alt-Tab when a tool window is opened to be a Windows issue (but maybe its a WinForms issue?), I've always found this to be pretty annoying myself, though. I'll try and see if there's a solution for it.
Thanks for the DKC report - based on the tcrf, it's most likely a SRAM mapping issue, will take a look tonight.


Top
 Profile  
 
PostPosted: Tue Apr 02, 2019 9:37 am 
Offline

Joined: Mon Apr 01, 2019 12:23 am
Posts: 4
Sour wrote:
Thanks for those tests, by the way! They were extremely useful when I started this and helped me fix a pretty large amount of CPU bugs (though I did find a few bugs that they don't seem to catch - if you're interested in adding some more test cases to them, let me know and I'll try to come up with a list of things I found so far)

Yes I would love to make my cpu tests more useful to help new SNES emulation authors, let me know anything you want me to add, & I'll try to implement it =D


Top
 Profile  
 
PostPosted: Tue Apr 02, 2019 11:34 am 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 1177
Location: Hokkaido, Japan
Damn this is real?? I was reading this taking it half seriously thinking it was an april fools joke. A SNES emulator with both the Mesen and bsnes goodnes sounds like a dream coming true!

byuu wrote:
Many prototype games documented by Evan at snescentral will not work with heuristics, because the SNES header bytes are all blank. You will either need a database for them (I did not make one for prototypes), a way to externally specify board mappings, or tell users to patch their ROMs to fix the bad headers (preferably with a BPS patch.)
I always thought prototypes comes with blank headers because the authors just didn't bother filling them in on an unreleased game.

Anyway it sounds like sfc ROMs would benefit from an iNES-like format so that databases and heuristics can be avoided. The iNES/NES 2.0 header mess might want to be avoided though so maybe a more complete understanding of licensed games' mappings is needed before something like that is attempted.


Top
 Profile  
 
PostPosted: Tue Apr 02, 2019 1:57 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 706
Pokun wrote:
Damn this is real?? I was reading this taking it half seriously thinking it was an april fools joke.
Mission accomplished, I've managed to fool at least one person!

RE: Headered roms, I think that's essentially the problem that higan's game folders are meant to fix, without needing a binary format header in the rom itself. I know a lot of people apparently don't like them, but if you just zip them up and consider the zip file as a rom with a header, they're pretty much a functional solution, imo.

krom wrote:
let me know anything you want me to add, & I'll try to implement it
Looking at my commit history, here's a few things the tests don't catch at the moment:
Code:
-The CPUPHL test seems to rely on open bus behavior for $4210 reads, which is a good test in a sense, but also confusing when trying to debug it
-Shift operations when 8-bit memory flag is enabled shouldn't affect the MSB of the A register
-MVP/MVN:
  -Check that the destination/source bank are correct (I had inverted them by mistake)
  -Check behavior when A is set to $FFFF
  -Check that the value of DBR is altered by the instruction
  -Check the wrap behavior for X/Y when 8-bit indexes are enabled
  -Check that MVP/MVN can be interrupted by an interrupt (this one might be a bit outside the scope of CPU-only tests, though)
-TSC/TDC/TCD always transfer 16 bits, regardless of the 8-bit memory flag
-I think BRK/COP aren't tested at all? Could be wrong - I had forgotten about the signature byte and so RTI wasn't returning to the correct address.
-HDMA:
  -Check that the "fixed transfer" flag is ignored by HDMA
  -Check that the "decrement" flag is ignored by HDMA
  -Check that DMA gets cancelled by HDMA
  -Validate some of the DMA restrictions (e.g trying to DMA from work ram to work ram, etc.)
I think those are the main ones that aren't PPU-related at all. The ADC/SBC tests don't catch everything, either, but since blargg made some tests for those particular instructions, it's not a big problem. The majority of these I found and fixed by debugging games that didn't work properly, so having test roms to validate these would have saved me a lot of time (and having them for regression testing would still be nice, too). That being said, please don't feel like you *have* to add these! At the very least maybe this list will someday be useful for someone else trying to debug their emulator :p


Top
 Profile  
 
PostPosted: Tue Apr 02, 2019 2:14 pm 
Offline
User avatar

Joined: Wed Oct 22, 2008 9:27 pm
Posts: 103
Pokun wrote:
Anyway it sounds like sfc ROMs would benefit from an iNES-like format so that databases and heuristics can be avoided.


On the contrary, we should go back in time and obliterate all traces of ines. Databases aren't copyrighted and are immune to the update issues the NES scene wallows in daily.


Top
 Profile  
 
PostPosted: Tue Apr 02, 2019 2:51 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4149
Location: A world gone mad
I'm going to make this crystal clear: any attempt to "invent a new file format" to relieve whatever absolute nonsensical pedantry is posted by users in this thread will completely and utterly fail. Stop talking about it. The existing widespread formats already in use won (read: what came first is what stuck). 98% of the userbase will not switch fully functional ROMs to whatever you come up with. The methodologies being used to identify this as it stands (re: heuristics and internal database) are completely reasonable.

I will not be commenting on this matter further, as there is well-established history of people trying to invent "better crap" in the past (for both consoles) and failing miserably. Multiple times. Fin.


Top
 Profile  
 
PostPosted: Tue Apr 02, 2019 3:35 pm 
Offline
User avatar

Joined: Mon Jan 23, 2006 7:47 am
Posts: 189
Location: Germany
Sour wrote:
Shift not being differentiated is a bit of a limitation to the way keys are processed in both Mesen & this one. I can't remember the exact details anymore, but I know I did actually try to fix this at some point in the past.. (did not find a viable solution, though)
I had assumed the whole disappearing from Alt-Tab when a tool window is opened to be a Windows issue (but maybe its a WinForms issue?), I've always found this to be pretty annoying myself, though. I'll try and see if there's a solution for it.

The Shift key(s) seem to confuse the GUI a lot... really just minor issues though.

More notes:

  • When enabling "Show FPS", exiting the program and restarting it, the FPS is still displayed but the menu item is unchecked.
  • enabling G-Sync shows a frame rate of 60/52. The 60 occasionally becomes a 61 (as expected) and the 52 also changes sometimes. Here's a video. (At the end of it I switched to another program and back to Mesen-S.)
  • The Electronics Test in Nintendo's test cart (No-Intro: "World Class Service Super Nintendo Tester (USA).sfc") fails sometimes; also a line at the top is flickering.
  • Here's a comparison of the graphics test with bsnes v87 (via BizHawk). bsnes is to the left.
  • ActRaiser 2 (USA) doesn't get to the title screen (because it uses Direct Color mode?)
  • Axelay level 2 is broken here.
  • Chrono Trigger's time warp is broken.
  • In Jurassic Park, when you wait on the title screen it transitions via mosaic to the highscore list. This transition seems to be broken. During gameplay the left and right borders aren't cropped.
  • In Super Metroid after the title screen, the menu transitions that don't change the screen brightness don't look right (mosaic).

_________________
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10


Top
 Profile  
 
PostPosted: Tue Apr 02, 2019 4:21 pm 
Offline

Joined: Mon Apr 01, 2019 12:23 am
Posts: 4
Sour wrote:
Looking at my commit history, here's a few things the tests don't catch at the moment:...

Thanks for the list, I'll see what I can do to improve my tests, using the help you have given me =D


Top
 Profile  
 
PostPosted: Tue Apr 02, 2019 7:13 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1498
I have come to agree with koitsu. All of my attempts have failed, and I burned up a lot of good will in trying to force the issue, which I regret. My current stance is that we will never replace the current file formats and must support them, but that we can support our alternatives quietly as an *option* for people who care. With the appropriate reverence of insight from blargg that this *does* cause community fragmentation and confusion, and increase complexity for future authors like Sour (see xkcd.com/927). I don't think there's an easy answer here. People are going to be unhappy no matter what.

I sent Sour a DM with detailed information on these (and no requests to support any of it my way, don't worry), but for everyone else ... here's a short list of the complications of SNES emulation:
* coprocessor firmware files, including games that shipped with both DSP1 and DSP1B
* homebrew that wishes to write custom coprocessor firmware
* prototypes with missing or invalid headers
* Rockman X v1.0 has bodge wiring on the PCB to unmap the last 8mbit of address space to avoid triggering copy protection
* Super Game Boy carts that take Game Boy sub-cartridges (and black GBC cartridges)
* Nintendo Super System per-game DIP switches to toggle lives, difficulty, etc
* the Nintendo Super System machine which has three game slots
* the Super Famicom Box machine which has three game slots
* Super Famicom Box cartridges which hold 2-3 games each
* Campus Challenge '92 and Powerfest '94 which hold a menu ROM plus three games (No-Intro stores them as separate ROMs)
* BS-X slotted cartridges that take BS Memory Packs, which are writable and maintain block erase counters
* JRA / SPAT cartridges that have writable flash memory
* the Voicer-kun (official) and MSU1 (unofficial) add ~20 or so additional CD audio tracks to games
* homebrew often makes up new "mappers", like ExLoROM, the Tengai Makyou Zero fan translation, and neviksti's SDD1 removal patch
* Sufami Turbo cartridges that take *two* Sufami Turbo games at once (consider save states in linked mode)
* peripherals like the Super Turbo File store game saves inside of them (consider where to save that memory to)
* IPS patches will always have a 50% failure rate due to copier headers
* and a few more I'm likely forgetting ...

Any SNES emulator that wants 100% completeness is going to have to address all of these. In the end, I was able to support most of it with bsnes v107, following traditional and historical ways of distributing games. In fact, bsnes is pragmatic and supports 2-3 alternative methods for most points on that list. A few exceptions require higan, but those cases are not emulated by any other SNES emulators, and are very niche.

If anyone wants to beat a dead horse with me, please switch to DMs or post in a new thread. I don't want to see Sour's thread derailed with this stuff.

Quote:
whatever absolute nonsensical pedantry


The same ASD that led to me spending 15 years perfecting an emulator for a retro video game system is what also drives my obsession with supporting absolutely everything I possibly can. I get huge levels of anxiety when things aren't "perfect" in my mind. I can't really separate the two, nor is this a condition that can be cured. I know how annoying I've been about all of this, and you all have my apologies for that. I'll do my best going forward to act professionally. I'm hopeful that Sour's emulator will be a worthy alternative for people who are tired of putting up with me, and give me some more room to experiment with my emulator.


Last edited by byuu on Tue Apr 02, 2019 9:47 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Tue Apr 02, 2019 9:30 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 706
creaothceann wrote:
More notes:
Thanks for testing!
There was a off-by-1 bug that happened when overscan mode was off (which is the source of the random line showing up on screen & seems to explain most of the differences with the bsnes video), this should be fixed.
Axelay was a bug in the offset-per-tile logic, should be fixed too.
CT was a bug where some sprites were not being shown when they should have been, this is fixed.
The borders in Jurassic Park should be fixed, was caused by color math not being applied to the subscreen pixels in hires mode.

The screen transition issues with Jurassic Park and Metroid are caused by the buggy mosaic implementation - pretty much any game that makes use of mosaic effects doesn't show up quite right.

About G-Sync, I don't actually own a monitor that supports it, so it's hard for me to say. FYI, the first number is the number of frames the emulation core generated in the last second, and the 2nd number is the number of frames that were pushed to the video card in the last second. The only thing I could see that could make it fall below 60 is if the video card was freezing the rendering thread for an abnormal amount of time while waiting on vsync. I'd imagine you'd get the same result on Mesen, though.

ActRaiser 2 seems like it's freezing due to an SPC bug (much like Illusion of Gaia). There are a couple of games that no longer work after I replaced blargg's SPC core with my own (though my core also fixed 20+ games that did have SPC-related issues, too) - ActRaiser 2 looks like it's one of the regressions. I'll try to see if I can figure out why this one freezes, maybe I'll have better luck with it than with Illusion of Gaia.

Haven't had the chance to check DKC yet, will try to figure that one out tomorrow.

Also, I added appveyor dev builds (they're linked in the readme on github), so these fixes should be available in the latest appveyor build.

byuu wrote:
I sent Sour a DM with detailed information on these
Thanks for that, very useful information that will save me from having to rewrite some portions of the code when I inevitably stumble on some hardware I didn't foresee could exist (which will definitely still happen, but hopefully just a little bit less often :p)


Top
 Profile  
 
PostPosted: Tue Apr 02, 2019 10:16 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1498
::four fixes in a row::

Holy heck, you are on fire!

Quote:
About G-Sync, I don't actually own a monitor that supports it, so it's hard for me to say.


The main challenge of adaptive sync is that you need your audio buffers to be extremely small, eg WASAPI exclusive or ASIO. Since your only synchronization is now based on audio, if they're too big, the stalls waiting on audio buffers to empty will become too inconsistently spaced and scrolling will become choppy.

Quote:
There are a couple of games that no longer work after I replaced blargg's SPC core with my own (though my core also fixed 20+ games that did have SPC-related issues, too)


Speaking of ... blargg's DSP core is almost perfect. The one flaw is that it reuses the 128-byte RAM block for direct register values. On real hardware, the registers and underlying RAM are separate. Magical Drop will hang on game over in endless mode if the underlying RAM is not randomized (ENDX can't equal zero), but if you actually randomize the real registers, then King of Dragons won't work (expects internal KOFF register to be zero.) Well, that and muting the DSP isn't instantaneous on real hardware, but that's getting pedantic.

A simple fix is to add a second 128-byte RAM block. Write to both, but only read from the one you randomize on reset.

Quote:
very useful information that will save me from having to rewrite some portions of the code when I inevitably stumble on some hardware I didn't foresee could exist


Thanks for taking it well. I'm trying not to overload you with minutiae and scare you off ^^;

The SNES is endlessly complex, but as long as you take it one step at a time, each task is very manageable. It's a very rewarding system to work on, and I hope Mesen-S will inspire more emudevs to try.


Top
 Profile  
 
PostPosted: Tue Apr 02, 2019 10:27 pm 
Offline
User avatar

Joined: Mon Jan 23, 2006 7:47 am
Posts: 189
Location: Germany
Sour wrote:
About G-Sync, I don't actually own a monitor that supports it, so it's hard for me to say. FYI, the first number is the number of frames the emulation core generated in the last second, and the 2nd number is the number of frames that were pushed to the video card in the last second. The only thing I could see that could make it fall below 60 is if the video card was freezing the rendering thread for an abnormal amount of time while waiting on vsync. I'd imagine you'd get the same result on Mesen, though.

As far as I know the video card shouldn't block programs at all, it just pushes out a frame as soon as it receives one and then just waits for the next frame. It only waits for the monitor's vsync if you push frames faster than the monitor's specifications allow. I'll test Mesen later today. For now I just disable G-Sync.

I played Chrono Trigger up to Heckran Cave (to test the noise effect), didn't notice any other errors.

byuu wrote:
[...] Since your only synchronization is now based on audio [...]

Wouldn't it be possible to sync on the CPU's own high resolution timer (QueryPerformanceCounter in Windows)?


EDIT: Same thing with G-Sync happens in Mesen.

_________________
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10


Top
 Profile  
 
PostPosted: Wed Apr 03, 2019 2:09 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 706
creaothceann wrote:
Wouldn't it be possible to sync on the CPU's own high resolution timer (QueryPerformanceCounter in Windows)?
Yes, this is exactly what I do - high performance counters & sleep calls to regulate frame rate, and dynamically resample the audio to make sure it stays in sync.

Thanks for confirming it's the same on Mesen, at the very least it reduces the possible causes, though I'm still not quite sure what might be causing it. I'll keep it in mind and try to review that code eventually, but without a g-sync monitor it may be rather hard to fix (and I don't exactly want to buy a 300+$ monitor that I would never use again just to debug this :p)

Thanks for testing so much, by the way, really helpful to get bug reports like these. Let me know if you find anything else!

byuu wrote:
Speaking of ... blargg's DSP core is almost perfect. The one flaw is that it reuses the 128-byte RAM block for direct register values.
Yea, I don't really plan on rewriting the DSP core anytime soon (maybe much later on, just for the sake of having written my own). I think I saw you mention that register initialization problem recently somewhere else, too (maybe in another thread on here?). I'll add it to my list of things to check/fix, thanks!
byuu wrote:
The SNES is endlessly complex, but as long as you take it one step at a time, each task is very manageable. It's a very rewarding system to work on, and I hope Mesen-S will inspire more emudevs to try.
It seemed pretty daunting at first with the 100+ registers to implement and the seemingly endless number of PPU features, but being able to use Mesen's code as a stepping stone allowed me to waste far less time on non-emulation related code, so it's been surprisingly smooth sailing so far. I've been gathering/reformatting info/documents into a wiki of my own as I go, which helped a lot in getting familiar with everything (and having a reference I'm familiar with to consult whenever I need to confirm some details)


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 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