Mesen - NES Emulator

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

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

Re: Mesen - NES Emulator

Post by unregistered »

Thank you Sour; :oops: you are correct. The other screens show when that red highlight goes away... so that tells me that a screen has to stay for an entire frame for it to display. This is just my guess.
mkwong98
Posts: 282
Joined: Mon May 30, 2011 9:01 pm

Re: Mesen - NES Emulator

Post by mkwong98 »

In a recent feature request and a recent commit, breaking save states compatibility is mentioned. So is it possible to split the save states into 2 parts? One part contains the emulated game state and the other part contains the emulator state. The emulated game state format should be standardized for the same mapper and so future changes to the emulator shouldn't break the compatibility of this part. The emulator state can change when required but it doesn't affect the gameplay so it shouldn't be a huge problem to skip this part and just initialize those values. This way old save states remain compatible.
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

I'm not too sure what distinction you're making between the "emulation" and "emulator" state? From my point of view, 99% of the content of save states is vital "emulation" state.

I usually try to keep save states compatible from one version to another, but between 0.9.7 and now I've reworked some of the internals to remove some limitations and simplify some code which forced me to break save state compatibility. The recent commit that broke it is just me breaking compatibility for simplicity since I've already done so since 0.9.7 (e.g from the point of view of someone using the official release builds, compatibility will only break once).

While it's certainly possible to create a more robust system for save states, the one I'm using now is simple to use/implement in terms of code, which I kind of prefer over having to come up with a more complex solution that would probably involve more boilerplate everywhere in the code.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: Mesen - NES Emulator

Post by unregistered »

Sour, here are 2 notes.

1.) After successfully hex editing my cdl file, here is what is now evident, to me, for each 8bit hex value (when it's set)...
  • bit 7: function starts (clearing this bit is a way to remove old sub start)
  • bit 4: helps Mesen to know the start of an instruction
  • bit 1: this byte is a member of a data section
  • bit 0: written when code has been visited
And so now there are helpful huge data sections, but when mouse over a byte it pulls up a screen that talks about its zeropage value. Would pulling up nothing when hovering over data section bytes be better? It even pulls up the zeropage value of a data section byte when the real byte has a label.

2.) After clicking: File>(Workspace)>"Export Labels" and saving a mlb file, and then opening that file in a unix text editor, here is another idea: would it be terrible to add a '|' after an address? That would allow me to add another address before the ':' so that naming more than one different spots of memory with the same name would be possible.

tokumaru taught me to use, in asm6,

Code: Select all

test=$
at the same address in multiple banks to specify the same label "test" in multiple banks. That is super helpful for me! :) Obviously, this doesn't port over to Mesen. But, maybe could you implement that '|'? Maybe when loading the mlb file you could store the other memory address in memory, when reaching '|', and then import those addresses into Mesen when reaching that address. (It seems like the mlb file is set up sequentially bc it's easier to load values in order.)


---
Thank you Sour for reading these two small notes. :)
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

The CDL flags are defined here: https://github.com/SourMesen/Mesen/blob ... ogger.h#L9
Bits $04, $08 and $20 are unused currently (in Mesen, FCEUX uses some of the bits differently).
unregistered wrote:when mouse over a byte it pulls up a screen that talks about its zeropage value.
That's a side effect of any "$...." syntax in the disassembly automatically displaying a popup for the matching address. I suppose I could disable it for data lines, though (never really display the data blocks in the disassembly view much, so I hadn't realized this was happening)

Labels in Mesen need to be globally unique, since there is no concept of label scope. So no, it's not possible to redefine the same label at multiple different addresses. In the CC65 integration, it automatically appends a digit when it finds duplicate labels in the source. As far as the asm6f label export goes, though, duplicate labels just overwrite one another, I think (the export code in asm6f would need to be improved)
mkwong98
Posts: 282
Joined: Mon May 30, 2011 9:01 pm

Re: Mesen - NES Emulator

Post by mkwong98 »

Sour wrote:I'm not too sure what distinction you're making between the "emulation" and "emulator" state? From my point of view, 99% of the content of save states is vital "emulation" state.
For example, the real NES hardware does not keep track of how many CPU cycles have passed since running the game so the CPU cycle counter shouldn't be vital to playing the game and should work fine by just initialising it to 0 instead of reading from a save state.
supercat
Posts: 161
Joined: Thu Apr 18, 2019 9:13 am

Re: Mesen - NES Emulator

Post by supercat »

mkwong98 wrote:
Sour wrote:I'm not too sure what distinction you're making between the "emulation" and "emulator" state? From my point of view, 99% of the content of save states is vital "emulation" state.
For example, the real NES hardware does not keep track of how many CPU cycles have passed since running the game so the CPU cycle counter shouldn't be vital to playing the game and should work fine by just initialising it to 0 instead of reading from a save state.
If mappers can access such a counter, however, they might do so rather than maintain their own, and malfunction if the counter doesn't behave as expected.
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

The NES doesn't keep track of the total number of cycles, no, but emulating it properly requires knowing if the current cycle is "odd" or "even" for DMA/etc, so keeping track of the cycle count solves that requirement.

Also, like supercat said, some mappers (and various other things) rely on the cycle counter for timing, so removing it from the state would require changing the logic for those (e.g they would need to have their own countdown timers that get decremented every CPU cycle, etc.).
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: Mesen - NES Emulator

Post by unregistered »

