BS-X Satellaview Datapak's

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Post Reply
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

BS-X Satellaview Datapak's

Post by nocash »

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
Tamanegi_taro
Posts: 25
Joined: Sat Dec 12, 2015 3:47 am

Re: BS-X Satellaview Datapak's

Post by Tamanegi_taro »

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
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Re: BS-X Satellaview Datapak's

Post by Near »

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.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: BS-X Satellaview Datapak's

Post by tepples »

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.
byuu wrote: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.
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?
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Re: BS-X Satellaview Datapak's

Post by Near »

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.
AWJ
Posts: 433
Joined: Mon Nov 10, 2008 3:09 pm

Re: BS-X Satellaview Datapak's

Post by AWJ »

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:

Image

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.
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Re: BS-X Satellaview Datapak's

Post by Near »

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.
AWJ
Posts: 433
Joined: Mon Nov 10, 2008 3:09 pm

Re: BS-X Satellaview Datapak's

Post by AWJ »

byuu wrote: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.
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Re: BS-X Satellaview Datapak's

Post by Near »

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.
AWJ
Posts: 433
Joined: Mon Nov 10, 2008 3:09 pm

Re: BS-X Satellaview Datapak's

Post by AWJ »

byuu wrote: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.
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:

Code: Select all

0000ff00  4d 00 50 00 00 00 79 00  00 00 00 00 00 00 00 00  |M.P...y.........|
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:

Code: Select all

80/AD12: 9C 8D 05      stz $058D
80/AD15: 9C 8E 05      stz $058E
80/AD18: 22 6E AD 80   jsl l80AD6E ; read Flash info block
80/AD1C: 90 3F         bcc aAD5D ; bail if above routine timed out (can only happen with a defective Flash chip)
80/AD1E: AD 90 05      lda $0590
80/AD21: C9 4D         cmp #$4D
80/AD23: D0 38         bne aAD5D ; first byte must be "M"
80/AD25: AD 91 05      lda $0591
80/AD28: C9 50         cmp #$50
80/AD2A: D0 31         bne aAD5D ; second byte must be "P"
80/AD2C: AD 92 05      lda $0592
80/AD2F: 29 81         and #$81
80/AD31: D0 2A         bne aAD5D ; third byte bits 7 and 0 must be clear
80/AD33: AD 93 05      lda $0593
80/AD36: 4A            lsr
80/AD37: 4A            lsr
80/AD38: 4A            lsr
80/AD39: 4A            lsr      ; extract type
80/AD3A: F0 21         beq aAD5D
80/AD3C: C9 05         cmp #$05
80/AD3E: 90 04         bcc aAD44
80/AD40: C9 07         cmp #$07
80/AD42: D0 19         bne aAD5D ; type must be 1, 2, 3, 4 or 7
aAD44:
80/AD44: 8D 8E 05      sta $058E
80/AD47: 22 EF AD 80   jsl l80ADEF ; terminate status mode
80/AD4B: AD 93 05      lda $0593
80/AD4E: 29 0F         and #$0F  ; extract size
80/AD50: AA            tax
80/AD51: BF 5E AD 80   lda f:FlashSizeLUT,x ; linearize size 
80/AD55: 8D 8D 05      sta $058D
80/AD58: D0 03         bne aAD5D
80/AD5A: 9C 8E 05      stz $058E ; looked-up size must be nonzero
aAD5D:
80/AD5D: 6B            rtl
FlashSizeLUT:
80/AD5E: 00 00 00 00 00 00 00 01 02 04 08 10 00 00 00 00
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):

Code: Select all

