Expanding a game beyond its physical board limitations

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderators: B00daW, Moderators

Post Reply
Pennywise
Posts: 62
Joined: Tue Jul 14, 2009 11:04 am

Expanding a game beyond its physical board limitations

Post by Pennywise » Wed May 08, 2013 11:00 am

This is a subject that has interested me for some time since I've made it common practice to expand NES ROMs and sometimes I would avoid expansion if there wasn't a physical board to support it. I believe that this might be a moot point with flash carts etc that emulate the original mapper, but can have ROM sizes larger than what's specified and still work on the NES.

Anyhow, the latest games I've come across are mapper 75 and those bandai mappers 16, 154, 159 etc

Now mapper 75 is capped at an unreasonable 128kb for the PRG-ROM, but I expanded the original ROM and had it tested on a Powerpak. The game ran fine from what I remember. Then there's the Bandai games which are capped at 256kb.

Anyway my question is to expand or not to expand? In most cases the games won't work in Nestopia, but emulator's and/or flash carts seems capable to playing them fine. Also is it possible to modify the original boards to support a larger PRG-ROM?

lidnariq
Posts: 8768
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Expanding a game beyond its physical board limitations

Post by lidnariq » Wed May 08, 2013 11:10 am

Pennywise wrote:Also is it possible to modify the original boards to support a larger PRG-ROM?
No. That's where these constraints come from.
Last edited by lidnariq on Wed May 08, 2013 11:15 am, edited 1 time in total.

User avatar
tokumaru
Posts: 11465
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Expanding a game beyond its physical board limitations

Post by tokumaru » Wed May 08, 2013 11:13 am

Pennywise wrote:Also is it possible to modify the original boards to support a larger PRG-ROM?
With discrete logic mappers you can easily add/replace parts to support larger ROMs, but with ASIC mappers things are not so easy. If they don't have the pins to support larger ROMs, there's no way to hack them in. One possibility in this case is to add a "master mapper" on top of the existing mapper (pirate multicarts sometimes do this). For example, if a mapper is limited to 256KB, you can add a few discrete logic components and become able to select different 256KB blocks from a larger ROM. This will break compatibility in emulators of course.

The other alternative, which will retain compatibility with emulators that implement more banking bits than available in the actual mappers, is to recreate the mapper in a CPLD or FPGA, but with more banking bits than the original mappers.

lidnariq
Posts: 8768
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Expanding a game beyond its physical board limitations

Post by lidnariq » Wed May 08, 2013 12:52 pm

Sometimes a game could be expanded by mapper hacking at the same time. For example, mapper 154 (Namco 108 with 1-screen mirroring) could probably be reasonably ported to any MMC3-like mapper that supports 1-screen mirroring, such as 207, 158, or 118. Similarly, mapper 75 (Konami VRC1) is approximately a subset of 64, 80, or 82.

Pennywise
Posts: 62
Joined: Tue Jul 14, 2009 11:04 am

Re: Expanding a game beyond its physical board limitations

Post by Pennywise » Wed May 08, 2013 1:07 pm

lidnariq wrote:Sometimes a game could be expanded by mapper hacking at the same time. For example, mapper 154 (Namco 108 with 1-screen mirroring) could probably be reasonably ported to any MMC3-like mapper that supports 1-screen mirroring, such as 207, 158, or 118. Similarly, mapper 75 (Konami VRC1) is approximately a subset of 64, 80, or 82.
True. I've actually expanded a GxROM game to 256kb and hacked the mapper to become one of those Chinese pirate mappers. It was the exact same, but with more PRG bits. I don't think 159 is even supported by flash carts and the unique nature of it prevents it from working with other mappers. At least I think. Unless extra time is spent to hack the game to use traditional SRAM instead of EPROM. If that is even possible, how difficult it is, time etc.

tepples
Posts: 21748
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Sega Dreamcast

Post by tepples » Wed May 08, 2013 1:21 pm

Pennywise wrote:True. I've actually expanded a GDROM game to 256kb
I thought GDROM supported over a million kB.

If you meant GNROM, you could always try expanding it to SLROM or another of the MMC1 variants.

User avatar
Drakon
Posts: 183
Joined: Mon Aug 16, 2010 4:48 am
Contact:

Re: Expanding a game beyond its physical board limitations

Post by Drakon » Thu May 16, 2013 5:19 am

I'm wondering if it's possible to use a memory bank controller chip like what's found in gameboy carts to use larger roms.

User avatar
tokumaru
Posts: 11465
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Expanding a game beyond its physical board limitations

Post by tokumaru » Thu May 16, 2013 6:35 am

AFAIK, the only problem in nesting mappers is the fact that their registers would share the same addresses unless you added some extra address decoding to select one mapper or the other. Or you could write to both mappers at once if you fed the extra mapper with data lines not used by the first mapper (for example, the MMC1 takes its data from bit 0, so you could connect bit 1 to a second MMC1 and control both mappers with a single write operation), or maybe even unused address lines (would make more sense for mappers that use all data bits).

lidnariq
Posts: 8768
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Expanding a game beyond its physical board limitations

Post by lidnariq » Thu May 16, 2013 11:27 am

