Mesen - NES Emulator

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

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

Re: Mesen - NES Emulator

Post by mkwong98 »

Sour wrote:He's made pretty heavy use of conditionals in his pack (has 700+ conditions defined), but I'm unsure how he built the pack. The definition file is over 5k lines long, so hopefully he didn't write all of it by hand. Maybe you can send him a PM on romhacking.net and see if he's willing to show it to you?
He told me he is not using any tool. :shock:

Anyway, here is the object editor that I'm working on:https://drive.google.com/open?id=11YFxz ... ypcnn6JzNl

How to use it:
1. Run the HD Pack Builder of Mesen.
2. Start a new project and locat the output of the builder.
3. Compose game objects by copying tiles from PPU viewer of Mesen or from the HD Images and the ROM viewer pages of this editor.
4. Add image files with replacement tiles to the pack.
5. Set the object to use the replacement tiles.
6. Add conditions if a tile appears at multiple locations.
7. Add palette swap if the same replacement tiles (with changes to brightness, hue and saturation) can be used for the new palette.
8. Choose "Generate pack data" when done.
hackfresh
Posts: 101
Joined: Sun May 03, 2015 8:19 pm

Re: Mesen - NES Emulator

Post by hackfresh »

How do you search for a hex sequence in the PRG ROM? It doesn't seem to be working for me on the lastest build
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

hackfresh wrote:How do you search for a hex sequence in the PRG ROM? It doesn't seem to be working for me on the lastest build
Thanks - that's a new bug from a couple of weeks ago, it should be fixed in this build: download
mkwong98 wrote:Anyway, here is the object editor that I'm working on
That's starting to look pretty nice!

A few issues I had:
-The color selection palette seems to be set to a transparent color by default? (I just get a blank gray form in the popup, but I can set colors by right-clicking on them)
-On the 3rd tab, in the textbox that gives the palette values (8 hex characters), pressing delete/backspace in this textbox causes the application to crash if there is no "project" loaded.
-libwinpthread-1.dll was missing from your zip (downloaded a version of it and it worked fine though)
-In the first tab when creating objects, I can't seem to configure conditions no matter what I try (both options in the right-click relating to conditions don't do anything for me)

It also crashes every time I try to start a project on a version of kya's pack that I have (it worked fine with axlrocks' megaman pack though) - but that might be because it is using some of the newer features (or it might have some leftover invalid tags in it, etc)
Bananmos
Posts: 552
Joined: Wed Mar 09, 2005 9:08 am
Contact:

Re: Mesen - NES Emulator

Post by Bananmos »

There's also a "Step Back" option that rolls by the execution by a single instruction, if you didn't notice it.
Oh, but I certainly did, and that was part of my praise ;)

Two small feature requests around this though:

1) I find myself using this feature a lot to rewind/fast-forward around a certain time point, to watch weird glitches/not-yet-great-looking animations in more detail. I think the slower rewind is just the implementation being more demanding on my computer, but I kind of like how it rewinds in slow-motion.

However, this creates quite an inconsistency with the fast-forward functionality which is a lot faster. Would it be possible to offer a "slow-mode" rewind & "fast"-forward, which would have their speed configured, so that these two could match? (at least on a computer where speed isn't an issue)

2) I also find that rewinding has a bit of a delay before it starts, when I rewind/fast-forward back&forth in succession. Don't know how hard this might be, but it would be nice if this delay could be eliminated. But again, it could just be my laptop being a bit sluggish...
Power Cycle reloads the ROM from the disk - you can map this to any key/button combination. I'm not sure why you need to reset after opening from the recent files, though? Does it not work properly otherwise?
Indeed, I have to do reset for the ROM to actually start. So to reload the ROM from disk, I need to do CTRL+T and CRTL+R. It'd be nice if this was just one button press (that could be mapped to my joypad via the shortcut keys)
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

Bananmos wrote:Would it be possible to offer a "slow-mode" rewind & "fast"-forward
There is a setting that configures the speed for the "fast forward" and "rewind" modes in the emulation settings' general tab, you can set them to any % value.
I also find that rewinding has a bit of a delay before it starts
This is a compromise between speed, memory usage and code complexity. Mesen takes savestates every 30 frames for the rewind feature and compresses them to save memory - this takes about 1mb/minute of gameplay. This means the emulator has to re-execute ~30 frames or so before the rewind can start displaying anything. It would be possible to remove this delay by, for example, keeping in memory the last second's worth of audio/video and replaying that immediately while the core rewinds older data, but the rewinder's code is already fairly complex as it is, and I would rather not add any more complexity to it if at all possible. I'll try to take a look at the code and see if it is simple to implement, but I can't promise anything.
Indeed, I have to do reset for the ROM to actually start.
Is this because of the ROM itself, or are you getting this behavior for any ROM? If you're getting this with all roms, this is not normal, and not something that should ever happen. If that's the case, are you getting this even when all debugger tools are closed, etc? I've never seen this particular issue on my end, so if you are able to figure out what conditions are required to cause the issue (e.g maybe some specific options you've enabled, etc.), that would be really helpful.
mkwong98
Posts: 282
Joined: Mon May 30, 2011 9:01 pm

