It is currently Tue Sep 25, 2018 7:40 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 65 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
PostPosted: Mon Apr 02, 2018 9:03 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 655
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.

Top
 Profile  
 
PostPosted: Mon Apr 02, 2018 9:28 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20574
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Mon Apr 02, 2018 9:32 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 655
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.


Top
 Profile  
 
PostPosted: Mon Apr 02, 2018 10:18 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7554
Location: Seattle
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?

Quote:
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.

Quote:
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.

Quote:
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?


Top
 Profile  
 
PostPosted: Mon Apr 02, 2018 10:22 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20574
Location: NE Indiana, USA (NTSC)
Here was zzo38's metadata proposal.


Top
 Profile  
 
PostPosted: Mon Apr 02, 2018 10:37 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 655
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.


Top
 Profile  
 
PostPosted: Mon Apr 02, 2018 11:24 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7554
Location: Seattle
NewRisingSun wrote:
The discussion was here. It quickly became philosophical.
Wow, that was a useless discussion. Small wonder I'd forgotten specifics.

Quote:
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?


Top
 Profile  
 
PostPosted: Mon Apr 02, 2018 11:31 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 655
I'll post an input device proposal for byte 15 to a separate thread then.

Edit: Done.


Top
 Profile  
 
PostPosted: Wed Apr 04, 2018 6:24 pm 
Offline
User avatar

Joined: Thu Jan 03, 2008 1:48 pm
Posts: 568
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.


Top
 Profile  
 
PostPosted: Thu Apr 05, 2018 2:02 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 655
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.


Top
 Profile  
 
PostPosted: Thu Apr 05, 2018 7:19 am 
Offline
User avatar

Joined: Thu Jan 03, 2008 1:48 pm
Posts: 568
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.


Top
 Profile  
 
PostPosted: Thu Apr 05, 2018 7:32 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 655
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.


Top
 Profile  
 
PostPosted: Thu Apr 05, 2018 8:54 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7554
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Thu Apr 05, 2018 9:28 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20574
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Thu Apr 05, 2018 9:58 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 655
All right, out with it then.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 65 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 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:  
cron
Powered by phpBB® Forum Software © phpBB Group