[AlanJacobs]

Hello, all. Im currently using FCEUX and use the Code/Data logger to check out what bytes are used in the game. Is there a way to search for a particular hex number only within the bytes recorded by the code/data logger? Or is there another hex editor that can do so? Thank you in advance.

[FAST6191]

Outside of coding it yourself using the lua options then not really. To closest you will tend to see to things like this is a free space finder or a simple search within a window, logs like that are for cheats and external tools as far as most emu devs seem to be concerned.

How many results? Most big boy hex editors will have a search in selection, or at least the ability to make a selection and copy paste into a new file.
That gets more annoying to do after more than about 15 sections though.

You could come the other way -- treat the selections it made as sacred and inverse patch everything else to be 00 or FF (or whatever you are not searching for).

Alternatively you could feed the logger results into a batch file and use a program to slice up the file (I tend to use one called filecutter http://min.midco.net/cracker/filecutter.zip but there are many choices). Stick the results back together, or in a TAR archive (something uncompressed, in the case of TAR it has names right there in the file though and you would then call it the names from the log).

[Psyklax]

check out what bytes are used in the game

Bytes? Sorry, I don't understand. What exactly are you looking for? I understand that you're using the logger to see which memory addresses are being accessed, and you want to search for a particular value solely in those addresses. In that case, I'm not sure how you might do that, but I'm just not sure why you'd want to. Learning a bit of assembly and using the debugger would be a far quicker and more effective way to find what you want.

If you tell us a little more about what exactly you want, maybe I can help find it for you?

[abw]

You might also be interested in using the "Save Stripped Data..." and/or "Save Unused Data..." options from the Code Data Logger window and then searching for the bytes you want in the stripped ROM.

The Code/Data Logger can also be used to generate a stripped NES ROM.

"Stripped" NES ROM is a ROM in which everything that was not logged by the Code/Data Logger is removed. It can be useful in many ways, for example, you can view the ROM in an external Hex Editor or a Tile Viewer, and you'll see only the parts that were used while playing.

But yeah, unless you're making a byte frequency chart or something ("New academic study reveals $00 is the most commonly used byte in the first level of Super Mario Bros."), more information about why you care about a particular hex value would likely lead to some better suggestions about how to isolate whatever it is you're looking for.

[AlanJacobs]

Okay, for instance, for Mario 3, I don't know how to change the tile properties and the only information I can find is what the tile ID numbers are. So, in order for me to change the tile properties, I must find another tile with the properties that I want. For example, I want to change a brick (solid) tile to a cloud (background) tile.  I use the code/data logger and search for the brick tile (lets say it's 'E6') in the addresses that were accessed, but the process takes forever because I have to go through every single 'E6' in the ROM and test the ones that were accessed to see if it's the right address. When I find it, I change the brick tile ID to the cloud. This is just an example but that's the method I use. Is there a better way to do this? The debugger was mentioned but I'm unsure how to read it even though I tried to figure it out on my own. This is the first time I've asked for help on that, actually.

About asm, is there a decent tutorial on how to use assembly or someone who could help me out with the basics? I know some of the acronyms but not enough to read it. Perhaps a little understanding of this may help me out. Thanks

[Psyklax]

I would've thought SMB3 had a level editor already, but okay, I'll tell you how I'd find the tile you want.

I'd open up the nametable viewer and find the block I want, hover over it and look at its position in VRAM. I'd go to that position in the hex editor and set a write breakpoint for when that tile gets written to. Then I'd go off the screen until the tile disappeared from the nametable, then go back on with the breakpoint active. When that tile is accessed, the debugger will open at the instruction that stores my tile.

The next step is to figure out where the CPU got that tile from. The easiest way is probably to go back to the moment before the breakpoint hit (so go off the screen again) and activate the trace logger, saving to a file. You wanna make sure it's JUST before hitting the breakpoint because that log file can get BIG.

So in the log file, you can go backwards from where the breakpoint hit, to see where the tile came from. So if the tile was E6, I'd see E6 at the end of the log, and search backwards (upwards?) to the next mention of E6. Eventually the ROM location (between $8000 and $FFFF) should show up. When I see it, I'd go there in the hex editor (making sure to right-click "go here in ROM file") and change it to see if I got it right.

Of course, if you're not familiar with assembly, you might find it confusing to read. What you need to know is that on this CPU, everything goes through the Accumulator (or A). So LDA means "load A with something" and STA means "store what's in A to somewhere". We'll be looking for a moment that there's a LDA instruction from the ROM area, most likely.

Give it a try, I can't look right now, but hopefully you'll get the idea eventually.

[AlanJacobs]

You're right! There's a level editor for SMB3, however, to change the themes of each world, not only must i do graphics, i also want edit some of the object definitions tile by tile, such as the background pyramid, to meet the demands i want (palette, physical properties, etc.) Thats why im doing this in the first place. I recently posted our project under Personal Projects for those who want to check it out! 

I would've thought SMB3 had a level editor already, but okay, I'll tell you how I'd find the tile you want.

I'd open up the nametable viewer and find the block I want, hover over it and look at its position in VRAM. I'd go to that position in the hex editor and set a write breakpoint for when that tile gets written to. Then I'd go off the screen until the tile disappeared from the nametable, then go back on with the breakpoint active. When that tile is accessed, the debugger will open at the instruction that stores my tile.

The next step is to figure out where the CPU got that tile from. The easiest way is probably to go back to the moment before the breakpoint hit (so go off the screen again) and activate the trace logger, saving to a file. You wanna make sure it's JUST before hitting the breakpoint because that log file can get BIG.

So in the log file, you can go backwards from where the breakpoint hit, to see where the tile came from. So if the tile was E6, I'd see E6 at the end of the log, and search backwards (upwards?) to the next mention of E6. Eventually the ROM location (between $8000 and $FFFF) should show up. When I see it, I'd go there in the hex editor (making sure to right-click "go here in ROM file") and change it to see if I got it right.

Of course, if you're not familiar with assembly, you might find it confusing to read. What you need to know is that on this CPU, everything goes through the Accumulator (or A). So LDA means "load A with something" and STA means "store what's in A to somewhere". We'll be looking for a moment that there's a LDA instruction from the ROM area, most likely.

Give it a try, I can't look right now, but hopefully you'll get the idea eventually.

Ill try this and see how it goes. Like you said, the debugger loads fast with lots of info (which is why i get lost easily looking at it.) Thanks for the help. Much appreciated.