Standalone Stadium GB Emulator ハックロムをダウンロード

Standalone Stadium GB Emulator
-or-
An Exercise In Futility

  Applied to a USA version of Pokemon Stadium 2, this patch isolates the GBC emulator and extends the number of titles it potentially supports.  You should be able to play most GB carts through the transfer pak, poorly.

  Insert a controller in controller port 1 and insert an transfer pak into the controller.  Insert a Game Boy or Game Boy Color cartridge into the transfer pak and start the game.  You cannot remove the cartridge during play.

  The emulator is restricted to running cartridges with 2MB ROM or less.  Saving is not guaranteed and even less recommended.  Although it has been modified to run carts without RAM, carts with dead batteries will throw an (unhelpful) error.  Despite being an official product there's a number of inaccuracies and outright errors.  However, it serves as a brilliant example why a proper GB emu for N64 should be made.

  The interface when an unrecognized title is loaded has been changed slightly.  Instead of green boxes that are not filled with images of the Pokemon you should have in your nonexistent party, a single box will be displayed containing some header information.
  Speedup mode is always available, and its behavior depends on the recognized game version.
  Returning to Pokemon Stadium has been replaced with a feature that reloads the current title and restarts it.  Unregistered games have no way to determine if the loaded data is accurate, so this feature may be useful to reload all banks in the case serious issues occur.
  As an interesting note, the GBC bootstrap used causes games to falsely report running on a GBA.  GBA-specific features and palettes will be used.  GB games use a DMG bootstrap.  SGB borders will always be used if found, even with GBC titles.

.:Patching:.
  Apply the xdelta patch with the similarly named xdelta patcher to an unbyteswapped copy of Pokemon Stadium 2 (USA).  Attempting to apply to any other version will produce a somewhat unhelpful checksum mismatch error.  The SHA512 for the correct source ROM is:
0DBC093C4915A406A702AEECBFCFC73AAA0663FEBAEE67704946C9FF03AF0AF1EC9506FBCB18D5AA691329087AF4DAA58E09DB3F1ECDA77C23A4978550174EA7

  The resulting file will be significantly smaller--only 0x164000 bytes, or ~1.4MB.

  An N64 flashcart is recommended and, for the moment, possibly required.
  Running an emulator in an emulator may be delightfully meta but historically few have been able to run the Stadium GB Tower.  You'll need to refer to their documentation to know if they can and how they should be set up.
  As of writing this (5/19), private builds of Cen64 with transfer pak support will run (albeit very, very slowly), and public builds of PJ64 crash within the recompiler.
  Additionally, using GB flashcarts in the transfer pak may not work in general.  There are many possible factors: power consumption, hardware behavior, save management, etc.  Suffice it to say the only way you'll know for certain is through trial-and-error and absolutely no support will be given for incompatible hardware.

  Tested on console using both a 64drive and V64 Jr. with official GB and GBC carts in an official transfer pak.

  Unlike the various Wideboy64 GB units playback is done in software, not hardware.  As a result, ultraHDMI users should have sound (emulation issues notwithstanding).



.:Things You're Likely Uninterested In:.

  There are three different official GB emulators.
Pocket Monster Stadium 1 & 2 (Japan)
	GB & SGB
	MBC3 or less, 1MB ROM max, exactly 32KB RAM, region-locked
	*not all opcodes implemented*
	Differ only in provided filetables
Pokemon Stadium (International)
	GB, SGB, GBC
	most MBC5 variants, 2MB ROM max, exactly 32KB RAM, region-locked