The problem is not that we couldn't add a register that would bank things. The problem is that it's not compatible with the existing definition, and so a specific release will either be compatible with the hardware you made as a one-off, or with existing emulators (including the PowerPak). At that point, rather than using existing ICs, you may as well use a CPLD or mapper-hack the game to something that is already completely adequate.

The obnoxious exception being expanding things past 512KiB PRG, since neither the PowerPak nor Everdrive N8 support that, and no historical mappers besides MMC5 and various pirates' did either.

User avatar
tokumaru
Posts: 11465
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Expanding a game beyond its physical board limitations

Post by tokumaru » Thu May 16, 2013 12:39 pm

lidnariq wrote:neither the PowerPak nor Everdrive N8 support that
Unfortunately, it looks like these devices are primarily meant for playing commercial games rather than encouraging experimentation with new ideas. Huge ROMs would allow games with short FMV sequences, 3D effects which use large look-up tables, etc.

lidnariq
Posts: 8768
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Expanding a game beyond its physical board limitations

Post by lidnariq » Thu May 16, 2013 5:26 pm

This is a tangent, but:

I don't think "FMV on the NES" is reasonable anyway. Because it lacks DMA the only way to stream video is directly supplying CHR fetches, and then you get no compression beyond the goofy palettized format, as well as being constrained to 4 to 13 colors and attribute zones no smaller than 8x1 pixels. Streaming said video from SD or CF is perfectly reasonable, but sufficiently inefficient (≈1MB/s at 60Hz on NTSC) that I don't think it ever really had a place. I don't know whether there even was a non-spinning-media method for delivering FMV before the GBA... that said I've been wanting to make a streaming video format for the NES, but have been stymied by not knowing if either the N8 or PowerPak are wired in a way such that you could stream video off large cheap flash. (Of course, once you can interpose an FPGA, you can implement zlib or something, reducing the bitrate substantially)

I'm also not convinced that 512KiB isn't enough for the lookup tables you describe; I strongly suspect the memory addressing modes of the NES are far more relevant there. Space-for-time exchanges only get you so far.

The only thing, AFAICT, that the 512KiB restriction really does for us is make fanslations a royal PITA. Although maybe that's why Battle Kid 2 was only 512KiB, I dunno ;)

As a final alternative point of view, infiniteneslives has that bootloader/128KiB RAM/1MB serial EEPROM project, which is really clearly the right option on a cost basis. But that makes bankswitching more expensive than conventional parallel ROMs.

User avatar
tokumaru
Posts: 11465
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Expanding a game beyond its physical board limitations

Post by tokumaru » Thu May 16, 2013 7:40 pm

lidnariq wrote:Because it lacks DMA the only way to stream video is directly supplying CHR fetches, and then you get no compression beyond the goofy palettized format
That's a pretty closed-minded way of thinking. Updating the whole pattern table isn't the only method of drawing bitmaps, you know... if you lower the resolution of the video, you can represent all pixel combinations in a fixed number of tiles. You could easily store 4 pixels per tile in the 256 tiles that are available, and they don't have to be ugly 4x4-pixel pixels, because you can lay all 4 pixels horizontally creating 4x1 patterns, and with scroll updates during rendering you can show only 1 or 2 scanlines of each row of tiles. With 2 name tables you could achieve a vertical resolution of 60 pixels. With 4 you could go up to 120, which could result in a nice wide-screen video.

Also, there are tricks to make the resolution seem better than it actually is. Look at the FMV intro in sonic 3D Blast on the Genesis. It's not perfect, but for something stored in a cartridge it's pretty amazing. If you step through that sequence frame by frame, you'll notice that alternating scanlines are shifted by one pixel (and the effect is reversed on alternating frames), creating a dithered look, and giving the illusion of more resolution. The same technique could be used on the NES.

FMV was smooth enough for most people at 15 frames per second on the original Playstation, so 15 or 12 should work well enough on the NES too. That leaves us plenty of time to decode simple compression schemes and upload all the data to the PPU, since there would be no need to deal with the massive amount of data that pattern table updates require, only name+attribute table updates have to be done.

If I were to try this, I'd probably use 4-screen mirroring and a resolution of 128x60 pixels for the video, so that 2 name tables could be used as a hidden buffer. I'd probably use the Sonic 3D blast trick to fake a higher resolution too. The challenge would be to come up with the best compression scheme possible, that could still be decoded during the available time.
as well as being constrained to 4 to 13 colors and attribute zones no smaller than 8x1 pixels.
This is not as bad as it sounds. Several video/image compression schemes rely on quantization of the color data. A very simple one is called Block Truncation Coding, but nearly every coded you can think of will use significantly less bandwidth for color than for lightness, so it isn't unusual for video to have 16 times less color information than lightness information. These ideas adapt fairly well to the limitations of the NES.
Last edited by tokumaru on Thu May 16, 2013 8:03 pm, edited 2 times in total.

tepples
Posts: 21748
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Expanding a game beyond its physical board limitations

Post by tepples » Thu May 16, 2013 7:42 pm

lidnariq wrote:I don't know whether there even was a non-spinning-media method for delivering FMV before the GBA
Nintendo 64 had FMV in Pokemon Puzzle League and Resident Evil, but then N64 Game Paks are comparable in capacity to GBA Game Paks. The intro to Sonic 3D Blast for Genesis still impresses me; it appears to be a short clip using some Sega CD codec.

On the other hand, Bad Apple.

Post Reply