Sour wrote:The CDL flags are defined here: https://github.com/SourMesen/Mesen/blob ... ogger.h#L9
Wow! :)
edit: link doesn't seem to work for me, at least not on this computer. END EDIT.
final edit: your link definitly works on a much better cpu. :) END EDIT.
Sour wrote:Labels in Mesen need to be globally unique, since there is no concept of label scope. So no, it's not possible to redefine the same label at multiple different addresses. In the CC65 integration, it automatically appends a digit when it finds duplicate labels in the source. As far as the asm6f label export goes, though, duplicate labels just overwrite one another, I think (the export code in asm6f would need to be improved)
Yes, in asm6, duplicate labels just overwrite one another... that's why duplicate labels must be at the same address for everything to work correctly. But, that is extremely helpful when used creatively. In our game a certain bytes, i.e. abyte = $, in each lower bank contain flags. Then a simple bit abyte paired with an appropriate branch can instantaneously tell what type of bank is selected without affecting the registers! :) It's so cool! Therefore, I hope "the export code in asm6f would need to be improved" does not eleminate the usefulness of duplicate labels. :)
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: Mesen - NES Emulator

Post by unregistered »

Sour wrote:Labels in Mesen need to be globally unique, since there is no concept of label scope. So no, it's not possible to redefine the same label at multiple different addresses.
After some thinking: Mesen uses two types of addresses, Byte Code and PRG Address. The nes game ROM treats duplicate labels as Byte Code. Mesen must somehow translate that Byte Code into the appropriate PRG Address. So, could you allow a flag character in the mlb files, say '*', that when found it interprets the following address as Byte Code? i.e. ...nm, it seems you already have something like that... :)

Does the R stand for Real and the P stand for PRG Address? Would allowing R:9000:abyte be possible? Or maybe your code that handles R is much simpler than your P code, if so and you need to use P code, would P:*9000:abyte be possible? (The '*' would work as suggested above.) Just some thoughts. :)


note: abyte is a fake variable and so is its 9000 address :)
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: Mesen - NES Emulator

Post by unregistered »

... or maybe don't use a '*'; replace that with an 'F'... just another idea. I don't know if the PRG Address can get that high. Just trying to help... I don't know if my ideas are even possible, I should be quiet now.
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

I'm not entirely sure I'm following what you're saying.
Like I said though, Mesen has no concept of label scope - it can't redefine the same label multiple times because of this.
If multiple identical labels existed, the debugger would have no idea which one was being referred to by a given line of code, which makes it harder/impossible to display a corresponding tooltip, or to navigate to the label, or to open the label in the hex editor, etc.

When I mentioned improving asm6f, I strictly meant the .mlb file export feature it contains, not the actual assembler.
"R" in the mlb label files refers to the 2kb of internal RAM that the NES has (e.g $0000 to $1FFF in CPU memory)
mkwong98
Posts: 282
Joined: Mon May 30, 2011 9:01 pm

Re: Mesen - NES Emulator

Post by mkwong98 »

Sour wrote:The NES doesn't keep track of the total number of cycles, no, but emulating it properly requires knowing if the current cycle is "odd" or "even" for DMA/etc, so keeping track of the cycle count solves that requirement.

Also, like supercat said, some mappers (and various other things) rely on the cycle counter for timing, so removing it from the state would require changing the logic for those (e.g they would need to have their own countdown timers that get decremented every CPU cycle, etc.).
In this case, a flag indicating "odd" or "even" and a value for timers in mappers belongs to the emulated game state and the CPU cycle counter is emulator specific implementation of that state. What I'm suggesting is a save state format which is emulator independent and hence always compatible. I see no reason why it is impossible but I guess it is too complicated to actually do.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Mesen - NES Emulator

Post by tepples »

Discuss a cross-emulator save state format here (if you dare).
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: Mesen - NES Emulator

Post by unregistered »

Sour wrote:I'm not entirely sure I'm following what you're saying.
Like I said though, Mesen has no concept of label scope - it can't redefine the same label multiple times because of this.
If multiple identical labels existed, the debugger would have no idea which one was being referred to by a given line of code, which makes it harder/impossible to display a corresponding tooltip, or to navigate to the label, or to open the label in the hex editor, etc.
I guess I don't understand how the PRG Addresses work. Does the assembler asm6 translate each of my identical labels in each our lower banks into PRG Addresses listed in the ROM (the .nes file)? Or does Mesen create the PRG Addresses so that the mlb file can work?

Regardless, I will try again. Somehow you must have access to the ROM addresses to emulate a NES. I thought it might be possible to specify a ROM address in your mlb file (i.e. $9000). That would be just one address. But, you'd have to get your assembler to treat those addresses with the same method you use to translate my identical labels into the PRG Addresses. For example, in each of the lower banks ($8000-$BFFF) in our MMC1 game (note: the 2 higher banks ($C000-$FFFF) can be either bank 15 or bank 31) there are certain bytes with identical labels, let's pretend one of those labels is named abyte and is always labeling address $9000. So my idea was to somehow specify in your mlb file that abyte points to address $9000.

Like:
  • P:*9000:abyte or
  • I:9000:abyte| note: I for identical
Then when reaching a '*' or the 'I' you would have to use that address specified in the same way you interpret each of the abytes that, we are pretending, are sitting in the same ROM address spot in each of the lower banks in our game.

Somehow when switching banks the PRG Address for abyte changes to the appropriate value... so you already have that code written. Just was wondering if it was possible to reuse that code so that when trying to label $9000, you might be able to translate that $9000 into the appropriate PRG Address depending on what bank is selected in the emulated game? :)
Sour wrote:When I mentioned improving asm6f, I strictly meant the .mlb file export feature it contains, not the actual assembler.
"R" in the mlb label files refers to the 2kb of internal RAM that the NES has (e.g $0000 to $1FFF in CPU memory)
Oh ok! :D Great choice of "R". :)
Post Reply