What does it take to convert a regular selfmade NES game to the VS unisystem?
The game is supposed to play the same, only that you include the whole "Insert key" into the game.
Would this just be a mundane addition or is there more to do?
To get the game to even run on Vs. System, you'd need to do at least these steps:
- Rewrite any code that touches palettes because 2C04 palettes are scrambled. Fading is a pain; the typical routine of subtracting $10, $20, and $30 and then mapping $F0 to $02 and map negative numbers to $0F won't work.
- Swap the joysticks.
- Rewrite the scrolling code to be tolerant of four-screen mirroring.
Because Vs. games are coin-operated, you'd also have to do these:
- Remove the pause function.
- Add scoring and a high score list if the game doesn't already have one. This feature was dropped on later NES games; Tetris by Nintendo is the only later game I can think of that has a high score list. Displaying score all the time in a game that doesn't normally have, such as later Mega Man games, may cost CHR tiles.
- Recognize inserted coins even during lag frames and during background transitions. The coin mech presses the coin button only for about three frames.
- Display the coin count at all times, except perhaps a second at a time during background transitions.
- Add an attract mode if the game doesn't already have one. Provide a DIP switch to control its sound.
- Add other DIP switches to control difficulty and coin to credit ratio.
- Add "ramping", or a gradual increase in difficulty as the player completes more levels on one life.
- Add enemies that attack the player at all times or a time limit or both in order to reclaim an idle joystick.
- Add countdowns on menus.
- Heavily location-test your game's reward structure to make sure players can't, say, turtle-tip for dozens of lives.
Do any Vs. games use a scanline- or cycle-counting IRQ or more RAM at $6000-$7FFF than the built-in dual-game communications RAM that
Vs. Super Mario Bros. hogs for itself? Or are those features of the NES and PlayChoice platforms not part of the Vs. System?
tepples wrote:
Do any Vs. games use a scanline- or cycle-counting IRQ or more RAM at $6000-$7FFF than the built-in dual-game communications RAM that Vs. Super Mario Bros. hogs for itself? Or are those features of the NES and PlayChoice platforms not part of the Vs. System?
None of the existing daughterboards add an IRQ... maybe because the IRQ pin is already ≈reserved for communications between the two CPUs.
Similarly, no daughterboard disabled the "master" CPU controlled 2KiB shared RAM.
tepples wrote:
Fading is a pain;
Not necessarily. Since DRW is talking about homebrew software, you simply have to design something more robust than he typical "subtract $10" (which I consider kinda lame, BTW).
In order to have more freedom when manipulating the palette in my programs, I reordered the colors in a more convenient way, and after each color is processed I use a table to convert the result from my made up palette into the real NES palette. In this case, simply modifying that translation table would be enough to make fades work on the VS. System.
How do you fade with such a table?
I think a better use of the DIP switches would be to let the user specify the PPU version, so you can look up the correct palette. In addition to varying palettes, some VS PPU I believe also swapped the location of the $2000 and $2001 registers.
Another thing is that you shouldn't have too much time between reads of the $4017 register, there is a watchdog timer that will reset the CPU/PPU, presuming the game has locked up.
Pokun wrote:
How do you fade with such a table?
This table isn't for fading, just for converting from my made up palette order (which is optimized for fading) to the real palette order.
If you wanted, you could use a normal NES fading routine and do this at the end, before using the result:
Code:
;color value in the accumulator
tax
lda PaletteTranslation, x
This can translate colors to whatever palette ordering you need.
tokumaru wrote:
If you wanted, you could use a normal NES fading routine and do this at the end, before using the result:
Code:
;color value in the accumulator
tax
lda PaletteTranslation, x
This can translate colors to whatever palette ordering you need.
Better yet:
Code:
;color value in the accumulator
tay
lda (PaletteTranslationForCurrentDIPSwitches), y
where
PaletteTranslationForCurrentDIPSwitches is a pointer stored on zero page.
Yeah, if you go with Memblers' suggestion.
Memblers wrote:
some VS PPU [...] also swapped the location of the $2000 and $2001 registers.
But that also means you can automatically detect the 2C05 by those swapped registers.
Support for 2C05 also means you lose two more RAM locations: one containing $00 or $01 and one containing $01 or $00.
Looks like there are some things to do for the VS Unisystem. I guess I'll just program my game for the regular NES for now. Thanks for the information.
Despite tepples's litany, the only things you really "have" to do are:
- Restrict yourself to one of the physically existing mappers (1,2,67,75,99(≈0,3,87,101),206)
- Don't use the start/select buttons in game play (e.g. on the "Red Tent" Vs. System, they're greatly separated from the A/B buttons)
- Swap the joysticks (player 1 is read from $4017 instead of $4016, and you must read from $4017 at least once every second or else the console will reset)
- Can't use nametable mirroring control; you instead always get 4-screen nametables.
- Accept coins
Remember that you can pick the PPU that your game will run on (whether it's 2C03, 2C04-{1,2,3,4}, or 2C05), so compatibility there is really only a "if you feel like it".
lidnariq wrote:
Despite tepples's litany
Yeah, I though some of it was more opinionated than that you have to do it, like this:
Quote:
•Add "ramping", or a gradual increase in difficulty as the player completes more levels on one life.
I can think of just as many arcade games that don't do this than ones that do.
Let me put it another way, hopefully with less opinion: You as the developer of a Vs. game have to consider the other paying players in line behind the player at the controls and the arcade operator who is leasing valuable real estate to exhibit your game on his Vs. cabinet.
Even that assumes the idea is to have it in a specific kind of arcade. There are arcades that just charge entry and by hour, not per game. And there are arcades with multiple cabinets of the same game, and there are arcades that also have actual console games. And one can play a game more like a console game in any of those scenarios, without it causing any trouble for anyone. So even that isn't a need.
It could be a game with drop in multiplayer, so someone could simply join the long game. And the idea could be totally separated from arcades too. I've considered buying a VS unisystem and putting a custom game on it just as a cool thing to have around the house.
Good point Kasumi. A lot of arcade games have "free play" or "event mode" modes for use in tournaments or in arcades that charge admission. But I've never happened to see a production game designed exclusively for free play. And even machines set to free play can have a line behind them.
There are two groups of tasks that have been combined in this thread: technical requirements to get a VS system game running, and proper design considerations for an arcade title.
I think most, if not all, of the requirements have already been stated.