NROM larger than 32K?

infiniteneslives · Post by **infiniteneslives** » Fri May 25, 2012 12:16 pm

Nice work lidnariq. I'll try it out this evening.

tokumaru · Post by **tokumaru** » Fri May 25, 2012 2:12 pm

IMO, the way emulators currently handle oversize NROM images shouldn't affect the design of this new configuration. I mean, even if you got only 32KB to be mapped correctly, the best you could do with that is display a message explaining that the emulator can't run the game, but the game will still not run, since it's incomplete. IMO, displaying a message (whih would be pretty much useless once the format is supported by current emulators) is not worth making the specification more complex.

MottZilla · Post by **MottZilla** » Fri May 25, 2012 2:58 pm

So... this is all to gain slightly less than an extra 16K of PRG-ROM? It's interesting but sure doesn't seem like the best way to go about it. Take a fairly big game like Ninja Gaiden. The whole main program and game engine exist in less than 16K. Simple bankswitching for data and the music and cinema engines gets the job done. Why exactly do you need almost 48K of linear PRG space? Unless you can implement it in hardware as simply as UxROM I hardly see the point.

I think there is a reason why UxROM is popular. It gives you plenty of space for data, code, and graphics and its operation and implementation is so simple. There is a laundry list of great games that use it, so it's no wonder it has been enough for homebrew efforts.

Shiru · Post by **Shiru** » Fri May 25, 2012 3:24 pm

There are plenty of posts in this thread that explain why it is needed and what is the point. I'm personally tired to repeat myself, sorry.

Post by **tepples** » Fri May 25, 2012 3:56 pm

As for the representation in iNES, kevtris told me he's in favor of just mapping it linearly.

On IRC today, Kev and I wrote:<kevtris> well if it was me, I'd just directly map 4000-FFFF in the file and not dick around with worrying about cutting out pieces of it
<tepples> So as I understand it, you say the ROM would have PRG size 3: first $4000-$7FFF, then $8000-$BFFF, then $C000-$FFFF. But the way it'd have to be burned to an actual 27C512 would be $8000, then $C000, then blank, then $4000
<kevtris> yeah sounds about right. it's probably best to linearly map it in the file, then adjust to burn an eprom. you have to process the file somehow anyways (stripping headers, etc)
<tepples> True, but the objection is that the existing tools for processing the file don't include reordering. That said, tokumaru agrees with you.
<kevtris> so... write a new one. it's going to be a hack one way or another

This means that for mappers 0 (NROM), 3 (CNROM), 13 (CPROM), and 99 (Vs. Unisystem), if PRG size is 3 banks, the ROM image is arranged as follows:

16 bytes: iNES or NES 2.0 header. Trainer and battery are forbidden; NES 2.0 PRG RAM size must be 0.
2048 bytes: Ignored.
47104 bytes: PRG ROM mapped to $4800-$FFFF.
8192*n bytes: CHR ROM mapped to PPU $0000-$1FFF.

Dwedit · Post by **Dwedit** » Fri May 25, 2012 4:00 pm

If someone tries to do something as bastardized as a Mapper #0 48k PRG game with the trainer flag on, I think the trainer should still override the defined ROM. Because that's what the trainer flag is for. Sure, it's completely worthless, but it's what should happen.

infiniteneslives · Post by **infiniteneslives** » Fri May 25, 2012 4:11 pm

Well at least that's settled now. Thanks for going to the authority on the matter and getting a final answer for us Tepples.

To be clear though it really doesn't matter how it's burned on the EPROM. That could vary and be used for optimizations of the mapper and PCB etc. So I guess in reality regardless of the situation the burner of EPROMs and designer of PCB/mapper really needs to know what they are doing anyways.

EDIT: Did we reach a conclusion on the name?

MottZilla · Post by **MottZilla** » Fri May 25, 2012 5:35 pm

Shiru wrote:There are plenty of posts in this thread that explain why it is needed and what is the point. I'm personally tired to repeat myself, sorry.

I just ask because earlier you stated it would help for programming in C and then later said that bankswitching is not impairing your ability to use C. When you create a UNROM board with just two 74 series chips I don't see the advantage of getting less PRG-ROM which perhaps more logic chips to decode it?

infiniteneslives · Post by **infiniteneslives** » Fri May 25, 2012 6:07 pm

lidnariq can you modify your test per the newly defined format? Your PRG is 64KB and I don't know how I should cut it down to 3 banks. I think I see the order you chose based on where the reset vectors appear to be, but I'm still left with an extra bank. Or is the test meant to be ran as 4 banks to ensure that the first bank doesn't get enabled and conflict with other devices at that address?

EDIT: I've been running all four banks although I'm assuming the first bank is useless other than filler (was actually the third bank in your .prg)

