Page 4 of 13
Posted: Wed May 23, 2012 4:48 pm
by Shiru
Yes, I think extending CNROM the same way would be a good idea. It is also easy to use with a HLL, since only CHR is bankswitched.
To make 'fullscale' tests we first need to modify an emulator. Since this is a 'chicken or the egg' situation, chances to get an active emulator developer interested in this are low (no software to test against and no reason to bother with yet). So I plan to do it by myself. Hopefully this won't be too difficult, it does not seem so at least.
Since the last quarter of a 64K ROM going to be empty, there is not much sense to store it in an iNES file. On the other hand, a ROM burner software may require to pad it to 64K to be used - don't know for sure.
Posted: Wed May 23, 2012 5:56 pm
by lidnariq
I wrote a simple test program to see what various emulators do with oversize iNES mapper 0 images.
- Nintendulator and Nestopia always map the first 32kB to the aperture
- FCEUX maps the first and last 16kB to $8000 and $c000 when it's a power of two. The emulated machine crashes when it's 3.
The actual layout on the physical ROM would be
$8000-$FFFF are in addresses 0x0000 to 0x7FFF
$4800-$7FFF are in addresses 0xC800 to 0xFFFF
0x8000 through 0xC7FF wouldn't be addressable, i.e. the padding's in the middle.
I'm still undecided whether the right iNES representation is the contents of the ROM verbatim or the linear 48kB as seen by the CPU. I vaguely feel like the latter is slightly more correct, but the former has the advantage that the interrupt vectors are in the correct place in emulators that truncate to the first 32kB, and just discards the remaining 14kB.
Posted: Wed May 23, 2012 6:26 pm
by tepples
lidnariq wrote:I'm still undecided whether the right iNES representation is the contents of the ROM verbatim or the linear 48kB as seen by the CPU. I vaguely feel like the latter is slightly more correct, but the former has the advantage that the interrupt vectors are in the correct place in emulators that truncate to the first 32kB, and just discards the remaining 14kB.
Storing the banks in an order that doesn't match the linear order in address space has precedent. Mapper 40, for example, has bank 6 at $6000-$7FFF and banks 4, 5, <switchable>, and 7 in $8000-$FFFF. In addition, having an odd number of 16 KiB units would more distinctly identify this variant of NROM/CNROM/CPROM.
I'll have to try making 8 KiB stubs that allow testing some of these programs on a PowerPak or an SNROM board. It'd switch to bank 1, copy $A000-$BFFF to $6000-$7FFF, copy $C000-$DFFF to CHR RAM, switch to bank 0, and finally jump to the reset code. Either way, there'll have to be a Barbie stub at $FFF0-$FFF9 to guarantee power-on behavior:
Code: Select all
fff0:
sei
ldx #$FF
stx $FFF2
jmp real_reset
.addr nmi_handler, fff0_entry, irq_handler
Posted: Wed May 23, 2012 7:10 pm
by infiniteneslives
Shiru wrote:To make 'fullscale' tests we first need to modify an emulator. Since this is a 'chicken or the egg' situation, chances to get an active emulator developer interested in this are low (no software to test against and no reason to bother with yet).
Not sure if you noticed or not since I ninja'd you on the previous page. But I can easily test this in hardware right now with the NESDEV1. At least that way the emulator could compare to the actual NES, which is really how it should be done to verify proof of concept.
If someone provides a test rom I can run it.
Posted: Thu May 24, 2012 3:17 am
by Shiru
To make test on the hardware we need to write and debug test code. An emulator support is needed to do it.
Posted: Thu May 24, 2012 3:49 am
by Bregalad
What about hacking a FDS games that runs code at $6000-$BFFF into your extension of NROM ?
There is also quite a lot of emus which are open souce, so you could easily modify one of them to get the oversize NROM configuration you want.
Also I'd add that if NROM were to have a larger PRG-ROM than 32k, since it would be mapped linearly in the adress space the data should definitely be mapped linearly in the .nes ROM too.
Posted: Thu May 24, 2012 4:05 am
by Shiru
Modifying an open source emulator is exactly what I'm going to do. I just need some time to do this.
Linear layout that corresponds to the NES address space has a drawback that you can't just burn this headerless file into a ROM chip, you need to convert it first - extra tool and knowledge required. Layout that corresponds to the ROM address space is free from this drawback. On the other hand it complicates romhacking, so this is definitely something to think well beforehand.
Posted: Thu May 24, 2012 4:35 am
by Bregalad
Huh ?
You'll need two EPROMs anyways because there is no 48k EPROM arround.
What makes the most sense is to have in the iNES file first the 16k that goes in the first EPROM at $4000-$7FFF (but adresses $4000-$4xxx should be blocked by some kind of hardware to prevent bus conflicts - anyways those adresses will still exist in the EPROM and in the iNES files - and then data in the second EPROM at $8000-$FFFF, like usual.
Posted: Thu May 24, 2012 4:47 am
by Shiru
I said it in the very first post - 64K ROM chip with wasted 16K (18K in the latest design).
Posted: Thu May 24, 2012 5:16 am
by Bregalad
This doesn't change anything - just that since data is wasted it won't be present in the ROM image. The used 48k should still be present, and linear, in the ROM.
Posted: Thu May 24, 2012 5:19 am
by Shiru
Bregalad, please read the thread. The discrete logic design makes layout non linear, with 32K halves swapped. If it would be linear, there would be no talk about non linear layout at all.
Posted: Thu May 24, 2012 5:53 am
by Bregalad
I don't think it changes anything if 32k halves are swapped. The NES can't see the difference, so you won't see a difference when you dump the ROM - therefore it should still be contiguous in the ROM image. You'd have to make it non-contiguous when programing the EPROM though - but that's another story.
Posted: Thu May 24, 2012 5:57 am
by Shiru
That is not another story. That is a very important thing to consider beforehand.
Whether you'll see the difference or not is depends from method of dumping, and dumping itself is certainly way less important thing than burning. You know, you need to make something first to have something to dump.
Posted: Thu May 24, 2012 6:12 am
by tepples
What we're trying to iron out is whether the $8000-$FFFF data appears before or after the $4800-$7FFF data in an iNES image with three 16 KiB banks. Either way, the PRG part is going to have to be rearranged before burning.
If $8000-$FFFF appears before $4800-$7FFF, then the PRG part is laid out as follows:
Bank 0: $8000-$BFFF
Bank 1: $C000-$FFFF
Bank 2: 2048 bytes of padding, then $4800-$7FFF
In this case, you have to double up bank 2 before burning it to the 27C512 EPROM. Then the EPROM sees PRG /CE as A15, and all is well; reads of $4800-$7FFF come from the doubled-up copy.
If $8000-$FFFF appears before $4800-$7FFF, then the PRG part is laid out as follows:
Bank 0: 2048 bytes of padding, then $4800-$7FFF
Bank 1: $8000-$BFFF
Bank 2: $C000-$FFFF
In this case, you have to move bank 0 to the end of the image and then double it up before burning it to the EPROM.
Posted: Thu May 24, 2012 6:26 am
by Shiru
We can just use the first variant but double up the bank 2 in the iNES image, having 4 banks there. Kind of overdump, but these days extra 16K on a hard disk is nothing important, and the files are usually stored zipped anyway.
Although doubling is a problem for authoring tools, and it is better to simply have all zeroes in bank 2. I mean, it is easier to make an assembler generate a file with padding in the middle rather than make it to double a bank.