It is currently Sat Dec 16, 2017 1:40 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 30 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Sat Apr 25, 2015 9:30 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 941
I don't know all of the stuff that is currently UNIF-only, but one is UNL-DripGame; we should assign mapper numbers to these things. Another thing that a mapper number should be assigned is Game Genie (FDS already has a number assigned so it doesn't need another one). For grace with emulators that don't support NES 2.0, we can assign these various UNIF-only stuff, as well as Game Genie, into not plane 0. Another reason not to assign UNL-DripGame into plane 0 is because the author of the game doesn't want to.

_________________
.


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 3:13 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6535
Location: Seattle
Game Genie doesn't need a mapper.

Tools don't need mappers.

You can't do anything with the FDS BIOS in isolation, nor can you easily replace it.
You can't do anything with the Game Genie bootstrap ROM in isolation, even though you could easily replace it.
The "slots" model used by MESS to handle Karaoke Studio (m188) and Nantettatte!! Baseball (m68) is irrelevant because the extensions that are added aren't usable on their own.
Mapper 100 is effectively a jersey barrier with blinking lights, saying "Bridge out".
Mapper 248's nominal assignment for development is nonsense. If you're developing a new mapper there's no reason to use mapper 248 as opposed to anything else.


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 9:40 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5899
Location: Canada
I think the Game Genie menu and FDS boot animation are both worth emulating, but I'd be really surprised if NROM wasn't sufficient to handle both of those.

Game Genie + Cart doesn't really have much value as a mapper, IMO. It's a modulation of every mapper, not a mapper by itself. A lot of emulators are already doing the right thing with it, I think.

As for drip game, I'm surprised it hasn't been assigned yet.


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 11:07 am 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 941
Game Genie and FDS are both NES/Famicom cartridges (although Game Genie takes a parameter being another cartridge; FDS takes a parameter that is changeable at runtime being a disk image for one side of one disk; other mappers also take parameters (the syntax of these parameters is implementation-specific)).

Have the principles:
  • One NES/Famicom cartridge = one .NES file
  • Same NES 2.0 header = same function of cartridge (not including ROM data)
  • These principles are from the functional view, so different hardware implementations with the same function have the same header, and also that CIC and lockout defeat are not part of the Famicom VM.

Other notes are that tepples has mentioned "lock-on" of certain cartridges (my idea of parameters is a generalization of this it seems), and koitsu, even though he disagrees about its usefulness, has said that regardless of what he thinks there should be a mapper number for Game Genie in order to have consistency since FDS BIOS already has one!