I got it running but for some reason I'm having an issue with what appears to be $5000-57FF. For the first line I'm getting HZ for the first quarter, checks for the second qtr, X's for the third qtr, and checks for last/fouth qtr.

All other lines are checks. I've never used PRG A12 as an input and that line being high is the only thing that tells my logic to enable the PRG ROM for $5000-57FF. I'll have to do some more debugging... I also sort of confirmed the ROM was good by enabling the PRG ROM above $4000. I got M's for the first qtr which is where PRG ROM should be disabled everything else is checks. So all signs point to an issue with PRG A12 for some reason.

Here's my verilog code for anyone curious/interested

Code: Select all

			if (prg_size == 1)
				begin//NROM128
					prg_addr_hi[15:14] = 2'b0;
					p_ce = b_prg_ce;	//prg /CE signal
				end
				
			else if (prg_size == 2)
				begin//NROM256
					prg_addr_hi[14] = b_prg_addr[14];
					prg_addr_hi[15] = 1'b0;
					p_ce = b_prg_ce;	//prg /CE signal
				end
				
			else 
				begin//NROM368
					prg_addr_hi[14] = b_prg_addr[14];
					prg_addr_hi[15] = b_m2 & ~b_prg_ce;
					w_ce = 1'b1;		//wram forbidden
					
					//if ( {prg_addr_hi[15], b_prg_addr[14:11]} >= 5'b01000 )	//PRG address >= $4000
					if ( {prg_addr_hi[15], b_prg_addr[14:11]} >= 5'b01001 )	//PRG address >= $4800
						p_ce = 1'b0;	//prg /CE enabled
					else
						p_ce = 1'b1;	//prg /CE disabled
				end

Shiru · Post by **Shiru** » Sat May 26, 2012 5:33 am

MottZilla wrote:I just ask because earlier you stated it would help for programming in C and then later said that bankswitching is not impairing your ability to use C.

My personal abilities has nothing to do with abilities of newcomers that I want to bring to the NES homebrew scene. Bankswitching requires to go low level and get a huge layer of knowledge, extra linear space does not require that.

So, are we settled down with the layout posted by tepples? I'm personally OK with it if that many people including kevtris prefer it.

This means that for mappers 0 (NROM), 3 (CNROM), 13 (CPROM), and 99 (Vs. Unisystem), if PRG size is 3 banks, the ROM image is arranged as follows:

16 bytes: iNES or NES 2.0 header. Trainer and battery are forbidden; NES 2.0 PRG RAM size must be 0.
2048 bytes: Ignored.
47104 bytes: PRG ROM mapped to $4800-$FFFF.
8192*n bytes: CHR ROM mapped to PPU $0000-$1FFF.

cpow · Post by **cpow** » Sat May 26, 2012 8:05 am

Shiru wrote: So, are we settled down with the layout posted by tepples? I'm personally OK with it if that many people including kevtris prefer it.

This means that for mappers 0 (NROM), 3 (CNROM), 13 (CPROM), and 99 (Vs. Unisystem), if PRG size is 3 banks, the ROM image is arranged as follows:

16 bytes: iNES or NES 2.0 header. Trainer and battery are forbidden; NES 2.0 PRG RAM size must be 0.
2048 bytes: Ignored.
47104 bytes: PRG ROM mapped to $4800-$FFFF.
8192*n bytes: CHR ROM mapped to PPU $0000-$1FFF.

I like it...going to give it a try.

Shiru · Post by **Shiru** » Sat May 26, 2012 8:29 am

OK, so I'm going to make a test ROM and try to make an emulator mod with this layout.

MottZilla · Post by **MottZilla** » Sat May 26, 2012 11:24 am

Shiru wrote: My personal abilities has nothing to do with abilities of newcomers that I want to bring to the NES homebrew scene. Bankswitching requires to go low level and get a huge layer of knowledge, extra linear space does not require that.

Well that makes more sense to me now, you're trying to do this to help get people without low level (6502 asm) knowledge involved by getting extra space for some sort of C programming development setup?

Kind of reminds me of that NBASIC or whatever it was called. There was a demo made with it called Sack of Flour Heart of Gold I think.

3gengames · Post by **3gengames** » Sat May 26, 2012 11:27 am

Yeah, the NBASIC made by that college guy and then his class (attempted) game programming with it. Bob Ross rings a bell, probably sounded something like that.

Bregalad · Post by **Bregalad** » Sat May 26, 2012 11:38 am

I'd agree with the layout proposed by tepples but why ignore the 2048 first bytes ? Why not just the first $17 bytes, which are used by the CPU registers ?

Ok, someone will answer "because with some shematic [....] it will ignore the first 2048 bytes". Ok, ok, but that doesn't mean all super-NROM carts would use this schematic. I'm pretty sure it's possible to decode the ROM at $4018-$ffff with a single PAL/GAL chip easily - and those aren't more expensive than 74xxx chips.