UNIF Support - NESdev BBS

UNIF Support
by xensyria on 2005-12-23 (#7636)

How does UNIF support FDS, VS Uni, PC10 and GC mini etc. I can't find anything for these - should they have their own special 'code' in the place of a board?

by Quietust on 2005-12-23 (#7639)

It doesn't.

by Dwedit on 2005-12-23 (#7641)

So, besides distingushing between different board types and indicating whether there is cartridge ram or not, what's the point of UNIF?

by Quietust on 2005-12-23 (#7643)

Dwedit wrote:
So, besides distingushing between different board types and indicating whether there is cartridge ram or not, what's the point of UNIF?

As I understand, that WAS the main point of UNIF. It handles Nintendo-made cartridges surprisingly well, though it has some major problems when it comes to third-party cartridge boards (i.e. stuff made by Color Dreams & Tengen, as well as Namco, Jaleco, Bandai, Konami, and all of the damn multicarts) which don't have a distinctive 'board name'. The other point was to make the file format modular (allowing any unrecognized block to be simply skipped), which means that it could be updated to support FDS (using DSK0/DSK1/DSK2/etc. blocks), Playchoice-10 (with a block to store the 8KB hint-screen ROM), and VS Unisystem (adding a small block to store the PPU used) just fine.

by tepples on 2005-12-23 (#7646)

What should be the chunk type for a 64-byte block that describes a VS Unisystem PPU?

What info would a chunk called "PC10" need other than that 8 KB block for the top screen?

by Great Hierophant on 2005-12-23 (#7647)

Most boards have some way of identifying themselves, even if the chief distinction is the lockout defeater. Unfortunately, many boards are to be identified just by their numbers. The true weakness of UNIF is the death of proper information available about the Famicom mappers.

by Quietust on 2005-12-24 (#7662)

tepples wrote:
What should be the chunk type for a 64-byte block that describes a VS Unisystem PPU?

What info would a chunk called "PC10" need other than that 8 KB block for the top screen?

The VS block would not be 64 bytes long, but a simple string - "RP2C03", "RP2C04-001", "RP2C04-002", etc. The palette can NOT be stored as a simple translation table, as the VS PPUs actually contain colors which do not exist in the standard NTSC palette - it should be left to the emulator to load the appropriate palette.

by AWJ on 2006-01-01 (#7901)

tepples wrote:
What should be the chunk type for a 64-byte block that describes a VS Unisystem PPU?

An RGB PPU's internal palette contains 64 9-bit colors, so a 64-byte block is insufficient. A 72-byte block would be sufficient if you bit-packed the color entries or stored them as bit planes, but I think a 128-byte block would be preferable considering simplicity and human-readability.

by tepples on 2006-01-01 (#7902)

AWJ wrote:
An RGB PPU's internal palette contains 64 9-bit colors, so a 64-byte block is insufficient. A 72-byte block would be sufficient if you bit-packed the color entries or stored them as bit planes, but I think a 128-byte block would be preferable considering simplicity and human-readability.

In that case, it might be wise to store the palette in Super NES format (0bbb00gg g00rrr00, little endian) for future expansion. (This is also the native color format of the PS1, Game Boy Advance, and Nintendo DS.)

by Quietust on 2006-01-01 (#7903)

Since there are only a discrete number of VS/PC10 palettes in existance (five - one 'normal' and 4 'scrambled'), as I said, it would be far more efficient to simply indicate which PPU is used. Besides, dumping a VS palette requires specialized hardware, so dumping VS games bound to particular PPUs before said PPUs are dumped would be impossible.

Some VS games, interestingly enough, use DIP switch settings to select which PPU to use (usually the upper 2 switches; a few of these even have another switch to let it work with an ordinary PC10 PPU) - these would require some special handling.