NROM larger than 32K?

[Shiru]

Breagalad, basically your argument is 'I don't like this because it seems illogical for me and like that because it seems logical for me', that's it. This is not something that changes current balance of pros and cons and helps to make a desicion, it just a discussion of a personal view of a problem.

'I don't care' and 'not my problem' are not valid argument, it is not something personal to you that no one else will use.

'What CPU sees' does not counts, because CPU is a thing, it simply works, and 'convinient or not' does not matter for it. It matters for people who will have to work with these files.

Multiple ROMs is not a practical option, the whole point of the extension is that modern electronics allows to make it in an easy way, as a waste of resources is acceptable these days.

NROM is kind of a format for beginners, requires less knowledge and skills. Extended NROM is targeted to the same category, to the people who not yet care or know tricky hardware details etc. It should be easy to use for all purposes, including ROM burning. Otherwise other people will have to answer endless questions like 'I did the same as I do for NROM games, but my cartridge does not work'.

[infiniteneslives]

I don't care at all how it's implemented in hardware, at least in iNES format.

Don't forget that hardware uses the iNES format.

I'm not saying I won't support the odd sized iNES file with the NESDEV1. But when you consider how to handle rom images with PC tools it makes things super nice and clean if you can assume even ROM sizes. odd sizes require special cases and such which would be nice to avoid. I know it doesn't sound logical. But personally I think we should put heavier weight on what's better and more convenient for emulators, ROM tools, and hardware. To most people they would never know the difference between the two choices other than it might not be sound logical to you.

To me order doesn't really matter in implementation. I see valid reasons for both choices. Neither has significant drawback IMO.

I agree...emulation and burning are different realms.

EDIT: Devcarts are stuck in the middle of those two things.

[Bregalad]

Ok, shiru's proposal would make the burning process easier, it's true. However it would make the compile process harder to have to reverse the data order.

The only goal to have ROM linearly mapper to space without using bankswitching is so that you can code something without caring where it will fall in memory, and that you can have some routine starting at $7Fxx and continue into $80xx. Therefore there is probably no way to tell the compiler to reverse the bank order in the final file in a single pass, unless you split it in two banks, and this kills the main purpose of having the ROM mapper linarly in the first point.

Therefore you'll need another "tool" to build the iNES ROM, there is probably 9128 ways of doing it, but in all cases it will complicate the building process to simplify the burning process.
This is not necessary a bad thing, but I just want to make sure you guys are aware of that.
The order $4000, $8000, $C000 makes simple building process, but complex burning process, and makes the most sense. The order $8000, $C000, blank, $4000 complicates the building process and makes a little less sense, but simplifies the burning process.

EDIT : Anyways this is the 89478276th thread with debates about mappers, board and hardware. Yet all the better homebrew games so far uses plain NROM and it works just as well if you ask me - and there would be a LOT of room for anything even if you restrict to existing mappers.

[Shiru]

Now that's a good argument and reasoning, thanks.

I thought about it, but not too deep, as I get used to assembler's abilities to swap banks in the resulting file in a required order. However, I forgot that CC65 would probably need to have a large linear chunk for the code segment and will not be able to spread code over two segments automatically.

So what is needed is to figure out - if it is possible to make CC65 make the data swap in the resulting file using memory config file only, without external tools.

I don't consider other assemblers, because larger linear space not really needed for users of these, and there is probably a workaround with using few banks/sections anyway.


Regarding importance of the NROM extension in general - yes, it is not very important, but it is a nice small improvement that is (relatively) easily achievable. As an author of a few NROM games I can tell that there is almost always shortage of room, especially if the program is in C. Also, one of the most often asked improvements for games is 'more levels'. More levels - more room needed - in case with C easier to add with extra linear space.

[tepples]

Yet all the better homebrew games so far uses plain NROM and it works just as well

How much of this is due to developers scaling back the scope of their projects due to 1. lack of artistic resources and 2. lack of battery-backed or IRQ-capable reproduction boards?

there is almost always shortage of room, especially if the program is in C.

Of course, one thing you could do is look at the resulting assembly code, rewrite the most space-inefficiently compiled parts, and submit them to the cc65 project.

[cpow]

Now that's a good argument and reasoning, thanks.

I thought about it, but not too deep, as I get used to assembler's abilities to swap banks in the resulting file in a required order. However, I forgot that CC65 would probably need to have a large linear chunk for the code segment and will not be able to spread code over two segments automatically.

Usually you don't use the compiler, linker, or assembler to do the "built executable to burnable binary" manipulations. I use objcopy to do that. If there's similar in cc65 toolchain or if GNU objcopy could be used then there's no need to debate the complications of how to take a linear image and make it burnable nonlinearly.

[tokumaru]

If there's similar in cc65 toolchain or if GNU objcopy could be used then there's no need to debate the complications of how to take a linear image and make it burnable nonlinearly.

Except that much of the reasoning you guys have in favor of this cart is that newbies get a larger linear space to work with. What's the point in that if compiling/assembling gets considerably more complex? Your average NESASM/ASM6 newbie will hardly understand this. Seriously, offloading the music engine/data to another bank sounds much simpler.

[cpow]

If there's similar in cc65 toolchain or if GNU objcopy could be used then there's no need to debate the complications of how to take a linear image and make it burnable nonlinearly.

Except that much of the reasoning you guys have in favor of this cart is that newbies get a larger linear space to work with. What's the point in that if compiling/assembling gets considerably more complex? Your average NESASM/ASM6 newbie will hardly understand this. Seriously, offloading the music engine/data to another bank sounds much simpler.

