Single Chip Cartridge
Moderator: Moderators
Re: Single Chip Cartridge
I have assigned the single-chip cartridge as NES Mapper 218, http://wiki.nesdev.com/w/index.php/INES_Mapper_218, using my initial idea for the name-table bits (iNES "four-screen" flag being interpreted as "one-screen" flag for this mapper - which should as good/bad as other solutions for the "how-to define one-screen in iNES problem".
Using an ARM CPU or the like as ROM+mapper would be cool. Not exactly the kind of low-end thing that I had in mind with the single chip idea, and probably more expensive, too (a 32Kbyte PROM should cost around 90 cents or so). But for more advanced designs it'd be nice!
From my experiences, ARM CPUs do need some waitstates for non-sequential accesses to external memory & external I/O ports, so they aren't as FAST as one might think. Maybe that applies only to the memory systems that I've dealt with (like the ARM CPU in the GBA/NDS), and raw ARM CPUs without such memory systems could faster.
Yes, the PPU address line to PRG-ROM address bus idea is pretty crazy, and would put some nasty limitations on the game. Not really recommended in most cases... On the other hand, if it does work, and if a game can deal with that limitations, then it would be extremly cool and very low-end.
I don't know if the PPU is constantly outputting the most recently used address during vblank (or when video is disabled). If it does output the address only for a few clock cycles (like during port 2007h reads), then the idea won't work at all. So that part needs to be definetly tested/verified before further dealing with the idea.
Using an ARM CPU or the like as ROM+mapper would be cool. Not exactly the kind of low-end thing that I had in mind with the single chip idea, and probably more expensive, too (a 32Kbyte PROM should cost around 90 cents or so). But for more advanced designs it'd be nice!
From my experiences, ARM CPUs do need some waitstates for non-sequential accesses to external memory & external I/O ports, so they aren't as FAST as one might think. Maybe that applies only to the memory systems that I've dealt with (like the ARM CPU in the GBA/NDS), and raw ARM CPUs without such memory systems could faster.
Yes, the PPU address line to PRG-ROM address bus idea is pretty crazy, and would put some nasty limitations on the game. Not really recommended in most cases... On the other hand, if it does work, and if a game can deal with that limitations, then it would be extremly cool and very low-end.
I don't know if the PPU is constantly outputting the most recently used address during vblank (or when video is disabled). If it does output the address only for a few clock cycles (like during port 2007h reads), then the idea won't work at all. So that part needs to be definetly tested/verified before further dealing with the idea.
Re: Single Chip Cartridge
OBJECTIONI have assigned the single-chip cartridge as NES Mapper 218, http://wiki.nesdev.com/w/index.php/INES_Mapper_218, using my initial idea for the name-table bits (iNES "four-screen" flag being interpreted as "one-screen" flag for this mapper - which should as good/bad as other solutions for the "how-to define one-screen in iNES problem".
I mean, if anything this should be a submapper for 0 or 7, not a brand new mapper.
And the four screen flag is a four screen flag and should never be used for anything else, the iNES format is already messy enough without adding some more mess to it.
Re: Single Chip Cartridge
For what it's worth, I too am against repurposing bits that already have well defined meanings. I do believe it's different enough from mappers 0 and 7 to deserve its own number though, but something has to be done about the mirroring selection, since there are 4 possible settings.
Re: Single Chip Cartridge
Or another way:
The PA10/PA11 variant is #0 with zero CHR ROM and zero CHR RAM (which requires NES 2.0), and the mirroring bit controls which line is connected to CIRAM A10 as in standard hardwired mirroring mappers.
The PA12/PA13 variant may be given its own mapper number.
I wonder what kevtris would do.
The PA10/PA11 variant is #0 with zero CHR ROM and zero CHR RAM (which requires NES 2.0), and the mirroring bit controls which line is connected to CIRAM A10 as in standard hardwired mirroring mappers.
The PA12/PA13 variant may be given its own mapper number.
I wonder what kevtris would do.
Re: Single Chip Cartridge
I'd say make it mapper #7, submapper #1, so every emulator that currently exists will be able run the rom without the user manually needing to change the mapper number to 7. There are a LOT of NES emulators out there. Emulators may appear on unexpected platforms, like the TI Nspire, Playstation 1, Dreamcast, in-car DVD player, and the list goes on. Emulators are often abandoned, and modifying emulators to support a new mapper is not always a possibility.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
- rainwarrior
- Posts: 8734
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Single Chip Cartridge
Is it really compatible with either mapper 7 or 0 as is? Doesn't the CHR address rewiring make that impossible?
Re: Single Chip Cartridge
The only rewiring of the PA10/PA11 variant compared to NROM is that the PRG ROM is always disabled and the CIRAM is always enabled. Pulling the CHR ROM, cutting the CIRAM /CE trace from /PA13, and wiring it to ground is all that's needed. That's less rewiring than a typical mask-to-flash conversion.
Re: Single Chip Cartridge
Read above my edited message how I implemented this mapper 218 in FamicomHDL. I think this mapper would have its own number, although I don't know whether it should use mirroring bits or submapper numbers (the codes I wrote can be modified to work with submapper numbers if you want to).
I do not think it is compatible with mapper 0 or mapper 7 (although a game could be made which is compatible with multiple mappers). However there probably would be ways to make simpler mappers which use the same iNES number as some complicated one if the game is compatible with the simpler one not using all the functions.
If you do use a microprocessor on the cartridge, it might be better to still have a PRG ROM chip, and use the microprocessor for audio and video (possibly also PRG ROM bankswitching). So this would be two chips but with many functions.
I do not think it is compatible with mapper 0 or mapper 7 (although a game could be made which is compatible with multiple mappers). However there probably would be ways to make simpler mappers which use the same iNES number as some complicated one if the game is compatible with the simpler one not using all the functions.
If you do use a microprocessor on the cartridge, it might be better to still have a PRG ROM chip, and use the microprocessor for audio and video (possibly also PRG ROM bankswitching). So this would be two chips but with many functions.
(Free Hero Mesh - FOSS puzzle game engine)
Re: Single Chip Cartridge
Uh, couldn't you have sent that objection before I released the specs? Well, and, now... what now?Bregalad wrote: OBJECTION
I mean, if anything this should be a submapper for 0 or 7, not a brand new mapper.
And the four screen flag is a four screen flag and should never be used for anything else, the iNES format is already messy enough without adding some more mess to it.
For the mirroring there are the 3 options that have been discussed above,
1. use the four-screen bit, which is at least roughly related for mirroring purposes, and can't conflict is case, since the cartridge cannot have extra ram
2. use the submappers, which are somewhat reserved for cases where the same mapper number has been used for different boards
3. invent a 3rd mirroring bit in the iNES header, that might make sense if other boards require single-screen mapping, too.
I think they are all equally messy. And all equally simple to implement: Read this or that bit from the header and treat it as one-screen flag. Doesn't matter that much which bit it is. But if there are plenty people clearly voting for one of the above 3 options: I could still change it.
Using different mapper numbers for the same PCB depending on the jumper settings... In this configuration it is NROM, but in that config it's AOROM... I really don't like that.
It's maybe roughly related to NROM with 0-byte CHR-ROM and 0-byte CHR-RAM, though that config might be also used for raw audio software, or web servers, or such things.
The game could be made compatible with mapper 7 (AOROM), but then the game would be required to initialize the AOROM mapper accordingly, although it's running on a PCB without AOROM mapper. Asides, then one could also declare the single chip cartridge as being a MMC1 mapper, which can be configured to one-screen mapping, too.
And anyways: after my poor soldering efforts, I want "my" own mapper number for the board
- infiniteneslives
- Posts: 2104
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
- Contact:
Re: Single Chip Cartridge
Since when have we ever assigned new mapper numbers for mirroring and ROM sizes? Heck we even used mapper 0 for NROM-368 (can never remember the number..) and it required an actual mapper chip and separate logic to work. Based on Kevtris' verdict on that I bet I can tell you what he'd say. If you get his opinion I say just go with it and end the debate.
This is really a subset of NROM as I see it which validates choice 2.
We don't have many mapper numbers left, no offense, but it's hardly worth it's own number IMO.
I agree with dwedit is saying to a point. However nothing is stopping one from denoting mapper 7, initializing the logic that isn't there properly and then not using all of the resources available if you want your game to be more compatible. A new mapper number certainly isn't going to solve the issue dwedit brings up either.
This is really a subset of NROM as I see it which validates choice 2.
We don't have many mapper numbers left, no offense, but it's hardly worth it's own number IMO.
I agree with dwedit is saying to a point. However nothing is stopping one from denoting mapper 7, initializing the logic that isn't there properly and then not using all of the resources available if you want your game to be more compatible. A new mapper number certainly isn't going to solve the issue dwedit brings up either.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
Re: Single Chip Cartridge
Don'cha think this discussion is getting a little heated for what it is?
Y U NO STOP PLUGGING EVERY POST? NOBODY REPLYINGzzo38 wrote:Read above my edited message how I implemented this mapper 218 in FamicomHDL
- infiniteneslives
- Posts: 2104
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
- Contact:
Re: Single Chip Cartridge
Probably true, but that's what we do best around these parts! Argue about mapper technicalities that usually never see the light of day in a released gamekyuusaku wrote:Don'cha think this discussion is getting a little heated for what it is?
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
Re: Single Chip Cartridge
Well, NES 2.0 allows you to specify no CHR RAM, so if it is NES 2.0 then it would be a case of mapper 0 although you would still need something new in order to specify connecting CIRAMA10 to PA12 and PA13.infiniteneslives wrote:Since when have we ever assigned new mapper numbers for mirroring and ROM sizes? Heck we even used mapper 0 for NROM-368 (can never remember the number..) and it required an actual mapper chip and separate logic to work. Based on Kevtris' verdict on that I bet I can tell you what he'd say. If you get his opinion I say just go with it and end the debate.
This is really a subset of NROM as I see it which validates choice 2.
(Also, the wiki specifies the mirroring for UNIF, but does not specify a mapper name for UNIF.)
(Free Hero Mesh - FOSS puzzle game engine)
- rainwarrior
- Posts: 8734
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Single Chip Cartridge
I'm beginning to understand why MMC6 never got its own mapper...
Re: Single Chip Cartridge
I could not guess you were going to do it, and some people has already objected to the idea of a new mapper before I (if you follow the thread's order).Uh, couldn't you have sent that objection before I released the specs? Well, and, now... what now?
After all I don't really care, this won't change the face of humanity, BUT, I think free mappers are too precious to be wasted on something that can easily be implemented using existing mappers, and that iNES flags shouldn't be reassigned to new uses like this.
If someone will do something crazy like I and tokumaru were talking about (using more than 32kb on a single chip cart) then definitely a new mapper will be neccesarly. But for a 16k or 32k mapper, mappers 0 or 7 will do the trick very fine, as long as authors are careful not to rely on mirroring (that is, restrict to the usage of tiles 0-63, and don't display the unused nametable if mapper 0 is chosen).