NES 2.0 Additions Proposal

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: NES 2.0 Additions Proposal

Post by NewRisingSun »

Emulating two CPUs and PPUs is not too difficult if the emulator design is modular. I don't think stuffing the two units' ROMs into one file is a problem at all provided it's properly documented how to separate them and no emulator does "its own thing" on that. Vs. Raid on Bungeling Bay is a Vs. Dual game with the second CPU only getting the dummy "mds-rb4-2 b.1a" ROM image. For iNES, you would pack the first 32 KiB PRG-ROM, then 24 KiB of padding, then the 8 KiB "mds-rb4-2 b.1a" ROM, then the 16 KiB CHR-ROM into the file. I've got it working right here.

Emulators can show both screens or just one of them. Showing just one is entirely justifiable, because the second unit running a different game session from the first is an unlikely option for home use, and players on the first playing against players on the second unit will necessarily show the entire game situation on both screens.

I am not sure what you mean by single PPU byte. You mean combining the Vs. PPU with the TV System field? I agree that could not be done without breaking backwards compatibility.

What I have not done is add a field for input/expansion device. I would have used to so-far unused byte 15 for that. That would make the "Vs. Mode" byte cleaner, since the Reversed and Weird control types would be moved out of it, and it would also relieve emulators of automatically assigning input devices using hash tables. But it was indicated on this board in the past that this would not be accepted and relegated to a metadata text file, so I left it out of the proposal, even though I would disagree and would find it nice.
Last edited by NewRisingSun on Mon Apr 02, 2018 1:50 pm, edited 1 time in total.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NES 2.0 Additions Proposal

Post by tepples »

NewRisingSun wrote:players on the first playing against players on the second unit will necessarily show the entire game situation on both screens.
Are all Dualsystem games mirrored like this? I thought there'd be at least one that presents different views for the two players, such as games of partial information like Stratego or many card games or many FPS or RTS games, or things where the scrolling viewpoint differs like any racing game that isn't non-scrolling like Super Sprint or edge-triggered like Micro Machines. Even in a game of perfect information, something like doubles tennis might display the reverse angle, causing one side's controls to appear inverted if everybody's looking at the first machine's display.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: NES 2.0 Additions Proposal

Post by NewRisingSun »

I think Vs. Mahjong only shows each player's own stones. Of course, putting both screens side-by-side loses you the limited information as well, so unless an emulator outputs each emulated screen to a separate host display, the limited information aspect will be gone. Vs. Tennis indeed shows the reverse point of view, though not seeing the different point of view would not necessarily impact gameplay, even as the left/right buttons of the second unit would have to be reversed in that scenario.

But those are not issues for the NES 2.0 file format, as they would present themselves even when using MAME-like split ROMs.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: NES 2.0 Additions Proposal

Post by lidnariq »

NewRisingSun wrote:Emulating to CPUs and PPUs is not too difficult if the emulator design is modular. I don't think stuffing the two units' ROMs into one file is a problem at all provided it's properly documented how to separate them and no emulator does "its own thing" on that. Vs. Raid on Bungeling Bay is a Vs. Dual game with the second CPU only getting the dummy "mds-rb4-2 b.1a" ROM image. For iNES, you would pack the first 32 KiB PRG-ROM, then 24 KiB of padding, then the 8 KiB "mds-rb4-2 b.1a" ROM, then the 16 KiB CHR-ROM into the file. I've got it working right here.
I've always been uncomfortable with mapper 99's "any padding is actually open bus" but given the constraints of the iNES format there was nothing to be done for it. Extending this such that
32 KiB PRG implies 1 CPU, no PRG bankswitching
48 KiB PRG implies 1 CPUs, PRG bankswitching at $8000
64 KiB PRG implies 2 CPUs, no PRG bankswitching

is ... well, I guess not really any worse.

I guess this does make we wonder if this behavior is better something baked into mapper 99 instead of into the header. We don't know of any DualSystem games that aren't mapper 99, and I'm unclear whether this "just pad and duplicate" behavior is something that should be generalized?
will necessarily show the entire game situation on both screens.
Well ... sorta? at least Vs. Wrecking Crew displays the complementary information on both screens (near vs far is flipped)
NewRisingSun wrote:Vs. Tennis indeed shows the reverse point of view, though not seeing the different point of view would not necessarily impact gameplay, even as the left/right buttons of the second unit would have to be reversed in that scenario.
Er. If you display both screens, then you don't need to reverse controls on the second unit. It's a problem specifically created by choosing to display just one screen.
But those are not issues for the NES 2.0 file format, as they would present themselves even when using MAME-like split ROMs.
They're issues with saying that it's practical to display just one screen, which evidently has some sticking points.

I think Nocash is the only previous person to have attempted to put DualSystem emulation in a general-purpose NES emulator; if I'm right in that regard, I'd like his input on this too.
What I have not done is add a field for input/expansion device. I would have used to so-far unused byte 15 for that.
I remember Zzo38 starting defining the external metadata format in response to being disappointed by that decision, but I forget basically everything else about that discussion. Link?
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NES 2.0 Additions Proposal

