nesdev.com

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


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.

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.

Bit 2 is 1=on - sort of. I tested both bits 2 and 3 and they actually both control the LED activation behavior:


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.


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


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:



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.

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


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


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


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


Writing $b0 ("erase suspend/resume") is also supposed to do this.


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?


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


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.



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:



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:



A better way to describe it:



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

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

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