Re: Mesen - NES Emulator

Post by mkwong98 »

Sour wrote: A few issues I had:
-The color selection palette seems to be set to a transparent color by default? (I just get a blank gray form in the popup, but I can set colors by right-clicking on them)
-On the 3rd tab, in the textbox that gives the palette values (8 hex characters), pressing delete/backspace in this textbox causes the application to crash if there is no "project" loaded.
-libwinpthread-1.dll was missing from your zip (downloaded a version of it and it worked fine though)
Should be fixed now. I uploaded a new version to Google drive, the link is the same.
Sour wrote: -In the first tab when creating objects, I can't seem to configure conditions no matter what I try (both options in the right-click relating to conditions don't do anything for me)
I added a file into the archive explaining how to use the editor. Please take a look.
Sour wrote: It also crashes every time I try to start a project on a version of kya's pack that I have (it worked fine with axlrocks' megaman pack though) - but that might be because it is using some of the newer features (or it might have some leftover invalid tags in it, etc)
Yes, the newer features are not handled yet.
Bananmos
Posts: 552
Joined: Wed Mar 09, 2005 9:08 am
Contact:

Re: Mesen - NES Emulator

Post by Bananmos »

There is a setting that configures the speed for the "fast forward" and "rewind" modes in the emulation settings' general tab, you can set them to any % value.
Ah, thanks! Was looking in "Preferences", didn't realise there was an option under "Emulation".
This is a compromise between speed, memory usage and code complexity. [...] I'll try to take a look at the code and see if it is simple to implement, but I can't promise anything.
Yeah, no worries if it doesn't get done. I'm finding the feature really useful already, just wanted to point out a possible improvement.
Is this because of the ROM itself, or are you getting this behavior for any ROM? If you're getting this with all roms, this is not normal, and not something that should ever happen. If that's the case, are you getting this even when all debugger tools are closed, etc? I've never seen this particular issue on my end, so if you are able to figure out what conditions are required to cause the issue (e.g maybe some specific options you've enabled, etc.), that would be really helpful.
It indeed seems to only happen with my own game - other ROMs reset when power cycling.

But it also happens for the cut-down repro I sent you in a PM. How does that one behave on your end?
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

Bananmos wrote:But it also happens for the cut-down repro I sent you in a PM. How does that one behave on your end?
It happens on my end, too (I had just assumed that rom was meant to show a green screen - never saw the actual graphics!).

As far as I can tell, your code does this:
-SEI
-Wait for vblank
-Write $80 to $4017, to set it to 5-step mode
-CLI

In Mesen's case this triggers an IRQ - the frame counter was running in 4-step mode long enough to set the IRQ flag, which was being inhibited by the interrupt disabled flag. So an IRQ ends up being triggered right after CLI is executed. Have you tested this on real hardware? If it works on a NES, the wiki's information about $4017 might be incomplete.

Currently it reads:
Bit 6 -I-- ---- Interrupt inhibit flag. If set, the frame interrupt flag is cleared, otherwise it is unaffected.
[...]
The frame interrupt flag is connected to the CPU's IRQ line. It is set at a particular point in the 4-step sequence (see below) provided the interrupt inhibit flag in $4017 is clear, and can be cleared either by reading $4015 (which also returns its old status) or by setting the interrupt inhibit flag.
If your code works on a console, it would imply that setting the APU Frame Counter to 5-step mode is enough to clear the IRQ flag, in which case Mesen is wrong - having a test rom to validate this specific thing would be pretty nice.

mkwong98 wrote:I uploaded a new version to Google drive, the link is the same.
Thanks, I haven't had the chance to take a look at it yet, though - I'll get back to you once I do.
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: Mesen - NES Emulator

Post by koitsu »

