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.
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?
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.
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.
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.
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.
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.
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)
I just dumped vendor info off my packs.
All my packs are Type 1 with 8M memory（０ｘ１A) too.
How did I miss this?
Also nice catch about the Type 7. That might be cool to detect when the dump is from a ROM instead of Flash, I guess.
AWJ wrote:
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)
I'm the author of that. And Type 1 is much simpler to emulate than Type 2. I don't get why byuu decided to emulate Type 2 instead.
Also it should be known that a lot of commands were tested, including undocumented ones by ikari_01:
http://wiki.superfamicom.org/snes/show/ ... k+Commands
I emulated type 2 because that was all the information that was available when I did it. It was just one crappy .txt file filled with ???s everywhere.
I haven't touched the BS-X Satellaview code in probably seven years now. If I ever get back to working on it, obviously I'll use type 1 because I don't even think type 2 exist.
Got some BSX hardware donated from skaman: An Itoi Bass No1 cart, a BSX BIOS cart, and a FLASH memory pak.
First of, the FLASH chip pinout (as from datasheet, and with the datapak slot connector pins in right column):
Code:
LH28F800SUT FLASH CHIP
1 3V/5V cn.34
2 /CE1 cn.51
3 NC (A21) cn.50
4 NC (A20) cn.48
5 A19 cn.46
6 A18 cn.44
7 A17 cn.42
8 A16 cn.40
9 VCC cn.31,32
10 A15 cn.38
11 A14 cn.29
12 A13 cn.35
13 A12 cn.11
14 /CE0 (GNDed) cn.1,2,61,62
15 VPP cn.30 <--
16 /RP (reset/powerdown) cn.47
17 A11 cn.41
18 A10 cn.43
19 A9 cn.39
20 A8 cn.37
21 GND cn.1,2,61,62
22 A7 cn.13
23 A6 cn.15
24 A5 cn.17
25 A4 cn.19
26 A3 cn.21
27 A2 cn.23
28 A1 cn.25
---
29 NC
30 NC
31 /BYTE cn.52 <--
32 A0 cn.27
33 D0 cn.3
34 D8 cn.60 <--
35 D1 cn.5
36 D9 cn.58
37 VCC cn.31,32
38 D2 cn.7
39 D10 cn.56
40 D3 cn.9
41 D11 cn.54
42 GND cn.1,2,61,62
43 VCC cn.31,32
44 D4 cn.4
45 D12 cn.53
46 D5 cn.6
47 D13 cn.55
48 GND cn.1,2,61,62
49 D6 cn.8
50 D14 cn.57
51 D7 cn.10
52 D15 cn.59
53 RDY/BSY (ready/busy) cn.12 <--
54 /OE cn.14
55 /WE cn.16
56 /WP cn.18 <--
The newly discovered pins are VPP, /BYTE, RDY/BSY, /WP, and D8-D15 (which formerly haven't been known if/where they were mapped on the datapak slot). Accordingly, the update datapak slot pinout is as so (btw. mechanically, the connector resembles a 50pin Compact Flash connector, with same 1.27mm pin pitch, but with 62 pins instead of 50 pins):
Code:
BSX Datapak Slot
1 GND
2 GND
3 D0
4 D4 (with cap to gnd)
5 D1 (with cap to gnd)
6 D5
7 D2
8 D6
9 D3
10 D7
11 A12
12 RDY/BSY (NC) (connected in BSX-BIOS cart)
13 A7
14 /RD via 33 ohm R2
15 A6
16 /WR via 33 ohm R3 (VCC in SA1)
17 A5
18 /WP (VCCed)
19 A4
20 - (in FLASH cart: via 47kohm R1 to VCC)
21 A3
22 via R4 to VCC (47kOhm) (NC in mempak)
23 A2
24 via R5 to GND (47kOhm) (NC in mempak)
25 A1
26 via R6 to GND (47kOhm) (NC in mempak)
27 A0
28 - (in FLASH cart: via 47kohm R2 to VCC)
29 A14
30 VPP (5V) (GND in SA1)
31 VCC (5V or 3.3V)
32 VCC (5V or 3.3V)
33 via R7 to VCC (47kOhm) (NC in mempak)
34 3V/5V (GNDed=5V)
35 A13
36 REFRESH to SNES.pin.33
37 A8
38 A15 rom SNES.A16 SNES.pin.41
39 A9
40 A16 rom SNES.A17 SNES.pin.42
41 A11
42 A17 rom SNES.A18 SNES.pin.43
43 A10
44 A18 rom SNES.A19 SNES.pin.44
45 SYSCK SNES.pin57 (and via R1 to SNES.pin.2 EXPAND) (100 ohm)
46 A19 rom SNES.A20 SNES.pin.45
47 /RESET (or VCC in some cart/slots)
48 A20 rom SNES.A21 SNES.pin.46
49 -
50 A21 rom SNES.A23 SNES.pin.48 (NOT SNES.A22 !!!)
51 /CS (from MAD-1A.pin1, SA1.pin81, MCC-BSC.pin23)
52 /BYTE (GNDed) (VCC in SA1 carts)
53 D12 (NC)
54 D11 (NC)
55 D13 (NC)
56 D10 (NC) ... pins here are D8-D15 (on PCBs with 16bit databus)
57 D14 (NC)
58 D9 (NC)
59 D15 (NC)
60 D8 (NC)
61 GND
62 GND
For the Itoi cart (with SA1 chip), writing to FLASH/ROM isn't supported: VPP is GNDed (no programming voltage), and /WR is VCC (no write signal at all, not even for issuing the FLASH chip detect commands). There's also another PCB with SA1 and datapak slot, but I haven't checked (the PCB photos) yet to see if they are wired the same way... there's a small chance that it could support flash writing (but it's also quite possible that the SA1 chip can't output /WR signals for the FLASH/ROM area at all). Apropos, small update to some SA1 pins:
Code:
SA1 pins
...
80 ROM./CS0.A22 (pin12=/CS in Itoi, pin1=A22 in Derby)
81 ROM./CS1 (datapak in Itoi)
82 GND?
83 VCC
84 GND?
85 GND-or-VCC ;GND in Derby, VCC in Itoi (maybe related to 1-2 rom chips)
...
The Derby cart uses pin80 as A22 (for ROMs with up to 8MByte; although the Derby ROM isn't actually that large) (and doesn't use any /CS and /OE pins; the ROM's /CS and /OE are just GNDed).
The Itoi cart uses pin80/pin81 as ROM and FLASH chip selects (and also has ROM /OE GNDed). And pin85 is wired differently, maybe switching between 8MB and 2x4MB ROM mode (although, /CS0 and A22 should be always low for first 4MB, so there's no real difference... unless the timing for outputting /CS0 and A22 is slightly different).
---
And, the MCC-BSC chip pinout (memory controller in BSX BIOS cart):
Code:
MCC-BSC
1 D7 snes.53
2 CIC1 snes.55
3 CIC2 snes.25
4 CIC3 snes.56
5 CIC0 snes.24
6 GND
7 /WR snes.54 via R8 (33 ohm)
8 /IRQ snes.18 for /FLASH.BSY
9 A23 snes.48
10 A22 snes.47
11 A21 snes.46
--
12 A20 snes.45
13 A19 snes.44
14 A18 snes.43
15 A17 snes.42
16 A16 snes.41
17 GND
18 A15 snes.40
19 A14 snes.39
20 A13 snes.38
21 A12 snes.37
22 REFRESH snes.33 why?
--
23 /ROM.CS rom.26 (aka rom.22)
24 /PSRAM.CS psram.22
25 /FLASH.WE mempak.16
26 /PSRAM.OE psram.24
27 VCC
28 GND
29 MA15 mempak.38
30 MA16 mempak.40
31 MA17 mempak.42
32 MA18 mempak.44
33 MA19 mempak.46
--
34 MA20 mempak.48
35 MA21 mempak.50
36 /FLASH.BSY mempak.12 with pullup R1
37 /FLASH.WP mempak.18
38 NC ? maybe /EXTMEM select?
39 VCC
40 /FLASH.CS mempak.51
41 /SRAM.CS mm1134.7
42 /RESET snes.26
43 SYSCK snes.57
44 /RD snes.23 via R7 (390 ohm)
The /IRQ and /FLASH.BSY and /FLASH.WP pins are certainly unexpected. And no idea what REFRESH is used for. Pin38 might be chipselect for some (uninstalled) extra memory chip, possibly sharing address lines and /OE /WE with other chips. CIC is basically just an intergrated CIC, but don't know if it could be swtched from NTSC to PAL mode (by changing one of the GNDed pins maybe), and don't know if it's somehow smashing the memory mapping (eg. when a PAL console doesn't output the expected NTSC CIC signal).
And the MCC chip's I/O ports... the (current) description in fullsnes.htm doesn't match up with the actual memory mapping, but the
http://wiki.superfamicom.org/snes/show/BS-X+MMIO seems to contain mostly correct mapping info for ports 025000h-0C5000h, the document formatting can be a bit confusing (I needed to gaze at it four about 5 hours before getting the impression that I understood what it's all about; however, the actual memory mapping is really a bit confusing hardware-wise... the mapping hardware is very simple, but nethertheless confusing because it comes up with many different bit-combinations... and for understanding that part, the superfamicom.org doc has been really helpful, I am glad that I didn't need to figure out all that stuff myself).
So far, I've verified parts of the superfamicom.org info (only checked the upper 32K halves at 8000h-FFFFh yet), and my test result did match up with the info (except one missing detail for PSRAM in HiROM mapping: The upper 32K-halves of the data at 40h-7Fh/C0h-BFh are ALSO mirrored to 00h-3Fh/80h-7Dh).
And the other MCC bits are working as so...
Code:
0:005000h FLASH Ready IRQ Flag (0=None, 1=IRQ) (write any value to acknowledge)
0:015000h FLASH Ready IRQ Enable (0=Disable, 1=Enable)
0:025000h..0C5000h see superfamicom.org
0:0D5000h Unknown (could be FLASH /WP pin... but doesn't really work as so)
0:0E5000h Write any value to apply changes to Page0:025000h..0D5000h (ONLY those 12 bits) (read: always 0)
0:0F5000h MCC Register Page (0=Page0, 1=Page1)
1:005000h..0E5000h Unknown (fifteen read/write-able bits)
1:0F5000h MCC Register Page (0=Page0, 1=Page1) (same as 0:0F5000h)
For Page0:025000h..0D5000h, reading returns to APPLIED value (not the most recently value). For 0:005000h, reading returns the IRQ flag, writing acknowledges it. For 0:0E5000h, reading seems to return always 0, and writing applies the most recently written bits. For 0:015000h, 0/1:0F5000h, and 1:005000h..0E5000h, reading just returns the most recently written value (no applying needed for those bits).
Reading page1 is slightly bugged: Upper/lower 8bits are swapped (reading 1:005000h..075000h returns what was written to 1:085000h..0F5000h, and vice-versa). That's making it somewhat impossible to read the MCC Register Page bit (or in fact, reading works fine, but without knowing its value, one cannot know if one needs to read it from 0F5000h or 075000h; and when knowing its value, then it would be pointless to read it at all).
For the /FLASH.WP pin, the pin seems to be always LOW=write protected. That protection should affected ONLY flash sectors that are flagged as protected, so writing should still work as long as there aren't any such flagged sectors, anyways, there SHOULD be a way to toggle the MCC's /FLASH.WP output pin...
I've tried setting 0:0D5000h, and also tried writing increasing numbers to the Page1 bits, but didn't manage to change /WP yet... at the moment I am running out of ideas... aside from checking if I've wired the scope to the correct pin.
The fifteen bits at 1:005000h..0E5000h are also still mysterious, some guesses would be a timeout counter for the FLASH Ready IRQ (not checked yet), or unlocking /WP (didn't seem to work out), or changing the memory mapping (though they didn't affect my mapping test for the memory areas at 8000h-FFFFh, no matter if I set all fifteen bits to all ones, or leave them at their power up default (all zeroes)).
There's a picture that describes the BS-X MMIO, with the register names (it has been rewired a little bit):
http://astamuse.com/ja/drawing/JP/0003/ ... 000012.pngFrom this japanese patent:
http://astamuse.com/ja/granted/JP/No/3615588 (On BS-X Project website there's other links to other japanese patents related to Satellaview, and I have made some discoveries concerning the satellite transmission protocol)
EDIT: I think 0D:5000 is ENRAMWR. As in: ENable psRAM WRite.
LuigiBlood wrote:
There's a picture that describes the BS-X MMIO, with the register names (it has been rewired a little bit):
http://astamuse.com/ja/drawing/JP/0003/ ... 000012.pngFrom this japanese patent:
http://astamuse.com/ja/granted/JP/No/3615588 (On BS-X Project website there's other links to other japanese patents related to Satellaview, and I have made some discoveries concerning the satellite transmission protocol)
EDIT: I think 0D:5000 is ENRAMWR. As in: ENable psRAM WRite.
That patent is interesting. It shows two different Flash memories: "Flash B" in 図６ which is the the removable data packs, and "Flash A" in 図４ which would have been built into the BS-X cartridge itself. Also, it
doesn't say anything at all about battery-backed SRAM. The diagrams showing how the memory controller works only show ROM, PSRAM, internal "Flash A" and external "Flash B".
It looks like the design of the cartridge was changed a bit after that patent was granted: the built-in Flash was replaced with battery-backed SRAM, possibly for cost reasons, but the registers for mapping the internal Flash are still there (resulting in the "hole" that's controlled by registers 09-0B--that originally would have been the internal Flash). Register 0D might be write-protect for the missing internal Flash.
ETA: got a question for nocash. Are there any pullups on the slot data pins in either the SA-1 cartridge or the BS-X cartridge? If you access the slot when there's no data pack inserted, do you get $FF or floating bus?
AWJ wrote:
That patent is interesting. It shows two different Flash memories: "Flash B" in 図６ which is the the removable data packs, and "Flash A" in 図４ which would have been built into the BS-X cartridge itself. Also, it doesn't say anything at all about battery-backed SRAM. The diagrams showing how the memory controller works only show ROM, PSRAM, internal "Flash A" and external "Flash B".
It looks like the design of the cartridge was changed a bit after that patent was granted: the built-in Flash was replaced with battery-backed SRAM, possibly for cost reasons, but the registers for mapping the internal Flash are still there (resulting in the "hole" that's controlled by registers 09-0B--that originally would have been the internal Flash). Register 0D might be write-protect for the missing internal Flash.
Every single japanese Satellaview patent are like documentations. It's just nuts. That patent even talks how the EXT port would be used for a HDD.
I've been testing the IRQ feature with IRQ vector in PSRAM... and writing PSRAM works fine with & without setting bit13. So, apparently no PSRAM-write-disable feature. There might be a SRAM-write-disable feature... though both PSRAM and SRAM are wired directly to SNES /WR line (however, the MCC could theoretically suppress chip select upon writes).
There are no pull-ups on the databus, so any open bus values are just as usually. In case of flash detection: That's done via directly addressing C0xxxxh, so the open bus value should be always C0h in that case (which also means that it won't hang in the detection-busy loop, since C0h has bit7=1="ready").
Apropos detection, that's throwing an FLASH Ready IRQ after writing the first two bytes (38h,D0h) of the detection sequence. Of course, the IRQ should be also thrown after Write/Erase commands, which would be a bit more useful - the BSX software isn't using the IRQ feature at all though.
Tested the mapping for addresses 0000h, 5000h and 6000h, too. Results are same as described on superfamicom.org, except for one thing, PSRAM in LoROM mapping is said to do this:
Code:
ALWAYS: 70-7D F0-FF * 0000-7FFF! (8 banks, mirrored)
The part about 8 banks mirrored is wrong (for LoROM mapping), it's mapping the whole 512K PSRAM in 16 banks at F0-FF (and almost the whole PSRAM in 14 banks at 70-7D). Oh, and to clarify "ALWAYS": That's meant to be unaffected by bit5,bit6 (but the other PSRAM related bits (bit2,3,4) do still affect that memory region).
And, I've been doing more tests on MCC Bit15, it does enable access to 8 hidden bits (not 15 hidden bits, as I had originally thought). Writing to normal bits does still work even the hidden-access is enabled. But if hidden-access was (already) enabled before the write, then the written bit is also stored in the hidden bit array (for whatever purpose). And reading does always return the hidden bit state while hidden-access is enabled.
More tech details below (this time I've tested that quite well, by doing about 65536 random writes (to 4bit random index with 1bit random data), and then computing the expected result, and then reading the actual state of the sixteen I/O-ports, and comparing that against the expect values, and showing an error message in case of mismatches; and going by that tests, the below pseudo code for reading/writing bits should be 100% reproducing the inner workings of the hardware).
So, here is the new updated description for the MCC chip... I've tried to use the some formatting/structure for descriptions of the separate memory regions... but I am afraid that it might still look a bit confusing...
Code:
MCC Satellaview BIOS Cart Memory Controller Chip
Basically, the MCC chip contains sixteen 1-bit I/O ports (accessed via
[00h-0Fh:5000h].bit7):
0 DATAPAK Ready IRQ Flag (0=None, 1=IRQ) (Write any value: Acknowledge)
1 DATAPAK Ready IRQ Enable (0=Disable, 1=Enable)
2 Mapping for PSRAM/EXTMEM/DATAPAK (0=LoROM, 1=HiROM)
3 PSRAM Enable for Slow Memory area (banks 00h-7Dh)
4 PSRAM Enable for Fast Memory area (banks 80h-FFh)
5 PSRAM Location Bit0 (offset within bank 00h-7Dh/80h-FFh)
6 PSRAM Location Bit1 (offset within bank 00h-7Dh/80h-FFh)
7 BIOS Enable for Slow Memory area (at 00h-3Fh:8000h-FFFFh) ;\always
8 BIOS Enable for Fast Memory area (at 80h-BFh:8000h-FFFFh) ;/LoROM
9 EXTMEM Enable for Slow Memory area (banks 00h-7Dh)
10 EXTMEM Enable for Fast Memory area (banks 80h-FFh)
11 EXTMEM Location (offset within bank 00h-7Dh/80h-FFh)
12 DATAPAK Write Enable (0=Read Only, 1=Allow Read/Write Access)
13 Unknown (isn't FLASH /WP pin... maybe EXTMEM Write Enable?)
14 Write any value: Apply changes to Bit2-13 (read: always 0)
15 Access Hidden Bits (0=Normal, 1=Access Hidden Bits/unknown purpose)
That sixteen ports are accessed via 4bit INDEX(0..0Fh) and 1bit DATA (0..1),
however, internally, the MCC chip does contain a total of 35 used bits:
lastwrite[N] ;14 bits used (bit1-13,15)
applied[N] ;12 bits used (bit2-13)
hidden[N] ;8 bits used (bit0-7)
irq_flag ;1 bit used (bit0)
Writing "[INDEX:5000h]=DATA*80h" does internally work as so:
if lastwrite[0Fh]=1 then hidden[INDEX and 07h]=DATA
lastwrite[INDEX]=DATA ;<-- this must be done AFTER the above step!
if INDEX=00h then irq_flag=0 ;<-- XXX this done also if lastwrite[0Fh]=1?
if INDEX=0Eh then applied[02h..0Dh]=lastwrite[02h..0Dh]
Reading "DATA=[INDEX:5000h]/80h" does internally work as so:
if lastwrite[0Fh]=0 and INDEX=00h then DATA=irq_flag
if lastwrite[0Fh]=0 and INDEX=01h then DATA=lastwrite[01h]
if lastwrite[0Fh]=0 and INDEX=02h..0Dh then DATA=applied[INDEX]
if lastwrite[0Fh]=0 and INDEX=0Eh..0Fh then DATA=0
if lastwrite[0Fh]=1 then DATA=hidden[INDEX and 07h]
Reading the whole 16bits after reset returns following intial values:
After Reset: 0BECh ;\initial "lastwrite" and "applied" are same
After Apply: 0BECh ;/ (bit2-3, bit5-9, and bit11 enabled)
After Hidden Access: 3F3Fh ;-3Fh on power-up, but NOT reset upon /RESET
Note: hidden[7] can be set to 1 only AFTER and WHILE lastwrite[F]=1.
Priority for overlapping memory locations
Prio Name Size Notes
1 BIOS 1024K (highest priority, if enabled)
2 PSRAM 512K
3 EXTMEM - (always open bus; no such memory chip installed)
4 DATAPAK 1024K (open bus if no datapak connected) (always enabled)
- SRAM 32K (always mapped, can't overlap with other areas)
Note: DATAPAK is on an external cartridge, size is usually 1MByte FLASH.
SRAM and I/O Port Mapping (always mapped, can't overlap with other areas)
00h-0Fh:5000h, Bit7 ;-MMC Bits 0-15 (or 16-31 when selecting 2nd page)
00h-0Fh:5000h, Bit0-6 ;-open bus (MCC chip connects only to D7)
00h-0Fh:5001h-5FFFh ;-Mirrors of above MMC Bits
10h-17h:5000h-5FFFh ;-SRAM (battery backed) (mapped in eight 4K banks)
18h-3Fh:5000h-5FFFh ;\
80h-BFh:5000h-5FFFh ; open bus
00h-1Fh:6000h-6FFFh ;
80h-9Fh:6000h-6FFFh ;/
20h-3Fh:6000h-6FFFh ;\open bus in LoROM mode, or PSRAM in HiROM mode
A0h-BFh:6000h-6FFFh ;/
BIOS Mapping (Priority 1, highest) (MCC Bits 7,8)
Bit7=1 (Slow Area) Bit8=1 (Fast Area)
00h-3Fh:8000h-FFFFh 80h-BFh:8000h-FFFFh
BIOS ROM is always mapped as LoROM (the ROM address lines are hardwired to SNES
bus, so the MCC chip can't change them).
PSRAM Mapping (Priority 2) (MCC Bits 2,3,4,5,6)
For Bit2=0 (LoROM):
Bit6-5 Bit3=1 (Slow Area) Bit4=1 (Fast Area)
0 00h-0Fh:8000h-FFFFh 80h-8Fh:8000h-FFFFh ;\in upper 32K only
1 20h-2Fh:8000h-FFFFh A0h-AFh:8000h-FFFFh ;/
2 40h-4Fh:0000h-FFFFh C0h-CFh:0000h-FFFFh ;\same in upper/lower 32K
3 60h-6Fh:0000h-FFFFh E0h-EFh:0000h-FFFFh ;/
- 70h-7Dh:0000h-7FFFh F0h-FFh:0000h-7FFFh ;-in lower 32K only
For Bit2=1 (HiROM):
Bit6-5 Bit3=1 (Slow Area) Bit4=1 (Fast Area)
0 00h-07h:0000h-FFFFh 80h-87h:0000h-FFFFh ;\
1 10h-17h:0000h-FFFFh 90h-97h:0000h-FFFFh ; only upper 32K half
2 20h-27h:0000h-FFFFh A0h-A7h:0000h-FFFFh ; of full 64K banks
3 30h-37h:0000h-FFFFh B0h-B7h:0000h-FFFFh ;/
0 40h-47h:0000h-FFFFh C0h-C7h:0000h-FFFFh ;\
1 50h-57h:0000h-FFFFh D0h-D7h:0000h-FFFFh ; full 64K banks
2 60h-67h:0000h-FFFFh E0h-E7h:0000h-FFFFh ;
3 70h-77h:0000h-FFFFh F0h-F7h:0000h-FFFFh ;/
- 20h-3Fh:6000h-7FFFh A0h-BFh:6000h-7FFFh ;-8K snippets
The 8K snippets in bank 20h-27h/A0h-A7h are taken from PSRAM offset 006000h,
016000h, .., 076000h. The same snippets are also mirrored in bank
28h-3Fh/A8h-BFh.
The four special regions (at 0000h-7FFFh and 6000h-7FFFh) are affected only by
MCC Bits 2,3,4 (not affected by MCC Bits 5,6).
EXTMEM Mapping (Priority 3) (MCC Bits 2,9,10,11)
For Bit2=0 (LoROM):
Bit11 Bit9=1 (Slow Area) Bit10=1 (Fast Area)
Bit11=0 00h-1Fh:8000h-FFFFh 80h-9Fh:8000h-FFFFh ;-in upper 32K only
Bit11=1 40h-5Fh:0000h-FFFFh C0h-DFh:0000h-FFFFh ;-same in upper/lower 32K
For Bit2=1 (HiROM):
Bit11 Bit9=1 (Slow Area) Bit10=1 (Fast Area)
Bit11=0 00h-0Fh:8000h-FFFFh 80h-8Fh:8000h-FFFFh ;\only upper 32K half
Bit11=1 20h-2Fh:8000h-FFFFh A0h-AFh:8000h-FFFFh ;/
Bit11=0 40h-4Fh:0000h-FFFFh C0h-CFh:0000h-FFFFh ;\full 64K banks
Bit11=1 60h-6Fh:0000h-FFFFh E0h-EFh:0000h-FFFFh ;/
EXTMEM would be some extra memory chip which isn't installed in existing carts.
In result, the corresponding memory area will just become open bus when trying
to enable EXTMEM.
DATAPAK Mapping (Priority 4, lowest) (MCC Bit 2) (and Bit 12: Write Enable)
For Bit2=0 (LoROM):
Always (Slow Area) Always (Fast Area)
00h-3Fh:8000h-FFFFh 80h-BFh:8000h-FFFFh ;-in upper 32K only ;1st 2MB?
40h-7Dh:0000h-FFFFh C0h-FFh:0000h-FFFFh ;-same in upper/lower 32K ;2nd 2MB?
For Bit2=1 (HiROM):
Always (Slow Area) Always (Fast Area)
00h-3Fh:8000h-FFFFh 80h-BFh:8000h-FFFFh ;-only upper 32K half of 64K banks
40h-7Dh:0000h-FFFFh C0h-FFh:0000h-FFFFh ;-full 64K banks ;full 4MB
DATAPAK is always enabled and mapped to the entire ROM area (unless it's
overlapped by higher-priority memory blocks).
For the chip pinouts... I still haven't found a way to get FLASH./WP switched HIGH, maybe it doesn't work at all?
Pin38 does seem to be EXTMEM./CE (during the memory mapping test, the pin gets low when EXTMEM is enabled, eg. when writing values in range of 0200h..7FFh to the 16bit MCC register). Still haven't tested if/where /OE and /WE exist for the EXTMEM area.
Just for the sake of listing them, here are disassembled updated BS-X BIOS functions (some are related to Memory Packs), found in SRAM dumps:
(I suggest getting bsx18.srm from the BS-X SRAMS Dumps 6-26-01 from Matthew Callis)
boot_hook:
http://pastebin.com/gGHkN4nNnmi_hook:
http://pastebin.com/Ee06uQ2qfile_start_hook:
http://pastebin.com/5Tq48Xphsend_16bit_to_port_2199:
http://pastebin.com/cUptjLYyforward_queue_to_channel_map:
http://pastebin.com/uzszyTL8execute_game_code:
http://pastebin.com/f30xytDSflash_get_and_interprete_id:
http://pastebin.com/cha8i0znflash_get_id:
http://pastebin.com/0htkP2kudetect_receiver_and_do_downloads:
http://pastebin.com/86LQZzBM
Thanks for posting that! I didn't knew about those SRAM dumps & patches yet. But, now I've found them, here:
http://superfamicom.org/blog/2011/06/bi ... ram-dumps/ - 22 dumps (bsx1..22.srm)
http://superfamicom.org/blog/2011/08/mo ... m-dumping/ - 2 dumps (bsx-a..b.srm)
So there are 24 dumps in total, bsx13.srm and bsx-a.srm are corrupt dumps (the first one seems to have bit2 of all bytes set to zero, and the other is almost completely zerofilled). That leaves 22 dumps that are (more or less) intact. I've written a small program that compares the SRAM vectors at SRAM offset 0974h..0FFFh against their normal default values, it's also checking the backup copy at 3974h..3FFFh, and the checksums for that areas. The results are:
Code:
addr [0xxxh] [3xxxh]
bsx1.srm
BAD CHECKSUM AT 0000
00000974 1150005C 1150005C
000009B0 1150175C 1150175C
00000AA8 8090D85C 80BDD85C
00000B6C 1150205C 1150205C
bsx2.srm
BAD CHECKSUM AT 0000
00000974 1150005C 1150005C
00000978 11506A5C 11506A5C
00000984 1152765C 1152765C
000009B0 11503C5C 11503C5C
00000A24 1150AA5C 1150AA5C
00000A80 1150755C 1150755C
00000AA8 8090D85C 80BDD85C
00000B0C 1152635C 1152635C
00000B10 1150855C 1150855C
00000B6C 1150455C 1150455C
bsx3.srm
00000974 1150005C 1150005C
00000978 11506A5C 11506A5C
00000984 1152765C 1152765C
000009B0 11503C5C 11503C5C
00000A24 1150AA5C 1150AA5C
00000A80 1150755C 1150755C
00000B0C 1152635C 1152635C
00000B10 1150855C 1150855C
00000B6C 1150455C 1150455C
bsx4.srm
00000974 1150005C 1150005C
00000978 11506A5C 11506A5C
000009B0 11503C5C 11503C5C
00000A24 1150AA5C 1150AA5C
00000A80 1150755C 1150755C
00000B0C 1152635C 1152635C
00000B10 1150855C 1150855C
00000B6C 1150455C 1150455C
bsx5.srm
00000974 1150005C 1150005C
00000978 11506A5C 11506A5C
000009B0 11503C5C 11503C5C
00000A24 1150AA5C 1150AA5C
00000A80 1150755C 1150755C
00000B10 1150855C 1150855C
00000B6C 1150455C 1150455C
bsx6.srm
BAD CHECKSUM AT 0000
BAD CHECKSUM AT 3000
00000974 1150005C 1150005C
00000978 11506A5C 11506A5C
000009B0 11503C5C 11503C5C
00000A24 1150AA5C 1150AA5C
00000A80 1150755C 1150755C
00000AA8 80D0D85C 8090D85C
00000B10 1150855C 1150855C
00000B6C 1150455C 1150455C
bsx7.srm
00000974 1150005C 1150005C
000009B0 1150175C 1150175C
00000B6C 1150205C 1150205C
bsx8.srm
00000974 1150005C 1150005C
00000978 11506A5C 11506A5C
00000984 1152765C 1152765C
000009B0 11503C5C 11503C5C
00000A24 1150AA5C 1150AA5C
00000A80 1150755C 1150755C
00000B0C 1152635C 1152635C
00000B10 1150855C 1150855C
00000B6C 1150455C 1150455C
bsx9.srm
00000974 1150005C 1150005C
00000978 11506A5C 11506A5C
000009B0 11503C5C 11503C5C
00000A24 1150AA5C 1150AA5C
00000A80 1150755C 1150755C
00000B0C 1152635C 1152635C
00000B10 1150855C 1150855C
00000B6C 1150455C 1150455C
bsx10.srm
00000974 1150005C 1150005C
00000978 11506A5C 11506A5C
000009B0 11503C5C 11503C5C
00000A24 1150AA5C 1150AA5C
00000A80 1150755C 1150755C
00000B0C 1152635C 1152635C
00000B10 1150855C 1150855C
00000B6C 1150455C 1150455C
bsx11.srm
00000974 1150005C 1150005C
00000978 11506A5C 11506A5C
000009B0 11503C5C 11503C5C
00000A24 1150AA5C 1150AA5C
00000A80 1150755C 1150755C
00000B0C 1152635C 1152635C
00000B10 1150855C 1150855C
00000B6C 1150455C 1150455C
bsx12.srm
00000974 1150005C 1150005C
00000978 11506A5C 11506A5C
000009B0 11503C5C 11503C5C
00000A24 1150AA5C 1150AA5C
00000A80 1150755C 1150755C
00000B0C 1152635C 1152635C
00000B10 1150855C 1150855C
00000B6C 1150455C 1150455C
bsx14.srm
BAD CHECKSUM AT 0000
00000AA8 8090D85C 80BDD85C
bsx15.srm
BAD CHECKSUM AT 0000
00000974 1150005C 1150005C
000009B0 1150175C 1150175C
00000AA8 8090D85C 80BDD85C
00000B6C 1150205C 1150205C
bsx16.srm
00000974 1150005C 1150005C
00000978 11506A5C 11506A5C
000009B0 11503C5C 11503C5C
00000A24 1150AA5C 1150AA5C
00000A80 1150755C 1150755C
00000B0C 1152635C 1152635C
00000B10 1150855C 1150855C
00000B6C 1150455C 1150455C
bsx17.srm
bsx18.srm
00000974 1150005C 1150005C
00000978 11506A5C 11506A5C
00000984 1152765C 1152765C
000009B0 11503C5C 11503C5C
00000A24 1150AA5C 1150AA5C
00000A80 1150755C 1150755C
00000B0C 1152635C 1152635C
00000B10 1150855C 1150855C
00000B6C 1150455C 1150455C
bsx19.srm
00000974 1150005C 1150005C
00000978 11506A5C 11506A5C
00000984 1152765C 1152765C
000009B0 11503C5C 11503C5C
00000A24 1150AA5C 1150AA5C
00000A80 1150755C 1150755C
00000B0C 1152635C 1152635C
00000B10 1150855C 1150855C
00000B6C 1150455C 1150455C
bsx20.srm
00000974 1150005C 1150005C
000009B0 1150175C 1150175C
00000B6C 1150205C 1150205C
bsx21.srm
00000974 1150005C 1150005C
00000978 11506A5C 11506A5C
00000984 1152765C 1152765C
000009B0 11503C5C 11503C5C
00000A24 1150AA5C 1150AA5C
00000A80 1150755C 1150755C
00000B0C 1152635C 1152635C
00000B10 1150855C 1150855C
00000B6C 1150455C 1150455C
bsx22.srm
00000974 1150005C 1150005C
00000978 11506A5C 11506A5C
000009B0 11503C5C 11503C5C
00000A24 1150AA5C 1150AA5C
00000A80 1150755C 1150755C
00000B10 1150855C 1150855C
00000B6C 1150455C 1150455C
bsx-b.srm
BAD CHECKSUM AT 0000
00000974 1150005C 1150005C
00000978 11506A5C 11506A5C
000009B0 11503C5C 11503C5C
00000A24 1150AA5C 1150AA5C
00000A80 1150755C 1150755C
00000AA8 8090D85C 80BDD85C
00000B0C 1152635C 1152635C
00000B10 1150855C 1150855C
00000B6C 1150455C 1150455C
no$sns.srm - without fast boot patch
no$sns2.srm - with my own fast boot patch installed
00000974 105C965C 105C965C
00000C94 47A90014 47A90014
00000C98 06658D53 06658D53
00000C9C 0000006B 0000006B
So, there seem to be five cases (not counting my own fast boot patch):
- 0 patches
- 3 patches
- 7 patches (same as above, plus 4 new patches, and with more code in the boot_hook patch)
- 8 patches (same as above, plus one extra patch appended at end of the patch area)
- 9 patches (same as above, plus another extra patch appended at end of the patch area)
And, a lot of the dumps have a byte at offset 0AAAh corrupted (ie. destroyed the "flash_erase_entire_type1" vector at 105AA8h), and alongsides they have a bad checksum for the area at 0000h. In the bsx6.srm dump, the same issue has also crept into the backup area at 3000h, so the bios would erase all user data on next boot.
There could be a couple of reasons for that corrupted byte: A bug in the BIOS, or a bug in a fairly popular game, or some hardware glitch in the MCC memory mapper chip, or - unrelated to BSX hardware/software - it could have also happened at time when dumping the SRAMs. The AAAh does look a bit like the flash command address at C02AAAh, but I don't know if or how that could affect the SRAM byte which is mapped at 105AAAh.
Anyways, did anybody ever get the same wrong byte in emulators? Ie. for no$sns, use a hex editor to check byte at offset 0AAAh in the BSX-BIOS.SAV file in the BATTERY folder... if the byte has another value then BDh, then the byte was destroyed there too (and if you remember which BSX game you've played most recently, then you've probably found the source of that bug).
I don't know where to put it, but I've been looking at satellite broadcasting norms from back then.
For the audio capabilities of the Satellaview, I came to this conclusion: It's either 32000 Hz or 48000 Hz. Not in between.
I suspect Satellaview uses MUSE as the broadcasting protocol as it was the norm in Japan for HDTV broadcasting quite early on (they had 1080i as far back as 1994!), and in fact, most of the standard can be found in the data expected for BS-X.
- Data Transmission Protocol:
https://www.itu.int/dms_pubrec/itu-r/re ... !PDF-E.pdf- MUSE protocol document:
https://www.itu.int/dms_pubrec/itu-r/re ... !PDF-E.pdfThe so called Hardware Channel is actually called the Logical Channel (LCI), and also contains the expected Data Structure (DS), basically, let me take 0x0124 as an exemple used to access the Channel Map:
- 0x0124 into bits:
Code:
00000001 00100100
00LLLLLL DDDCCCCC
L = Logical Channel 2 (LCI2)
D = Data Structure
C = Logical Channel 1 (LCI1)
So 0x0124 is:
LCI1 = 04
LCI2 = 01
DS = 1
What is Data Structure 1? The 5-byte header found in every transmission.
The so called Transmission ID, which is Data Group Identifier 1 (DGI1), also contains in the lower 4 bit the Data Group Repetition (DGR), which indicates the number of repetitions.
I could go on and on, but it's the exact same thing. The five other bytes in other packets is actually exclusive to the Satellaview. The Satellaview hardware is quite capable, actually.
And you know what, most of the Channel Map is actually like the norm, in fact, the actual name of it is Transmission Control Data (TCD).
The so called Software Channels are actually a mix of Service Broadcaster (PV) for the 2 first bytes, and Programme Number (PR) for the two others.
Good finding! A bit nasty to see those docs after reverse-engineering the protocol, and all the abbreviations are making them harder to read than neccessary, but anyways, nice to know that those docs exist!
So, the Data Transmission Protocol doc covers the overall Channel/Packet format, and the Channel Map? I haven't spotted things like Files/Folders or Time Channels in there, so those are probably Nintendo-specific (unless I missed them, or unless they are described in some other document).
And the MUSE doc, that's looking like Video transmission, is there some relation to BS-X at all? I guess the satellite might have actually transferred both Video and other/custom data (which could be used for BS-X data/audio), though I didn't spot any notes about how/where to include custom data with the MUSE stuff. But you've probably studied the doc more carefully than me (I only had a short look at it yet).
Just found out that the digital sub-carrier NTSC system is also from Japan. Explains why MUSE and that one are similar.
The reason why I was linking to video transmission: It's mostly because the Satellaview patent mentions it and uses the sound/data transmission part as an exemple.
I even suspect that radios actually used it even if it doesn't transmit any video (maybe a still image?), after all, the Satellaview came with an AV selector, just so you could use the BS tuner to watch TV without plugging everything again.
Also, I found another PDF about the audio transmission:
https://www.itu.int/dms_pubrec/itu-r/re ... !PDF-E.pdfLook at MDS system. It's the same format as the digital sub-carrier NTSC system but this time, finally some more details, especially about the control codes!
Apropos Sound: Did anybody ever verify if the BS-X receiver unit does really connect to the external audio inputs on the SNES expansion port? It probably does so, but there's still at a small chance that the "soundlink" feature was implemented by streaming data to the APU instead of using the external audio inputs.
nocash wrote:
Apropos Sound: Did anybody ever verify if the BS-X receiver unit does really connect to the external audio inputs on the SNES expansion port? It probably does so, but there's still at a small chance that the "soundlink" feature was implemented by streaming data to the APU instead of using the external audio inputs.
Well I would love to know, but I would be surprised if it didn't. There's a PCM decoder in the Satellaview base unit, I doubt it's for nothing.
I'm annoyed though, there's still no high quality pics of the PCB on both sides.
EDIT: Here are some names and specs coming from the White Satellaview manual:
-Satellaview
DCD (Data Channel Decoder)
PCM Decoder
Data Receiver Speed: 668 kbps
-BS-X
MCC (Memory Map Controller and Security Chip) [Yes, I swear, that's the actual name]
EDIT2: I may found the key to understand how the Satellaview works.
Apparently, Hi-Vision Laserdiscs COULD work on the Satellaview for the audio. And I'm not even joking.
I found out that BS Tuners are usually what is used to decode them.
nocash wrote:
Apropos Sound: Did anybody ever verify if the BS-X receiver unit does really connect to the external audio inputs on the SNES expansion port? It probably does so, but there's still at a small chance that the "soundlink" feature was implemented by streaming data to the APU instead of using the external audio inputs.
Might be a little late for this post.... We are referring to the Satellaview base unit, correct? The expansion port audio pins do connect to an op-amp (U9 - LM324) on the PCB. Left channel (Expansion port 27) is connected to pin 14 of U9 through some RC-type circuit. Right channel (Expansion port 28) is on pin 1 of U9 in a similar fashion. Both op-amps configured as buffers. Haven't traced where inputs of op-amps go to yet.
Cool, that's still interesting & good to have it confirmed that there's really a connection to the expansion/audio pins! Did you comapre the LM324 wiring to SNES mainboard schematic? It's having LM324, too (with each channel having two opamp's in series, in lack of knowing a better name, I've called them "pre-amp" and "post-amp").
The opamp wired "as buffer" means that it has OUT and IN- shortcut with each other? That would be same as for the "pre-amp" on the mainboard (and makes sense since that satellaview "pre-amp" signal is then mixed with the snes "pre-amp" signal; and then passed to the "post-amp" on the snes mainboard).
On the SNES, the pre-amp's IN+ pin is wired via three 22K resistors (=66K) to the DAC's audio output. In the satellaview unit it's probably wired to the 64pin or 100pin chip. Ah, and/or... it might also go to one of the six "???" pins on the 38pin CN2 connector.
PS. just curious, as the LM324 is a quad opamp, and needing only two opamp's for the stereo audo... are the other two opamp's used for something, too?
Quote:
The opamp wired "as buffer" means that it has OUT and IN- shortcut with each other?
Yes. The gain should ideally be 1:1.
Quote:
Did you comapre the LM324 wiring to SNES mainboard schematic? It's having LM324, too (with each channel having two opamp's in series, in lack of knowing a better name, I've called them "pre-amp" and "post-amp").
Yes, they have similar configurations - One "pre-amp" (the buffer stage) with some RC filters and the "post-amp" (the gain stage) that has connections for mixing three separate inputs with an added transistor for muting the output. There are some differences.
I should draw up a schematic...
Quote:
PS. just curious, as the LM324 is a quad opamp, and needing only two opamp's for the stereo audo... are the other two opamp's used for something, too?
After doing some quick probing the op-amp setup appears to be
almost the reverse of what the SNES has - being that the gain stage ("post-amp") with the muting signal (I am going to assume it is a muting signal) comes prior to the buffer ("pre-amp"), the buffer ("pre-amp") then connects to expansion port.
Quote:
In the satellaview unit it's probably wired to the 64pin or 100pin chip. Ah, and/or... it might also go to one of the six "???" pins on the 38pin CN2 connector.
Decided to probe those out.
Code:
EXT_port --- Chip.Pin
23 --- Q5.Base (Collector of Q5 to /IRQ on SNES Expansion port, Emitter to GND)
29 --- U5.75
30 --- U5.74
31 --- U5.72
33 --- U5.82
34 --- U5.83
Okay, then EXT.pin23 should be an "active high IRQ input, inverted via Q5, and then passed to active low SNES /IRQ", right?
I wonder if there's another IRQ source in the base unit? Going by the BSX BIOS disassembly there isn't anything hinting on IRQs from the base unit (however, the BSX BIOS cart itself can throw Datapak IRQs).
The other five pins going to the custom DCD-BSA chip (U5) could be anything... but nice to know that they do connect to U5.
If you feel like doing more probing, there's this (yet unconfirmed) sentence in fullsnes.htm: "The U3 transceiver is probably passing databus to/from SNES, the U1/U2 drivers are maybe passing some address/control signals from SNES."
nocash wrote:
Okay, then EXT.pin23 should be an "active high IRQ input, inverted via Q5, and then passed to active low SNES /IRQ", right? I wonder if there's another IRQ source in the base unit? Going by the BSX BIOS disassembly there isn't anything hinting on IRQs from the base unit (however, the BSX BIOS cart itself can throw Datapak IRQs).
Yes. The output is of the inverter should be considered open-collector. The input (base) is pulled low by 4.7kOhm resistor. I cannot seem to find any other source of IRQ except the EXT port on the Satellaview receiver unit.
Quote:
If you feel like doing more probing, there's this (yet unconfirmed) sentence in fullsnes.htm: "The U3 transceiver is probably passing databus to/from SNES, the U1/U2 drivers are maybe passing some address/control signals from SNES."
Good observation! U1 is for PA address bus. U3 is for data bus. U2 is for control.
Code:
SNES expansion port - Resistor - IC.pin
Address bus
PA0 - 110ohm - U1.9
PA1 - 110ohm - U1.8
PA2 - 110ohm - U1.7
PA3 - 110ohm - U1.6
PA4 - 110ohm - U1.5
PA5 - 110ohm - U1.4
PA6 - 110ohm - U1.3
PA7 - 110ohm - U1.2
Data bus
D0 - 20ohm - U3.9
D1 - 20ohm - U3.8
D2 - 20ohm - U3.7
D3 - 20ohm - U3.6
D4 - 20ohm - U3.5
D5 - 20ohm - U3.4
D6 - 20ohm - U3.3
D7 - 20ohm - U3.2
Control
/PAWR - 75ohm - U2.9
/PARD - 75ohm - U2.8
EXPAND - 0ohm - U2.7 (yes, 0 ohm resistor)
/RESET - 75ohm - U2.6
other...
All "/OE" type pins on U1, U2, U3 are connected to GND. Meaning the buffers are always active, they can never be in a hi-z output state.
Pin 20 on IC U5 controls data bus direction (U3.1)
Many thanks! Then, putting it together, the connector pin-out should be as so (in left column (with the old info from byuu & your new in info in right two columns)):
Code:
BSX-EXT-Port Pinouts
1 = +5V
2 = +5V
3 = +5V
4 = +5V
5 = GND
6 = GND
7 = GND
8 = GND <----byuu-----------> <--Davey--->
9 = GND
10 = GND
11 = D6 U3.pin17 (74LS245 B2) -- U3.pin3 (A2) ;\
12 = D7 U3.pin18 (74LS245 B1) -- U3.pin2 (A1) ;
13 = D4 U3.pin15 (74LS245 B4) -- U3.pin5 (A4) ; transceiver
14 = D5 U3.pin16 (74LS245 B3) -- U3.pin4 (A3) ;
15 = D2 U3.pin13 (74LS245 B6) -- U3.pin7 (A6) ;
16 = D3 U3.pin14 (74LS245 B5) -- U3.pin6 (A5) ;
17 = D0 U3.pin11 (74LS245 B8) -- U3.pin9 (A8) ;
18 = D1 U3.pin12 (74LS245 B7) -- U3.pin8 (A7) ;/
19 = /PAWR U2.pin11 (2nd 74LS541 Y8) -- U2.pin9 (A8)
20 = GND
21 = /PARD U2.pin12 (2nd 74LS541 Y7) -- U2.pin8 (A7)
22 = GND
23 = IRQ (inverted via Q5, then passed to SNES /IRQ)
24 = GND
25 = PA1 U1.pin12 (1st 74LS541 Y7) -- U1.pin8 (A7)
26 = GND
27 = PA0 U1.pin11 (1st 74LS541 Y8) -- U1.pin9 (A8)
28 = PA2 U1.pin13 (1st 74LS541 Y6) -- U1.pin7 (A6)
29 = ? U5.pin75 (DCD-BSA)
30 = ? U5.pin74 (DCD-BSA)
31 = ? U5.pin72 (DCD-BSA)
32 = /RESET U2.pin14 (2nd 74LS541 Y5) -- U2.pin6 (A5)
33 = ? U5.pin82 (DCD-BSA)
34 = ? U5.pin83 (DCD-BSA)
35 = GND
36 = GND
37 = GND
38 = GND
The PA0..PA2 address lines alone aren't useful, but there's probably a "select" signal on one of the five DCD-BSA chip pins (getting triggered when the upper bits in PA3..PA7 have a certain value, ie. for eight bytes somewhere in the Port 21A0h..21BFh area).
Hmmmm, and the other four DCD-BSA pins might be a SPI bus with /CS,CLK,DTA.IN,DTA.OUT (assuming that Port 2198h might go to some external serial-bus hardware).
EXPAND isn't forwarded to the connector. NB. in general, EXPAND can be a "general purpose signal from the cartridge", but, with satellaview cartridges it's having a fixed purpose: EXPAND is always wired to SYSCK via 100 ohm (as so in BSX BIOS cart, and BSX carts like Itoi/Derby, and also in Nintendo Power flashcarts (making them theoretically BSX-compatible)).
Quote:
EXPAND isn't forwarded to the connector. NB. in general, EXPAND can be a "general purpose signal from the cartridge", but, with satellaview cartridges it's having a fixed purpose: EXPAND is always wired to SYSCK via 100 ohm (as so in BSX BIOS cart, and BSX carts like Itoi/Derby, and also in Nintendo Power flashcarts (making them theoretically BSX-compatible)).
That is interesting. Assuming SYSCK is an abbreviation of "System Clock"?
The only other source of a clock signal is from the 18.432 MHz oscillator paired with the VCO (Voltage Controlled Oscillator U7). This frequency appears to be a common frequency from doing a quick search.
According to
Wikipedia:
Code:
UART clock (10×1.8432 MHz); allows integer division to all common baud rates. Also allows integer division to 48 kHz (384×48 kHz), 96 kHz, and 192 kHz sample rates used in high-end digital audio.
DaveyPocket wrote:
That is interesting. Assuming SYSCK is an abbreviation of "System Clock"?
The only other source of a clock signal is from the 18.432 MHz oscillator paired with the VCO (Voltage Controlled Oscillator U7). This frequency appears to be a common frequency from doing a quick search.
Yes, SYSCK should be short for "System Clock". Though "Memory Access Clock" might be a better name (as far as I know, that "clock" signal varies for slow/fast memory accesses, during the "/PAxx" accesses it should be clocked at 3.58MHz).
The 18.432 MHz might be whatever needed to tick the receiver hardware, probably matched to the satellite's bitrate.
LuigiBlood wrote:
Data Receiver Speed: 668 kbps
MCC (Memory Map Controller and Security Chip) [Yes, I swear, that's the actual name]
That 668kbps doesn't match too well to 18.432MHz though. But maybe it's meant to be 668kbps "excluding packet headers" (or "excluding error correction info", if there's been such a thing used).
If "bps" stands for
bits per second for all data+audio channels then... that seems a bit slow (not really suitable for uncompressed audio broadcasts).
MMC being something like "Memory Controller & Cicurity" sounds just right (it does memory mapping, and has a CIC in it).
nocash wrote:
LuigiBlood wrote:
Data Receiver Speed: 668 kbps
MCC (Memory Map Controller and Security Chip) [Yes, I swear, that's the actual name]
That 668kbps doesn't match too well to 18.432MHz though. But maybe it's meant to be 668kbps "excluding packet headers" (or "excluding error correction info", if there's been such a thing used).
If "bps" stands for
bits per second for all data+audio channels then... that seems a bit slow (not really suitable for uncompressed audio broadcasts).
MMC being something like "Memory Controller & Cicurity" sounds just right (it does memory mapping, and has a CIC in it).
Honestly something's not right but I think 668kbps is just data and does not count the rest but it's really weird.
It's the manual saying it though. But it doesn't fit how it works via Digital NTSC subcarrier data speed...
EDIT: Also, this may be worth reading:
http://forum.lddb.com/viewtopic.php?f=25&t=6569Putting aside my own ignorance on how things kind of work...
Quote:
I stumbled across this when looking for anything related to the MN88821:
Screenshot of diagramIt was in an application note document of reference designs of other Panasonic devices. That forum thread you linked, it appears the conclusion is that the data going into the Satellaview base unit from the BS tuner is simply 1s and 0s (as far as the physical characteristics of the signal). My original concern was that the signal going into the Satellaview receiver was not demodulated entirely (being that the tuner would bring the signal down to some intermediate frequency, then pass this to other devices). I came to this conclusion as I noticed the Satellaview had a voltage controlled oscillator, something that is often used in a PLL circuit in radio receivers (I have limited knowledge on the subject, just remember from DSP and Telecomm. theory courses I took at one point).
Speaking of the 668kbps bit rate, it seems that this is
nearly half of the bit rate used in the audio signal transmission (1.35 Mbps / 2 = 675 kbps). Not sure if there is any relation, just thought I would state an observation.
Also, as a reminder, japanese Satellaview patents describes the process of the whole thing very very well.
More translated pictures here:
http://imgur.com/a/Nq35LThey're from this patent:
https://astamuse.com/ja/published/JP/No/1995007481I also have a list of patents on
https://bsxproj.superfamicom.org/links.htmBasically, MN88821 seems like it gets the RAW data and only takes the PCM audio, and sends the data portions to the DCD-BSA chip managing the data decoding.
Double posting, just to give an update about Satellaview register $2197.
Since we got a new dump, which is Wario's Woods Event Version 2, something was up.
You could set the radio ON or OFF. The kind of stuff that's very explicit how it is done.
Radio ON: Clear bit7 of $2197
Radio OFF: Set bit7 of $2197
It was already figured out, but it's nice to have some confirmation like this. It literally does nothing else.
LuigiBlood wrote:
Double posting, just to give an update about Satellaview register $2197.
Since we got a new dump, which is Wario's Woods Event Version 2, something was up.
You could set the radio ON or OFF. The kind of stuff that's very explicit how it is done.
Radio ON: Clear bit7 of $2197
Radio OFF: Set bit7 of $2197
It was already figured out, but it's nice to have some confirmation like this. It literally does nothing else.
This register bit might enable/disable the two transistors in the audio-amp section of the receiver unit (if this has not already been discovered) to disable the sound going into the SNES. I will verify.
DaveyPocket wrote:
This register bit might enable/disable the two transistors in the audio-amp section of the receiver unit (if this has not already been discovered) to disable the sound going into the SNES. I will verify.
Considering you can write also to every other bit and returns them just fine, I don't know what's the point of the others.
LuigiBlood wrote:
Radio ON: Clear bit7 of $2197
Radio OFF: Set bit7 of $2197
Thanks, good to know! I had only figured out that it was somehow related to powerdown and/or soundlink.
So it seems to be simply soundlink related (assuming that the "radio" is the same as the "soundlink" feature).
Here are two photos of a BSC-1J5M-01 with the Datapak connector removed, for reference.
(Needed the connector for something, figured I’d photograph the board)
A photo of the SameGame character cartridge PCB. Fullsnes.htm seemed to be missing verified info on these, so uploading if it's of any help.
nocash wrote:
LuigiBlood wrote:
Radio ON: Clear bit7 of $2197
Radio OFF: Set bit7 of $2197
Thanks, good to know! I had only figured out that it was somehow related to powerdown and/or soundlink.
So it seems to be simply soundlink related (assuming that the "radio" is the same as the "soundlink" feature).
I actually didn't say it much, but bit 0 of $2194 does enable the stream registers. In fact, I heard even a static sound when I enabled it (when SPC700 is unmuted... which I did).
Reading $218B (or $2191), because it isn't initialized properly, reads garbage, and the data is ORed at $218D (or $2193), that's done no matter what... but when I read it when $2194.0 is set, it does read once and then resets itself to 0x00. But when it isn't, when that bit is unset, it does not reset. That bit is simply the one that enables stream registers.
sanmaiwashi released a specialized SRAM dumper for Superufo Pro 8 just a few days ago so here's another fresh BS-X SRAM dump incoming.
This one's got a few SRAM patches too but I'm unable to tell if they differ from the previously discovered ones.
The player's got a ton of money and items with interesting descriptions and dialog boxes.
Maybe worth of translating, since the file seems to have lots of save data from different games.
Thanks for the dump! Concerning SRAM Patches, it seems to be the newest version: with 9 patches, as found in "bsx3.srm".
The checksum is okay (and the byte at offset 0AAAh isn't corrupted, unlike as in a handful of other dumps).
And the game positions, you have something at 13E4h-13FFh, which was NOT known to be used by any games yet.
Many of the other addresses are used by two or more games, so it's hard to tell if a dump contains game positions from one of those games - or from yet another unknown game.
One mention about the header of Memory Pack contents:
Assuming 32-bit little endian:
Code:
FFB2h 4 Program Type
- 0x???????? = 65C816
- 0x00000100 = BS-X Script Tokens
- 0x00000200 = SA-1 (Itoi Bass Fishing No. 1)
Shigesato Itoi's Bass Fishing No. 1 literally just boots the content. If you can rewrite the Memory Pack you can actually mess with real SA-1 hardware
LuigiBlood wrote:
Code:
FFB2h 4 Program Type
- 0x???????? = 65C816
- 0x00000100 = BS-X Script Tokens
- 0x00000200 = SA-1 (Itoi Bass Fishing No. 1)
Is this the correct address? All mempak images I checked just now had the byte 00 at 7FB2/FFB2h.
Commercial games seem to have the first character of the release code (e.x. ZBSJ) at that address.
LuigiBlood wrote:
Code:
FFB2h 4 Program Type
- 0x???????? = 65C816
- 0x00000100 = BS-X Script Tokens
- 0x00000200 = SA-1 (Itoi Bass Fishing No. 1)
Nice finding. I had spotted the [7FB3h]=02h check somewhere in Itoi - but didn't knew what it was intended for. Are there any existing games/datapaks using that feature?
From what I can see, it's checking the byte at 7FB3h only. So it should work for LoROM only. And it should work with any "xxxx02xxh" value.
And if the 02h byte is there... then it's just booting the file as normal 65C816 code (which may then use SA-1 hardware if it wants to (provided that the cart does really contain SA-1 hardware), or leave the SA-1 stuff unused if it doesn't need it), right?
blurayno wrote:
Is this the correct address? All mempak images I checked just now had the byte 00 at 7FB2/FFB2h.
Commercial games seem to have the first character of the release code (e.x. ZBSJ) at that address.
It is. Satellaview Content does not use the header the same way as commercial cartridge games.
nocash wrote:
Nice finding. I had spotted the [7FB3h]=02h check somewhere in Itoi - but didn't knew what it was intended for. Are there any existing games/datapaks using that feature?
From what I can see, it's checking the byte at 7FB3h only. So it should work for LoROM only. And it should work with any "xxxx02xxh" value.
And if the 02h byte is there... then it's just booting the file as normal 65C816 code (which may then use SA-1 hardware if it wants to (provided that the cart does really contain SA-1 hardware), or leave the SA-1 stuff unused if it doesn't need it), right?
We don't have any content that uses this feature yet.
I assume there must be some kind of check at first to make sure it isn't Itoi booting it and simply tell the player "Please insert the Memory Pack into Itoi Bass Fishing cartridge" or something like that.
LuigiBlood wrote:
blurayno wrote:
Is this the correct address? All mempak images I checked just now had the byte 00 at 7FB2/FFB2h.
Commercial games seem to have the first character of the release code (e.x. ZBSJ) at that address.
It is. Satellaview Content does not use the header the same way as commercial cartridge games.
My bad. The value you gave was a little endian dword and I wasn't paying enough attention on what I was reading and looking at...
According to patent
JP3734532B2Here is the full Time Channel format (including header AND using official terms):
Code:
Offset - Size (in bytes) - Description
0x00 - 1 - Data Group ID 1 (upper 4 bits) / Data Group Repetition (lower 4 bits)
0x01 - 1 - Data Group Link (bit7) / Data Group Continuity
0x02 - 3 - Data Group Size
0x05 - 1 - TYPE
0x06 - 1 - DGN
0x07 - 3 - Address
0x0A - 1 - Second
0x0B - 1 - Minute
0x0C - 1 - Hour (0-23)
0x0D - 1 - Day of Week (1-7) [1 = Monday, 7 = Sunday]
0x0E - 1 - Day
0x0F - 1 - Month
0x10 - 2 - Year
0x12 - 2 - Unused (Preliminary)
0x14 - 2 - CRC [Does not count in the Data Group Size]
Also, difference between time at 1.1.0.8 and 1.2.0.48:
- 1.1.0.8 is an absolute time. (1.1.X.X are all BS-X related, so it makes sense)
- 1.2.0.48 is relative to the start of the broadcast. (1.2.X.X are all game related)
So I've done a bit of research about Satellaview register $2198. While I did notice about the serial number being found, I admit I didn't try to find the nature of all the BIOS functions dedicated for it.
And eventually I found something in the Satellaview patents. Because Nintendo is nice to the people who reads those, they actually put the ID of chips used for a bunch of things, and all of them did correspond to what we got so far.
So I found that $2198 talks to a EEP-ROM chip manufactured by Seiko under the ID of "S-2913CR". While I did not find this specific chip, I found "2913C", and it fits the description completely, it is a 16-bit Serial EEPROM, manufactured by SEEQ Technology. A datasheet can be found here:
http://datasheet.datasheetarchive.com/o ... 047710.pdfWhen I tried to read the EEPROM's content, I needed bit7 to be set. This 100% corresponds to the read opcode.
Therefore, according to this information, I'll use nocash's documentation as a base and change the BIOS function names, while checking the disassembled routines that I got:
Code:
Port 2198h (serial port 1 to SPR-BSA EEPROM) (unused)
1059B8 read_multiple_eeprom [In: A = 6bit address, Out: read 16 bytes to [DB:0000h+Y]]
1059BC read_single_eeprom [In: A = 6bit address, Out: A]
1059C0 write_verify_multiple_eeprom [In: A = 6bit address, X = amount of words, [D+00h+Y] = data]
1059C4 write_verify_single_eeprom [In: A = 6bit address, X = word]
1059C8 write_word_eeprom [In: A = 6bit address, X = word]
1059CC write_verify_first_word_eeprom [In: X = word] (kinda weird, it does Write All opcode, but only writes and checks one word)
1059D0 erase_word_eeprom [In: A = 6bit address]
1059D4 erase_all_eeprom
1059D8 verify_address_20h_to_3Fh_eeprom [In: X = word, Out: Carry flag (if set = wrong, if clear = verified)]
1059DC verify_single_eeprom [In: A = 6bit address, X = word, Out: Carry flag (if set = wrong, if clear = verified)]
1059E0 program_enable_eeprom
1059E4 program_disable_eeprom
1059E8 send_byte_eeprom [In: A = byte]
1059EC wait_eeprom_ready
And because of that, I'm suspecting that $2199 has nothing to do with any audio output. I'm suspecting that $2199 is what manages that was supposed to be the hard drive for the EXT port which records audio and data as well, as the patent suggests.
Good finding!
What is the "serial number being found"? Is there a serial number stored in the eeprom... and is it used for something?
Now that you've discovered the SPR-BSA being a Seiko S-2913CR chip... there's also a Seiko datasheet for it
http://datasheet.datasheetarchive.com/o ... 144153.pdf - so no need to use the Seeq datasheet.
The read/write multiple functions don't do anything with 7E0000h. The source/dest address in RAM is in Y register.
For read_multiple it's using [DB:0000h+Y], with DB needed to be a "lorom" bank, as it's also used for [DB:2198h].
For write_multiple it's using [D+00h+Y], with the direct page... I guess it should be zero (or maybe the related functions survive other values).
If the D, DB, Y registers are all zero then it will use address 000000h, which will actually mirror to RAM at 7E0000h.
So well, there's an EEPROM and the BSX-BIOS has functions for accessing it - but I don't know of any games that would use that functions (nor does the BSX-BIOS itself use that functions (nor do any known games access 2198h directly)). If I didn't miss something: The EEPROM is there, but it was never ever actually used?
For the other serial port at 2199h: That port is actually used: by the BSX-BIOS, by BSX-BIOS patches, and by Itoi, and by BS Dragon Quest 1, and in respect to data in the Town Status packet. Being used that often, I have some doubts that it was used for any kind of yet unreleased expansion hardware.
I would have assumed that it goes to the MN88821 chip (there's a datasheet for a similar chip, which has a serial port). You do have a BSX unit, don't you? What happens when executing the 2199h reading functions? Does it return any data - despite of not having a HDD or whatever attached at the EXT port?
Or if it goes to the EXT port, if you attach an oscilloscope, a logic analyzer, a multimeter, or a bloody LED... can you see a pin getting toggled when toggling the 2199h clock bit by software? Going by DaveyPocket's findings, the five candidates for serial or other unknown features would be EXT pins 29, 30, 31, 33, 34.
The serial number I was talking about that's in the EEPROM is something like this that I found:
Code:
BSA00??????? A4h FFh FFh FFh and so on...
Each byte is repeated twice on each 16-bit word. The ??????? matches my Satellaview's serial number.
Also I only gave a quick look and I admit that while Direct Bank and stuff crossed my mind I didn't quite bother...
I have never seen anything that uses 2198h so far. It's just there.
2199h is totally used, that I definitely saw. And considering the EEPROM access was treated as a bus in the patent, there's also a EX Bus, linked to the EXT port. There's potentially other registers directly linked to it as well according to that.
When I use it, I got it to return E00000h. Any command does not seem to change that. Also, unsetting 2194h.bit0 actually disables that register (alongside the streams that are stuck). Not 2198h however. I'll try to check with a LED at some point.
Okay, there is a serial number under the satellaview...
Is that the same thing as the barcode on this picture:
https://static.giantbomb.com/uploads/or ... view1.jpeg ?
Well, that isn't under the satellaview, but maybe they've plastered it with the same barcode everywhere.
I am afraid nobody has ever photographed the bottom side of the satellaview. Only found a photo of the SNES's bottom:
http://www.nintendoworldreport.com/media/27664/4/2.jpg which is also having a similar barcode. My own PAL/SNES has barcode "UPnnnnnnnn"
So, those barcodes seem to be two letters and eight digits, the last digit probably being a barcode checksum - and when removing that last digit - the remaining seven digits are your "???????" string in ASCII, then followed by a non-ASCII byte with value A4h, and the rest of the eeprom is filled with FFh bytes?
Wished I would have a satellaview, so I could check myself, I've only the BIOS cartridge, but not the base unit.
Getting E00000h from 2199h might be some sort of data, or garbage... if the "E" is in the first some bits, then it might come from some floating pin that drops to low during reading for whatever reason, if it's so then you might get values like F80000h or C00000h when outputting the serial CLK at different speeds.
Getting E00000h shouldn't happen, at least not when sending the usual 2199h init sequence (and then repeatedly reading the 24bit data).
Itoi wants the MSB (first bit) to be zero. If it doesn't get that after repeated reading, then it does do some timeout and disables the Satellaview option in the game main menu.
Either there is hardware in the console (and it does output another value than E00000h at some point).
Or, Itoi is trying to detect add-on hardware (and passes okay if the open-bus pin drops to zero at some point).
EDIT: Also, compared to the 24bit read BIOS function, Itoi is writing chip select, clock and data.out at least slightly differently, so BIOS might be bugged?
EDIT: Speaking of bugs, the "send_16bit_to_port_2199" (1059B0h) function works only if DB points to a low rom bank (for accessing DB:2199h), one of the BIOS patches in SRAM is fixing that.
nocash wrote:
EDIT: Also, compared to the 24bit read BIOS function, Itoi is writing chip select, clock and data.out at least slightly differently, so BIOS might be bugged?
I'm at work right now so can't check either version, but I seem to remember the BIOS reading $2199 on the opposite clock edge as when reading $2198 - is that changed in the Itoi version?
nocash wrote:
Okay, there is a serial number under the satellaview...
Is that the same thing as the barcode on this picture:
https://static.giantbomb.com/uploads/or ... view1.jpeg ?
Well, that isn't under the satellaview, but maybe they've plastered it with the same barcode everywhere.
I am afraid nobody has ever photographed the bottom side of the satellaview. Only found a photo of the SNES's bottom:
http://www.nintendoworldreport.com/media/27664/4/2.jpg which is also having a similar barcode. My own PAL/SNES has barcode "UPnnnnnnnn"
Then let me solve this problem myself:
https://imgur.com/a/hdHKqwfI've put all the photos that I took of my Satellaview unit, with a photo of the bottom of mine that I took just now.
nocash wrote:
So, those barcodes seem to be two letters and eight digits, the last digit probably being a barcode checksum - and when removing that last digit - the remaining seven digits are your "???????" string in ASCII, then followed by a non-ASCII byte with value A4h, and the rest of the eeprom is filled with FFh bytes?
Yes. That's exactly right.
nocash wrote:
Getting E00000h from 2199h might be some sort of data, or garbage... if the "E" is in the first some bits, then it might come from some floating pin that drops to low during reading for whatever reason, if it's so then you might get values like F80000h or C00000h when outputting the serial CLK at different speeds.
To be honest, I had a different reaction before but it was because my tester was programmed a little sloppily, but it does use the BS-X BIOS' functions.
nocash wrote:
EDIT: Also, compared to the 24bit read BIOS function, Itoi is writing chip select, clock and data.out at least slightly differently, so BIOS might be bugged?
EDIT: Speaking of bugs, the "send_16bit_to_port_2199" (1059B0h) function works only if DB points to a low rom bank (for accessing DB:2199h), one of the BIOS patches in SRAM is fixing that.
I guess I didn't actually think of that patch when I tested it. I should try again. Though since sd2snes got a new firmware and everything and I don't feel like switching, I'll rewrite my Memory Pack to see about that, and change the SRAM for the sake of having updates.
nocash wrote:
Getting E00000h shouldn't happen, at least not when sending the usual 2199h init sequence (and then repeatedly reading the 24bit data).
Itoi wants the MSB (first bit) to be zero. If it doesn't get that after repeated reading, then it does do some timeout and disables the Satellaview option in the game main menu.
Oh wow, so the option doesn't show up without the base unit attached ...
I wonder if SD Gundam G Next has a similar limitation. I've never been able to actually observe a difference using the data pack no matter how I emulated it. My base unit emulation is junk at the moment. Only really emulate the town cart registers well so far, and basic channel data for the flashable paks (disabled for mask ROM paks.) Well, that and SA1 SuperMMC banks 4-7 rerouting to the BS memory pack.
Also curious if any released Satellaview images actually need these SRAM patches to be playable. That'll pose a tricky problem for emulation. Only thing that immediately comes to mind is bundling BS-X Town SRAM files into BS Memory Pack gamepaks (ZIP archives.) Probably not legal to ship SRAM files with copyrighted code with emulators.
Here are my findings on the EEPROM functions... read_multiple has X=num_words, read_word returns data in X (the dataword is also in A, but that's unintended, and A is in 8bit mode at that time), write_all does fill the memory by the dataword value (said so in datasheet), verify_multiple checks if the upper half of memory is filled by value X, used after write_all and erase_all, but that verify is bugged (the POP opcode smashes the zeroflag from preceeding CMP opcode) (verifying only the upper is probably related to /PROTECT pin, which might write protect the lower half... depending on how it's wired).
Code:
1059B8 eeprom_read_multiple ;in: A=addr6bit, X=num_words, DB:Y=dest, out: [DB:0000h+Y+(0..X*2-1)]=data ;DB must be a lorom bank
1059BC eeprom_read_word ;in: A=addr6bit, out: X=word (and A=word, too, M is in 8bit mode though) ;DB must be a lorom bank
1059C0 eeprom_write_multiple ;in: A=addr6bit, X=num_words, D+Y=src, out: cy=1=error
1059C4 eeprom_write_word ;in: A=addr6bit, X=word, out: cy=1=error
1059C8 eeprom_internal_write_word ;in: A=addr6bit, X=word (internal subfunction for write) (without program_enable and without verify)
1059CC eeprom_write_all ;in: X=word/fillvalue, out: cy=1=always (bugged, should be cy=1=error)
1059D0 eeprom_erase_word ;in: A=addr6bit, out: cy=1=error ;note: erase is NOT needed before writing
1059D4 eeprom_erase_all ;out: cy=1=always (bugged, should be cy=1=error) ;note: erase is NOT needed before writing
1059D8 eeprom_internal_verify_multiple ;in: X=expected_fill_value_for_upper_half_of_eeprom, out: cy=1=always (bugged, should be cy=1=error) ;BUGGED
1059DC eeprom_internal_verify_word ;in: A=addr6bit, X=expected_word, out: cy=1=error (internal subfunction for write/erase)
1059E0 eeprom_internal_program_enable ;in/out: nothing, A,Y=unchanged (internal subfunction for write/erase)
1059E4 eeprom_internal_program_disable ;in/out: nothing, A,Y,P=unchanged (internal subfunction for write/erase)
1059E8 eeprom_internal_send_byte ;in: A=byte (internal subfunction for sending commands)
1059EC eeprom_internal_wait_busy ;in/out: nothing (internal subfunction for write/erase)
As far as I know the only two cartridges that use ports 21xxh for the satellaview base unit are Derby96 and Itoi, ie. SD Gundam G-Next shouldn't be affected by having or not having the base unit.
For 2199h, during transfer, the select pin is same in Itoi and BIOS. The transfer starts up a bit differently, and the data.out pin is inverted (but it might be just a dummy value when reading). I would think it goes to the CCS, CCK, CTLI, CTLO pins shown here
viewtopic.php?f=12&t=14493&start=30#p204015 the MN88831 datasheet uses the same names (except that it lacks CTLO, which might exist only on the bigger MN88821 chip).
EDIT: The EEPROM Content, using the barcode from the photo... gives a checksum byte
Code:
00h 5 ASCII "BSA00" ;="BSA00"
05h 7 ASCII "nnnnnnn" (from "BSnnnnnnnx" barcode/sticker) ;="1076682"
0Ch 1 Checksum byte (all ASCII bytes added together) ;=A4h
0Ch 33h Empty (FFh-filled) ;=FFh's
I just tried Itoi Bass Fishing on my SFC + Satellaview setup: The Satellaview option is not selectable. So I suspect my tool actually works just fine.
EDIT: Made sure if Itoi was reading $2196 or not. It doesn't so I'm guessing it only cares about that $2199 and $2194.
EDIT2: For some reason, I never checked if there was any more Satellaview registers... and I did find something new:
Code:
$219A always returns 10h
$219B to $219F always returns 00h
$21A0 to $21FF is open bus.
EDIT3:
I rocked out the multimeter and tried to find the pinout of each chip, this is what I have so far:
https://docs.google.com/spreadsheets/d/ ... cTcRQ/editEDIT4: seems I got the full pinout of the Satellaview EXT port... and seemingly it's directly connected to the SNES EXT port bus, and some pins of the DCD-BSA chip.
So what I thought of $2199 is most likely wrong. $2199 is most likely MN88821 serial access.
Maybe $218A is EXT port serial port? Maybe $2195? And then there are a few direct EXT port access (which only PA0, PA1 and PA2 is directly connected to it for some reason).
You have made a tool that makes the Satellaview option non-selectable in Itoi?
Hmmm google docs, this link works slightly better with browsers
https://docs.google.com/spreadsheets/d/ ... /htmlview# but it's showing only U1 pinouts, the links to U2, U3, etc. show up, but clicking them doesn't do anything. Or well, I can see them on an android toy computer. For CN2, you seem to have missed EXT.pin23 = IRQ, see
viewtopic.php?f=12&t=14493&start=30#p203608Of the five unknown EXT port pins, one should be a select signal for the 8-byte PA0-PA2 space somewhere at 21A0h-21FFh, and one should be the LED signal shown in the patent, the other three might be whatever, my best guess would be some CLK signals, I don't remember anything hinting on a serial port on the EXT connector.
Okay, so the SPR-BSA EEPROM has VCC/GND same as the "DIP" pinout in Seiko/Seeq datasheet (as opposed to the "SMD" pinouts). That, despite of SPR-BSA being a SMD chip, so the chip is at least slightly customized concerning pinout/package. The pins other than VCC/GND might be following the "DIP" pinout, too, if /PROTECT is not connected (or GNDed) then the lower half of the EEPROM should be write-protected (going by datasheet).
The extra features for SD Gundam G-NEXT with extra ROM PAK are hidden among the standard features, this page shows what to look for
https://satellaview.org/1996/sd-gundam- ... -pack-2-15 (requires some paranoid https revision). The ROM PAK works okay in no$sns, it seems to be mapped via port [2223h]=84h, ie. pad the 1.5MB cart ROM to 4MB size, then append the ROM PAK at the end of the file.
nocash wrote:
Hmmm google docs, this link works slightly better with browsers
https://docs.google.com/spreadsheets/d/ ... /htmlview# but it's showing only U1 pinouts, the links to U2, U3, etc. show up, but clicking them doesn't do anything.
Crappy browser, or crappy JavaScript somewhere. All of these tabs/pages (both in the original link and the htmlview'd link, work fine in Google Chrome on Windows and OS X -- I tested 'em).
nocash wrote:
You have made a tool that makes the Satellaview option non-selectable in Itoi?
No, I meant that the tool reads registers and serial registers, so while E00000h may seem weird, and uses the BS-X BIOS functions, Itoi does seem to have a similar output since the Satellaview option isn't selectable.
Yeah sorry I use Google Docs because it's faster for me to make something and share quickly.
I'd say the SPR-BSA chip is customized since it does say SPR on it and the ID on it does not correspond to a known EEPROM, at least in my case.
Also while I made this Google Sheet, I don't want to pretend I'm good at this (and I did try to find /IRQ, but I guess I didn't get to the right inverter? The PCB is really really small).
I guess I somehow missed the posts about the EXT port here.
EDIT:
Just tested SPR-BSA EEPROM writing. The first half does not do anything but I've successfully written and erased a byte for the second half.
More register findings using my recently purchased Satellaview:
- CN2 pin 29 (U5 pin 75) goes low when accessing $xxA0 through $xxA7
- CN2 pin 30 (U5 pin 74) goes low when accessing $xxA8 through $xxAF
- CN2 pins 33 and 34 (U5 pins 82 and 83) are respectively latched from writing bits 1 and 0 of $2197 (both high on powerup)
- CN2 pin 31 (U5 pin 72) is EXLED, $2194 bits 2-3 control behavior (active high, active low or ignored)
Essentially, combined with A2:0, /PARD and /PAWR, these signals map $21Ax and part of $2197 to the Satellaview EXT port.
Edit: added other pins
Edit 2: added (hopefully final) EXLED behavior
Cool, that's solving most of the remaining pins. Interesting that there are two 8-byte areas instead of only one 8-byte area.
What do you mean by "high->low when accessing $xxA0 through $xxA7"? That sounds as if it's LOW by default (eg. when accessing xxFFh), and goes HIGH for a short moment when accessing xxA0-A7? Ie. it's a active high SELECT, rather than active low /SELECT? Just asking because the latter would be more common. But then, the external IRQ pin is active high, too.
The "xx" in xxA0-xxA7 and xxA8-xxAF is unexpected, I would have thought that it triggers only on 21A0-21A7 or the like.
Hmmm, maybe that's a dirt effect that occurs when NOT using the 21xxh space; ie. the CPU might then output the same address bits to A0-A7 and also to PA0-PA7 (?)
On the other hand, for cases like DMA from ROM to WRAM, A0-A7 and PA0-PA7 would output different addresses (and in that case the satellaview base unit should see the PA0-PA7 address (as it doesn't connect to A0-A7 at all).
For EXLED, I would have assumed the CPU can switch that LED on and off... maybe via some bit in port 2194h... and maybe that works only when also setting 2194h.bit0=1 (to "power on" something)?
Or, as pin33 and pin34 are working as general purpose outputs... maybe one of that bits was supposed to be used as EXLED output?
Or maybe EXLED was meant to be an input... allowing external hardware to inject some signal that blinks the ACCESS LED in the base unit? Yeah, that would make sense for an internal HDD drive (if the drive doesn't have its own LED, but outputs a signal for LED on the front panel). Do you think it'd be risky to try to inject a high/low level to the pin and check if it affects the LED (or if it blows the chip; to avoid that, maybe insert a 1K resistor instead of directly wiring it to GND or VCC)? When testing that, it might be also worth checking if the injected high/low level affects some bit in the 2188h-219Fh registers.
nocash wrote:
Cool, that's solving most of the remaining pins. Interesting that there are two 8-byte areas instead of only one 8-byte area.
Yeah, that's strange. It seems like just including PA3 would have been easier for mapping the same 16-byte region.
nocash wrote:
What do you mean by "high->low when accessing $xxA0 through $xxA7"? That sounds as if it's LOW by default (eg. when accessing xxFFh), and goes HIGH for a short moment when accessing xxA0-A7? Ie. it's a active high SELECT, rather than active low /SELECT? Just asking because the latter would be more common. But then, the external IRQ pin is active high, too.
No, it's active low/default high (i.e. transitions high->low->high when the access occurs).
nocash wrote:
The "xx" in xxA0-xxA7 and xxA8-xxAF is unexpected, I would have thought that it triggers only on 21A0-21A7 or the like.
Hmmm, maybe that's a dirt effect that occurs when NOT using the 21xxh space; ie. the CPU might then output the same address bits to A0-A7 and also to PA0-PA7 (?)
A7:0 and PA7:0 are indeed the same when only using Bus A (this is how defparam's 21fx hijacks the reset vector, for example). I did specifically confirm that accessing e.g. $80Ax also outputs those signals, though you also don't get /PARD or /PAWR when doing that.
nocash wrote:
For EXLED, I would have assumed the CPU can switch that LED on and off... maybe via some bit in port 2194h... and maybe that works only when also setting 2194h.bit0=1 (to "power on" something)?
Or, as pin33 and pin34 are working as general purpose outputs... maybe one of that bits was supposed to be used as EXLED output?
Or maybe EXLED was meant to be an input... allowing external hardware to inject some signal that blinks the ACCESS LED in the base unit? Yeah, that would make sense for an internal HDD drive (if the drive doesn't have its own LED, but outputs a signal for LED on the front panel). Do you think it'd be risky to try to inject a high/low level to the pin and check if it affects the LED (or if it blows the chip; to avoid that, maybe insert a 1K resistor instead of directly wiring it to GND or VCC)? When testing that, it might be also worth checking if the injected high/low level affects some bit in the 2188h-219Fh registers.
The CPU can control the LED with $2194, but I don't know if it requires the streams to also be enabled with bit 0 or not (but I think the only time BS-X enables the LED is when it's also downloading something).
I'm pretty sure EXLED is supposed to just be an input (see
this block diagram from the patents which has EXLED coming into the data decoder chip from the expansion port with another signal going out to the actual LED). I haven't tried wiring it up directly yet, though.
I haven't tried any tests specifically involving the other registers either, but I'd like to try playing around with the unknown ones at $2195 and $219A-9F somehow. Also, pins 33/34 are both high at first even though (according to LuigiBlood) reading $2197 initially returns 0x80, so I'm not sure if those pins are just latched separately from the actual register value when a write occurs or something.
Good to know that the select lines are active low. Yup, also noticed that they could have used PA3 instead of the second select line, guess they have planned some hardware consisting of two chips, thus needed two select lines.
Interesting that PA0-7 and A0-7 are actually same on A-Bus-only access. Hmmm, in this case (when adding your findings to BSX info in fullsnes.htm)... maybe I could mention it in the pinout chapter... but I'd rather omit it in the overall I/O description, saying "Port FFA0h and the like ARE ALSO part of the BSX I/O map - but they WON'T DO anything because they doesn't trigger /PARD and /PAWR !!!" would be a bit pointless in that place ; )
You are right, the blurry lines/arrows in the block diagram are looking as if EXLED is meant to be an input. If you test if the LED reacts to dragging the suspected EXTLED pin Low (or High) would be cool! Apropos (hope I didn't already asked that elsewhere): The Power LED and Access LED, are normal 2-pin LEDs; with only one color each? And the Power LED, is there a way to switch it on/off, or is it simply wired to VCC+GND+resistor?
If it's really initially [2197h]=80h, and if that doesn't match up with the two output pins being initially high: Maybe there are some more bits used in the same register (or in another register) for changing the pin-direction (ie. the "output=high" might be actually "input=highZ").
The power LED is controlled directly by the power supply just like the one on the actual SFC (you can see as such in one of the other patent diagrams), and the access LED is powered by one of the outputs from DCD-BSA, but they're both basically regular single-color LEDs.
Anyway, I did a quick test with pulling the pin both high and low and neither one seemed to actually affect the LED. It could be that some other register setting is required first or possibly that the pin is actually just a regular input (probably active low, it seems to be pulled up normally) readable in some register.
I'm going to do more register testing in software but first I'll have to either:
- get a new(-ish) sd2snes firmware that doesn't emulate the same registers on its own, or
- figure out why my Super UFO crashes only when trying to boot into DRAM on my Japanese SFC with the BS-X cart attached (unless I can test the same registers without having the BS-X cart attached to provide the EXPAND signal). I was going to email sanmaiwashi to see if he had any suggestions there.
edit: Register state on reset
without BS-X cart present: (reading each register once in a row)
Code:
$2188: 00
$2189: 00
$218A: 00
$218B: 9F
$218C: 00
$218D: 9F
$218E: 00
$218F: 00
$2190: 00
$2191: 9F
$2192: 00
$2193: 9F
$2194: 00
$2195: 00
$2196: 02
$2197: FF
$2198: 80
$2199: 01
$219A: 00
$219B: 00
$219C: 00
$219D: 00
$219E: 00
$219F: 00
BS-X does manually set $2197 to #$80 on startup, though. (edit: misremembered; it only sets bit 7)
Okay, after another quick test, pin 31 is EXLED after all - grounding it turns the access LED off whenever it's enabled by $2194.
Cool, then pin31 is confirmed. For the corresponding bits:
From what I know, access led is switched on via 2194h.bit2. But I don't know if it's 0=On or 1=On.
And bios does set both 2194h.bit2 and 2194h.bit3 to the same value, don't know if bit3 is also having some effect on the LED state (or on the EXLED behaviour).
Revenant wrote:
$2197: FF
BS-X does manually set $2197 to #$80 on startup, though.
Yeah, I was wondering if the "initial" value of 80h was meant to be "after reset" or "after bios init", too. However, the bios does never set it to 80h (it's accessing the register only via "read-modifyBit7-write" code). So value 80h could occur only in emulators (if they use zero as initial value), or maybe if hardware boots up with a random value (unaffected by /reset signal).
The two serial ports with "$2198: 80 and $2199: 01"... Different DATA in bit7 may be explained by the external chips, but different CLK state in bit0 is odd. Maybe it's uninitialized/random, or maybe it's initentionally done so for different external chips (but then different chip select level would have made more sense).
The unknown/unused register "$219A: 00"... the last thing I had heard was that it's always 10h, or well, maybe that depends on state of other registers.
For some registers it would be interesting to see their values when reading more than once, eg. bits 2193 might be cleared after reading (so you might see 9F,00,00,00...), on the other hand, reading 2191 might load new nonzero bits into 2193.
nocash wrote:
For some registers it would be interesting to see their values when reading more than once, eg. bits 2193 might be cleared after reading (so you might see 9F,00,00,00...), on the other hand, reading 2191 might load new nonzero bits into 2193.
I may have done a terrible job for other registers, but I can 100% already confirm that behavior. However, $2193 will NOT reset as long as $2194.bit0 is not set. Reading $2191 will set $2193 no matter what. Same for Stream 1 regs. I have also heard that setting $2194.bit0 actually makes a small static sound in my case.
nocash wrote:
Cool, then pin31 is confirmed. For the corresponding bits:
From what I know, access led is switched on via 2194h.bit2. But I don't know if it's 0=On or 1=On.
And bios does set both 2194h.bit2 and 2194h.bit3 to the same value, don't know if bit3 is also having some effect on the LED state (or on the EXLED behaviour).
Bit 2 is 1=on - sort of. I tested both bits 2 and 3 and they actually both control the LED activation behavior:
Code:
00 = LED always off
01 = LED on when EXLED is high (or disconnected)
10 = LED on when EXLED is low
11 = LED always on
The BIOS setting both at once is probably just to make sure that the "download in progress" LED indicator isn't affected by whatever an EXT port device might also be doing.
nocash wrote:
Yeah, I was wondering if the "initial" value of 80h was meant to be "after reset" or "after bios init", too. However, the bios does never set it to 80h (it's accessing the register only via "read-modifyBit7-write" code). So value 80h could occur only in emulators (if they use zero as initial value), or maybe if hardware boots up with a random value (unaffected by /reset signal).
Yeah, you're right, I was going off of (faulty) memory there. I can confirm that it is actually initialized to 0xFF on reset, though, so the two output pins on EXT defaulting to high does make sense.
I think the only registers that don't seem to be consistent after a reset are the stream prefix/data registers, but I don't know how those are exactly supposed to behave on first power-on, since I'm currently running on my Super UFO that has its own memory mapping registers overlapping with some of the ones controlling the data streams (but the UFO doesn't touch $2194, and that's initialized to 0x00, so the prefix/data ports might just be essentially returning garbage).
nocash wrote:
The two serial ports with "$2198: 80 and $2199: 01"... Different DATA in bit7 may be explained by the external chips, but different CLK state in bit0 is odd. Maybe it's uninitialized/random, or maybe it's initentionally done so for different external chips (but then different chip select level would have made more sense).
The unknown/unused register "$219A: 00"... the last thing I had heard was that it's always 10h, or well, maybe that depends on state of other registers.
For some registers it would be interesting to see their values when reading more than once, eg. bits 2193 might be cleared after reading (so you might see 9F,00,00,00...), on the other hand, reading 2191 might load new nonzero bits into 2193.
I think what LuigiBlood says about the prefix/status registers is correct - the only different thing I've noticed so far is that if a stream fails (i.e. error bits in $218B/2191), the "first packet" flag in bit 4 might not be cleared when reading the prefix bytes. But it's probably unpredictable if an invalid stream will even cause that bit to be set in the first place; sometimes when booting via the Super UFO or sd2snes then I get constant prefix/data bytes of 0x9F and 0x00 for stream 1 but 0x8F and 0x80 for stream 2, or things like that, and the values stay the same even when repeatedly resetting the console.
I'm going to do some more different tests with the other registers soon (esp. $2199-$219F), though I don't really have a way to tap any of the pins on the DCD-BSA chip which probably limits what else I'll be able to figure out for now.
<copy paste from my own forum:
https://board.byuu.org/viewtopic.php?f= ... 166#p57166>
I rewrote my BS Memory flash emulation to use type 1 cartridges instead of type 2 cartridges, since only type 1 cartridges actually exist. I may or may not bother with type 2. Kind of annoying to emulate something that's impossible to test.
I ran my own hardware tests to clarify some things, and discovered some new information.
First, the MCC has two types of write-enable for the BS memory carts.
$0c5000.d7 enables the query interface
$0d5000.d7 enables the write command (the one that clears bits)
If you don't set $0c5000.d7 and commit the change (by writing $0e5000.d7), then all writes to the BS memory cart will fail, and all reads will be the ROM data. It will act exactly like a ROM cartridge. If you do set it, then you can write values to it to query status registers, vendor information, erase data, and write bytes.
If you don't *also* set $0d5000.d7, then all writes (type 1 flash commands $10 and $40) will fail. However, *erases still work!* even if you don't set $0d5000.d7. Both the 64K page erase, and the entire-chip erase work regardless of $0d5000.d7.
Obviously, if $0c5000.d7 is clear, there's no way to trigger a write, so for write commands to work, you must have both $0c5000.d7 and $0d5000.d7 set.
Next, $0f5000.d7 is truly bizarre. If I write $0f5000.d7=1, then I can read any one $0x5000 status register. The second time I try and read one, the entire SNES deadlocks until I reset it. If I write $0f500.d7 before every read, then I read back the same exact values I normally get from $0x5000.
This does not appear to be an extra page of extended bits, at least not on my system.
I still don't emulate $01500.d7 IRQs. Unsure how exactly those work.
Okay, now for the flash carts themselves ... there are no two-byte commands as with bsnes-plus.
Writes act on the current mode, and then change the mode, but only when the low 16-bits of the address are all zeroes. So $c00000 and $cf0000 will work for writing $75 to get vendor information, but $c08000 will not. I'm guessing in LoROM configuration that it's the decoded low 16-bits? But I didn't verify that.
So with this setup, if you write $10 to write a byte, or $20 to erase a page, or even $a7 to erase the entire chip (which ostensibly doesn't need another byte of data), nothing will happen until the next write, which doesn't care about the address (other than $20 using the upper eight bits instead of the data bus bits to determine which page to clear.)
nocash mentioned $97 being some kind of alternate full-chip erase mode ... it does nothing here, whereas $a7 does.
Revenant had $40 as an alternate write command, and I can confirm that does indeed work. Weird.
$10, $20, $40, $a7 writes seem to kick the mode to $70 automatically. Games seem to do it anyway, but it doesn't appear necessary to do so.
Reading from mode $70 always returns a single status byte, no matter what the address is.
Reading from $71 always returns zeroes, except in three cases that I can see:
(address&$ffff) == 2
(address&$ffff) == 4
(address&$ffff) == 6
The last one is usually zero, but if perform an erase command, the value changes around. I've seen $70 and $8f from it.
I'm going to guess that (address&$ffff) == 0 is something too, but so far it only returns zeroes for me.
Reading from mode $75 returns vendor information. In this case, it looks at the low 8-bits of the address.
(address&$ff) == 0 ? return 'M'
(address&$ff) == 2 ? return 'P'
(address&$ff) == 4 ? return 4 (unknown purpose)
(address&$ff) == 6 ? return type << 4 | log2(size >> 10);
All other addresses return ... noise. I tried four different BS memory packs, and all four had different values in every single byte, and the values never changed. The values are not ROM values, and they're not open bus.
Here, see if you can make any sense out of it:
Code:
[Cartridge 1] => 4d 50 04 1a 00 00 20 31 22 99
c0ff00 4d 1c 50 16 04 ef 1a 7d 00 bf 00 6e 20 eb 31 05
c0ff10 22 73 99 52 f6 cb 4a d3 64 fb 7e 78 1a d8 20 27
c0ff20 55 cd 4c e4 f7 58 2f df 27 d7 75 a8 e6 3a b0 28
c0ff30 f4 9b 2e 21 fe fa c8 3c 99 af a6 9f f0 ff 13 a2
c0ff40 50 b6 fa e4 af ad 0f 30 2c 9d b3 7d 73 96 ee 85
c0ff50 00 34 14 a2 77 63 70 79 23 33 f5 64 d7 e1 8a e8
c0ff60 e9 94 68 30 b8 6d ce 71 ba ff e7 64 93 82 9e 7b
c0ff70 12 29 5a 8c 6a cf e5 bc 6a 98 bb 4d 8f a0 9d 61
c0ff80 8e e9 36 a6 f0 28 7b 8a 4b df d9 6b 49 06 12 82
c0ff90 68 0e 15 a4 db 9d ab 5d 6c 35 b3 37 75 0e 46 60
c0ffa0 11 e7 19 1b 2e 7d 99 ac bf 0e 9a 8f 3a e2 98 07
c0ffb0 94 ec 4a e3 e2 fb f2 7e 16 1e 7b fd 11 2a 03 f6
c0ffc0 d5 00 20 89 9e 32 0d bd 75 69 ed fa 2f dc 06 01
c0ffd0 78 2b df 4b 3f 3f 1e d4 de 7a 93 5a 1e 43 51 ae
c0ffe0 fc d2 20 21 54 f3 0b e7 ff ef 8b dd 93 52 d6 c5
c0fff0 32 66 30 b8 6c 5f 0a f3 83 e5 7f f8 0f f3 2e 64
[Cartridge 2] => 4d 50 04 1a 00 00 20 41 12 33
c0ff00 4d e7 50 d5 04 ef 1a df 00 6f 00 ff 20 59 41 94
c0ff10 12 2c 33 b3 47 6d 73 ed 6c d6 ff fd 48 00 13 03
c0ff20 03 a8 a3 63 ed 69 bf de ef fd fe ff de ce a5 12
c0ff30 b2 33 a0 a9 e7 ef 9f f1 4b 7d de 7f fc 40 20 51
c0ff40 b1 64 03 82 a9 7f df da ca e7 ba f7 34 5a c0 44
c0ff50 a0 26 1f 2e b7 0b 3b a5 bb bb 35 be b0 d6 41 48
c0ff60 1a 47 16 4c 97 c3 53 fa fa 7e df ff b0 1e a6 60
c0ff70 f6 84 a4 0f 1f ad ed 3f ef ff af e9 1c 80 34 80
c0ff80 87 98 8a 14 fb 7d f6 fa 2e 3d ef fc c1 d3 93 65
c0ff90 55 05 ed 47 bd e3 17 1b 3b fb 7d 75 39 64 4d 61
c0ffa0 02 c6 28 50 e6 df a9 7e fe 7f e3 fd 2b 43 af 04
c0ffb0 1c 3c 67 92 69 ab 7a bd 7f af a5 f7 03 cb 80 de
c0ffc0 4a 58 21 48 fe 73 87 bf 7d 6e ff fd 08 84 5a 30
c0ffd0 18 07 92 69 9f fd ff 75 7a cf ef 8e 48 d2 e5 5a
c0ffe0 1a 83 60 74 4f de 72 b7 bf f3 fb fb 09 81 a3 69
c0fff0 38 64 57 94 ed 7a f1 fd bf ff e3 fb 82 15 e2 94
[Cartridge 3] => 4d 50 04 1a 00 01 40 41 70 59
c0ff00 4d ab 50 7a 04 0b 1a fe 00 34 01 fc 40 f6 41 02
c0ff10 70 89 59 89 fe 97 bd bd 9f 54 df 7a bc 8a c6 bf
c0ff20 03 94 f9 88 3d d3 f7 fd 36 7e e7 fe cf 6f ed 19
c0ff30 93 94 1e 6a ac 0f fb d9 53 72 c7 fe f7 92 db 0e
c0ff40 0e 2a 1b 23 5b d4 9b fd be fb 67 5c 24 d1 7f 56
c0ff50 b8 44 c6 2e 13 a5 fe ef e5 d7 ad 3a 7b 3e d7 03
c0ff60 02 bf dc e1 f4 6b f7 d9 31 56 3a 58 21 30 9e 62
c0ff70 bd b0 ea 59 79 7b 34 6c 77 ba 27 fd a1 1a 98 91
c0ff80 3a 3e 9c 3b d9 ac b7 e7 76 cf 2c fd fc 3f f9 1b
c0ff90 2e aa 32 ed 9e ce b7 1c 39 fb f3 b7 3f 58 05 46
c0ffa0 09 93 17 80 6f e6 f6 04 ef ed 0f bf c1 26 7b 74
c0ffb0 84 a3 36 b2 86 0a b4 fd 6b b3 85 f6 54 12 60 94
c0ffc0 5f 91 3a 78 a4 03 d7 18 ef 89 5c 7f 1d 47 2c 20
c0ffd0 bd 57 f2 00 da a2 1e 87 7f f0 e0 b9 2d 35 2b ab
c0ffe0 70 6f c5 7b 9d 90 17 5d bd f7 dd fe 01 6a 3d fd
c0fff0 1e f3 ac 8b df ba b6 dc 27 c6 ab 79 35 98 87 ac
[Cartridge 4] => 4d 50 04 1a 00 91 90 70 31 03
c0ff00 4d 42 50 ca 04 bc 1a 7f 00 fe 91 ed 90 6a 70 28
c0ff10 31 90 03 9c c2 ff 5f 47 dd fb 7e bd 01 00 cc 02
c0ff20 37 22 5c 40 5a f7 e7 f5 df fe fe d7 10 00 4b 94
c0ff30 95 8a f5 0e 65 de eb fd ba 3b fe ff b7 4c e0 28
c0ff40 23 46 46 31 ee ff ff fb ff ff ff f9 4f 18 92 54
c0ff50 e8 03 40 00 f7 66 7f 3d ff d7 eb 5f 00 32 12 40
c0ff60 a2 29 95 80 97 bb fe 77 fe de 3f eb 07 60 98 c8
c0ff70 83 a9 64 a0 fd 6e ff ed fe ff eb fb 25 36 c8 48
c0ff80 a9 38 c2 44 5d 79 7b 7f ff 77 f7 ff 44 1b 62 9d
c0ff90 a8 02 04 60 ff df ff f9 bf b7 de 3d 22 b2 25 02
c0ffa0 1b c3 23 04 f7 6f 9d bf bf ff fd 9f b2 e3 eb 3a
c0ffb0 40 0f 4b 06 fd 2f eb ec ff f7 bf f9 84 47 06 94
c0ffc0 02 00 67 50 ff ef ce bb fb bf fb 3f 4e 38 62 04
c0ffd0 56 60 5b 11 fe a9 bf 9f f7 ab 8f de b1 40 0c ea
c0ffe0 26 70 15 05 ef be ee eb ff ff fd f3 08 08 5a a0
c0fff0 60 46 81 04 f7 ff e2 3e ff 5f ff fb 80 a2 e6 61
One pack had an RPG Tsukuru 2 save on it, and I get the exact same 256 values back even after I later erased the cartridge. If it was reading data from the BS-X Town cart ROM/SRAM/PSRAM, then it'd be the same values for all cartridges, but it isn't.
Again note it only looks at address&$ff. You can read from $c00000 or $c1fe00 and get the same data. If you try and read from $c0ff02, it starts from address 2, not 0, so it's not a counter.
More fun ... there's a ton of mirrors of the three readout modes.
$70 mirrors to $76 - $7d, and I also saw it at $6d and then stopped because what the hell >_<
$71 mirrors to $72 - $74, and probably to more areas.
I didn't try and enumerate all 256 values because some of them are write/erase commands.
I'll need to write a fancier test that tries all 256 values and maps out what they do, I guess.
byuu wrote:
Next, $0f5000.d7 is truly bizarre. If I write $0f5000.d7=1, then I can read any one $0x5000 status register. The second time I try and read one, the entire SNES deadlocks until I reset it. If I write $0f500.d7 before every read, then I read back the same exact values I normally get from $0x5000.
This does not appear to be an extra page of extended bits, at least not on my system.
Strange. ikari's and nocash's notes already differ about what that bit does (according to nocash it's the extra page, according to ikari "strange things happen, apparently the MCC assumes A23-A19 = 0 when set"). Are you able to tell if writing it does anything to the actual memory mapping?
I can try to test this on my BS-X cart as well, now that I actually own one.
re: the flash memory packs, for reference,
here's a datasheet for Sharp flash chips that pretty much everything in existing implementations is based on (largely via LuigiBlood/nocash/etc's documentation).
byuu wrote:
So with this setup, if you write $10 to write a byte, or $20 to erase a page, or even $a7 to erase the entire chip (which ostensibly doesn't need another byte of data), nothing will happen until the next write, which doesn't care about the address (other than $20 using the upper eight bits instead of the data bus bits to determine which page to clear.)
$20 and $a7 (according to the sheet) supposedly requires writing $d0 once to confirm the erase, plus a second time if a suspend command was issued previously (at least that's how I'm reading it). But for $20, if you write $d0 more than once, the address only seems to matter for the first write.
byuu wrote:
nocash mentioned $97 being some kind of alternate full-chip erase mode ... it does nothing here, whereas $a7 does.
$97 is called "upload status bits", which sounds like it's supposed to latch the initial state of the block status registers after powering up (and requires another $d0 write to any address to confirm), but it's not clear if you're supposed to do that every time you read the registers, or just the first time.
byuu wrote:
Revenant had $40 as an alternate write command, and I can confirm that does indeed work. Weird.
$40 and $10 are listed respectively as "word/byte write" and "alternate word/byte write". No idea if there's supposed to be a difference between the two, but they're listed right next to each other in the list of commands and have identical descriptions.
byuu wrote:
$10, $20, $40, $a7 writes seem to kick the mode to $70 automatically. Games seem to do it anyway, but it doesn't appear necessary to do so.
Writing $b0 ("erase suspend/resume") is also supposed to do this.
byuu wrote:
Reading from mode $70 always returns a single status byte, no matter what the address is.
Reading from $71 always returns zeroes, except in three cases that I can see:
(address&$ffff) == 2
(address&$ffff) == 4
(address&$ffff) == 6
The last one is usually zero, but if perform an erase command, the value changes around. I've seen $70 and $8f from it.
I'm going to guess that (address&$ffff) == 0 is something too, but so far it only returns zeroes for me.
Reads from $70 are the "compatible status register", which has to do with the basic read/write/erase commands (the datasheet calls these the "compatible mode commands", as opposed to the other chip-specific ones).
For $71, addresses 2 and 4 are the block status register (for a specific block of addresses) and the global status register. 0 and 6 are both listed as "reserved", so I have no idea what the value read from 6 is supposed to be. Can you tell if it matters whether the erase is still in progress when reading that one?
byuu wrote:
Reading from mode $75 returns vendor information. In this case, it looks at the low 8-bits of the address.
(address&$ff) == 0 ? return 'M'
(address&$ff) == 2 ? return 'P'
(address&$ff) == 4 ? return 4 (unknown purpose)
(address&$ff) == 6 ? return type << 4 | log2(size >> 10);
All other addresses return ... noise. I tried four different BS memory packs, and all four had different values in every single byte, and the values never changed. The values are not ROM values, and they're not open bus.
Writing $72 supposedly swaps between two different pages of this, though I believe/assume only page 0 is actually used by BS-X. I assume any byte that BS-X doesn't actually explicitly check is just garbage.
There are also several commands for writing to these buffers, and according to
these notes writing $38+$d0 will reset their contents, but I'm not sure if that means losing the "M P " signature and size info, etc. and that command isn't even listed in the datasheet... (the info there about $08 and $38 possibly only applies to type 3/4 carts if any even exist?)
byuu wrote:
More fun ... there's a ton of mirrors of the three readout modes.
$70 mirrors to $76 - $7d, and I also saw it at $6d and then stopped because what the hell >_<
$71 mirrors to $72 - $74, and probably to more areas.
This doesn't seem right... at least going by the same Sharp datasheet, $72, $74, and $77 are all separate commands.
Okay, going at this more tonight ...
$38 isn't documented in the data sheet, and it also doesn't complete until you write $d0 after.
It has two effects, actually: it writes the vendor info into the current page buffer, *and* it toggles the current page buffer after that. So if you do this after a reset:
$c00000 = #$38
$c00000 = #$d0
$c00000 = #$75
read($c00000..c000ff)
You will get data from the second page, but it won't have the magic markers in memory because you're reading from the wrong page. Write $c00000 = #$72 between #$d0 and #$75 to read back the current page you modified.
Quote:
Detection Sequence
[C00000h]=38h, [C00000h]=D0h ;request chip info part 1
delay (push/pop A, three times each) ;delay
[C00000h]=71h ;enter status mode
repeat, X=[C00002h], until (X.bit7=1) ;wait until ready
[C00000h]=72h, [C00000h]=75h ;request chip info part 2
FOR i=0 to 9, info[i]=BYTE[C0FF00h+i*2], NEXT ;read chip info (10 bytes)
[C00000h]=FFh ;somewhat bugged, see below ;terminate status mode
Which is exactly what the BS-X BIOS is doing here.
...
Now that I know how to write to the page buffer, I can fill it with $00, $55, $aa, $ff, and clearly see what bytes $38d0 is writing:
$00 = #$4d
$02 = #$50
$04 = #$04
$06 = #$1a
$08 = #$00
$0a = #$91
$0c = #$90
$0e = #$70
$10 = #$31
$12 = #$03
Or with a few cartridges ... good thing Matthew Callis sent me a box of them:
Code:
#1 => 4d 50 04 1a 00 91 90 70 31 03
#2 => 4d 50 04 1a 00 00 20 31 22 99
#3 => 4d 50 04 1a 00 00 70 31 85 78
#4 => 4d 50 04 1a 00 00 10 50 24 43
#5 => 4d 50 04 1a 00 01 40 41 70 59
#6 => 4d 50 04 1a 00 00 20 41 12 23
#7 => 4d 50 04 1a 00 00 10 41 20 64
#8 => 4d 50 04 1a 00 02 80 31 22 83 (FLASH marking: 9517 5 OA)
#9 => 4d 50 04 1a 00 00 10 62 62 39 (FLASH marking: 9517 5 OA)
The values are static for each cart. The first four (or five) digits are always the same, and then the rest change.
Do you see it? These are unique serial numbers.
...
The page buffers themselves are really, really cool. You can fill them with bytes using:
$c00000 = #$74
$c000xx = #$data
<repeat>
And there's even a sequential write command that I need to try out.
Once you have them, you can write out all or a portion of the page buffers directly to the flash memory, and it works even where bits were zero. So it probably combines an erase with writes or something.
#1 is the odd one out, #$91 where the rest are #$00,#$01,#$02. So I doubt these are even strictly sequential.
...
The page buffers themselves are volatile, they decay to random data after a time of no power to the cartridges. It's not immediate though. If you quickly turn the system off and back on, you'll still have your old data. It decays to high entropy values (at least compared to SRAM/DRAM chips on the base SNES.)
The intelligent identifier (activated by writing #$90) is another readout mode of this chip.
It returns the following data on all cartridges:
Code:
c00000 b0 a8 63 20 20 20 20 20 20 20 63 20 20 20 20 20
c00010 20 20 63 20 20 20 20 20 20 20 63 20 20 20 20 20
...
cffff0 20 20 63 20 20 20 20 20 20 20 63 20 20 20 20 20
A better way to describe it:
Code:
if(ReadMode == IntelligentIdentifier) {
if((uint24)address == 0) return 0xb0; //only appears once in the entire address space
if((uint24)address == 1) return 0xa8; //only appears once in the entire address space
if( (uint3)address == 2) return 0x63; //repeats every eight bytes: (address&7)==2
return 0x20; //fills in all remaining bytes
}
This is supposed to return the manufacturer and device ID#s.
According to the PDF, the LH28F016SANS-70 has:
Manufacturer ID# 0089H
Device ID# 66A0H
In 8-bit mode (which is what our BS Memory Cassettes operate in), these IDs are shortened to:
Manufacturer ID# 89H
Device ID# A0H
The device ID would obviously be different for the Sharp LH28F800SUT-ZI, but the manufacturer ID would not.
On a whim, Nintendo's manufacturer ID is 0553H (Bluetooth), 057EH (USB), 12E1H (PCI).
I found a match here:
http://www.idhw.com/textual/chip/jedec_spd_man.htmlSharp has a manufacturer ID under 10110000 (B0), which begs the question why the datasheet says their manufacturer ID is 0089H.
The datasheet indicates we can only read out the low bytes of the IDs in 8-bit mode, and yet I have four unique values.
I guess the only way to be sure will be if someone can desolder the flash memory from a BS Memory Cassette, wire it up in 16-bit mode, and read out the full 16-bit IDs for us. Until then, this emulation will have to do.
Uh ... remind me again why we're looking at the datasheet for the LH28F016SANS-70, when the datasheet for the LH28F800SU is readily available?
https://www.dataman.com/media/datasheet ... F800SU.pdfManufacturer ID# 00B0H (B0H in 8-bit mode)
Device ID# 66A8H (A8H in 8-bit mode)
https://pastebin.com/raw/YpNrrxYP(note: I forgot to increment the erase counters on page writes to flash.)
Okay, with the exception of the critical emulation of commands taking time to complete, this should be a complete implementation of the Sharp LH28F800SUT-ZI in 8-bit configuration.
For a quick overview:
The block lock flags don't appear to do anything. Whether they are set or not, I can both write and erase the flash data.
On power-up, all of the block lock flags read as set. There are 16-bits of non-volatile storage inside the flash chip that hold their last written state. Executing $97d0 after a reset will load those bits in for you.
Locking a page with $77d0 will update both the readable BSR lock flag, and the non-volatile bit. Erasing a page via $20d0 or $a7d0 is the only way to clear the lock flags once they've been set.
Erase commands can execute whether $0d5000.d7 is set or not, but write commands will fail if that's not set.
No commands work if $0c5000.d7 is set. Current theiry is that $0c5000.d7 is internal to the MCC and controls whether it sends /WR to the BS Memory Cassette, and $0d5000.d7 is likely /WP to the BS Memory Cassette.
$0c is a really cool command that erases a block for you, and will then write out a 256-byte block to flash. It actually takes a 16-bit value, so you can write out 65536 bytes of data to the flash if you wanted, it'll just keep repeating. The address portion of $0c is the same for both the flash write and page read, so eg if you write to $c25037 - $c25038, it will write from the page buffer $37 to $38, not from page buffer $00 to $01.
$38d0 writes out a unique serial# per BS Memory Cassette to $80,$0a,$0c,$0e,$10,$12 of the page buffer. Along with the Nintendo-specific information at $00,$02,$04,$06. The rest of the active page buffer bytes are untouched.
$80 abort seems to set the GSR sleeping flag. I have no idea how to clear the sleeping flag for either $80 abort or $f0 sleep.
$90 gives you the low-byte of the vendor ID, then the low-byte of the product ID, then some noise. It fills the entire 256-byte page.
$96(01,02,03,04) says something about ready-busy mode in the PDF, but I don't understand it. It may not even be observable from the SNES, if it's just pulsing pins?
$99d0 is a truly fascinating command ... it writes #$06 to page address $06, and #$00 to page address $07, which is constant with all of my BS Memory Cassettes. It also writes 32-bit block erase counters, which are non-volatile, in a weird way to memory.
The block counter starts at 0x80000000, and increments by one with every block erase command. I don't have any never-erased packs, so I couldn't tell you if it starts at 0x00000000 or not.
There's sixteen of these 32-bit counters, one for each block, written into memory locations at:
(block&3)*8 + (block>>2)*0x40, eg:
00-03, 08-0b, 10, 18, 40, 48, 50, 58, 80, 88, 90, 98, c0, c8, d0, d8-dc.
I have no idea how this would change if you had a 16mbit or 32mbit flash. There's room in there for them (up to 64 blocks, so 32mbit), but if I were to try and emulate it without having one of these non-existent carts, I'd have to guess where the rest of block counters went.
$e0 is a very interesting command, the only one like it, and it screws with simplistic attempts at a command queue. You write $e0, then the low byte count, then the high byte count, then you keep writing address:data pairs to write to the page buffer. A high byte count other than $00 is pretty dumb but, it's supported if you wanted to do that ... I don't think you an abort this one?, so don't write $ffff unless you want to do a whole lot of writing, or reset your console.
$fb is a 16-bit word write command, with some funky behavior. A0 of the second write controls whether the second and third writes are data low, data high (A0=0), or data high, data low (A0=1). The target location comes from the third address write, and instead of incrementing the address, it does a ^1.
Corrections and more information would be greatly welcome.
With the unique serial#, the non-volatile lock status bits, and the flash write counters ... I've decided to store these attributes in a BML manifest alongside the flash ROMs themselves.
Oops, major mistake on my part ... I didn't realize the flash was already FF from a previous erase command ...
The write to flash from page buffer command is a write only, not an erase + write. Realized that when I was thinking, "but wait, it doesn't write entire blocks at once ... how could it erase the blocks first, then?" >_>
So yeah, write from page buffer stores: write(address, read(address)&data)); and doesn't increment the erase counters, of course.
Amusingly, the emulation code was already correct in that case.
---
Aha, finally! Figured it out.
Okay, $0c5000.d7 works as I explained. If you set it, /WR is disconnected from the memory pack, and so it acts exactly like a mask ROM cart would.
$0d5000.d7 controls /WP on the memory pack.
So what happens is that if you set $0d5000.d7, it's like an override that forces the memory pack to always be both writable and erasable, regardless of the lock bit.
The lock bits come into play when $0d5000.d7 is low. In this case, writes and erases fail when a block is locked, but will succeed otherwise.
Once you lock a block, the only way to unlock it (that I know of) is through erasing the block. And to erase a locked block, you have to set $0d5000.d7 first.
Locking a block requires $0d5000.d7 to be set. Even if the block is already locked. If you execute this command anyway with $0d5000.d7=0, then regardless of the current lock status bit or non-volatile lock bit, it'll set CSR.d4,5 + BSR[n].d5 + GSR.d5. And if the page was already locked, it obviously remains locked.
It's an open question how the other BS-X slotted cartridges work. My guess is that without $(0c,0d)5000.d7 available (no MCC), the write protect feature is always disabled, and it will always allow commands to be sent to flash carts.
...
Also, it seems another mistake I made earlier: the $d0 terminal byte is important. $77d1 will set the block error bit and not lock the page, whereas $77d0 will indeed lock it.
Isn't 0E:5000 just a way to apply changes? Or is it that our comprehension of it was completely wrong from the start and all changes are actually instant?
Oops, sorry. Was off by one on the addresses. s/$0d5000/$0c5000, s/$0e5000/$0d5000 in the last post. Fixed it.
Also, more fun ... the theoretical LH28F032SU (32mbit flash chip) variant (well, the chip is real, the BS Memory Cart with it is not) is going to be a lot more painful to emulate properly. As was pointed out to me on Twitter, this chip is just two LH28F016SU's glued together. And of course, the LH28F016SU is *not* two LH28F800SU's glued together.
So basically what this means is that:
8mbit => $c0-cf:0000-ffff = LH28F800SU (16 x 65536 x 8-bit)
16mbit => $c0-df:0000-ffff = LH28F160SU (32 x 65536 x 8-bit)
32mbit => $c0-df:0000-ffff = LH28F160SU #1 + $e0-ff:0000-ffff = LH28F160SU #2
This changes a lot:
* a full chip erase requires $a7d0 to be sent to eg $c00000 and $e00000
* status mode changes have to be done on each chip separately
* the block erase count retrieval command will only populate 32 entries per chip
* the device ID really is going to be the same for both the 160SU and 320SU as a result
* you could technically do certain operations with one chip while the other is busy
* proper timing emulation of the flash write commands will require *two* threads instead of one
The 4mbit variant is also annoying as heck. That one's 32 x 16384 x 8-bit, so it invalidates assumptions like 64KB block sizes.
I think I'll drop support for 32mbit flash carts, and just keep 8mbit and 16mbit sizes supported.
Interesting stuff, thanks for looking into it more.
Assuming I do update my BS-X flash emulation based on this info, I'll probably try to keep supporting sizes other than 8 and 16 Mbit just because BS-X does; I guess I could just have two instances of a generic flash chip class (with either 16kb or 64kb block size) and let the existing BSXFlash class be an interface to both of them. I also currently support 2 Mbit flash, which could probably be treated as 16x16k(?)
Also, I don't think I remembered to mention this before but I did confirm that the bits in $2197 also work as (active low) inputs.
I can't believe I didn't notice this before, but the Satellaview EXT connector is nearly just an 8-bit version of the parallel ATA/IDE interface; even part of the pinout is virtually identical:
Since
the ATA-1 standard does allow for enabling 8-bit transfers, you could theoretically hook it up to such a drive and get the following register mapping (based on Table 6 in the spec):
Code:
Command block:
$21A0: data (R/W)
$21A1: error register (R) / features (W)
$21A2: sector count (R/W)
$21A3: sector number / LBA bits 0-7 (R/W)
$21A4: cylinder LSB / LBA bits 8-15 (R/W)
$21A5: cylinder MSB / LBA bits 16-23 (R/W)
$21A6: drive/head / LBA bits 24-27 (R/W)
$21A7: status + ack. IRQ (R) / command (W)
Control block:
$21A8-21AD: open bus
$21AE: status (R) / device control (W)
$21AF: drive address (R)
What's that in practical terms? Someone with a Satellaview can hook up a CF card, and have their game contain 128 GB of data?
Cool, that does in fact look very similar - and it does explain why they came up with two chip selects instead of using a fourth address line.
Hmmm, I was always thinking that PC's did have some sort of "HDD controller", but looking at the pinout, it does more seem as if they did only have some "address decoder" and did merely forward the chipselects to the actual controller in the drive.
Revenant wrote:
Since
the ATA-1 standard does allow for enabling 8-bit transfers, you could theoretically hook it up to such a drive...
Do you have some info which drives support 8bit transfers, up to which capacity, from which era?
As far as I remember somebody made a homebrew adaptor for connecting 16bit-only drives to 8bit computers using a dirty trick: It's simply leaving each second byte unused, so you get only half of the drive capacity. The advantage is that it should work with all 40pin/parallel drives, and even halved capacity should be huge for SNES standards. The downside is that one couldn't swap the drive between 8bit and 16bit computers because they'd either see each 2nd byte missing, or see garbage bytes inserted between each byte.
nocash wrote:
Do you have some info which drives support 8bit transfers, up to which capacity, from which era?
No idea about specific drives, unfortunately.
In terms of era, the standards timeline looks like:
- ATA-1 published in 1994, declared obsolete in 1999
- ATA-2 published in 1996, declared obsolete in 2001
- ATA-3 published in 1997, no longer allows 8-bit transfers
It might be safe to assume that most IDE drives made during the lifespan of the Satellaview (or at least the earlier years) could be usable in 8bit mode.
(note: I also edited my previous post since I think I had the IDE CS0 and CS1 signals the wrong way around previously)
Quote:
The CF spec requires that all compliant cards support 8-bit transfers in True-IDE mode using Set Features as you discovered. So you are guaranteed this will work for all CF cards.
Interesting. Sounds like a CF/EXT adapter would be the way to go, then, but since there's no BIOS support I have no idea what it'd actually be useful for aside from some extravagant homebrew project...
As the HDD interface is mainly consisting of an address decoder, one won't even need the BSX base unit for that, one could as well built some small circuit that decodes 21Axh, and wire it to the SNES mainboard, expansion port, or cartridge slot.
Extravagant homebrew... how about porting the unreleased Super CD BIOS to load unreleased CD games from the unreleased HDD interface instead of from the unreleased CDROM interface. And of course, for the best of best extravagancy: after finishing that homebrew project - keep it unreleased!
Story time!
Quote:
"Nintendo, for example, showed the Kittyhawk team an entertainment system they had already designed, unbeknownst to HP, with a slot for a Kittyhawk drive to be plugged in—a module that could contain many more games, with much more sophisticated graphics, than Nintendo’s conventional cartridge approach. ‘The system is all set,’ the Nintendo representative persuaded. ‘All you have to do is sell us your drive for $50.’ When White protested that the Kittyhawk’s accelerometer alone (required for shock resistance) rendered the $50 price impossible, Nintendo responded that they did not need the accelerometer— they just needed 20 megabytes at $50, cheap and simple."
Citation: Clayton M. Christensen. (2006).
Hewlett-Packard: The Flight of the Kittyhawk (A). HBS No. 606-088. Boston, MA: Harvard Business School Publishing.
Excerpt used with permission.
In reference to the
HP Kittyhawk hard drive. This hard drive was introduced in 1992, plausible that this is what was intended for the Satellaview.
For some context, the quote is from a case study on the HP Kittyhawk hard drive project from a business standpoint. The study did mention that Nintendo was a potential customer and showed interest in the hard drive after the idea of a miniature mass storage device was pitched to Nintendo marketing manager at a trade show. What 'system' the quote mentions can be up for interpretation but I am placing bets on the Satellaview.
Out of curiosity, I found a Dauphin DTR-1 tablet - an old portable touch screen MS-DOS tablet produced around 1993. It has a Kittyhawk hard drive in it. I purchased to see how the drive would fit.
Comparison of the Kittyhawk drive next to 0.01CAD inside of the Satellaview EXT bay.
Plenty of room to build a plastic enclosure around this and fit an adapter to connect the hard drive to EXT port.
I have a Microdrive or two somewhere, larger IBM models IIRC, a GB or few. They come in the CF form factor, with a CF connector. Early iPods used those.
Pretty interesting find about the Kittyhawk drives. A small form factor drive like that would have made sense for a console peripheral, but it sure is small for the amount of space in the actual bay.
I started prototyping a CF adapter board just for fun earlier this week, I might post the KiCad files / some example software to read the card whenever I start writing the latter (probably sometime next week).
This took longer to get around to doing than I meant it to, but I managed to successfully read a CF card through the Satellaview EXT port:
images hereIn doing this, I designed a passive adapter using a CF breakout board connected to my own small custom board ordered from OSHPark. The KiCAD files and small demo ROM are here:
https://github.com/devinacker/satecardStill no idea what this would ever actually be useful for, but at least it's a successful proof of concept
Well DaveyPocket got ahold of a BS Encoder (Kenwood BS-3600), and it generates BS signals from back then, and guess what?
(Warning: Loud)
https://www.youtube.com/watch?v=6mrze-Z027cIt works on the Satellaview hardware!
This will be super helpful. Hoping to find some documentation on the device actually.
Uh, what is that "Kenwood BS-3600"? It looks like a beep-generator with train-station-sized LED display... or does it have some slightly more useful features like converting incoming analog or digital audio to digital BS format? And what was that thing good for, was it for broadcast stations, or was it some sort must-have daily madness home wifi equipment?
Anyways, it's a pretty good finding for testing the satellaview hardware.
The BS-3600 is capable of encoding video and digital audio to the standards compatible with BS decoder set-top boxes. There is a built-in function generator to test the audio channels. It has the capability of accepting external audio input from an external analog-to-digital converter (which I do not have). It might be capable of encoding auxiliary data but I am unaware as I do not own documentation for this device. The BS-3600 seems to be intended for manufacturing/repair/testing of BS-related equipment, definitely not intended for the consumer market.
What pinout do you have on the digital audio input? It might be some standard stuff, for example, most PC cdrom drives did have some digital serial output connector, and I guess they should work without PC, when just attaching a power supply to the drive and then pressing the play/stop button.
Sound Journal for Lovers info:
So far the only software I found out to use both Stream 1 & 2 of Satellaview.
Uses Software Channel 1.2.2.145 - 1.2.2.150 to download image data (album covers, artist photo, etc) to Memory Pack for a selection of tracks at a time (about 2 or 3 tracks it seems).
Meaning that it downloads the images for the first few tracks, then once all played, downloads the next ones, and so on.
There are some image data in the current dump in the latter half of Memory Pack. (It downloads just like a regular download in BS-X it seems, maximum size is 512 KB however)
...Also found out of a Memory Pack emulation bug that way so at least it was not in vain.
https://github.com/devinacker/BSFlashManager
I started working on a tool over the weekend for viewing/modifying Memory Pack contents. Has the ability to try to detect & recover deleted files as well, though I haven't really tried it with every known dump or anything to really test the file detection heuristics yet.
Can you provide a pre-compile version? I have a great interest in testing your program
Sure, the releases section has a prebuilt version for Windows:
https://github.com/devinacker/BSFlashManager/releases
Thank you for the link, I made some test, this works very well on the real hardware, what do you think you bring as eventual option for the futur version?
https://github.com/devinacker/BSFlashMa ... /tag/0.2.0Built a new release - now if you have the INL-Retro programmer you can use it to quickly dump/inspect physical memory packs over USB. I may add support for other tool options (e.g.
Roswell, my own homebrew dumping solution), but right now I'm currently limited to what I actually have sitting on my desk...
I have a few more memory packs coming in the mail soon though, so I'm hoping to record a short demonstration or something.
