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

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.

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?

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.

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:

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.

Last edited by LuigiBlood on Sat Jul 14, 2018 11:00 am, edited 1 time in total.

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.

Who is online

Users browsing this forum: No registered users and 3 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