Blargg's APU document seems to cover this scenario, if I'm understanding correctly. Search for "Frame Sequencer" (and don't miss the very last paragraph of the section). This doc says that 5-step (bit 7 of $4017 set to 1) never sets the interrupt flag, so I would assume the preceding sei would keep it inhibited, and the subsequent cli would not trigger an IRQ.

There's also Brad Taylor's document (search for "Low frequency timer control"), which... well... is harder for me to understand (more hardware-oriented in some ways).

Someone more familiar with this (i.e. not me) should probably do some testing on actual hardware, though blargg AFAIK did exactly that.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Mesen - NES Emulator

Post by lidnariq »

Visual2A03 breaks down the frame sequencer using six states:
A - at binary 001000001100001 → 3728 clocks
B - at binary 011011000000011 → 7456 clocks
C - at binary 010110011010011 → 11185 clocks
D - at binary 000101000011111 → 14914 clocks - this one asserts IRQ and restarts the sequence if allowed by frm_/seqmode
E - at binary 111000110000101 → 18640 clocks
F - at 0

Unfortunately, these are implemented using an LFSR, so converting between these numbers and ordinary sequential ones is a pain. (I tentatively think it's the same 15-bit LFSR used for noise —x14 + x13 + 1) So F is the recovery/power-on state, guaranteeing that a 1 is shifted in when the state is all 0. (edit: assumed the above LFSR, did the work, added the offsets which of course agree with the time seven years ago when Quietust did the same work)

Frm_quarter is ultimately asserted when any of the six above states is found.
Frm_half is asserted when states B, E, or (D AND frm_/seqmode) are found.
E or (D AND frm_/seqmode) restarts the counter from $7FFF—so the very first power-on sequence probably differs from all subsequent operation?
Last edited by lidnariq on Sat Mar 10, 2018 7:17 pm, edited 1 time in total.
Bananmos
Posts: 552
Joined: Wed Mar 09, 2005 9:08 am
Contact:

Re: Mesen - NES Emulator

Post by Bananmos »

Well, let's not jump to any conclusions. That init code of mine is very old and I can't even remember why it writes $80 rather than $C0.

I've also been testing this on a Powerpak/Everdrive, as I don't have a true MMC3 devcart setup handy to test with ATM (that would require a parallel-port and getting my old DOS-only EPROM emulator program). And the Powerpak/Everdrive probably simulate reset behavior rather than any true NES power-up state.

Anyway, changing it to write $C0 rather than $80 fixes my problem. So I'd assume the bug is my blunder and leave it at that. Thanks for pointing it out :)
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

Well, I guess licensed games don't ever do this (otherwise it would likely cause problems in Mesen), but it would be nice to know the exact behavior of the APU in this case (since it's clearly not being tested by any of the existing test roms). This should be pretty simple to test - I might try writing a test rom for this eventually (and make someone else check the result for me... :p)
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Mesen - NES Emulator

Post by lidnariq »

As far as I can tell from Visual2A03, /RESET should have the same effect as a write to $4017, namely resetting the frame sequencer LFSR to the $7FFF state.

I'm not clear why they also included the frm_f node that recovers from the all-zeroes state; it's unnecessary given the above.

Maybe the original letterless revision of the CPU doesn't do anything on reset? (checks) ... yup! The letterless 2A03 doesn't reset the LFSR to the $7FFF state on reset:
Attachments
Nintendo_RP2A03G_t12845.jpg
Nintendo_RP2A03G_t12845.jpg (27.31 KiB) Viewed 7589 times
nintendo_rp2a03_no_t12845.jpg
nintendo_rp2a03_no_t12845.jpg (43.12 KiB) Viewed 7589 times
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

The problem doesn't so much seem to be about the behavior when resetting (one of blargg's tests validates this, iirc), but rather whether or not the IRQ signal remains enabled when switching from 4-step mode to 5-step mode (if it was already active), or if switching to 5-step mode acknowledges the IRQ signal and prevents an IRQ from being fired. The wiki implies $4015 must be read, or $4017 must be written to with bit 6 enabled to acknowledge an IRQ, but does writing $80 when the last written value was $00 (same as reset) also acknowledge it?

If switching to 5-step activates frm_/seqmode, then the question is, can the IRQ signal remain active while frm_/seqmode if it was previously activated? (I've unfortunately forgotten 99% of the little I ever knew about understanding transistors, so I have no idea if this is something that is easily checked or not). It should be pretty simple to test this in the visual 2a03/visual nes, though - might give that a try tomorrow.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Mesen - NES Emulator

Post by lidnariq »

Looking through Visual2A03, I see only the following can clear frame_irq:
- /reset
- frm_intmode, which is the latched copy of D6 on writes to $4017
- node 13170 = NOR(clk1out, r4015)
Sour wrote:If switching to 5-step activates frm_/seqmode, then the question is, can the IRQ signal remain active while frm_/seqmode if it was previously activated?
so ... I'd say, correct, writes to $4017 with the bit 6 clear don't acknowledge the IRQ. frame_irq is acknowledged/disabled continuously while it's high.
Post Reply