Post by tepples »

NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: NES 2.0 Additions Proposal

Post by NewRisingSun »

The discussion was here. It quickly became philosophical. My point would be that the ROM header should contain everything needed to allow an emulator to run the game in a way that it can be played, without having to use a hash database. "in a way that it can be played" would include input devices, while it would not include cartridge codes, manuals, overscan and palette preferences and things like that. If the objection is to say that the real-hardware user has to know as well which input device he needs to plug into his console, I would reply saying that the user also has to know into which type of console --- NTSC, PAL, Dendy --- he is sticking his cartridge, and yet we have a TV System field.

As for the "who's going to update the headers in all the ROM files out there" problem (regardless of whether an "input devices" field is included or not), I would volunteer to make a NES-header correction utility (which in turn would of course need to have its database) that can be applied on an entire ROM collection. Once everything is finalized, new mapper numbers and all, that is.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: NES 2.0 Additions Proposal

Post by lidnariq »

NewRisingSun wrote:The discussion was here. It quickly became philosophical.
Wow, that was a useless discussion. Small wonder I'd forgotten specifics.
My point would be that the ROM header should contain everything needed to allow an emulator to run the game in a way that it can be played, without having to use a hash database. "in a way that it can be played" would include input devices
I can't think of a good reason to not include this information, but I think discussion about it should probably have its own thread.

There's plenty of homebrew that supports a choice of multiple different controllers via any given input; are there commercial games that do so also?
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: NES 2.0 Additions Proposal

Post by NewRisingSun »

I'll post an input device proposal for byte 15 to a separate thread then.

Edit: Done.
User avatar
B00daW
Posts: 586
Joined: Thu Jan 03, 2008 1:48 pm

Re: NES 2.0 Additions Proposal

Post by B00daW »

Should we add a Byte 13 reference to the CPU TEST mode being enabled? Not certain if test ROMs have been made yet, but it could also help with accurate emulation of the feature. Not certain if it's even emulated yet either.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: NES 2.0 Additions Proposal

Post by NewRisingSun »

That's quite esoteric. I suppose one could add a value for it, as long as it does not turn the whole proposal into a complete joke.

On another note, there already exist ROM images with 64 MiB and more in PRG-ROM size --- two OneBus plug-and-plays with exactly 64 MiB, and that "Coolgirl 320-in-1" multicart which has more than 64 MiB of PRG-ROM (and an insanely complex mapper). NES 2.0 only allows up to 64 MiB at the moment, and 64 MiB are implicitly represented by zero PRG-ROM banks.
User avatar
B00daW
Posts: 586
Joined: Thu Jan 03, 2008 1:48 pm

Re: NES 2.0 Additions Proposal

Post by B00daW »

Not certain how the proposal would be a joke if it's an embedded feature (albeit hidden) within the processor itself. It also gives the emulator an opportunity to let the user know that the type of ROM requires the features enabled; and to provide a compatibility message.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: NES 2.0 Additions Proposal

Post by NewRisingSun »

It would become a joke if emulator authors started seeing the proposal as a wishlist for obscure features they have no intent of adding, and refuse to implement the header additions themselves for that reason. But okay, I have added Byte 13 value 02 to the proposal along with a disclaimer.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: NES 2.0 Additions Proposal

Post by lidnariq »

P.S. enumerating what test mode means:

* Normally, only reads from $4015 come from the CPU's internal data bus. There's some simple logic that controls whether the external data bus drives the internal data bus, and it's normally true during all other reads.
* When TEST is enabled, reads from the entire range from $4000-$401F are only from the internal data bus. THERE IS NO WAY TO USE EXTERNAL CONTROLLERS WHEN IN TEST MODE. Entirely separate controllers attached to the cartridge would be the only way.
** Now, Zzo38 has asked, and I think Quietust has confirmed, that TEST can be switched on a cycle-by-cycle basis, so it's possible to connect CPU A3 to TEST and change the isolated addresses to $4008-$400F, and $4018-$401F, but ... this option bothers me.
* When TEST is enabled, a write-only register at $401A and three read-only registers from $4018-$401A are enabled.

TEST is not present in the 2A03letterless. I don't know if it's present in the 2A03E and 2A03H.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NES 2.0 Additions Proposal

Post by tepples »

Just a wild guess, but Nintendo's factory probably tested 2A03 CPUs received from Ricoh, and the test rig had a 2A03 socket and some additional MMIO port that controls the test mode pin, letting the program switch between test mode and run mode. But I imagine that sort of stuff would be even more obscure than the Nintendo PlayStation. So until such a test rig surfaces, I oppose baking into NES 2.0 a means to distribute a firmware for it.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: NES 2.0 Additions Proposal

Post by NewRisingSun »

All right, out with it then.
Post Reply