DocWaluigean wrote:-So the iNES header is an information. But I'm assuming this ines only works in the ASM6.
The .ines*** directives only exist in NESASM. In most other assemblers people just create the header using .db/.byte statements. It's also possible to create macros that simulate NESASM's directives.
-Is there a limit to numbers for each codes beside inesmap? I'm sure you can go up to inesmap 255 something with Namco mapper, Konami mapper, Sunsoft mapper, etc.
Mapper numbers are normally assigned by whoever discovers/creates them. The wiki has a list of the most popular mappers:
https://wiki.nesdev.com/w/index.php/List_of_mappers
The limits for the other fields will depend on the mapper. Each mapper supports different amounts of PRG and CHR stand use different techniques for bankswitching them.
-So PRG code is "assign scripts to sprites, by limit"?
The PRG field is the amount of PRoGram-ROM, measured in units of 16KB. This is the memory used to hold the game program, the code that the CPU runs to make stuff happen. All the game logic is here, along with all the data used by the game (e.g. levels, music, etc.).
and CHR data "the amount of sprite and tile banks"?
Yes, that's the amount of CHaRacter-ROM, measured in units of 8KB (512 tiles).
ineschr 1 = 1 bank of tiles/sprites? can it go up to over 128?
Don't get too hung up on the term "bank" here, since the size of a bank varies from mapper to mapper. CHR-ROM banks can be any of 8KB, 4KB, 2KB or 1KB, but the INES header always measures the total amount in multiples of 8KB, regardless of the mapper.
How high you can go will depend on the mapper. 128 x 8KB would be 1MB, and not many mappers support that. Another thing to keep in mind is that even though the total amount of tiles can be significantly high, you can't use any tile you want whenever you want, because the NES still only sees a small number of them at a time. The way in which you select which tiles will be usable at any given time will depend on the mapper.
-Obviously a good idea to ignore for now, but is there importances for inesmir 1?
The NES has a virtual background space of 4 screens arranged in a 2x2 grid, but it only has enough memory to hold 2 screens, which means that 2 of those 4 will have to be repeats. The mirroring setting selects whether the screens will repeat horizontally or vertically.
Universal question: At which part is needed to show the entire gray screen? Up to ines?
I don't understand the question. What do you mean by "entire gray screen"?
need bank 0, 1, and 2 to make a correct blank NES?
Memory chips are only manufacred in sizes that are powers of 2 (e.g. 8KB, 16KB, 32KB, 64KB, 128KB, etc.), so you need to have a number of banks that adds up to a power of 2 in order to represent a valid memory chip, even if they are empty.
Do note that NESASM's .bank directive creates banks that are 8KB in size, while the INES header counts banks that are 16KB. So in this case, NESASM banks 0 and 1 would be the one 16KB bank defined via .inesprg, and bank 2 is the one 8KB bank defined via .ineschr.
Like I said, don't focus too much on the work "bank" as used by NESASM and the INES header, because the actual size of the banks is defined by the bankswitching scheme of the mapper you use. Just think of INES banks as units for counting, and NESASM's banks as blocks of 8KB, which won't necessarily be manipulated individually.