QDS tag which is fixed value can't handle saves correctly

[cynagenautes]

The current QDS tag does not support saving data.
In Japanese version of Animal Crossing (Doubutsu no Mori+),

• The Legend of Zelda (FDS)
• Nazo no Murasame Jō (The Mysterious Murasame Castle)
• Super Mario Bros. 2 (Super Mario Bros.: The Lost Levels

are exist, but each has a different QDS tag value.

I don't currently know how to derive the correct value for these tags from the .fds / .qd files, but I'm reporting this as it seems like a potential issue.

Below is the raw debug log displayed when starting the aforementioned Disk System games in Doubutsu no Mori+ (executed on the Dolphin emulator).

The Legend of Zelda

14:15:800 Core\HW\EXI\EXI_DeviceIPL.cpp:307 N[OSREPORT]: タグ＝QDS 長さ＝5
14:15:801 Core\HW\EXI\EXI_DeviceIPL.cpp:307 N[OSREPORT]: ディスクセーブエリアをロード
14:15:801 Core\HW\EXI\EXI_DeviceIPL.cpp:307 N[OSREPORT]:  01 ba fd 05 1c

I found the BBR tag for the NES version of The Legend of Zelda appears to share some similarities.
ref. https://hunter-r.com/posts/ac-nes-tag-data/#the-legend-of-zelda

We might be able to implement support if we can determine the save data size and the offset needed to extract the save data from the .fds.

Nazo no Murasame Jō

56:45:774 Core\HW\EXI\EXI_DeviceIPL.cpp:307 N[OSREPORT]: タグ＝QDS 長さ＝5
56:45:775 Core\HW\EXI\EXI_DeviceIPL.cpp:307 N[OSREPORT]: 初プレイなのでディスクセーブエリアを保持します
56:45:775 Core\HW\EXI\EXI_DeviceIPL.cpp:307 N[OSREPORT]:  00 9a c7 00 3e

Super Mario Bros. 2

58:28:145 Core\HW\EXI\EXI_DeviceIPL.cpp:307 N[OSREPORT]: タグ＝QDS 長さ＝5
58:28:145 Core\HW\EXI\EXI_DeviceIPL.cpp:307 N[OSREPORT]: 初プレイなのでディスクセーブエリアを保持します
58:28:145 Core\HW\EXI\EXI_DeviceIPL.cpp:307 N[OSREPORT]:  01 cc 4e 00 01
58:28:145 Core\HW\EXI\EXI_DeviceIPL.cpp:307 N[OSREPORT]: タグ＝HSC 長さ＝8
58:28:146 Core\HW\EXI\EXI_DeviceIPL.cpp:307 N[OSREPORT]: ハイスコア: オフセット＝87d7 初期値＝初プレイでハイスコアデータがないので初期化しました
58:28:146 Core\HW\EXI\EXI_DeviceIPL.cpp:307 N[OSREPORT]:  00 00 00 00 00 00

[cynagenautes]

I extracted and verified the .qd file from the GC iso. It seems The Legend of Zelda has save data located at the end of side B, and the QDS tag appears to match the actual address in the qd format.

The character $ (=0x24) acts as a filename placeholder. Japanese ROM allows for settings for three file name, each with 8 characters.
All remaining bytes were 0x00.
The size confirmed using a binary editor matches the size specified by the QDS tag.(0x051c = 1308bytes)

If someone familiar with extracting save data from .fds files could assist, the issue regarding save data handling for the Famicom Disk System might be solvable.

I've been trying to add the FDS version of METROID. I found a string starting with 'SAVE' using a binary editor and changed the QDS tag near it, but the save file isn't being created correctly.

Taking The Legend of Zelda as a successful example, a two-block file is created on the memory card, and banners and titles are configured for the Japanese ROM.
In my attempt, a one-block file is created, no banner or title is configured, and according to the debug log, it seems to be discarded as corrupt data.

[cynagenautes]

I found a QDS tag that enables saving in METROID(FDS).

Tags.Add(new KeyValuePair<string, byte[]>("QDS", new byte[5] { 0x00, 0xCA, 0xDF, 0x00, 0x75 }));

This was the result of trying multiple potential values with a binary editor.
The problem is I can't find a systematic way to set up the QDS file. Reverse engineering may be necessary by examining the behavior of NES/Famicom emulators...