How to emulate ASC16 with write support?

Página 1/2
| 2

Por Bengalack

Paladin (747)

Imagen del Bengalack

04-11-2022, 17:33

Under this headline, there is something called ESE-RAM:
https://www.msx.org/wiki/MegaROM_Mappers#ASC16_.28ASCII.29

It says:

ESE-RAM (DIY cartridge called also Mega-SRAM that only contains SRAM):
Bits 0~6 = Segment number
Bit 7 = Enable writing. (write protected at initialization)

This is of particular interest for me. How do I use this in Openmsx? I want to use ASC16 for general ROM-segments, but the moment I use bit 7, I want to have access persistent storage. Possible?

Login sesión o register para postear comentarios

Por Bengalack

Paladin (747)

Imagen del Bengalack

04-11-2022, 17:49

Hmm, looking at it, this is what I need then:

Royal Blood & Wizardry (SRAM of 8kB):
Bits 0~6 = Segment number (0 when SRAM because there is only one segment)
Bit 7 = 1 to select the SRAM (writable on page 8000h~9FFFh or A000h~BFFFh only)

If this is -romtype ASCII16SRAM8 I should be home free.

Por Bengalack

Paladin (747)

Imagen del Bengalack

04-11-2022, 18:12

When I run the cart with: -romtype ASCII16SRAM8

I find SRAM via the debugger, and I also find it in \openMSX\persistent\roms\saga.rom\saga.rom.SRAM

But when I try to select SRAM, by writing 128 to switching address for page2, at 0x7000, I still get this:

ROM segment 0. But it is not the SRAM, that is for sure :-( What do I do wrong?

Por Bengalack

Paladin (747)

Imagen del Bengalack

04-11-2022, 18:17

Bengalack wrote:

Hmm, looking at it, this is what I need then:

Royal Blood & Wizardry (SRAM of 8kB):
Bits 0~6 = Segment number (0 when SRAM because there is only one segment)
Bit 7 = 1 to select the SRAM (writable on page 8000h~9FFFh or A000h~BFFFh only)

If this is -romtype ASCII16SRAM8 I should be home free.

Replying to myself here... It wasn't. The above thing as for ASC8 Sad

Por wouter_

Hero (525)

Imagen del wouter_

04-11-2022, 18:22

Hi Bengalack,

Currently the openMSX debugger doesn't understand SRAM-segments. It can only correctly show segments for memory mappers and for ROM mappers. I mean the ROM part of the mapper, not the SRAM part.

Apart from the display issue in the debugger, SRAM emulation of these mappers should work properly in openMSX.

Por Bengalack

Paladin (747)

Imagen del Bengalack

04-11-2022, 19:01

Thanks Wouter Smile But...

wouter_ wrote:

Hi Bengalack,

Currently the openMSX debugger doesn't understand SRAM-segments. It can only correctly show segments for memory mappers and for ROM mappers. I mean the ROM part of the mapper, not the SRAM part.

Apart from the display issue in the debugger, SRAM emulation of these mappers should work properly in openMSX.

I found out I think, the way to access SRAM (8kB) is like this (as for 2kB):

Hydlide 2 (SRAM of 2kB):
Bits 0~3 = Segment number (0 when SRAM because there is only one segment)
Bit 4 = 1 to select the SRAM (writable on page 8000h~BFFFh only)
Bits 5~7 = Unused

The problem with this (for me), is that ROM-segments can max be 3216. In Lilly's Saga we currently have 76.

To use bit 7 as the write-bit would be ideal. Any way to set such a config?

Por gdx

Enlighted (6215)

Imagen del gdx

05-11-2022, 09:31

OpenMSX cannot emulate ESE-RAM with ASCII16 mapper. It emulates ESE-RAM-SCC. There is also "ESE-Ramdisk" that is probably an ESE-RAM with ASCII8 mapper like below.

https://www.msx.org/wiki/ESE-RAM

or something like that:
https://www.msx.org/wiki/Niga_ESE-RAM_Maximum

The source code should be analyzed to confirm.
Games with an ASCII mapper and a small SRAM to save games is something else again

ESE-RAM is a generic name which means fake RAM. At first, this device was called Mega-sram (also a generic name), but 似非RAM (Fake-RAM) stayed because it's a word game, 似非RAM is pronounced almost the same as SRAM in Japanese. Also, the device is associated with a fake Rom cartridge. That's why different device with ESE.

Por Bengalack

Paladin (747)

Imagen del Bengalack

05-11-2022, 23:17

Thanks.

Well, it would have been cool if all (or most of) the different mapper-types could be configured via xml, and not coded. This way it would be easier to add new variants Smile New variants pop up now and then, you know Smile

But I think I have found my way around this for now.

Por Manuel

Ascended (19468)

Imagen del Manuel

06-11-2022, 10:53

We could add a variant of the RBSC flash cartridge.

We did consider programmable mappers, but we couldn't come up with something that could cover all current mappers, without getting immensely complex.

Por Bengalack

Paladin (747)

Imagen del Bengalack

06-11-2022, 11:38

Manuel wrote:

We could add a variant of the RBSC flash cartridge.

https://www.msx.org/wiki/RBSC_Carnivore2 ? Not sure if that would help me. How?

I'm currently working towards a proposed design of a megarom cartridge (with 8kB nvram), like this:

Just as ASCII16, but if bit 7 of the segment number is set, nvram will be present.

This is the same setup as for ASC8 Royal Blood & Wizardry (SRAM of 8kB), just that it is 16kB segments... Sounds like a combo that should not be too hard to get in openmsx. If I could get openmsx to compile maybe I could even do it myself - but me and win32, c++ projects almost always goes badly :(

Manuel wrote:

We did consider programmable mappers, but we couldn't come up with something that could cover all current mappers, without getting immensely complex.

Yes, looking at the variations on this page https://www.msx.org/wiki/MegaROM_Mappers, this seems a bit complex, yes. But if you leave out the anti-piracy mapper, and split out SCC to be partly hardcoded as today, it might be doable. But then again... what are the benefits of implementing this compared to other features and time available? I see that this might not be top priority.

Por gdx

Enlighted (6215)

Imagen del gdx

06-11-2022, 12:54

Are you working on a megaflash cartridge with ASCII 8/16K mapper and with 8kB nvram ?

Página 1/2
| 2