Save to SRAM

Paragon (1138)

03-04-2023, 19:46

After adding in my lib MSXgl the support for saving to MSX2's RTC CMOS, I would like to add support for saving to SRAM cartridge like PAC or FMPAC.
I found how access the data on the wiki but I have some questions.

1) Is there a easier way to detect PAC cartridge slot than active/disactive access and check write success/fail?

2) Do you know any good practice to detect if a given bank is already used by another application? I plan to use MSXgl application ID for detection (like I do for CMOS writing) but I wonder if back in the day there were any (un)official guideline to handle that. I doubt because games seems to used hard coded bank or manual selection.

3) Do you know other SRAM backup device I should support?

ログイン/登録して投稿

By ericb59

Paragon (1126)

03-04-2023, 20:00

You also have the Game Master 2 which save Konami games on its SRAM, and some other few cartridges with such sram save embedded.

By Sylvester

Hero (593)

03-04-2023, 22:31

1) did you check the source code of Pac-saver on: https://www.msx.org/wiki/Panasoft_PAC ?
3) There is also the Sony HBI-55 data cartridge (http://map.grauw.nl/resources/hbi55.php) but I don't think many people use it.

By aoineko

Paragon (1138)

04-04-2023, 00:41

Yes, I of course wanted to check at the PAC Saver code, but the link seems broken.
If you know of any source of information on how this cartridge works in detail, I am interested.

For the HBI-55 cartridge it's very interesting. Moreover, unlike the PAC, its behavior is very well documented (thanks to MAP).

By gdx

Enlighted (6438)

04-04-2023, 02:44

At the link given by Sylvester there is necessary info:
https://www.msx.org/wiki/ROM_mappers#PAC_.28Panasoft.29

The HBI-55 cartridge is not really interesting because it is too complicated for the interest it brings. It takes a lot of codes to save a few bytes.

By aoineko

Paragon (1138)

04-04-2023, 09:10

gdx wrote:

At the link given by Sylvester there is necessary info:
https://www.msx.org/wiki/ROM_mappers#PAC_.28Panasoft.29

As I said there are necessary info to access the PAC but no answer to my 1st post's questions.

By gdx

Enlighted (6438)

04-04-2023, 10:25

引用:

Is there a easier way to detect PAC cartridge slot than active/disactive access and check write success/fail?

According info, that's how I'd do it:

Read 5FFEh and 5FFFh, if the two value are FFh then write 4Dh at 5FFEh and go to the second step else this is not PAC.
Read 5FFEh, if it is not 4Dh go to the third step else this is not PAC.
Write 69h at 5FFFh, if the values at 5FFEh and 5FFFh are 4Dh and 69h then this is PAC.

(by repeating the operation in each slot for an auto-detection)

By aoineko

Paragon (1138)

04-04-2023, 14:10

Why would you stop testing if address 5FFEh is not equal to FFFFh?
Why does it say that this is the default value? And even if it is, this address can contain any value if the PAC has already been activated by another software, right?

Or maybe I'm missing something. ^^

By gdx

Enlighted (6438)

04-04-2023, 14:29

aoineko wrote:

Why would you stop testing if address 5FFEh is not equal to FFFFh?

That's not what I wrote.

aoineko wrote:

Why does it say that this is the default value? And even if it is, this address can contain any value if the PAC has already been activated by another software, right?

I considered it to be a single program but you can add writing a value other than 4Dh at 5FFEh before to avoid this.

By aoineko

Paragon (1138)

06-04-2023, 00:10

gdx wrote:

aoineko wrote:

Why would you stop testing if address 5FFEh is not equal to FFFFh?

That's not what I wrote.

It was a shorten to say FFh in 5FFEh and 5FFFh; that's what you said, right?
I don't understand where this value comes from.

Another point I don't understand is that the mapper is presented as having 8 segments of 1 KB, but from what I understand, it seems to be just a single space of 8 KB (minus the 2 last bytes that are used to enable SRAM access). If this is the case, why is this presented as a ROM mapper? If not, how can the visible segments be switched?

By gdx

Enlighted (6438)

06-04-2023, 01:59

aoineko wrote:

It was a shorten to say FFh in 5FFEh and 5FFFh; that's what you said, right?

What I wrote means that 5FFEh and 5FFFh both stay at FFh until you write 4Dh and 69h. The order in which we write these values does not matter. So either it's FFh and FFh or it's 4Dh and 69h. If there is only one of the these two values or something else, it is not a PAC.

aoineko wrote:

These are not segments but an area of 8 KB arbitrarily divided into 8 blocks. These 8 kB are only visible after writing 4Dh and 69h to 5FFEh and 5FFFh.