Mesen - NES Emulator

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

User avatar
Dwedit
Posts: 4460
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Mesen - NES Emulator

Post by Dwedit » Thu Apr 22, 2021 9:03 am

Was the hack tested on Power Pak or Everdrive?
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

mkwong98
Posts: 265
Joined: Mon May 30, 2011 9:01 pm

Re: Mesen - NES Emulator

Post by mkwong98 » Thu Apr 22, 2021 9:12 am

CharCorr wrote:
Thu Apr 22, 2021 5:21 am
Hello again.

mkwong98, I tried your fork of Mesen. The new one with the changes to the MMC3 IRQ. Sorry to say that in this version, the Mega Man 3 Improvement hack crashes on the title screen every time. No matter what the settings are, it delivers "invalid op code - CPU crashed" and flips out. Darn. :(
That's odd, I tried both x86 and x64 and they didn't crash.
Which version do you use?
Does it work if you revert back to earlier releases?
Do you use a patched ROM or do you let the emulator apply the patch?

CharCorr
Posts: 3
Joined: Tue Jan 12, 2021 10:28 am

Re: Mesen - NES Emulator

Post by CharCorr » Thu Apr 22, 2021 10:18 pm

I tried it softpatched and hardpatched. I also ran on a fresh install with only what the emulator came with. All default settings.

But I then tried the hack on a previous version of the mkwong98 fork I knew the hack to work on. And it crashes there too. Then I tried on the base Mesen and it crashes there too. Something changed about my setup. I have no idea what it could be. I'll need to do some more investigation.

EDIT: OH, I found it! I had patched a NES 2.0 headered copy. The hack crashes if it has the NES 2.0 header. Or at least one configured like this one is. I'll need to check it further to see if I can find exactly what part of the header is the cause.

EDIT 2: I checked. The header is what it should be for Mega Man 3. But it just doesn't work for the hack unless you go to ines 1.0 header style. Does the hack use work ram or chr ram by chance?

The hack only has the previous known issues when run in Mesen now, with the ines 1.0 header. Kuja Killer's "wait for h blank loop" fixes the stage select screen jiggle, though not the pause menu oddness.

Sorry for the weird report. :?

unregistered
Posts: 1184
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: Mesen - NES Emulator

Post by unregistered » Fri Apr 23, 2021 1:31 am

mkwong98,

Sour, near the top of page 50, replied:
You can try using the "register" ("G" in mlb files for 'global') type labels for your scenario, maybe it'll work as you expect it to.
Essentially, they are CPU memory labels ($0000-$FFFF) that ignore all banking, etc. This is the type of label used to define the PPU/APU registers. The rules for them to be used in the disassembly window are slightly different, but might work for your case.
I’m not sure where his explanation of each .mlb letter is. Maybe I’m just imagining an explanation list of each .mlb letter. 🙃


He said the P: is for PRG ROM. That conversation is also at the top of page 50:
The "PRG ROM" labels are not based on the address of bytes in the CPU's memory (e.g $0000-$FFFF), but rather based on their offset in the .nes file (excluding the header). i.e it's an offset in the entire PRG ROM.

So while your first "abyte" might be at offset $1000, the 2nd one could be at $23000, for example (even though at runtime they are both mapped to $9000 in the CPU's address space, in the actual .nes rom, they refer to different bytes). Mesen treats these as completely independent labels. If it was possible to give 2 different bytes in the PRG ROM the same label, some functionality would no longer work properly (e.g right-click, edit in memory viewer, etc.)

mkwong98
Posts: 265
Joined: Mon May 30, 2011 9:01 pm

Re: Mesen - NES Emulator

Post by mkwong98 » Fri Apr 30, 2021 7:07 pm

Hi Dwedit,

I'm updating the documentation to include the new features and I'm trying out the comment editor. I have found a inconsistency with it and hope you can help fixing:
If a comment is added using the comment editor to a line which doesn't have a label, the comment editor will automatically add a label to that line. If that comment with the auto label is deleted using the comment editor, the comment editor will delete the label too. However if I set the label to blank using the label editor and then delete that comment using the comment editor, the comment editor won't delete the blank label. The result is that the line will look clean but actually has a blank comment and a blank label. So the next time I add a comment to that line with the comment editor, the comment editor won't automatically add a label.

And if you want to write up the documentation for the comment editor, you can post it here and I'll add it or you can edit the Docs\content\debugging\Debugger.md directly. I'll make a documentation release later.

Thanks

mkwong98
Posts: 265
Joined: Mon May 30, 2011 9:01 pm

Re: Mesen - NES Emulator

Post by mkwong98 » Tue May 04, 2021 8:50 am

I'm working on the documentation and I'm having trouble with taking screen shots of the updated forms. When I run Mesen, it uses a font different from the font used in the old screen shots:
AudioOptions_Advanced.png
HdPackBuilder.png
The original can be found here:
Image
Image

I need new screen shots of those two forms and any help would be appreciated. Thanks

User avatar
Dwedit
Posts: 4460
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Mesen - NES Emulator

Post by Dwedit » Tue May 04, 2021 12:46 pm

*facepalm* Windows can be silly sometimes...
It's changing the default font depending on system locale. If a control or form doesn't specify a font, it instead uses the DefaultFont property.
This will end up using the font specified by GetStockObject(DEFAULT_GUI_FONT).

On English locale, the default font is "Microsoft Sans Serif" size 8.25, but those screenshots look something like "SimSun", can't exactly identify the font.

Using reflection, you can actually change the default font. Set the backing field for the private static variable "Control.defaultFont" to something else. But any open forms will need their font changed as well.

***
Best solution:
Change "ResourceHelper.ApplyResources" to also set the Form's font based on which language is selected. That will also change the font of all controls within the form.
***

I don't know what the default fonts for the different languages of Windows are, can't easily find a page that lists them all.
English: "Microsoft Sans Serif"
Chinese: "SimSun" (?)
Japanese: "MS UI Gothic" (?)



***
Quickest workaround:
Run this before any forms are created:
typeof(Control).GetField("defaultFont", BindingFlags.NonPublic | BindingFlags.Static).SetValue(null, new System.Drawing.Font("Microsoft Sans Serif", 8.25f));
And you'll have the default fonts from the English locale.
***
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

User avatar
Gilbert
Posts: 476
Joined: Sun Dec 12, 2010 10:27 pm
Location: Hong Kong
Contact:

Re: Mesen - NES Emulator

Post by Gilbert » Tue May 04, 2021 6:14 pm

Dwedit wrote:
Tue May 04, 2021 12:46 pm
Chinese: "SimSun" (?)
Worse still, that font is just for Simplified Chinese (as signified by the "Sim" in the font name; it's not a font created by Maxis!), so it's not for the other half of Chinese people (like me).
Because of this I often set the locale of my Windows to English or Japanese top reduce UI problems as much as possible. I rarely need to run programmes in Chinese anyway. (My take on software is that unless I cannot read that language I'll try to run them in their original language of creation whenever possible.)

mkwong98
Posts: 265
Joined: Mon May 30, 2011 9:01 pm

Re: Mesen - NES Emulator

Post by mkwong98 » Wed May 05, 2021 9:10 am

Dwedit wrote:
Tue May 04, 2021 12:46 pm

***
Best solution:
Change "ResourceHelper.ApplyResources" to also set the Form's font based on which language is selected. That will also change the font of all controls within the form.
***
Thank you for this solution!

mkwong98
Posts: 265
Joined: Mon May 30, 2011 9:01 pm

Re: Mesen - NES Emulator

Post by mkwong98 » Tue May 11, 2021 12:28 am

I updated the documentation and added it to the previous release:
https://github.com/mkwong98/Mesen/relea ... 9.9-210415

mkwong98
Posts: 265
Joined: Mon May 30, 2011 9:01 pm

Re: Mesen - NES Emulator

Post by mkwong98 » Thu May 13, 2021 9:03 am

I notice the Sprite Viewer is showing the Position Y using the value in the first of the 4 bytes in OAM instead of the actual position on screen (byte value + 1). Which one works better for you?

I'm asking this because the "Copy All Sprites (HD Pack Format)" function is giving me the byte value, but the HD Pack condition "SpriteAtPosition" is expecting byte value + 1 and it took me a while to realize this. If more people prefer to keep it as it is then I'll change the "Copy All Sprites (HD Pack Format)" function only, otherwise I'll change the displayed position too.

unregistered
Posts: 1184
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: Mesen - NES Emulator

Post by unregistered » Fri May 14, 2021 1:15 pm

mkwong98 wrote:
Thu May 13, 2021 9:03 am
I notice the Sprite Viewer is showing the Position Y using the value in the first of the 4 bytes in OAM instead of the actual position on screen (byte value + 1). Which one works better for you?

I'm asking this because the "Copy All Sprites (HD Pack Format)" function is giving me the byte value, but the HD Pack condition "SpriteAtPosition" is expecting byte value + 1 and it took me a while to realize this. If more people prefer to keep it as it is then I'll change the "Copy All Sprites (HD Pack Format)" function only, otherwise I'll change the displayed position too.
Ok, yes, I’ve read on the wiki that the screen adds 1 to the first byte of the OAM sprite values bc of some sort of delay. However, currently, our sprite is at a #$2F y position… OAM shows the 1st byte as $2F. After zooming in to 4x screen value it is really clear that the sprite is drawn at #$2E y position. So, I’m confused as to how the sprite is supposed to be displayed at 1st byte of OAM ($2F)+1 when the sprite is actually displayed at 1st byte of OAM ($2F)-1. :?


(The sprite appears to be at #$2F, but that sprite has a 1 pixel clear/transparent row at its top… so that would mean it’s showing up at #$2E? We want it to appear at #$30 y position.)

EDIT: The Sprite Viewer’s position says “143, 45”. So that’s declaring the sprite is positioned at #$1D y position? :?


FINAL-EDIT: To arrive at this debug position I used ALT+~ to step back a bit. Does step back really destroy sprite values? 😔

unregistered
Posts: 1184
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: Mesen - NES Emulator

Post by unregistered » Fri May 14, 2021 2:19 pm

Aaah… now it makes a bit more sense. After opening Sprite Viewer, the first OAM byte has also changed to #$2D. So the sprite is correctly displayed (at #$2E, like I thought). That change of OAM-value-displayed happened even though the game has been paused this entire time.

Though, a #$2E y value is not wanted so troubleshooting continues. :)

I guess, in the future, I’ll always open Sprite Viewer to correct OAM values after stepping back a bit. 🙂


Note: It makes sense to me that since, Sprite Viewer is a widow that displays information about sprites on the screen, the y value displayed in position should reflect the screen’s interpretation of the corridinates (y+1). :)

FINAL-EDIT: Maybe you could add a tiny “(y+1)” below the y position on the Sprite Viewer to alert the casual user?

mkwong98
Posts: 265
Joined: Mon May 30, 2011 9:01 pm

Re: Mesen - NES Emulator

Post by mkwong98 » Tue May 18, 2021 7:40 pm

Thanks, I'll change the viewer to show Y+1 and add a note about this.

unregistered
Posts: 1184
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: Mesen - NES Emulator

Post by unregistered » Thu May 20, 2021 1:47 pm

mkwong98 wrote:
Tue May 18, 2021 7:40 pm
Thanks, I'll change the viewer to show Y+1 and add a note about this.
Cool! :D You’re welcome. :)

Post Reply