Mesen - NES Emulator

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

User avatar
Controllerhead
Posts: 314
Joined: Tue Nov 13, 2018 4:58 am
Location: $4016
Contact:

Re: Mesen - NES Emulator

Post by Controllerhead »

lidnariq wrote: Wed Sep 02, 2020 10:13 pm It might deal better with three PLA ? And it's only barely slower, 12cy instead of 10.
Good idea! Still broken though. But hey, 2 byte savings! Optimal for JSR if you don't want to return conditionally.

EDIT: I thought about it. The call stack should probably handle if/when a return address gets altered or overwritten. That seems appropriate.

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

Re: Mesen - NES Emulator

Post by unregistered »

Fiskbit wrote: Wed Aug 26, 2020 8:45 am This can be done with the "Mark selection as..." option in the right click menu either in the memory tools or the debugger's disassembly view, though the latter has the shortcoming that it can't be done on a byte-by-byte granularity.
tokumaru, to speed up the “Mark selection as...” process, and to also be allowed to edit “on a byte-by-byte granularity”, simply open your rom’s .cdl file with your hex editor.

The .cdl file is kept in Mesen’s “Debugger” folder. To find what byte to edit, use Mesen’s Debugger’s address list on its left side. If, for example, it says “DD80 [3D]” at the spot you want to edit, simply search “3DD80” in your hex editor. (The cdl address always begins with the digit(s) in [] and ends with that 4digit hex code’s last 3 digits.)


Oh, .mlb, in same folder, can be edited with a text editor to do all sorts of cool display things.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: Mesen - NES Emulator

Post by unregistered »

Ooh, I use .cdl hex codes:

If bit7 is set, that marks the start of a function.
If bit0 is set, that makes the code active (or makes it appear like it has already been run).


A hex code of #$02 specifies that the byte is part of a data section.
A hex code of #$00 specifies that the byte is part of unknown code... will be most likely hidden under a thin red box.


Sour replied to me, in this thread, about all the different cdl bit’s meanings, but the ones listed are the only cdl values I use. :)

He also replied to me, in this thread, about the interesting .mlb file and how it’s used. Search for that knowledge; it’s quite helpful, to me, at least. :)
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: Mesen - NES Emulator

Post by unregistered »

Is is possible to see the state of the serial register while using Mesen? (Maybe I’ve asked this before.)

edit: sry, if the debugger’s Event Viewer is opened, it’s evident that the last write to $2006 set the 2nd write flag.
Fiskbit
Posts: 890
Joined: Sat Nov 18, 2017 9:15 pm

Re: Mesen - NES Emulator

Post by Fiskbit »

Based on your edit, you mean w in the PPU? That's shown in the debugger as "Write Toggle", and yeah, you can see the state of w in the event viewer on $2005 and $2006 writes.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: Mesen - NES Emulator

Post by unregistered »

Fiskbit wrote: Tue Sep 22, 2020 3:55 pm Based on your edit, you mean w in the PPU? That's shown in the debugger as "Write Toggle", and yeah, you can see the state of w in the event viewer on $2005 and $2006 writes.
Thank you so much Fiskbit! :D “Write Toggle” in the debugger makes the process much faster! :)

I’m not sure if I mean w in the PPU bc the nesdev wiki mentions that the serial register can become terrible if an NMI interrupts a series of writes, like when I want to change MMC1 banks. The “serial register” must hold the first 4 bits written during the 5 writes to ROM to change MMC1 banks. Sry, for being confused, but I now don’t believe I meant to talk about w in the PPU.
Fiskbit
Posts: 890
Joined: Sat Nov 18, 2017 9:15 pm

Re: Mesen - NES Emulator

Post by Fiskbit »

Different serial registers have different ways of handling the serial writes. w is used specifically for the $2005 and $2006 PPU writes, which take 2 writes. You're correct that interrupts can be a big problem for serial registers; if the handler needs to use a serial register that is also used outside the interrupt, then the two might interfere with each other. This also happens in cases like MMC3, where you write to two different registers to do something like swap banks.

MMC1 has a 5-write serial register, but this isn't using the w bit in the PPU; it has its own method of tracking the 5 writes. Unfortunately, Mesen doesn't allow you to see the interior state of a mapper. There's a ton of mappers and they all have their own registers and behavior, so it's not an easy thing to expose. As a result, it's a bit hard to debug MMC1 issues where your number of writes is wrong.
User avatar
dink
Posts: 157
Joined: Sun Jan 12, 2020 8:42 pm

Re: Mesen - NES Emulator

Post by dink »

Sour,
Thanks for the greatest emulator/debugger/ppu event viewer ever. seriously!

I'd like to let you know about 2 issues with the JY Company mapper,

1: prg mode w/reversed bits, bit 3 (0x08, 1<<3..) is missing
2: the outer prg banks aren't being used in mapper 90, 209, 211. See "Outer Bank Select ($D003)" @ https://wiki.nesdev.com/w/index.php/J.Y._Company_ASIC
For testing, use JY Company's "JY-120 1998 Super 45-in-1". You'll need the version with NES 2.0 header to properly test this. If you can only find the iNES headered version, change it to NES 2.0 and change the CHR banks to 256 (from 255).
Attached is an IPS patch just in-case...

Once the PRG outer bank has been impl'd, "01.Super Mario World" and "03.Aladdin III" will boot / run properly.

Read more about this cart (if interested)
https://bootleggames.fandom.com/wiki/JY ... _Multicart
https://tcrf.net/Super_45-in-1_(JY-120)

