SDD1 mapping (attn: byuu)

[AWJ]

byuu, do you have a Star Ocean cartridge? Now that you have a working 21FX, the address map for SDD1-with-SRAM really needs to be verified; currently Icarus maps the SRAM in both the "LoROM" fashion (starting at 70:0000) and the "HiROM" fashion (starting at 20:6000 and A0:6000) and somehow I doubt that's correct.

Also, have you tested whether the "LoROM" part of the ROM mapping can be bankswitched on the SDD1 the same way as it can on the SA-1, by setting bit 7 of the ROM bank registers to 1?

(reminder in case you need it: SA-1 bankswitching always affects the HiROM banks. If bit 7 of one of the ROM bank registers is set, the bankswitching also affects the corresponding 1MB LoROM block; if bit 7 is clear then the LoROM blocks are fixed to the first 4MB of the ROM)

Oh, and can you check if SDD1 registers 4802 and 4803 do anything (like enabling/disabling SRAM, or controlling where/how it's mapped)?

[Near]

Alright, I looked into this for you.

You're gonna love this ... it's a lot screwier than we thought it'd be ;)

Nothing is ever simple or straight-forward with the SNES.

> somehow I doubt that's correct.

Sorry, you're wrong on this one. RAM is mapped to:
$00-3f,80-bf:6000-7fff (more than we thought)
$70-73:0000-ffff (less than we thought)

Also, ROM is not mapped to $40-7d:0000-ffff at all, that was an incorrect guess as well.

> Also, have you tested whether the "LoROM" part of the ROM mapping can be bankswitched on the SDD1 the same way as it can on the SA-1, by setting bit 7 of the ROM bank registers to 1?

Great catch on d7 being present, but unfortunately that's not what it does.

The bitmask of these four registers is a000bbbb, so you can write #$ff and read back #$8f.
$4804-4807.d0-d3 have no effect on 00-3f,80-bf:8000-ffff.
$4804.d7 has no effect on anything, but can be set.
$4805.d7 set forces 20-3f:8000-ffff to mirror 00-1f:8000-ffff.
$4806.d7 has no effect on anything, but can be set.
$4807.d7 set forces a0-bf:8000-ffff to mirror 80-9f:8000-ffff.

Basically, 00-3f:8000-ffff and 80-bf:8000-ffff are the first 16mbit of the ROM. When you set those d7 bits, it chops it down as if it were an 8mbit ROM. $4805.d7 controls 20-3f, and $4807.d7 controls a0-bf.

Honestly ... this isn't too much worse than the SPC7110. That one's really screwy, too.

> Oh, and can you check if SDD1 registers 4802 and 4803 do anything (like enabling/disabling SRAM, or controlling where/how it's mapped)?

$4802,$4803 ... and apparently $4808-480f return constant values:
aa,cc and 68,85,02,68,85,00,28,60.
Your guess is as good as mine what they mean.
I tried beating the hell out of the chip to change them: writing lots of noise, triggering decompressions, writing the DMA registers that this chip monitors, etc. So far, nothing changes them.
$2200-47ff and $4810-5fff don't respond at all (open bus.)

Full research: http://board.byuu.org/phpbb3/viewtopic.php?f=8&t=1075

That's all the work I'm going to do on this chip for now. In the future, I'll try to figure out what happens when you ask for a bank higher than the number of 8mbit chunks in the ROM itself. I'm particularly interested in Star Ocean, since that ROM isn't a power of two. Bank values of 6 and 7 should be pretty interesting.

[AWJ]

Thanks for the quick response!

So d7 forces the LoROM banks to mirror the first 8MBit of the ROM, regardless of d0-d3? Writing 81 instead of 80 doesn't make the LoROM banks mirror the second 8Mbit (that's what it would do on the SA1)? Not sure what you mean on the other board by the "A15 select" terminology.

I thought the only screwy thing about the SPC7110 mapping-wise was that software has to tell it how big the "program" (uncompressed) ROM is. Same as the Cx4, which has to be software-configured to tell it whether it's connected to one 16MBit ROM or two up-to-8MBit ROMs. The SDD1 doesn't seem to need such configuration--I guess it only supports up-to-32MBit ROMs, or maybe it has redundant chip select outputs like the MAD-1.

Interesting that the banking registers are readable. Read-write registers are a bit unusual on Nintendo hardware. I've seen NES and Game Boy games that have the bank number at a fixed address in every ROM bank so the game can tell which banks are mapped in (e.g. when an interrupt handler needs to switch banks and then restore them)

ETA: I need to call out an incorrect comment in sdd1.cpp:

Code: Select all

//SDD1::mcu_read() is mapped to $c0-ff:0000-ffff
//the design is meant to be as close to the hardware design as possible, thus this code
//avoids adding S-DD1 hooks inside S-CPU::DMA emulation.
//
//the real S-DD1 cannot see $420b (DMA enable) writes, as they are not placed on the bus.
//however, $43x0-$43xf writes (DMAx channel settings) most likely do appear on the bus.
//the S-DD1 also requires fixed addresses for transfers, which wouldn't be necessary if
//it could see $420b writes (eg it would know when the transfer should begin.)

Logic analyzer traces have shown that writes to $420B are placed on the external bus; see here.

However, the SDD1 most likely still does need to spy on $4300-437F in order to determine what data to decompress and when.

ETA 2:

I'll try to figure out what happens when you ask for a bank higher than the number of 8mbit chunks in the ROM itself

I thought you already did this with SFA2, and found that out-of-range banks read random noise?

Here's my guess at how the hardware works: The SDD1 is designed to work with ROMs up to 32Mbit in size, and has chip select outputs for a certain number of ROMs (I'd guess 4 based on how many bits of the bank registers are readable) Banks 00-03 select the first ROM, banks 04-07 select the second ROM, etc.

