It is currently Tue Nov 21, 2017 10:44 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 27 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Wed Oct 25, 2017 2:51 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 299
Yea, the issues with .nl files aren't hugely problematic, importing them probably wouldn't be that hard ([nl file number] * $8000 + label address - $8000 = prg rom offset, I think?). I'm not sure there's any real reason to support the format since Mesen can already integrate with CC65 & ASM6 - are there any other common tools that generate .nl files?

rainwarrior wrote:
I'd rather just have one big file that maps ROM addresses to memory addresses than this mess of separate files for every 16k hunk.
This is pretty much what the ".mlb" format I added to Mesen does, e.g:
Code:
R:700:MyLabel
P:38A00:AnotherLabel:And a multi-line\ncomment\nabove it
Where the first letter is a label "type": R (internal ram), P (prg rom), S (save ram), W (work ram) or G (cpu address, $0000-$FFFF)
All labels are offsets starting from 0 for that specific memory type (so "P:$30000" corresponds to byte $30010 in the .nes rom).
It's not perfect when it comes to ram variables that are reused for different purposes at different points in the code, but for anything else, it works and is simple to parse. Mesen can import/export this format, and freem was kind enough to merge my modifications to ASM6 into his branch (ASM6f), so ASM6f can export a .mlb file to import into Mesen.

The .dbg support in Mesen is based off a bunch of regexes and only supports what I actually needed, but it shouldn't break from minor file format changes (though from what I can tell, CC65's code for this has not changed since 2014). I just didn't want to use CC65's code directly (8000 lines) when the relatively small subset of features I needed fits in ~300 lines of C# code.


Top
 Profile  
 
PostPosted: Wed Oct 25, 2017 2:57 pm 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 874
Location: Sweden
Yeah if you need both accuracy and good debugging tools, Mesen is the way to go. I still use FCEux a lot for quick testing as it's quicker to start (and on my laptop it's much quicker) though.


Top
 Profile  
 
PostPosted: Wed Oct 25, 2017 6:14 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19239
Location: NE Indiana, USA (NTSC)
I guess a proof of concept might be to make a ROM map in .mlb format for MLB.


Top
 Profile  
 
PostPosted: Wed Oct 25, 2017 6:47 pm 
Offline
NESICIDE developer
User avatar

Joined: Mon Oct 13, 2008 7:55 pm
Posts: 1049
Location: Minneapolis, MN
:beer:
As far as 'accuracy' goes, nesicide's emulator is fairly so. But it's been a few years since I checked or cared about accuracy.
As far as 'good' debug features go, depends on what you need. Full visibility into all memories. Full visualization of nametable, pattern table, sprites. Fully enumerated bit-field visibility into all register details of CPU, PPU, APU, and [some, not all] mappers. Code profiler. Execution visualizer (where is my code executing in the TV frame). Symbol inspector with watch. Assembly view. Code/data logger. Breakpoints on an ungodly amount of events within the CPU, PPU, APU, or mapper. Controller logging for test suites.
I'm presently working on automated distro for Win/OSX/Linux of the nesicide package so hopefully that helps.


Top
 Profile  
 
PostPosted: Thu Oct 26, 2017 2:47 am 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 382
Location: Denmark (PAL)
cpow wrote:
:beer:
As far as 'accuracy' goes, nesicide's emulator is fairly so. But it's been a few years since I checked or cared about accuracy.

I love Nesicide mostly for providing live debugging that points me directly to the code, but I think it has quite a few issues. I don't know if this is the correct thread to bring it up, but it always bothered me that breakpoints are directly bound to PC addresses - I feel it would be nicer to stick them directly to a line number in the text editor (so the breakpoint also moves when you add code above it, etc.), and then it updates the emulator with actual PC breakpoints "behind the scenes" whenever you load the rom into the emulator.
This would also help with a lot of other issues such as old breakpoints becoming useless, and old "garbage" breakpoints still showing, when they are suddenly somewhere else.

Another slightly minor issue is that clicking a breakpoint disables it instead of removing it, adding one extra step to cycle between compared to the standard for most IDEs. It makes sense in the breakpoint overview window, but on the actual text editor I would prefer that a click just creates/removes the breakpoint entirely. Maybe it's a setting somewhere that I overlooked?

More on topic to this thread, though, my main reason for rarely using the Nesicide emulator when I can avoid it, is that it runs extremely slowly on every computer I've tried it. It both skips frames and runs the game much slower than intended. How slow it is seems to be strangely variable though - some times it will run almost full speed (but still with frameskips?) while at other times it's absurdly slow. I'm not sure what makes the difference, but if you have any idea, that would be nice to know.
Also, a speed up key and savestates would be pretty nice for testing gameplay stuff. I almost exclusively use FCEUX and Nestopia for this purpose as it is.


Top
 Profile  
 
PostPosted: Thu Oct 26, 2017 5:52 am 
Offline
NESICIDE developer
User avatar