best regards,
- dink
Attachments
JY 45-in-1 (Unl)NES2.ips
(18 Bytes) Downloaded 172 times
Tygerbug
Posts: 61
Joined: Sun Jan 19, 2014 5:15 pm

Re: Mesen - NES Emulator

Post by Tygerbug »

Thank you, Sour, for by far the best NES emulator we've ever used, and one which has spoiled us for all other emulators of other systems.

Tetrahedrus and others have been helping us out (at RHDN) by creating hacks of NES/SNES games to be safe for those with photo-sensitive epilepsy, and we're very grateful.

I'm curious about how viable it would be for an emulator like Mesen to detect and remove (or lessen) this sort of full-screen flashing, or an emulator script to do it.

Many triggers come from rapid writes to color 0 of the background palette (universal background color). This could be unchecked.

One thing that might work would be setting a minimum frame count for checking writes to that address, ignoring any further writes that land within that time window, and when no further writes are detected, apply the most recently attempted write only.
Fiskbit
Posts: 890
Joined: Sat Nov 18, 2017 9:15 pm

Re: Mesen - NES Emulator

Post by Fiskbit »

Sour is on indefinite break right now, but regarding the flashing, I think you could automatically detect this with something along the lines of looking for large changes in a color histogram across adjacent frames, and doing some kind of effect when this is detected too many times in a short window. Maybe the effect would be to fade the palette to the new one over several frames. If it's beneficial for the emulator to know this before a frame is rendered instead of after (which I'd guess would be less effective because you'd miss mid-screen changes, such as greyscale toggles after a top HUD), you could maybe track how many pixels on the screen come from each palette index on the previous frame and see what the overall change would be from palette or mask changes made during vblank for the upcoming frame. Any anti-flash mechanism would need to be looking for multiple transitions, not just one, because it might otherwise detect switching to things like a menu or transitioning to a new screen. I'd probably start with a threshold of 3 or more rapid transitions, maybe also detecting 2 if going from dark to light to dark (since I suspect legitimate screen transitions are more likely to go light to dark to light.).
Tygerbug
Posts: 61
Joined: Sun Jan 19, 2014 5:15 pm

Re: Mesen - NES Emulator

Post by Tygerbug »

That's a good idea. Perhaps it could be accomplished via a lua script?

There's further discussion of this here:

viewtopic.php?f=3&t=20920
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: Mesen - NES Emulator

Post by unregistered »

Fiskbit, thank you once again! :D

I realize, from new thread conversation, that Sour is on an indefinite break now. He’s done so much; though, I hope he comes back sometime. :) I have a suggestion:

You say that it would be rough to allow Mesen to show serial registers bc there are so many mappers. To me that doesn’t seem so complicated... Mesen has to respond to values in the serial registers used, and so it must know exactly what serial registers it needs to keep track of when a mapper is selected.

What if Mesen just provided a “serial registers” icon/tools-menu-option, if serial register(s) are present in the emulated game, where a window would open allowing us to see the value of each serial register present?


Does any mapper have countless serial registers? I’m aware that MMC5 is the most complex.

Well, just an idea. Thank you for reading! :)


edit: Maybe it could be a bit more complicated... it could have a number next to each serial register value, showing what write it’s on. Mesen has to keep track of that somehow too... maybe increment that number after each write (and zero it after the serial register’s value is sent somewhere else), or something helpful like that. :) I’m guessing that all serial registers have a write maximum. :)
Nix
Posts: 12
Joined: Wed Aug 26, 2020 12:22 pm

Re: Mesen - NES Emulator

Post by Nix »

You know, I hate to make a post like this and hesitated a lot to do so. But has anyone else considered the possibility that Disch and Sour were the same person all this time?

They both disappeared around the same time, and both were prominent members of the NES scene. Disch (who is no longer around us) had extensive knowledge about the NES internals/specifications and whatnot. If there's anyone who would be competent enough to create such a high quality emulator like Mesen, it'd be him.

I know that if Sour ever comes back and proves me wrong, I'd look like a complete fool. But I'd still rather look like a fool and see the guy is alive and well than the other way around. It'd be a small price to pay.
coto
Posts: 102
Joined: Wed Mar 06, 2019 6:00 pm
Location: Chile

Re: Mesen - NES Emulator

Post by coto »

Open Source community sometimes isn't that fair at all. The one who does stuff is the one who deserves to choose what to do next.

That said, if Sour ever "stole" code (because reverse engineering is somewhat similar), that doesn't mean a thing to me if the guy made giant steps towards lowering/automating the learning curve. So yeah.

Now, if the dev who actually did the RE job, "documented" it through Open Source is a jerk and an asshole, then he / she can go and never come back fwiw. Somebody else will actually RE that again and repeat the cycle.

-


Nes related things I remember fixing NesDS code, I may look into some new issues that arised in 1.3c (if my changes or devkitARM changes, actually broke compatibility).
User avatar
Controllerhead
Posts: 314
Joined: Tue Nov 13, 2018 4:58 am
Location: $4016
Contact:

Re: Mesen - NES Emulator

Post by Controllerhead »

Nix wrote: Thu Sep 24, 2020 11:06 am if Sour ever comes back
I looked at Sour's Github History. It seems like he periodically takes a break for a month or two every year. Well deserved in my humble opinion for a man who has given so much. This break seems to be on par with that.

Personally, i wouldn't rush to any conspiracy theories or assume a tragedy or even expect that he has left his projects and the community forever... at least not yet; or without more information.
Image
Post Reply