Pokemon Stadium 2 (International) / Pocket Monster Stadium 3 (Japan)
	GB, SGB, GBC
	MBC5 or less, HuC (arguably), 2MB ROM max, > 8KB RAM
	supports individual bank replacements

  No version will natively run a GB title that does not have RAM.  Additionally, they will not properly read RAM when there are fewer than four banks unless a filetable is provided.  This has been corrected in the provided patch, however.
  Any exotic hardware address will not work.
  Ironically, the GB camera has a special handling flag in the later two emus' mapper tables yet is not supported, despite a number of N64 titles that utilize it.  Similarly, a flag assigned to HuC chips to indicate the IR port is not handled.

  Beyond borders, most Super Game Boy features are not implemented or only partially implemented.  For instance, the 2 player feature in many Takara games and the Puyo Puyo series is detected, but controller 1's input is mirrored onto controller 2.  Some SGB borders, such as the one in Choro Q, may not display.  The SGB BIOS isn't present, so those colorized by built-in palettes are, well, not.

  Refer to the doc on filetables for more info of what those are and do.
  Filetables for all 43 Pokemon games are provided but obviously not all have been tested.  
  Replacement data was omitted in the standalone variant, reducing the filesize by nearly 2MB.  They can be added if...
    1) entries + headers either doesn't exceed 0x800 or you split headers into a second copy of the block at 0x1546F0,
    2) 0x7D76 is changed to the maximum header entries in a 0x800 block,
    3) the N64 ROM checksum is recalculated.
  With 41 versions of Stadium-supported GB titles--not counting the two Korean games--and each title having its own specific set of replacement and patch information, it can't be guaranteed they will all run without a hitch.  That said, the two prior emus didn't use that stuff so it can't be that important, right?
  These replacement binaries covered every version of the Pokemon handheld games, not just Crystal.  In addition, Japanese version 0 and 1 copies of Gold and Silver patch individual banks within the emulator code.  What those changes do hasn't been investigated.

  During testing a number of additional filetables were created.  They've been included in the release as a sort of example.  Following the format doc it's trivial to make and insert your own.  N64 checksum recalculation isn't necessary.
  In addition to Pokemon titles, additional filetables are provided for:
Puyo Puyo, both versions
Pocket Puyo Puyo Tsuu
Pocket Puyo Sun
Pocket Puyo Puyo~n
Link's Awakening DX, all three USA versions
Super Mario Land 2, both USA versions
Super Mario Land 2 DX v1.81 (USA) by toruzz

  A minor change was made to the standalone header data.  The game version is no longer tested.  Instead, it can be used to set the Pokemon version that is used on-screen.  Using Gold, Silver, or Crystal also changes the speedup behavior.  Instead of always running in color it will switch to sepia and black on higher playback speeds.  By default, Green is used for unrecognized titles.

  The final emu introduced a bug when a screen is perpetuated in vram.  Thankfully that mostly applies to "this game can only be played on a GBC" warnings, but some titles like Shadowgate become unplayable.

  Some titles, most notably Super Mario Land 2, will be in a perpetual state of "saving".  It (thankfully) isn't saving your game, but it is preventing access to the menu.
  Saving, in general, can't be trusted.  One of the early verification tests is fudged to permit carts without RAM, but even without that it is possible save files can be corrupted.  Typically, they write a save, read it back, then compare, repeating on a miss...to a point.  After that there's an error message, and if you're lucky it may attempt writeback again.  The same save verification test is also why it fails to run carts with dead batteries.

  The transfer pak is underpowered--literally.  On paper it only receives 3 volts, but in actuality less than that (just over 2 on average).  It's evident in the software driver.  Every step is wrapped in failure tests and repeats with timeout loops that happen to be just as long as it, on paper, needs to rebuild voltage.  In fact, the very first access is guaranteed to fail.  Consequently, the more power a cart draws the less likely it is to work for any length of time with the transfer pak.  Flashcarts built from salvaged GB boards are significantly more likely to run if only because they draw vastly less from the pak than some fpga based monstrosity, all other hardware behavior aside.

  The emulator can be stripped down significantly more than it has been.  It can be completely excised and attached to a ROM providing standard threads + transfer pak support, the emu code mapped via TLB, and a new error display system provided (or not).  As far as things go though it would be more effective to just write a new emulator without all the sprite display issues and hardware access errors.
  It isn't reliant on external soundbanks.  Sounds used in the menus are GB audio run through its audio emulation routines.

-Zoinkity