nesdev.comhttp://forums.nesdev.com/ BS-X Satellaview Datapak'shttp://forums.nesdev.com/viewtopic.php?f=12&t=14493 Page 2 of 8

 Author: Tamanegi_taro [ Sun Jul 10, 2016 5:48 am ] Post subject: Re: BS-X Satellaview Datapak's I just dumped vendor info off my packs.All my packs are Type 1 with 8M memory（０ｘ１A) too.

 Author: LuigiBlood [ Fri Jul 22, 2016 9:58 am ] Post subject: Re: BS-X Satellaview Datapak's 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

 Author: byuu [ Fri Jul 22, 2016 10:15 am ] Post subject: Re: BS-X Satellaview Datapak's 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.

 Author: LuigiBlood [ Fri Aug 19, 2016 7:56 am ] Post subject: Re: BS-X Satellaview Datapak's 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.

 Author: AWJ [ Fri Aug 19, 2016 9:06 am ] Post subject: Re: BS-X Satellaview Datapak's 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?  Author: LuigiBlood [ Fri Aug 19, 2016 9:18 am ] Post subject: Re: BS-X Satellaview Datapak's 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.  Author: nocash [ Fri Aug 19, 2016 3:36 pm ] Post subject: Re: BS-X Satellaview Datapak's 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.  Author: nocash [ Mon Aug 22, 2016 1:05 pm ] Post subject: Re: BS-X Satellaview Datapak's 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 ChipBasically, 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 /RESETNote: 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-FFFFhBIOS ROM is always mapped as LoROM (the ROM address lines are hardwired to SNESbus, 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 onlyFor 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 snippetsThe 8K snippets in bank 20h-27h/A0h-A7h are taken from PSRAM offset 006000h,016000h, .., 076000h. The same snippets are also mirrored in bank28h-3Fh/A8h-BFh.The four special regions (at 0000h-7FFFh and 6000h-7FFFh) are affected only byMCC 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 32KFor 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 tryingto 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 4MBDATAPAK is always enabled and mapped to the entire ROM area (unless it'soverlapped 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.  Author: LuigiBlood [ Thu Aug 25, 2016 8:28 am ] Post subject: Re: BS-X Satellaview Datapak's 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  Author: nocash [ Fri Sep 02, 2016 6:32 pm ] Post subject: Re: BS-X Satellaview Datapak's 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 1150205Cbsx2.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 1150455Cbsx3.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 1150455Cbsx4.srm 00000974 1150005C 1150005C 00000978 11506A5C 11506A5C 000009B0 11503C5C 11503C5C 00000A24 1150AA5C 1150AA5C 00000A80 1150755C 1150755C 00000B0C 1152635C 1152635C 00000B10 1150855C 1150855C 00000B6C 1150455C 1150455Cbsx5.srm 00000974 1150005C 1150005C 00000978 11506A5C 11506A5C 000009B0 11503C5C 11503C5C 00000A24 1150AA5C 1150AA5C 00000A80 1150755C 1150755C 00000B10 1150855C 1150855C 00000B6C 1150455C 1150455Cbsx6.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 1150455Cbsx7.srm 00000974 1150005C 1150005C 000009B0 1150175C 1150175C 00000B6C 1150205C 1150205Cbsx8.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 1150455Cbsx9.srm 00000974 1150005C 1150005C 00000978 11506A5C 11506A5C 000009B0 11503C5C 11503C5C 00000A24 1150AA5C 1150AA5C 00000A80 1150755C 1150755C 00000B0C 1152635C 1152635C 00000B10 1150855C 1150855C 00000B6C 1150455C 1150455Cbsx10.srm 00000974 1150005C 1150005C 00000978 11506A5C 11506A5C 000009B0 11503C5C 11503C5C 00000A24 1150AA5C 1150AA5C 00000A80 1150755C 1150755C 00000B0C 1152635C 1152635C 00000B10 1150855C 1150855C 00000B6C 1150455C 1150455Cbsx11.srm 00000974 1150005C 1150005C 00000978 11506A5C 11506A5C 000009B0 11503C5C 11503C5C 00000A24 1150AA5C 1150AA5C 00000A80 1150755C 1150755C 00000B0C 1152635C 1152635C 00000B10 1150855C 1150855C 00000B6C 1150455C 1150455Cbsx12.srm 00000974 1150005C 1150005C 00000978 11506A5C 11506A5C 000009B0 11503C5C 11503C5C 00000A24 1150AA5C 1150AA5C 00000A80 1150755C 1150755C 00000B0C 1152635C 1152635C 00000B10 1150855C 1150855C 00000B6C 1150455C 1150455Cbsx14.srm BAD CHECKSUM AT 0000 00000AA8 8090D85C 80BDD85Cbsx15.srm BAD CHECKSUM AT 0000 00000974 1150005C 1150005C 000009B0 1150175C 1150175C 00000AA8 8090D85C 80BDD85C 00000B6C 1150205C 1150205Cbsx16.srm 00000974 1150005C 1150005C 00000978 11506A5C 11506A5C 000009B0 11503C5C 11503C5C 00000A24 1150AA5C 1150AA5C 00000A80 1150755C 1150755C 00000B0C 1152635C 1152635C 00000B10 1150855C 1150855C 00000B6C 1150455C 1150455Cbsx17.srmbsx18.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 1150455Cbsx19.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 1150455Cbsx20.srm 00000974 1150005C 1150005C 000009B0 1150175C 1150175C 00000B6C 1150205C 1150205Cbsx21.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 1150455Cbsx22.srm 00000974 1150005C 1150005C 00000978 11506A5C 11506A5C 000009B0 11503C5C 11503C5C 00000A24 1150AA5C 1150AA5C 00000A80 1150755C 1150755C 00000B10 1150855C 1150855C 00000B6C 1150455C 1150455Cbsx-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 1150455Cno$sns.srm - without fast boot patchno$sns2.srm - with my own fast boot patch installed 00000974 105C965C 105C965C 00000C94 47A90014 47A90014 00000C98 06658D53 06658D53 00000C9C 0000006B 0000006BSo, 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).

 Author: LuigiBlood [ Tue Sep 20, 2016 8:24 am ] Post subject: Re: BS-X Satellaview Datapak's 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 0010010000LLLLLL DDDCCCCCL = Logical Channel 2 (LCI2)D = Data StructureC = Logical Channel 1 (LCI1)So 0x0124 is:LCI1 = 04LCI2 = 01DS = 1What 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.

 Author: nocash [ Tue Sep 20, 2016 4:47 pm ] Post subject: Re: BS-X Satellaview Datapak's 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).

 Author: LuigiBlood [ Wed Sep 21, 2016 6:44 am ] Post subject: Re: BS-X Satellaview Datapak's 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!

 Author: nocash [ Wed Sep 21, 2016 8:46 am ] Post subject: Re: BS-X Satellaview Datapak's 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.

 Page 2 of 8 All times are UTC - 7 hours Powered by phpBB® Forum Software © phpBB Grouphttp://www.phpbb.com/