UNIF Support
Moderator: Moderators
UNIF Support
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?
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.Dwedit wrote:So, besides distingushing between different board types and indicating whether there is cartridge ram or not, what's the point of UNIF?
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
P.S. If you don't get this note, let me know and I'll write you another.
-
- Posts: 780
- Joined: Tue Nov 23, 2004 9:35 pm
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.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?
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
P.S. If you don't get this note, let me know and I'll write you another.
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.tepples wrote:What should be the chunk type for a 64-byte block that describes a VS Unisystem PPU?
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.)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.
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.
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.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
P.S. If you don't get this note, let me know and I'll write you another.