The "series of simple gates masquerading as a CHR ROM" act exactly like CHR ROM and have its same function, therefore if a NES 2.0 header is given it should be treated like a CHR ROM and the data given explicitly in the file. (Note what I wrote about the "functional" principle above; I know this wastes 8K (actually 20K) of disk space but that isn't a lot in this case and anyways improves the simplicity of the system.)

I agree that mapper 248 assignment is nonsense (although it may have been assigned before NES 2.0 was invented?).

Apparently there is other currently-UNIF-only stuff too other than UNL-DripGame, but I don't know of any. If you do know of any, please post it on here.

Also, an emulator using these tool mapper numbers doesn't even prevent the old way from working too; here is an example of a kind of "modular system":
  • If the main file the emulator is told to load does not have a NES 2.0 header then look in the configuration file to determine what to do; if it doesn't tell what to do, then if it is a old iNES header then internally convert to NES 2.0 otherwise display an error message.
  • If a mapper takes a parameter being another cartridge, that cartridge's mapper might also take a parameter.
  • You can have support for -G for Game Genie codes (perhaps it would be useful to support hex codes instead of (or in addition to) the ones Game Genie uses?); this is different because if gamegenie.nes is used then the game start with PPU already is ready; if the emulator's internal patching function is used then the PPU isn't ready when the game starts.
  • One possibility for the configuration file's code to do if it finds it is a .FDS image: Find the save directory for that game inside of the user's save games directory; if not found, create it and unpack the .FDS into files disk1a.qdi and so on into that directory. After that, start disksys.nes with that save game directory as the current directory and disk1a.qdi as its parameter. (The mapper option screen will then display the disk sides to easily switch between them.) (Note: Depending on the implementation, it might support the configuration file creating the NES 2.0 image in RAM from fdsbios.rom)
  • After the cartridge is loaded you can check for the user parameters; if some parameter is not specified, you might use a default, use none if the parameter is optional, ask the user for that parameter, or display an error message; it depends on the implementation.

_________________
.


Last edited by zzo38 on Sun Apr 26, 2015 1:39 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 11:47 am 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
rainwarrior wrote:
I think the Game Genie menu and FDS boot animation are both worth emulating, but I'd be really surprised if NROM wasn't sufficient to handle both of those.

Doesn't the FDS firmware rely on FDS hardware? (e.g. the custom sound hardware or the fact video memory is writeable) But then again it's basically "boot FDS firmware like it was a Famicom with FDS attached".


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 12:00 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 941
Sik wrote:
Doesn't the FDS firmware rely on FDS hardware?
Yes, and the FDS hardware is a Famicom cartridge.

_________________
.


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 12:25 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5899
Location: Canada
I meant that it could be duplicated as an NROM with probably very minimal changes.

Actually, yeah all you really need is an emulator that has a no-disk state for its FDS emulation. (You can do this in FCEUX by ejecting immediately after loading an FDS file.) Emulator support for FDS BIOS is already pretty robust, I think? It also has an assigned mapper already, but I don't know if there's any reason to create rips with it.

I just checked, and there is a working NROM game genie .NES floating around. I don't know what problem would be solved by designating a mapper for it, though. An emulator author could implement a Game Genie mode that uses a ROM like this as the menu, and lets the user specify the cartridge to stack with it. I think this is an emulator UI problem, not a mapper allocation problem. What do you want a Game Genie mapper number for, zzo38?

There are some other cartridge stack situations like the Aladdin Deck Enhancer, but even though the physical form is special, the ROMs aren't, really. Each of the compact cartridge plugins just boils down to a single NES file rip, pretty simple. (iNES mapper 071, I think?)


As for things that actually do need a mapper allocation, aside from drip game, tepples mentioned some Chinese UNIF-only rips by CaH4e3, but I don't know who that is or where to find the rips. Maybe these mappers are defined in the source of some popular emulators?


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 12:30 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5899
Location: Canada
zzo38 wrote:
the FDS hardware is a Famicom cartridge.


So, I suppose what you're getting at is that you like the symmetry of treating FDS as an NES file. Probably want you want to do is create a mapper 20 NES file for the FDS bios, and then create an emulator that boots this and has a UI for loading disks.

At any rate, the mapper is already allocated. I would guess the only reason this isn't done is because we already have good working emulation solutions and nobody really cares about the file format symmetry. You have to load the associated disks anyway, so I presume most emulator authors figure you might as well just open them directly like any other file, rather than having the additional step of loading the BIOS NES first.


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 12:45 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5899
Location: Canada
Actually, you know what, after thinking about it that way I want to change my position on this, slightly. I think a (plane 1?) mapper for Game Genie and the Aladdin Deck Enhancer would both be fine.

Though I would suggest the same requirement for this as I would for any other mapper allocation. Implement it first, publish the results, and then allocate the mapper. I think it's perfectly reasonable to ask for an allocation to support a living, real solution. Mapper allocations for proposed/theoretical ideas, on the other hand, waste everyone's time.

1. Create and publish the ROMs that require it. (Not just theorizing they could exist.)
2. Create and publish an emulator implementation that uses them. (Working, not just a design draft.)

The impediments to this I've already outlined (i.e. we've already solved the problem for FDS, Game Genie, and Deck Enhancer, and the proposed idea might seem like pointless busywork in pursuit of ideology rather than practical implementation),


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 1:04 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 941
OK, although I am not sure about plane 1 for Game Genie. If the planes are analogous to Unicode (for example plane 2 for Chinese), then you might assign Game Genie into plane 14 (which in Unicode is the "Supplementary Special-purpose Plane"). This is only for organizational purposes though (was it originally tepples's idea?) and if other people decide that plane 1 is better, use plane 1.

_________________
.


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 1:17 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5899
Location: Canada
Unicode has nothing at all to do with the NES format. There is absolutely no reason to organize anything about it based on unicode.

Honestly it'll probably take us at least another 15 years to fill up plane 1. The reason I wouldn't suggest putting them in plane 0 because they lack new utility (the problems are already solved other ways), so they don't have enough value for allocate plane 0, IMO. You could actually just allocate them as submappers of 020, alternatively, and just stick every "tool" mapper there?


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 1:37 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 941
rainwarrior wrote:
The reason I wouldn't suggest putting them in plane 0 because they lack new utility (the problems are already solved other ways), so they don't have enough value for allocate plane 0, IMO.
That much I absolutely agree with; I suggested the same thing originally too. (I thought tepples wanted it like Unicode, but of course you don't have to.)

However there are two other things considered, which are Datach (mapper 157) and Aladdin Deck Enhancer.

With mapper 157, the implication that the EEPROM is shared across all games that ever use this mapper violates the first principle. Fixing it involves the following two ideas:
  • If the PRG ROM amount is nonzero, then the .NES file represents a cartridge with its own EEPROM and the game built-in, separate from any other .NES files. (Since there is only one game that uses this, this fix won't break any existing .NES files, and even makes it easier to manage save games. There might exist a few emulators that already do this, meaning those emulators don't need to be changed!)
  • If the PRG ROM amount is zero (requires updating the NES 2.0 specification so that it doesn't default to 16K like old iNES), then the mapper takes a user parameter being the ROM image for the game itself, and uses the EEPROM allocated to the .NES file originally loaded.

I found no information about Aladdin Deck Enhancer in NESdev wiki, but if I understood properly what was discussed on IRC, Aladdin Deck Enhancer violates the third principle. Assigning a mapper number won't actually give that mapper number any meaning (if I misunderstood how Aladdin Deck Enhancer works then I am likely wrong and you can please correct me).

_________________
.


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 1:45 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
rainwarrior wrote:
zzo38 wrote:
the FDS hardware is a Famicom cartridge.

So, I suppose what you're getting at is that you like the symmetry of treating FDS as an NES file. Probably want you want to do is create a mapper 20 NES file for the FDS bios, and then create an emulator that boots this and has a UI for loading disks.

This reminds me, the way Fusion handles firmware is that they aren't loaded directly (as they could refuse to boot), but rather there's a "no game" state where the firmware boots as-is. It has that for both the Sega CD and the Master System firmware. I can see this logic working perfectly for the FDS firmware as well.


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 1:49 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6535
Location: Seattle
rainwarrior wrote:
1. Create and publish the ROMs that require it. (Not just theorizing they could exist.)
It is, by definition, impossible to create a ROM that requires the Game Genie hardware be present.

The registers are either available for writing and have no effect; or the boot ROM is NOT MAPPED, the registers are not available for writing, and three locations in memory are substituted.

So you can only use the Game Genie hardware to make something that's basically an NROM subset... in which case it should be stored AS NROM.

Similarly, the process of creating a firmware replacement for the FDS BIOS is so difficult that it practically speaking won't happen: it requires that you disable reads/writes to the FDS hardware to $E000-$FFFF AND you cannot just solve this by only disabling /ROMSEL or M2.

Thirdly, I strongly object to reserving mappers for things that don't exist in hardware.

Quote:
and koitsu, even though he disagrees about its usefulness, has said that regardless of what he thinks there should be a mapper number for Game Genie in order to have consistency since FDS BIOS already has one!
That is one of the worst arguments I've ever heard. It's just the sunk cost fallacy.



The Aladdin Deck Enhancer is nothing but CHR-RAM, a lockout defeater, and a simple UNROM-like bankswitch mapper. The PRG-ROM itself is on a daughtercard. The hardware, when combined, is already assigned to mapper 71 or 232 depending on how the daughtercard wires things.


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 1:58 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 941
lidnariq wrote:
It is, by definition, impossible to create a ROM that requires the Game Genie hardware be present.
Wrong; Game Genie does. If emulated as NROM you may be able to get the display, but it won't do anything then after that. Game Genie has extra registers and what I called a "user parameter" (or what tepples called a "lock-on"). In this case the user parameter is another .NES cartridge file.

Quote:
Similarly, the process of creating a firmware replacement for the FDS BIOS is so difficult that it practically speaking won't happen.
The fact that the existing hardware implementation makes it difficult is irrelevant (it is equally nonsense to avoid assigning a mapper number if the ROM chip of a game cartridge is inside of anoter IC; notice my third principle). It is still a Famicom cartridge, and the BIOS is the ROM data of the cartridge.

Quote:
Thirdly, I strongly object to reserving mappers for things that don't exist in hardware.
I am agree too but Game Genie is actually exist in hardware.

Quote:
Quote:
and koitsu, even though he disagrees about its usefulness, has said that regardless of what he thinks there should be a mapper number for Game Genie in order to have consistency since FDS BIOS already has one!
That is one of the worst arguments I've ever heard. It's just the sunk cost fallacy.
I don't agree with his argument either; I have my own argument, I'm just mentioning it in case someone doesn't like my argument.

Quote:
The Aladdin Deck Enhancer is nothing but CHR-RAM, a lockout defeater, and a simple UNROM-like bankswitch mapper. The PRG-ROM itself is on a daughtercard. The hardware, when combined, is already assigned to mapper 71 or 232 depending on how the daughtercard wires things.
Exactly that; that's what I have been saying!! Aladdin Deck Enhancer does not need a mapper number (the exception would be if it had battery-backed CHR-RAM, but I am pretty sure that it doesn't).

_________________
.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 30 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Majestic-12 [Bot] and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group