80/AB35: AD 8E 05      lda $058E
80/AB38: C9 07         cmp #$07
80/AB3A: D0 15         bne NotMaskROM
80/AB3C: 20 53 AB      jsr LogarithmizeFlashSize
80/AB3F: C2 20         rep #$20
80/AB41: BD 62 AB      lda FakeBlockMapLUT,x
80/AB44: 8D 2C 05      sta $052C
80/AB47: BD 64 AB      lda FakeBlockMapLUT+2,x
80/AB4A: 8D 2E 05      sta $052E
80/AB4D: E2 20         sep #$20
80/AB4F: 38            sec
80/AB50: 60            rts
NotMaskROM:
80/AB51: 18            clc
80/AB52: 60            rts
LogarithmizeFlashSize:
80/AB53: A2 00         ldx #$00
80/AB55: AD 8D 05      lda $058D
aAB58:
80/AB58: 4A            lsr
80/AB59: F0 06         beq aAB61
80/AB5B: E8            inx
80/AB5C: E8            inx
80/AB5D: E8            inx
80/AB5E: E8            inx
80/AB5F: 80 F7         bra aAB58
aAB61:
80/AB61: 60            rts
FakeBlockMapLUT:
80/AB62: 01 00 00 00   .dword $00000001
80/AB66: 03 00 00 00   .dword $00000003
80/AB6A: 0F 00 00 00   .dword $0000000F
80/AB6E: FF 00 00 00   .dword $000000FF
80/AB72: FF FF 00 00   .dword $0000FFFF
80/AB76: FF FF FF FF   .dword $FFFFFFFF
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.
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: BS-X Satellaview Datapak's

Post by nocash »

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).
AWJ
Posts: 433
Joined: Mon Nov 10, 2008 3:09 pm

Re: BS-X Satellaview Datapak's

Post by AWJ »

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)
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: BS-X Satellaview Datapak's

Post by nocash »

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.
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Re: BS-X Satellaview Datapak's

Post by Near »

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!
AWJ
Posts: 433
Joined: Mon Nov 10, 2008 3:09 pm

Re: BS-X Satellaview Datapak's

Post by AWJ »

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.

Code: Select all

00/81BB: A9 40         lda #$40
00/81BD: 8D 0C 60      sta $600C ; #$40 = data pack absent?
00/81C0: A9 84         lda #$84 ; first data pack slot bank
00/81C2: 85 00         sta $00
Loop:
00/81C4: A5 00         lda $00
00/81C6: 8D 23 22      sta FXB ; map data pack at A0-BF:8000-FFFF
00/81C9: AF DA FF A0   lda $A0FFDA
00/81CD: C9 33         cmp #$33
00/81CF: D0 34         bne Fail
00/81D1: C2 20         rep #$20
00/81D3: AF DC FF A0   lda $A0FFDC
00/81D7: 18            clc
00/81D8: 6F DE FF A0   adc $A0FFDE
00/81DC: 1A            inc
00/81DD: D0 26         bne Fail   ; checksums must complement
00/81DF: AF B0 FF A0   lda $A0FFB0
00/81E3: CD B0 FF      cmp $FFB0
00/81E6: D0 1D         bne Fail   ; 2-byte maker code must match ours
00/81E8: E2 20         sep #$20
00/81EA: A2 00 00      ldx #$0000
a81ED:
00/81ED: BF C0 FF A0   lda $A0FFC0,x
00/81F1: DD AA FF      cmp $FFAA,x
00/81F4: D0 0F         bne Fail   ; title must start with "GNEXT "
00/81F6: E8            inx
00/81F7: E0 06 00      cpx #$0006
00/81FA: D0 F1         bne a81ED
00/81FC: A9 C0         lda #$C0
00/81FE: 8D 0C 60      sta $600C ; #$C0 = data pack present?
00/8201: A5 00         lda $00
00/8203: 80 0C         bra Success
Fail:
00/8205: E2 20         sep #$20
00/8207: E6 00         inc $00
00/8209: A5 00         lda $00
00/820B: C9 88         cmp #$88 ; last data pack slot bank
00/820D: 90 B5         bcc Loop
00/820F: A9 81         lda #$81
Success:
00/8211: 8D 22 22      sta EXB ; map data pack or ROM at 80-9F:8000-FFFF
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)
Post Reply