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.

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

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

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:

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

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

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

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)

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?

Last edited by AWJ on Fri Aug 19, 2016 9:31 am, edited 1 time in total.

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

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)

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:

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.

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:

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.

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.

Who is online

Users browsing this forum: No registered users and 4 guests

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