Mesen - NES Emulator

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Mesen - NES Emulator

Post by tokumaru »

rainwarrior wrote:Why is that a reason not to show the palette memory at the address that you would read or write it? It's still what you'd find at that PPU address.
Actually, palette RAM is overlaid on top of actual VRAM, so you could argue that the viewer in Mesen shows the contents of the memory chip rather than what you'd get if you hypothetically read that address via the PPU registers. There are normally only NT mirrors at $3F00-$3FFF, but there could be unique RAM there too, and it can be read with some mild trickery (source). I'm not sure how you could write data there though, without bankswitching.

To me it makes more sense to show the underlying memory than the overlaid palette RAM, because AFAIK they're are no other means to see that data (if it's unique instead of mirrored), while palette RAM has its own dedicated viewer.

Sure it may be one of those "who's ever gonna need this?" cases, but the fact is that deliberately hiding something and making it inaccessible just because most people have no use for it is a bad design choice. Palette RAM is *NOT* part of VRAM and I feel like it's important to show it's treated differently (it's even read differently).
User avatar
nesrocks
Posts: 563
Joined: Thu Aug 13, 2015 4:40 pm
Location: Rio de Janeiro - Brazil
Contact:

Re: Mesen - NES Emulator

Post by nesrocks »

Yeah I agree, if it's the real accurate thing, then that's what it is.
I would like an export feature that had ppu chr0, chr1, nam, pal and oam all in one file. That would be for loading that into the tool I'm making. So far fceux has the complete bg part, while mesen offers the oam export.
https://twitter.com/bitinkstudios <- Follow me on twitter! Thanks!
https://www.patreon.com/bitinkstudios <- Support me on Patreon!
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Mesen - NES Emulator

Post by rainwarrior »

tokumaru wrote:Actually, palette RAM is overlaid on top of actual VRAM, so you could argue that the viewer in Mesen shows the contents of the memory chip rather than what you'd get if you hypothetically read that address via the PPU registers.
Yes, but this is a view of the PPU address space, not VRAM. The area from 0000-1FFF is another chip entirely, and bankable, etc. Even the VRAM itself might be replaced by other things.

An "internal VRAM" view might make sense (though TBH, I think it's easiest to understand in its place at $2000-2FFF) but I don't really get the purpose of the "underlying" concept here. It is simply not accessible by the PPU addressing, and the palettes are.
nesrocks wrote:I would like an export feature that had ppu chr0, chr1, nam, pal and oam all in one file. That would be for loading that into the tool I'm making. So far fceux has the complete bg part, while mesen offers the oam export.
You can view the OAM in the hex editor in interim builds of FCEUX (and save it to disk).
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Mesen - NES Emulator

Post by tokumaru »

nesrocks wrote:I would like an export feature that had ppu chr0, chr1, nam, pal and oam all in one file.
All of this in a single file? That would make it harder to create labels for each part in a project that includes this file, don't you think?
That would be for loading that into the tool I'm making.
Even if it's just for importing in tools, that means that the tools have to accept whatever file format the emulator author decides to use for packing all this stuff together.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Mesen - NES Emulator

Post by tokumaru »

rainwarrior wrote:It is simply not accessible by the PPU addressing, and the palettes are.
It's readable at least... A read from $3F00-$3FFF will immediately return a value from palette RAM, but will also copy the VRAM value to the read buffer. Then, if you change the VRAM address to something below $3F00, you can read $2007 to get the buffered value. Like I said, this falls into the "who's ever gonna need that?" category, but even though they're mapped to different areas in the same addressing space, only writes behave the same, reads are completely different, so treating the whole thing as an uniform block of memory is quite misleading IMO. Palette RAM is more like OAM I think, only it didn't get its own addressing space and access registers like OAM did.
User avatar
nesrocks
Posts: 563
Joined: Thu Aug 13, 2015 4:40 pm
Location: Rio de Janeiro - Brazil
Contact:

Re: Mesen - NES Emulator

Post by nesrocks »

There doesn't need to be a format or labels. It's just sequences of raw bytes of fixed length at known locations. No wonder both emulator's PPU memory dump features already work, with the exception of mesen's palette, which isn't exported on that file. I just read the correct byte ranges from the file and it works. Are there exceptions? It worked with most games, and the ones that didn't I figured it was because they change data mid-frame.
https://twitter.com/bitinkstudios <- Follow me on twitter! Thanks!
https://www.patreon.com/bitinkstudios <- Support me on Patreon!
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Mesen - NES Emulator

Post by rainwarrior »

nesrocks wrote:There doesn't need to be a format or labels. It's just sequences of raw bytes of fixed length at known locations. No wonder both emulator's PPU memory dump features already work, with the exception of mesen's palette, which isn't exported on that file. I just read the correct byte ranges from the file and it works. Are there exceptions? It worked with most games, and the ones that didn't I figured it was because they change data mid-frame.
A dump either at the start of NMI, or end of NMI should be fine, but yeah mid-frame banking (or other rendering changes) is very common and will throw it off.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Mesen - NES Emulator

Post by tokumaru »

One way to support raster effects like that in a tool is to grab multiple dumps from the emulator and tell the tool in which scanlines the changes are supposed to happen. That should be enough to simulate the output of the emulator. Exporting the from the tool would be trickier though, you'd probably have to write code for specific mappers to handle the necessary raster effects.
nesrocks wrote:There doesn't need to be a format or labels.
Labels aren't necessary if you're importing the data into a tool, but they're convenient if you're importing from an .asm file. I guess you can manually create labels by adding offsets and such, or INCBIN sections of a larger file, but it's not as versatile (e.g. compression for examplegets very impractical). And by "format" I mean basically the order in which things are stored in the large file. Does OAM come before or after VRAM? Is palette RAM at $3F00 or as a separate chunk? Things like that.
User avatar
nesrocks
Posts: 563
Joined: Thu Aug 13, 2015 4:40 pm
Location: Rio de Janeiro - Brazil
Contact:

Re: Mesen - NES Emulator

Post by nesrocks »

Yeah but isn't it possible to have mid-scanline changes? That'd be crazy. Maybe stop the support at mid-frame changes, but at full scanline. Anyway, this is just a bonus feature on my tool, I guess adding support for all effects would be overkill and out of purpose. I don't know of any practical reason to add such a feature to an emulator anyway.

It would be magical though to include OAM at the end of the file to load bg+sprites with one click, but I guess it doesn't hurt for it to be a two step process.
https://twitter.com/bitinkstudios <- Follow me on twitter! Thanks!
https://www.patreon.com/bitinkstudios <- Support me on Patreon!
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Mesen - NES Emulator

Post by lidnariq »

tokumaru wrote:It's readable at least... A read from $3F00-$3FFF will immediately return a value from palette RAM, but will also copy the VRAM value to the read buffer.
Not only that, but the older PPUs (rev B/C, all the Vs. System alternate PPUs, maybe others?) reads from $3Fxx just go from the underlying RAM: there's no way to read the palette RAM.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Mesen - NES Emulator

Post by rainwarrior »

lidnariq wrote:Not only that, but the older PPUs (rev B/C, all the Vs. System alternate PPUs, maybe others?) reads from $3Fxx just go from the underlying RAM: there's no way to read the palette RAM.
Woah, now that I did not know about! (I never had a use for reading the palette, personally, but I did test it on my NES! I never realized it wasn't always supported.)

I can actually understand that as a conceptual reason to do the PPU memory viewer this way... though I still think for practical purposes: people will expect palette data to appear where it was written and it's useful to be able to find it here (nesrocks demonstrates one reason why), and I doubt anyone will have practical use for reading CHR RAM data from here.
nesrocks wrote:Yeah but isn't it possible to have mid-scanline changes? That'd be crazy. Maybe stop the support at mid-frame changes, but at full scanline. Anyway, this is just a bonus feature on my tool, I guess adding support for all effects would be overkill and out of purpose. I don't know of any practical reason to add such a feature to an emulator anyway.
If you know how the raster split is done, you can set breakpoints on the write that causes it and do a couple of dumps. I've done this several times to make diagrams...

Actually on Mesen you can use "Scanline == 100" or similar for a breakpoint condition, so maybe it's pretty easy to manually set a few breakpoints to dump a frame, which is pretty cool! (I haven't yet done this in Mesen, but noticing it's there I'm sure I will someday.)

Edit: ...or you can click on the "Break on..." button at the top right and type a scanline number for a one time advance-and-break to a specific scanline! I didn't notice that before. Ha ha Mesen is so good.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Mesen - NES Emulator

Post by tepples »

never-obsolete wrote:Found an issue with the debugger [when jumping into the middle of an instruction]
Should be fixed as of revision 70ad89a.
Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

Re: Mesen - NES Emulator

Post by Fiskbit »

Mesen 0.9.7 seems to have a substantial memory leak when using the Event Viewer while the emulator is not paused. It got as far as ~119 GB of private bytes before starting to give me OOM exceptions such as this:

---------------------------
Mesen
---------------------------
An unexpected error has occurred.

Error details:
System.OutOfMemoryException: Out of memory. at System.Drawing.Graphics.CheckErrorStatus(Int32 status) at System.Drawing.Graphics.DrawImage(Image image, Int32 x, Int32 y, Int32 width, Int32 height) at System.Drawing.Graphics.DrawImage(Image image, Rectangle rect) at System.Windows.Forms.PictureBox.OnPaint(PaintEventArgs pe) at System.Windows.Forms.Control.PaintWithErrorHandling(PaintEventArgs e, Int16 layer) at System.Windows.Forms.Control.WmPaint(Message& m) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
---------------------------
OK
---------------------------
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

Fiskbit wrote:Mesen 0.9.7 seems to have a substantial memory leak when using the Event Viewer
This was fixed a couple of weeks ago (someone else reported the same problem on GitHub). If you try the latest appveyor dev build, the leak should be gone.
User avatar
never-obsolete
Posts: 411
Joined: Wed Sep 07, 2005 9:55 am
Location: Phoenix, AZ
Contact:

Re: Mesen - NES Emulator

Post by never-obsolete »

Not sure if this is intentional but:

Code: Select all

			lda $4B
			beq +
			dec $4B
+
I had a RW- breakpoint set on $4B. Stepping through the DEC ZP in the debugger requires multiple clicks to actually get to the next line. I'm assuming because of the way RMW instructions work.

This was the eventual pattern that emerged:

Code: Select all

condition  clicks
 R--         2
 -W-         3
 RW-         4
. That's just like, your opinion, man .
Post Reply