nesdev.com

Here are high-resolution PCB photos for the BS-X Datapak hardware - the BS-X BIOS cart, and several game carts with Datapak slots, and the actual Datapak's (a regular FLASH cart, plus two ROM carts). All photos are taken by skaman. As far as I can tell, the two photo sets are covering each and every BS-X cartridge that has been ever released.
http://www.mediafire.com/download/m5scy ... ctures.zip - 52.36 MB - Various Carts and two ROM datapak's
http://www.mediafire.com/download/heg0v ... ures_2.zip - 17.28 MB - Derby Stallion 96 and a FLASH datapak

Thanks for pictures.

I was wondering if Samegame and Gundom data packs are re-writable like 8M memory packs but I guess they have completely different ROM chip which is not re-writable.

Thanks,
Tamanegi

Nope, and Same Game won't even run if the data pack responds to the cartridge info subchannel data that you can't suppress with flash carts. The game checks for and blocks this case, so you have to emulate the pack data as mask ROM or it fails to work. (and I currently can't tell them apart just by .bs extension, so you have to manually specify in the manifest that it's mask ROM.)

Which always seemed like a huge waste to me. They could have supported BS-X downloadable character data that way.

But now I look at it as a good thing. With nocash's notes, people could have more easily passed off fake Same Game Tengai Makyou carts. Those are around $350 each these days.

Or I could play Insane Game on a TI calculator or BreakThru! on a Super NES. It's the same game. One of my first (unreleased) NES projects was to port Insane Game to NES, not knowing the history that dates back to Chain Shot, the first known SameGame implementation. And Swell Foop rhymes with but isn't Zoop.


How does this work? I thought to query a flash cart you needed to write to it. Couldn't a pirate modify a flash cart to tie /WE high?

That may work, I've only tested this in software. If nocash has a spare BS-X data pack he doesn't mind modding, and a Same Game cart, we could see.

I have the MaskROM version of this game, so I have no reason (or skill to) to try this.