I'm confused. I was arguing exactly the opposite. Compiling/assembling/linking has *nothing* to do with preparing the linked-thing to be burned in whatever device(s) it'll end up being burned in. Heck, you could even accomplish whatever's necessary with something like head/tail.

Your average newbie won't have to understand how to make a burnable image, right? They'll just have to understand "I get an iNES out that is runnable in emulator x, y, or z..." Once they get to the point of wanting to burn something they'll probably be considerably less newbie-ish.

[Shiru]

Since there are many ways to do it, my design approach is to find a solution that will simplify as much things as possible without involving any extra knowledge and tools than required to handle not extended NROM files.

If a compiler can rearrange data to make a ROM image that is easily burnable without extra tools and without complicated programming, it is a win, and this solution is the best.

I honestly don't get the attitude 'I don't understand/don't need/don't like it, so it is useless/bad/not needed'.


Also, please, guys, don't tell me how I can solve my personal problems I mention in the thread, like shortage of space in my projects, or handling mappers, offloading data into banks etc. Be sure, I know how to do it, is capable to do it, and in fact did it in the past. My interest in extending NROM and my point of view on its design is based off my desire to bring more people on the platform by lowering the entry barrier in various ways, and also based off my experience of communication with these people.

[tokumaru]

I'm confused. I was arguing exactly the opposite.

Oh yeah, my bad! =)

[tepples]

At this point, if kevtris doesn't have anything to say, I'm inclined to go with tokumaru's suggestion and define no-mapper PRG ROM as always having the banks in linear-address-space order because of the noob-friendliness advantage.

• 1 bank: mapped into $8000 and $C000; optional PRG RAM at $6000
• 2 banks: bank 0 in $8000 and bank 1 in $C000; optional PRG RAM at $6000
• 3 banks: bank 0 in $4000 (first 2048 bytes inaccessible), bank 1 in $8000, and bank 2 in $C000; PRG RAM forbidden

As for burning an EPROM, one needs a tool anyway to split an iNES file into header, PRG, and CHR. A tool supporting this format extension could have an option to rearrange PRG into 1, 2, 0, 0 order for an EPROM image.

(Note to self: Try to catch kevtris on EFnet tonight.)

[infiniteneslives]

I'm starting to think the 'in order' method is the better choice too:
$4000, $8000, $c000

Are there any arguments to go with 3 banks vice 4 aside from waste of space? Not to discredit the space argument but it's the only one I've heard. However I agree with Shiru that it's kind of a moot point.

I'd prefer a format with:
blank, $4000, $8000, $c000

Odd banks will be annoying but not difficult to add a special case for in my software/hardware. I guess I'm just more concerned about the idea of odd bank being acceptable or the norm. So really my argument is that there should ALWAYS be even (power of 2) number of banks. Moving files around is simpler and potentially quicker if you don't have to make special cases of when there are odd ROM sizes. I don't know what's all involved with the powerpak but with the NESDEV1 I've got a small 8bit mcu that's handling these special cases. Add this one mapper and it's not much issue. But if down if the road all kinds of special odd ROM sizes need to be supported it'll be a headache. Especially if one setup puts the padding in front or in the back. Then there are even more special cases. I guess I see leaving the blank bank out as somewhat ambiguous from the perspective of how the mapper interact with the ROM. And there are already enough ambious things with iNES that I'll argue against adding another until people agree or they just tell me to shut up.

I would think it would also be easier if down the road someone wanted to bank swap the lower memory that's being wasted here. Seems somewhat logical to me if one only stores level data and/or music there. The change becomes simple at that point at least for hardware. You only have to change the mapper, not the special case logic/code to fill in the blank bank that actually exists in the ROM image.

[bunnyboy]

Yet all the better homebrew games so far uses plain NROM and it works just as well

How much of this is due to developers scaling back the scope of their projects due to 1. lack of artistic resources and 2. lack of battery-backed or IRQ-capable reproduction boards?

None. Almost every finished homebrew uses CHR RAM (some with banking) so artistic resources isn't a limit. I have seen zero finished (or even beta) homebrews that were significantly scaled back because of hardware reasons like IRQ or WRAM. Lack of hardware is not a concern when there are emulators, donor boards, and building hardware is far easier than building a game.

Battle Kid is by far the best selling and arguably the best completed homebrew, and it uses plain 256KB UNROM. The second best selling is 8 BIT XMAS 2011, and while it certainly isn't the best homebrew it only used NRAM (other than the LEDs). Nomolos will hopefully take the #2 slot soon and again uses 256KB UNROM.

[tepples]

Almost every finished homebrew uses CHR RAM (some with banking) so artistic resources isn't a limit.

I was referring more to the human resources of artists to draw what goes into CHR RAM. A lot of homebrew games are one-man efforts, and I imagine that a lot of programmers who know they won't be able to find an artist for a given project design their games so as to use fewer graphics. I apologize for being less than clear about this.

[lidnariq]

I've written a rudimentary test for support, it's at http://eamp.org/li/nrom368.zip . It contains an iNES file to demonstrate what it will look like when only the top 32kB are decoded, as well as the CHR and expanded PRG (where ROM A15 = nPRGSEL) for placing on a devcart. If implemented correctly, the center of the screen should be full of white symbols (HZ or ✓) and no red (X or M).

To repeat: the iNES file does NOT contain the full 48-or-64kB image both because FCEU(X) behaves differently from the other emulators I've tried and would not work and because I don't want to cast a vote on the layout inside an iNES file.