Vs. DualSystem

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: Vs. DualSystem

Post by zeroone »

NewRisingSun wrote:Of course. Just look at the Vs. System's ROM files...
I started working with your VS DualSystem NES 2.0 files. I setup 2 CPUs bridged by the shared memory range. And I am alternating between executing one instruction each processor. The master CPU appears to be attempting to trigger interrupts on the slave processor and I see reads from the exact addresses listed in your stub-processor code snippet. But the slave processor appears to be stuck in an infinite loop. It's not interested in the interrupt requests.

I'm not sure what I'm missing here. Any suggestions or experiments I can try?
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: Vs. DualSystem

Post by NewRisingSun »

Well, you need to actually raise the IRQ pin, of course, and $4016 must return reads with D7 clear on the master and D7 set on the slave CPU, so that the code knows on which CPU it's running.
User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: Vs. DualSystem

Post by zeroone »

NewRisingSun wrote:Well, you need to actually raise the IRQ pin, of course, and $4016 must return reads with D7 clear on the master and D7 set on the slave CPU, so that the code knows on which CPU it's running.
Yep. I'm doing all that (I think). I also split the NES 2.0 PRG ROM, giving each CPU a half.
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Vs. DualSystem

Post by lidnariq »

Just so I can follow along, which specific game are you testing with right now?
User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: Vs. DualSystem

Post by zeroone »

lidnariq wrote:Just so I can follow along, which specific game are you testing with right now?
I've primarily focused on Balloon Fight and Wrecking Crew. They both have the behavior that I described where only the Master CPU seems to be doing it's thing.

Is there one game in particular that's easier to get running?
User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: Vs. DualSystem

Post by zeroone »

I finally got most of the VS DualSystem games running. It turned out that I was failing to initialize the slave PPU properly, preventing it from receiving NMI's.

The only game that won't launch is Raid on Bungeling Bay. Supposedly, it has the same copy protection that Ice Climber has, but duplicating that has yet to get it going. I'm also testing with the padded NES 2.0 version; so, it's not an issue with PRG RAM locations.

Anyone have any hints for this one?

Edit: I got Raid on Bungeling Bay loaded. It just a typo on my end.
User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: Vs. DualSystem

Post by zeroone »

I noticed that if I power on VS. Baseball in test mode (B2 - DS1), it shows a red battery:

Image

But if I reset it, the battery turns green.

Any idea how it does it's battery check?

Edit: Nevermind. It's supposed to do that.
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Vs. DualSystem

Post by lidnariq »

... oh, huh, I guess the wiki should mention that the shared RAM can be battery backed.
User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: Vs. DualSystem

Post by zeroone »

lidnariq wrote:... oh, huh, I guess the wiki should mention that the shared RAM can be battery backed.
In addition to high scores, these games appear to keep track of total coinage. For example, in the screenshot below of VS. Ice Climber (Japan), 6 coins were inserted into the left slot of System 2:

Image

This also means that the left and right coin slots provide independent signal bits. The wiki incorrectly suggests that the slots are usually wired in parallel. Nonetheless, for user-interface simplicity, I'm considering only providing options for inserting a coin into System 1 and into System 2, instead of System 1 - Slot 1, System 1 - Slot 2, System 2 - Slot 1, and System 2 - Slot 2. Unless someone really cares about the numbers displayed in test mode, is there any reason to provide all 4 options?

Edit: On a side note, all the VS manuals refer to the systems as "Main" and "Sub" as opposed to "Master" and "Slave". And the slots are referred to as "left" and "right". If I got with 4 insert-coin menu options, I may use that nomenclature.
Last edited by zeroone on Tue Jan 29, 2019 11:16 am, edited 1 time in total.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Vs. DualSystem

Post by tepples »

zeroone wrote:these games appear to keep track of total coinage. For example, in the screenshot below of VS. Ice Climber (Japan), 6 coins were inserted into the left slot of System 2:

Image
Transcribing text in this screenshot in case it disappears from Imgur or Imgur changes its policy on third-party hosting, as ImageShack and Photobucket have:

Code: Select all

    DISTRIBUTION

MAIN LEFT   000000
MAIN RIGHT  000000
SUB  LEFT   000006
SUB  RIGHT  000000
The main/sub terminology reminds me of what I would later see in the DS homebrew scene. On the DS, only the main GPU has a 3D unit, but the system can switch which physical screen gets the main GPU's output and which gets the 2D-only sub GPU's output.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: Vs. DualSystem

Post by NewRisingSun »

Does that mean that the canonical NES 2.0 headers for Vs. Uni/Dual games should have the battery bit set?
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Vs. DualSystem

Post by lidnariq »

Not all games use, or can use, that RAM. I'd naively assume that DualSystem games probably do. Most UniSystem games probably don't?
User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: Vs. DualSystem

Post by zeroone »

NewRisingSun wrote:Does that mean that the canonical NES 2.0 headers for Vs. Uni/Dual games should have the battery bit set?
The manuals may reveal which titles have battery-backed RAM and which do not. But I can't find manuals for all the games.
User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: Vs. DualSystem

Post by zeroone »

I found an old forum post that mentions VS game batteries: https://web.archive.org/web/20050206091 ... webbat.htm

It's still unclear if that applies to all VS games or only a subset of them.

Also, here's an unrelated yet interesting link about "suicide batteries": http://www.arcadecollecting.com/dead/

Edit: Here is a pic of VS. Excitebike board. It's a VS. UniSystem board and an AA batteries holder is fixed to the left-side. I'll check other VS boards if I find more pics.

Edit 2: In the VS schematic, the battery appears in the upper-left and it powers chip 8L (MB8416-15 2k x 8bit Static CMOS RAM 150 ns). Even though VS games have 2K of nonvolatile RAM, that doesn't necessarily mean that all VS games use it. And it's uncertain what memory region it is mapped to.
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Vs. DualSystem

Post by lidnariq »

As far as I can tell, the Vs. System only had one class of PCB ("MDS-version-CPU"), regardless of game. All five versions have the battery holder, so all games could have that RAM battery-backed.

But because the battery is clearly field serviceable, and only one side can have access to the RAM at any given time, I don't know how many ever did.

"8L" is the 2K shared RAM.
Post Reply