Could it be Same Game is actually testing itself (that it's running off a real cartridge and not a copier), and not the data pack slot? Maybe the PCB it runs on doesn't connect /WR from the cart edge to the data pack slot, or it has a jumper that breaks the connection.

Japanese Wikipedia claims that content for Same Game was distributed on the Satellaview service, and this advertisement for the game has the BS-X logo and 衛星放送対応 ("Compatible with satellite broadcast") in the lower right corner:



Same Game and Joushou Mahjong Tenpai use the BSC-1J3M-01 PCB, while Ongaku Tsukuru uses BSC-1J5M-01 (and I strongly suspect the latter does need the slot to be writable, since it's a "tsukuru" cartridge)

ETA: Looked at the PCB photos, and Same Game has three capacitors (?) soldered onto the PCB (two on the component side and one on the solder side) which none of the other games have.

Well, the SNES ROM itself tries to ask for subchannel data from the BS-X pack. If it works, then the game ignores the cart entirely, even if it's identical to the official Tengai Makyou Same Game BS-X cartridge.

If you trace the boot-up routine, you can see it doing exactly this.

I don't see any possible way a rewritable cartridge could ever work with this game, and I'm not aware of any data actually distributed through the BS-X download service for this game.

Maybe the data packs have some metadata indicating whether they're retail or broadcast, and the game will reject it if the metadata and the hardware type don't match. That would prevent pirates from copying the retail data packs onto flash cartridges.

I have a hard time believing Hudson was worried about people pirating Same Game character data packs by reprogramming BS-X packs. Especially given the game shipped with one, and the other only had a release of ~100 copies. And then no downloadable content was ever released anyway.

I don't even know how those 100 copies ever got out in the first place. They were supposed to be sold in retail boxes at stores, but said release never happened. Yet somehow, a very small number of loose copies with no boxes or manuals exist in the wild. 100% of the English search results for the game only turn up a combination of real and fake ROM download links.

But, who knows. Maybe there's a byte somewhere you can flip to make Same Game Tengai Makyou boot from a flash ROM BS-X cart. It'd be a cool novelty, but not really worth the time or effort. It's just Tengai Makyou character heads in place of more mainstream Hudson character heads in a puzzle game.

After a bit of disassembling, I've figured it out, and my second guess was more or less right. I'm not sure if it's intentional protection or not, but Same Game does treat mask ROM and Flash ROM data packs differently, with the result that the mask ROM data packs won't work if you emulate them as Flash ROM (or if you copy them byte-for-byte onto a Flash pack and run it on hardware)

The mask ROM data packs contain a fake Flash chip detection block at offset $FF00:



Notice that the fake info has a type code of "7". BS-X Flash packs all have a type of either 1, 2, 3 or 4 (each with a slightly different protocol).

Same Game reads the chip detection block and copies it to RAM at $0590-$0599. If the data pack responds to writes, it'll be the actual Flash chip info; if the data pack ignores writes, it'll be the fake info from the ROM. Then it validates the info, extracts the "type" and "size" fields, converts the size from logarithmic to linear units of 128KB, and stores the converted size and type at $058D and $058E respectively:



tl;dr version: after this routine, $058D contains the size of the data pack in units of 128KB, and $058E contains the Flash chip type (1-4 or 7). If anything is wrong with the chip info, $058D and $058E are both set to 0 and the game will treat the slot as empty.

Some time later, the following routine runs (which, amusingly, has to convert the data pack size back to logarithmic representation before using it as an index into another LUT):



This routine stores a fake block map at $052C indicating that whatever size the data pack is, it's completely occupied by a single file--but only if the data pack is type 7 (i.e. mask ROM). If the data pack isn't type 7, a different routine ends up loading $052C with the actual block map from offset $FFD0 of the data pack (see here).

If you look at offset $FFD0 in the mask ROM data pack, it's a bunch of zeroes. So if the above override routine doesn't override it, the game thinks that the data pack is empty. And that's why the mask ROM data packs won't work if copied to or emulated as Flash ROM. To make them work, just change the byte at offset $FFD0 in the .bs file from $00 to $0F (tested and confirmed to work with both data packs).

By the way, the mask ROM data pack for SD Gundam G Next contains an identical fake Flash chip detection block, only it's at offset $7F00 rather than $FF00.

Nice disassembly! Good to know about the extra bytes at FF00h, and about the missing byte at FFD0h. Even if Nintendo planned to produce more of those ROM carts, the missing byte wouldn't serve too well as copy-protection. I guess they have just unintentionally left it set to zero (after all, the bytes at FFD0h are usually supposed to be set at time when writing a file to a flash cart, with the separate bits set/cleared depending on which free blocks the file is written to, ie. the ROMs could be just treated as 'raw files' that haven't been written to a FLASH card yet; similar as when downloading a file via satellite).

Btw. for the ROM PCB photos, the most intersting parts to me are that they are really Mask ROMs (not write-protected FLASH chips or the like), and that one ROM cart uses 8bit databus, and the other ROM cart uses 16bit databus. FLASH carts can be used in 8bit or 16bit mode - but the ROM carts are hardwired to one bus-width, so the 16bit ROMs can be used only with SA-1 game cards, and the 8bit ROMs with the MCC bios card and MAD-1 game cards.
Theoretically it might be possible to switch the 16bit ROM chip to 8bit mode (as FLASH chips can do), but skaman reported problems dumping that particular ROM card (for SD Gundam), so the 16bit ROM card is probably wired to operate always in 16bit mode (regardless of whether the actual ROM chip also supports 8bit or not).

Here's a question for you: The BS-X cartridge and other slotted cartridges support four different types of Flash chip with different interfaces, but do you know which type(s) actually exist in data packs in the wild?

I guess you'd have to reprogram a slotted cartridge (one of the plain MAD-1 ones would be easiest) with a program that queried the data pack and displayed the chip info on-screen, and test it with a bunch of different data packs...

bsnes emulates the type 2 flash chip, I guess because it's the simplest protocol to emulate. But one of the third-party forks (not mine) changed it to emulate the type 1 instead, claiming that the code (in games, not the emulator) for type 2 was obviously buggy/broken and that type 1 worked better with certain games (I think the ~Tsukuru games might have been the ones that didn't seem to like type 2, according to this fork author)

From what I remember, people reported the FLASH cards to be are all containing the same chip (ie. the Sharp LH28F00SUT-ZI shown on the photo). Which, skaman identified that chip as this: "All of the Memory Paks that I have are Type 1 (coded 0x1A). The Intelligent Identifier (Chip ID) is 0xB0, 0xA8 (Sharp Chip ID 0xA8)."

The BS-X BIOS cart has two bugs (for Type 2 detection and Type 3 erase-entire-chip; see the "BUG" markings in fullsnes.htm), though the bugs aren't neccessarily making the carts totally nonfunctional, so Type 2/3 cards (if they should have ever been manufactured, at least as prototypes) might have still worked despite of those bugs.

I haven't disassembled the FLASH code in the Tsukuru games, maybe they are containing more serious bugs.

All of my carts are type 1 as well. Types 2-4 have never been confirmed in the wild.

Also, fantastic sleuthing on Same Game, thank you!

Here's the data pack validation from SD Gundam G Next. It runs on the S-CPU very early in initialization, before starting up the SA-1. Unlike Same Game, G Next doesn't seem to write to the Flash registers at all (so the fake chip info at $7F00 isn't used or needed). Perhaps the SA-1, like the SuperFX, simply doesn't support writing to ROM.



Note that the game only checks one location in each 1MB bank, so files smaller than 1 MB that aren't located at the start of the Flash ROM won't be found (maybe all the broadcast DLC packs for the game were a full 1MB in size? The Mask ROM pack is only 512KB)

ETA: Bass Tsuri No.1 doesn't seem to write to the Flash registers either, at least not while detecting/validating the data pack (I don't know where to get a data pack image with valid data for the game, so I can't tell what it does after that)