Page 1 of 1

NES ROMs to Vs. Unisystem

Posted: Thu Feb 16, 2017 12:08 pm
by sleepy9090
Hi all,

I've been reading a lot the past few weeks on PPU differences between the NES and the different Vs. Unisystem Arcade machines. I've searched the forums and found information here as well.

I was wondering if anyone had an in depth example of converting a NES ROM to use each of the 13 different PPUs so I can have a better understanding of how to go about it myself. I've found bits and pieces but nothing fully explanatory.


Re: NES ROMs to Vs. Unisystem

Posted: Thu Feb 16, 2017 12:20 pm
by mikejmoffitt
Other than the one variant with the swapped lines, it's a matter of modifying the palette to match the scrambled one of the other PPUs. That is just to handle the other PPU, not the rest of the VS. Unisystem.

Re: NES ROMs to Vs. Unisystem

Posted: Thu Feb 16, 2017 12:34 pm
by tepples
2C03 behaves the same as the standard NTSC PPU (2C02) with four minor differences. From least minor to most minor:
  1. Emphasis makes a particular component (red, green, or blue) fully bright instead of slightly darkening the other two.
  2. The palette is similar to the NTSC palette but much more saturated.
  3. Grays $2D and $3D are displayed as black (like $1D). Instead, use $00 and $10 respectively.
  4. No shortened pre-render line every other field.
The Famicom Titler and Famicom TV (but not the NES TV) also use the 2C03 PPU. Some Famicom games that use emphasis carry warnings that they won't work on a Famicom TV.

2C04 behaves the same as 2C03, but the lookup table from 6-bit colors to RGB colors is shuffled with one of four random permutations. This makes fades more difficult, and the grayscale bit ($2001 bit 0) is less useful. At least one Vs. game maps the DIP switches to select a lookup table that undoes this shuffling, allowing use with more than one PPU at runtime.

2C05 behaves the same as 2C03, except that $2000 and $2001 are swapped. If you use labels for these two (such as PPUCTRL and PPUMASK), you can make this a build-time switch. In addition, each of the different 2C05 models returns a different constant value in the otherwise unused bits 4-0 of $2002. But an external circuit (A0' = A0 XOR (A1 NOR A2)) will unswap the registers, making the 2C05 behave 99.99% the same as a 2C03.

Other changes needed for a full port to Vs. System include coin switch and coin log handling, the need to prevent stalling or infinite lives tactics, 4-screen VRAM, a different way of enabling WRAM at $6000, DIP switch handling, controller 1 being on the right side of the panel, a different Zapper protocol, and I think mapper IRQs (VRC4/6/7, MMC3) don't work properly.

Re: NES ROMs to Vs. Unisystem

Posted: Thu Feb 16, 2017 1:20 pm
by lidnariq
A few more differences, with numbers chosen relative to Tepples's list:
1.5: Vs. System always has full four-screen nametables, while the NES/Famicom almost always uses H or V layout of just two nametables.
3.5: The letterless 2A03 used in the Vs. System has no "tonal noise" mode, only full white noise.
5: A bug in the 2C02G with non-zero values written to $2003/OAMADDR before a write to $4014/OAMDMA causes the first two entries (bytes $00-$07) of the "shadow OAM" to always be copied to sprites 0 and 1. In contrast, the 2C03,4,&5 don't have this bug and writing a non-zero value to OAMADDR will rotate the data that is used for sprites 0 and 1.

Re: NES ROMs to Vs. Unisystem

Posted: Thu Feb 16, 2017 3:04 pm
by sleepy9090
Thanks for the quick response and useful info.

I've read about the other issues with converting a game to Vs. Unisystem and will tackle that in the future. First I want to understand the color conversion.

Where in the ROM is the information stored that I need to change. I'm figuring this is a very vague question and I'll get a RTFM hah!
I'm going to head home from work will check back later. Thanks again.

Re: NES ROMs to Vs. Unisystem

Posted: Thu Feb 16, 2017 3:22 pm
by tepples
sleepy9090 wrote:Where in the ROM is the information stored that I need to change.
It's different in every ROM. Do you have the ROM's source code?

If not, you'll need to work backwards. In FCEUX for Windows, open the debugger and put a write breakpoint on PPU $3F00-$3FFF to find code that writes the palette. This should help you find where it reads the data.

Re: NES ROMs to Vs. Unisystem

Posted: Fri Feb 17, 2017 6:00 am
by sleepy9090
I figured it wouldn't be that easy.

Sweet thanks for the tip, going to get started sometime today.

Is there a list somewhere of ROMs that have already been converted? I thought I saw some from an earlier thread but the link wasn't working anymore that showed the list.

Re: NES ROMs to Vs. Unisystem

Posted: Sat Feb 18, 2017 12:45 am
by Pokun
I don't know about games converted to VS System but a member here converted a bunch of VS System games to NES:

Another VS thing:
If $4017 (which is used for player 1 control panel) isn't read at least every 1.2 s, a watch dog timer resets system to prevent the arcade from locking up when no engineer is around to reset it manually.

Re: NES ROMs to Vs. Unisystem

Posted: Sat Feb 18, 2017 1:05 am
by Memblers
I've done some hacks to change some VS games to use a different VS PPU. Usually you don't need to disassemble the code to change the palette, a simpler way is to run the game in an emulator that lets you view the palette. For example if first color set is $0F,$04,$14,$24 then just search for that string of bytes in the ROM, and in a lot of cases all the palettes will be together in one big table. Though it certainly could be spread around in the ROM, too. It helps to know what palette data looks like, color #0 is usually repeated and the values are usually $3F and under.