It is currently Wed Oct 18, 2017 6:47 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 36 posts ]  Go to page Previous  1, 2, 3

Do we need to add Nametable Address Detection for the recent FCEUX or Nintendulator?
Poll ended at Thu May 12, 2016 4:55 am
Yes 29%  29%  [ 2 ]
No 71%  71%  [ 5 ]
Total votes : 7
Author Message
PostPosted: Tue May 03, 2016 10:41 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5718
Location: Canada
Hamtaro126 wrote:
Did you try actually using the correct nametable and not it's respective mirror?

Yes, but why would hovering over a "mirror" change the results? It should be looking for the same data...

Oh wait, now I understand what this is. Every time there is a write to memory, it stores the last read address, and this tool just displays that read address for each nametable byte you highlight? OK. (It should still duplicate that for mirrors, BTW, but whatever...)

Like in one game I am seeing that it points to an ASCII table wherever there was text on screen, because that was the last thing fetched before the character is written. I suspect for a lot of games this could find metatiles, rather than nametables. That explains a lot of what I'm seeing, I think. When stuff's compressed, you get RAM addresses, when it's metatiles, you get the metatile address, etc. Hmm. Though, honestly it's really quick to find this kind of stuff with a trace log anyway.

I'm wondering if this could be improved significantly if there was a second layer of indirection for RAM. i.e. any time the last read was from RAM, read back that RAM's last read recursively until you hit something? (Wondering also if it correctly tracks immediate values as the last read?) A lot of cases the resulting value would come from multiple sources though; intermediate arithmetic or binary combinations. (Edit: found it, it's all laid out in Debugger_Update() in src/Debugger.c, see where it calls SetMemFollow. Does seem to track immediates, and do what else it can in this respect.)


I'm thinking a generic memory-follower tool might be pretty useful, actually, like if we could do this for all RAM, not just the PPU and nametables. Though, I dunno what kind of overhead this would incur (probably fine if it can be turned on/off anyway). I change my mind a bit if the scope is expanded; it'd be a pretty decent feature for romhacking. (Easy to do already with a trace though.)


Top
 Profile  
 
PostPosted: Tue May 03, 2016 11:53 pm 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 898
Location: Gothenburg, Sweden
Quote:
thinking a generic memory-follower tool might be pretty useful, actually, like if we could do this for all RAM, not just the PPU and nametables.


This is a neat idea! I'm doing this manually to learn the ropes (and because there's currently no other way), but a tool like this would certainly be handy.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Wed May 04, 2016 4:30 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19098
Location: NE Indiana, USA (NTSC)
rainwarrior wrote:
Oh wait, now I understand what this is. Every time there is a write to memory, it stores the last read address, and this tool just displays that read address for each nametable byte you highlight? OK. (It should still duplicate that for mirrors, BTW, but whatever...)

Like in one game I am seeing that it points to an ASCII table wherever there was text on screen, because that was the last thing fetched before the character is written. I suspect for a lot of games this could find metatiles, rather than nametables. That explains a lot of what I'm seeing, I think.

That's why I suggested adding a filter for increasing ROM addresses: "consecutive stream in PRG ROM".

Quote:
Hmm. Though, honestly it's really quick to find this kind of stuff with a trace log anyway.

Then perhaps memory followers could be organized in this way:
  1. Keep a trace log.
  2. Collect heuristics. In this case, lots of writes to VRAM during a force-blanked frame likely indicate nametable loading.
  3. When a heuristic triggers, grep the last hundred thousand instructions for the corresponding access pattern.


Top
 Profile  
 
PostPosted: Wed May 04, 2016 10:01 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5718
Location: Canada
tepples wrote:
  1. Keep a trace log.

Hmm, if you could use the trace log tool and then combine it with the hex memory view. You could click on a memory address and choose "history", and have it follow it back to its roots spitting out a series of instructions and data fetches until it hits a dead end.

The history would be a tree structure. Something like LDA or an immediate operand would be a leaf node. Combining operations like ADC or EOR would be a branch node. A fetch from RAM would be a continuation node, starting a subtree going further back. Perhaps indexed loads could create a branch for the index register or pointer variable used too. Clicking on a node should take you directly to that moment in the trace log and/or directly to that byte in ROM.

I guess I'd invision a UI with 3 panes. Hex view (PRG/PPU/ROM), the history search, and the trace log.

I've written some simple trace parsers in python in the past just to do performance profiling and stuff like that. Something like this could be done as an offline tool as a proof of concept (trace logs can get kinda big anyway).

Anyhow, just dreaming about the kind of tool someone might make if they expanded this concept beyond nametables and last-read history.


Top
 Profile  
 
PostPosted: Wed May 04, 2016 10:12 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10056
Location: Rio de Janeiro - Brazil
rainwarrior wrote:
Anyhow, just dreaming about the kind of tool someone might make if they expanded this concept beyond nametables and last-read history.

Now THAT sounds useful!


Top
 Profile  
 
PostPosted: Wed May 04, 2016 11:00 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5718
Location: Canada
Modern GPU debuggers have a "pixel history" feature, which is what this was reminding me of, where each write to a pixel you can drill down into all the associated information.

Image


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google Adsense [Bot] 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