Add support for 768Kbit SRAM save type

[meeq]

LibDragon Save Type Detection Test ROM: savetest.zip (source)

Highlights

• Fixes a segmentation fault when trying to access SRAM > 256Kbit
• Implements "banked" 768Kbit SRAM as used exclusively by "Dezaemon 3D":
  • The cartridge contains three 256Kbit SRAM chips and uses bank selection bits in the address.
  • The 768Kbits of SRAM cannot be accessed contiguously, only one bank at a time.
• Introduces options for specifying SRAM capacity: -sram256k (alias of -sram) and -sram768k

Intentional omissions

The test ROM includes checks for save types that should not exist. These save types are intentionally not implemented by cen64:

• 1Mbit SRAM (Banked)
• 768Kbit SRAM (Contiguous)
• 1Mbit SRAM (Contiguous)

Known issues

Dezaemon 3D boots, shows the publisher logo, then gets stuck at the "sad man screen" that appears to indicate SRAM errors:

Additional investigation and research is needed to get Dezaemon 3D working.

[meeq]

I have updated this PR to correctly handle 768Kbit SRAM detection based on Verilog used by 64drive. The LibDragon test ROM is working correctly, but Dezaemon 3D is still showing the sad man (but at least it’s no longer segfaulting after the publisher logo).

I need to do a deeper dive into the DMA read/writes to figure out why it’s still failing the SRAM check — I confirmed that the 19:18 bits of the address are being used to select the SRAM chip

[meeq]

I have dumped the 768Kbit SRAM read/write data from Dezaemon 3D to inspect what's happening, and from what I can tell it's reading each SRAM bank, then writing each SRAM bank, then reading each SRAM bank again.

From the data dumps, the reads and writes appear to be working correctly (unless there's something subtle I'm missing here): Dezaemon3D.log

I may need to go deeper here and actually debug or disassemble what Dezaemon3D is actually failing on 😞

Any advice or suggestions would be greatly appreciated.