It is currently Sat Dec 16, 2017 8:07 am

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 56 posts ]  Go to page 1, 2, 3, 4  Next
Author Message
PostPosted: Tue Jul 05, 2016 3:11 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 538
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


Top
 Profile  
 
PostPosted: Tue Jul 05, 2016 5:44 am 
Offline

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


Top
 Profile  
 
PostPosted: Tue Jul 05, 2016 10:36 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1339
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.


Top
 Profile  
 
PostPosted: Tue Jul 05, 2016 11:23 am 
Offline

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


Top
 Profile  
 
PostPosted: Tue Jul 05, 2016 4:49 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1339
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.


Top
 Profile  
 
PostPosted: Wed Jul 06, 2016 12:54 am 
Offline

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


Top
 Profile  
 
PostPosted: Wed Jul 06, 2016 1:47 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1339
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.


Top
 Profile  
 
PostPosted: Wed Jul 06, 2016 2:23 am 
Offline

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


Top
 Profile  
 
PostPosted: Wed Jul 06, 2016 4:13 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1339
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.


Top
 Profile  
 
PostPosted: Wed Jul 06, 2016 11:03 am 
Offline

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


Top
 Profile  
 
PostPosted: Wed Jul 06, 2016 2:25 pm 
Offline

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


Top
 Profile  
 
PostPosted: Wed Jul 06, 2016 3:19 pm 
Offline

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


Top
 Profile  
 
PostPosted: Wed Jul 06, 2016 4:30 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 538
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.


Top
 Profile  
 
PostPosted: Wed Jul 06, 2016 5:57 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1339
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!


Top
 Profile  
 
PostPosted: Fri Jul 08, 2016 5:53 pm 
Offline

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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 56 posts ]  Go to page 1, 2, 3, 4  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 10 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group