When you select bank 04 with SFA2, the SDD1 outputs the chip select for ROM #2, but there's no ROM connected to that output, so you read back the SDD1's open bus (which is different from the SNES's)

When you select banks 06 or 07 with Star Ocean, the SDD1 outputs the chip select for ROM #2, and since there is a ROM there, you should get mirrors of banks 04 and 05 respectively. But if you select bank 08 or higher, then the SDD1 will select non-existent chips and you'll get bus noise just like with SFA2.

I wouldn't be the least surprised to be wrong, though, given my track record here

[KungFuFurby]

$4802,$4803 ... and apparently $4808-480f return constant values:
aa,cc and 68,85,02,68,85,00,28,60.
Your guess is as good as mine what they mean.

$4808-$480F can be used as 65C816 code... if you're pushing values from the SDD1 into the stack and storing them two those two direct page locations and called it from a non-long subroutine. That's unusual to see that kind of code in there...

[AWJ]

$4802,$4803 ... and apparently $4808-480f return constant values:
aa,cc and 68,85,02,68,85,00,28,60.
Your guess is as good as mine what they mean.

$4808-$480F can be used as 65C816 code... if you're pushing values from the SDD1 into the stack and storing them two those two direct page locations and called it from a non-long subroutine. That's unusual to see that kind of code in there...

I just looked at the Star Ocean ROM in a hexeditor, and those "constant values" are actually the data at ROM offsets $004802-$004803 and $004808-$00480F. Looks like reads to non-readable registers fall through to ROM (even though ROM is normally not mapped anywhere near $00:4800)

[KungFuFurby]

In this scenario, Street Fighter Alpha 2 should give different results for those registers when read...

[Near]

> So d7 forces the LoROM banks to mirror the first 8MBit of the ROM, regardless of d0-d3?

d0-d3 has no effect on $00-3f,80-bf:8000-ffff, so yes that is correct.

> The SDD1 doesn't seem to need such configuration--I guess it only supports up-to-32MBit ROMs

Star Ocean is 48mbit. I suspect the SDD1 supports up to 128mbit given four bits are exposed for the bank select.

The downside is, the 64 megabyte Lunar FMV demo is going to be permanently busted with this correction.

I don't know why S-DD1 itself would implement the upper two bits as a chip-select. You'd figure it'd just feed the whole linear address out and let PCBs wire those lines into the ROM chip select signals or whatever.

> Logic analyzer traces have shown that writes to $420B are placed on the external bus; see here.

Then it probably just doesn't care. Because it does seem to require fixed addressing.

Dejap's "let's plaster our logo all over the title screen" DMA hijack leaves the SDD1 enabled, but doesn't set the fixed transfer flag (the graphic isn't compressed), so it works.

> I thought you already did this with SFA2, and found that out-of-range banks read random noise?

I don't remember that, but maybe.

> I wouldn't be the least surprised to be wrong, though, given my track record here

I'm wrong 95% of the time as well.

Everything on the SNES seems to defy common sense.

Look at the BCD code for the EpsonRTC emulation in higan sometime. I don't even know why I reverse engineered all of that.

> I just looked at the Star Ocean ROM in a hexeditor, and those "constant values" are actually the data at ROM offsets $004802-$004803 and $004808-$00480F. Looks like reads to non-readable registers fall through to ROM (even though ROM is normally not mapped anywhere near $00:4800)

Oh, nice catch.

That is super screwy behavior.

> In this scenario, Street Fighter Alpha 2 should give different results for those registers when read...

Correct. We'll have to return rom.read(addr) for those registers.

[AWJ]

> So d7 forces the LoROM banks to mirror the first 8MBit of the ROM, regardless of d0-d3?

d0-d3 has no effect on $00-3f,80-bf:8000-ffff, so yes that is correct.

Hmm, strange. The SDD1 address map seems very similar to the SA-1 map (e.g. having SRAM mapped at both "HiROM" and "LoROM" locations). I wonder if Nintendo partially reused the same address decoding and bankswitching logic in both chips, but some of it ended up nonfunctional/vestigial on the SDD1. Does the SDD1 support 3.58 MHz access? If it does, that could be a reason for wanting 00-3F and 80-BF to mirror the same ROM banks (unlike the SA-1).

Star Ocean is 48mbit. I suspect the SDD1 supports up to 128mbit given four bits are exposed for the bank select.

I meant the individual ROM chips are up to 32mbit. Star Ocean has one 32mbit ROM and one 16mbit ROM.

I don't know why S-DD1 itself would implement the upper two bits as a chip-select. You'd figure it'd just feed the whole linear address out and let PCBs wire those lines into the ROM chip select signals or whatever.

If you've got two 32mbit ROMs (or one 32mbit and one 16mbit), then one chip needs A22 connected to /CS and the other needs inverted A22 connected to /CS. You'd need a NOT gate to invert the signal to one of the two ROMs, and I don't believe the Star Ocean PCB has any discrete logic chips on it. The MAD-1 has redundant chip select outputs ("ROM 0", "ROM 1", and just "ROM" for single-ROM carts); I expect the SDD1 is similar. Every yen not spent soldering an additional component onto the PCB is one yen of profit.

> Logic analyzer traces have shown that writes to $420B are placed on the external bus; see here.

Then it probably just doesn't care. Because it does seem to require fixed addressing.

Maybe the SDD1 uses a change on the address bus to recognize the end of one DMA transfer and the start of the next channel's? (or the resumption of normal opcode fetching)