This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Disassembling using Mappers / multiple rom banks?

Disassembling using Mappers / multiple rom banks?
by on (#74369)
one thing I've noticed almost all NES disassemblers lack is support for mappers and multiple rom banks.. and its not surprising. I want to add this feature to DASM6, but I'd like to get some insight from those who are more familiar with dealing with mappers than i am

To disassemble a rom with a mapper, there are the following difficulties:
1. Knowing how the rom file is mapped into memory.

For some mappers this is relatively straightforward (ex mapper 2), but for others, it's totally up to the programmer. We can use CDL logs to know where in memory the file was mapped to, but even then, it's technically possible for the same bytes in the file to be loaded into either rom bank, so a CDL log might not be 100% correct

possible solutions:
* allow use of user provided memory map in addition to CDL
* don't support games which put the same bank in two locations
* ?


2. Knowing how to deal with label references which are outside of the current bank

for example, lets say a game has a bank hard coded to 0xc000, and code in that bank jumps to someplace around 0x8000. But which bank is it jumping to? It's possible that the proper destination for the jump code is only in one bank.. but we don't know which bank.

Assuming it exists in all banks will mess up the output of the other banks

possible solutions
* only allow "code" labels (mentioned in jmp/jsr/branch) from other banks if CDL says it's code and also the label points to an opcode, not inside of a command. and conversely only allow data labels (lda/sta) if CDL says it's data
* allow user defined labels to also specify which bank it exists in (seems like we'll need this anyways) and add label to that bank if the user specified it. using this alone could lead to invalid labels though.. so maybe output a list of labels which weren't found and force user to define them?


i separated this from my DASM6 thread since it could be handy for other disassembler authors.. would love to hear about other problems and solutions to disassembling roms which use mappers.

funny thing is just writing this out has helped me brainstorm lol

by on (#74370)
Usually the "fixed bank" either hardwired into it or something, and then like defender, other routines are switched in and out as needed. So knowing which bank it's in will be hard. But the main code should be all in grouped banks close together. Subroutines that are shared in another, then another for other routines? It depends on how the programmer did it, but that's how I'd do it.

by on (#74375)
I don't know how you'd implement this reliably. Some mappers permit multiple bank sizes (4KB vs. 8KB vs. 16KB for example) which a programmer can toggle on-the-fly by writes to memory-mapped mapper register space (too many "m"s!!!). Your disassembler would literally have to have a 6502 emulator in it and emulate the entire console to map writes to those registers -- don't think "watching" LDA/STA would suffice, because they don't (as I'm sure you know there are multitudes of ways to write a byte to an address on the 6502).

I tend to recommend that disassemblers permit the person using them to provide a file offset via a command-line argument (e.g. -x 12345), as well as an explicit bank size (e.g. -s 8192). Supporting unit types for the bank size (e.g. -s 8K) would be useful too (UNIX dd has support for this and lots of people rely on it).

by on (#74382)
koitsu wrote:
I don't know how you'd implement this reliably.


yes that's why i haven't really tried.. there is rudamentary mapper 2 support but i havent even tested it because as i was writing it i realized doing so adds a whole nother layer of complexity and if done wrong, the mapper handling code for all of the mappers could be longer than the rest of the program

Quote:
I tend to recommend that disassemblers permit the person using them to provide a file offset via a command-line argument (e.g. -x 12345), as well as an explicit bank size (e.g. -s 8192). Supporting unit types for the bank size (e.g. -s 8K) would be useful too (UNIX dd has support for this and lots of people rely on it).


i like that suggestion.. much easier to implement :D

by on (#74386)
I'd say let the program decide what the chunks are used for (kernal, subroutines, data, etc) and then just let the user know what the general bank of ROM if for.

by on (#74387)
^ i'm not sure i'm following you

in this thread i found an interesting suggestion from Hamarto to use FCEU ABS which has an address use logger.. have too look into it more

by on (#74388)
frantik wrote:
^ i'm not sure i'm following you


I'm not sure what he's referring to there either. Possibly data vs. code disambiguation, but I believe your software already does that to some degree. But I have no idea what "let the user know what the general bank of ROM is for". I'll tell you what it's for: "stuff". Bank 0 =stuff. Bank 1 = stuff. Bank 2 = stuff...

by on (#74389)
frantik wrote:
^ i'm not sure i'm following you

in this thread i found an interesting suggestion from Hamarto to use FCEU ABS which has an address use logger.. have too look into it more


AND it supports FDS unlike other ports, But I think FCEUX cut the address logger out,

We need to see if a new suggestion for a replacement of that address logger, plus a new format based on that logger that will be more readable and stuff...

Should we do another proposal? It's our decision.

EDIT, Heh, Hamarto.

by on (#74390)
Yeah I just going for something like bank 0:Program bank 1:data bank 2:subrotuines but just my idea. I'm interested to see how you go about this tricky task!

by on (#74395)
Quote:
But I think FCEUX cut the address logger out,

We need to see if a new suggestion for a replacement of that address logger, plus a new format based on that logger that will be more readable and stuff...


yeah i noticed it wasn't in FCEUX.. only in FCEU ABS... plus the format looks a bit confusing and is obviously not well supported. using an obscure format generated by an obscure fork isn't the best solution. but i think something like this is needed to make a good multi-bank disassembly

Quote:
Should we do another proposal? It's our decision


well we could make a proposal, but someone would have to decide to adopt our proposal and then program the tools into FCEU* or some other emulator... which isn't very likely i don't think.

Hamtaro126 wrote:
EDIT, Heh, Hamarto.


:oops:
Re: Disassembling using Mappers / multiple rom banks?
by on (#74405)
frantik wrote:
it's technically possible for the same bytes in the file to be loaded into either rom bank, so a CDL log might not be 100% correct

I think this is unlikely to happen a lot in the wild though, I mean it's just not something that would be useful for the programmers to do. But I'm sure there are some exceptions out there. :)

I'd start with "don't support games which put the same bank in two locations" and see how many games pop up that actually would need that feature.

Quote:
2. Knowing how to deal with label references which are outside of the current bank

I don't know exactly how capable CDL files are but I wouldn't even think about doing this in any other other way than using emulator logs.

What are the address logs like? I can't find any info about FCEU ABS. I will consider adding support for that (as well as "CDL") in Nintendulator if you let me know what you need.
Re: Disassembling using Mappers / multiple rom banks?
by on (#74406)
thefox wrote:
What are the address logs like? I can't find any info about FCEU ABS. I will consider adding support for that (as well as "CDL") in Nintendulator if you let me know what you need.

the Address Use Log (.AUL) format is described in fceuabs.txt which is inside this zip. if you want to incorporate something like this into nintendulator or come up with a different format that would be cool

the Code/Data Log (CDL) format is described in a post above and also here