It is currently Wed May 22, 2019 2:39 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 741 posts ]  Go to page Previous  1 ... 46, 47, 48, 49, 50  Next
Author Message
 Post subject: Re: Mesen - NES Emulator
PostPosted: Mon May 13, 2019 4:43 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 668
You probably have the "Highlight tile updates" option enabled at the bottom of the nametable viewer?


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Tue May 14, 2019 8:39 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 1001
Location: cypress, texas
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.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Tue May 14, 2019 8:00 pm 
Offline

Joined: Mon May 30, 2011 9:01 pm
Posts: 215
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.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed May 15, 2019 1:57 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 668
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.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed May 15, 2019 4:57 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 1001
Location: cypress, texas
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:
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. :)


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed May 15, 2019 7:20 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 668
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)


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Thu May 16, 2019 2:24 am 
Offline

Joined: Mon May 30, 2011 9:01 pm
Posts: 215
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.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Thu May 16, 2019 5:17 am 
Offline

Joined: Thu Apr 18, 2019 9:13 am
Posts: 103
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.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Thu May 16, 2019 6:03 am 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 668
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.).


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Thu May 16, 2019 8:59 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 1001
Location: cypress, texas
Sour wrote:
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. :)


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Thu May 16, 2019 10:47 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 1001
Location: cypress, texas
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 :)


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Thu May 16, 2019 12:03 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 1001
Location: cypress, texas
... 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.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Thu May 16, 2019 1:19 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 668
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)


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Thu May 16, 2019 7:09 pm 
Offline

Joined: Mon May 30, 2011 9:01 pm
Posts: 215
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.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Thu May 16, 2019 7:27 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21391
Location: NE Indiana, USA (NTSC)
Discuss a cross-emulator save state format here (if you dare).

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 741 posts ]  Go to page Previous  1 ... 46, 47, 48, 49, 50  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 12 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group