Joined: Mon Oct 13, 2008 7:55 pm
Posts: 1049
Location: Minneapolis, MN
Sumez wrote:
but I think it has quite a few issues.

Indeed.
Sumez wrote:
I don't know if this is the correct thread to bring it up, but it always bothered me that breakpoints are directly bound to PC addresses - I feel it would be nicer to stick them directly to a line number in the text editor (so the breakpoint also moves when you add code above it, etc.), and then it updates the emulator with actual PC breakpoints "behind the scenes" whenever you load the rom into the emulator.
This would also help with a lot of other issues such as old breakpoints becoming useless, and old "garbage" breakpoints still showing, when they are suddenly somewhere else.
Another slightly minor issue is that clicking a breakpoint disables it instead of removing it, adding one extra step to cycle between compared to the standard for most IDEs. It makes sense in the breakpoint overview window, but on the actual text editor I would prefer that a click just creates/removes the breakpoint entirely. Maybe it's a setting somewhere that I overlooked?

I will look into this.
Sumez wrote:
More on topic to this thread, though, my main reason for rarely using the Nesicide emulator when I can avoid it, is that it runs extremely slowly on every computer I've tried it. It both skips frames and runs the game much slower than intended. How slow it is seems to be strangely variable though - some times it will run almost full speed (but still with frameskips?) while at other times it's absurdly slow. I'm not sure what makes the difference, but if you have any idea, that would be nice to know.

There are four options for debug level. The first is the bug in the toolbar. If not selected, no debugging features are enabled [not even breakpoints]. The other debug level options are in NESICIDE->Environment Settings->Nintendo Entertainment System->Debugging. You can select between updating only on pause, at frame rate, or once per second. That should help with performance issues. Also, if you're using a build that somehow got released but is a debug build, those are incredibly slow. That is another reason why I am trying to automate the distro since sometimes I forget when building to switch to "Release" configuration. :|


Top
 Profile  
 
PostPosted: Thu Oct 26, 2017 8:25 am 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 382
Location: Denmark (PAL)
I'll see if I can build a new version for myself, I had no idea my version was so out of date - I actually just thought you hadn't been working on the probject for a long time, so I'll try that out before commenting any more on how it works.

As for my settings now, the debugger is already set to only update on pause, so that's definitely not the issue. The emulator's performance is the same even if I disable debugging - that's pretty much the first thing I tried. :)


Top
 Profile  
 
PostPosted: Thu Oct 26, 2017 8:34 am 
Offline
NESICIDE developer
User avatar

Joined: Mon Oct 13, 2008 7:55 pm
Posts: 1049
Location: Minneapolis, MN
Sumez wrote:
I'll see if I can build a new version for myself, I had no idea my version was so out of date - I actually just thought you hadn't been working on the probject for a long time, so I'll try that out before commenting any more on how it works.

I honestly haven't been *continually* working on it. I am having a bit of a resurgence in motivation. :)
Sumez wrote:
As for my settings now, the debugger is already set to only update on pause, so that's definitely not the issue. The emulator's performance is the same even if I disable debugging - that's pretty much the first thing I tried. :)

What OS do you need? I might just go ahead and upload Win/Lin/OSX builds now since I happen to have all three in front of me. :beer:


Top
 Profile  
 
PostPosted: Thu Oct 26, 2017 8:57 am 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 382
Location: Denmark (PAL)
Windows.

I'm actually in the process of installing QT now just for the purpose of building Nesicide... it's a pretty damn heavy dependency, both downloading an installing is taking forever, and I'll probably delete it immediately afterwards :P


Top
 Profile  
 
PostPosted: Thu Oct 26, 2017 9:09 am 
Offline
NESICIDE developer
User avatar

Joined: Mon Oct 13, 2008 7:55 pm
Posts: 1049
Location: Minneapolis, MN
Sumez wrote:
Windows.

I'm actually in the process of installing QT now just for the purpose of building Nesicide... it's a pretty damn heavy dependency, both downloading an installing is taking forever, and I'll probably delete it immediately afterwards :P

It may be heavy but it's *nothing* compared to a completely different Eclipse-based IDE that I am currently trying to build. :shock:
I should be able to upload Windows builds in the next couple hours. Will report back.


Top
 Profile  
 
PostPosted: Thu Oct 26, 2017 9:16 am 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 382
Location: Denmark (PAL)
Thanks a lot, cause I'm giving up on this. The shell scripts are giving me all kinds of errors, and I have no idea where to look to fix it :)


Top
 Profile  
 
PostPosted: Thu Oct 26, 2017 12:28 pm 
Offline
NESICIDE developer
User avatar

Joined: Mon Oct 13, 2008 7:55 pm
Posts: 1049
Location: Minneapolis, MN
Sumez wrote:
Thanks a lot, cause I'm giving up on this. The shell scripts are giving me all kinds of errors, and I have no idea where to look to fix it :)

I hadn't had a chance yet to debug the win-deploy.sh script. Turns out it was bollocks. I've got it building now but I'm having DLL issues.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 27 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 5 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