BS-X Satellaview Datapak's

[Tamanegi_taro]

I just dumped vendor info off my packs.
All my packs are Type 1 with 8M memory（０ｘ１A) too.

[LuigiBlood]

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.

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

[byuu]

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.

[nocash]

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: Select all

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: Select all

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: Select all

  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: Select all

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: Select all

  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)).

[LuigiBlood]

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.png

From 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.

[AWJ]

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.png

From 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?

[LuigiBlood]

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.

[nocash]

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.

[nocash]

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: Select all

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: Select all

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.

[LuigiBlood]

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/gGHkN4nN
nmi_hook: http://pastebin.com/Ee06uQ2q
file_start_hook: http://pastebin.com/5Tq48Xph

send_16bit_to_port_2199: http://pastebin.com/cUptjLYy
forward_queue_to_channel_map: http://pastebin.com/uzszyTL8
execute_game_code: http://pastebin.com/f30xytDS
flash_get_and_interprete_id: http://pastebin.com/cha8i0zn
flash_get_id: http://pastebin.com/0htkP2ku
detect_receiver_and_do_downloads: http://pastebin.com/86LQZzBM

[nocash]

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: Select all

 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).

[LuigiBlood]

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.pdf

The 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: Select all

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.

[nocash]

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).

[LuigiBlood]

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.pdf

Look 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!

[nocash]

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.