Forums

(approximate trasnlation)
File CHASM.EXE is linked to a missing exportation DINPUT.DLL: DirectInputCreateEx
Still, I'm using DirectX 5 (not 4, I verified), so I'm not complaining :)

About the open savegame format.
Why by the hell do you say it is doubful that MEKA will support it ?
Thanks.

Now If I can comment on the principle of "open", this should have been discussed right here
before even a first public use. Say, you are open to yourself, right?

--Now my comments--

RAM size is dependant of the machine, and cartridge/mapper kind.
64 bytes of ColorRAM are not needed for SMS, only 32 bytes are needed.
Some systems does not even have kind kind of memory (I'm talking about SG-1000 and SC-3000)

SaveRAM size should be speficicated, as it's entirely depending on the cartridge itself.
No need to save both pages everytime. Some cartridge uses on-board EEPROM with 128 bytes
of accessible data.

FM Chipset register has to be saved (64 bytes)
As well as FM Chipset detection register

Port 0x3F has to be saved (1 byte)
Port 0xDF has to be saved (1 byte)

SC-3000 peripherals specific stuff (like printer, cassete) has to be saved if used.
Which lead to a modular format.

Weither Country should or not be saved is an interesting question. It is saved in Meka.
Technically, it should be saved to have zero chances to screw a game. Practically it's not really needed.

Weither Image is odd or even need to be saved (1 bit.. 1 byte?)

More than two Gear-to-Gear specific registers need to be saved for sure. Not quite sure which, thought.

As for PSG stuff. The current state of the generated wave should be saved to have accurate save/load during a voice play.

Quote

> Port 0x3F has to be saved (1 byte)

Zoop, could you elaborate on this? I know it has something to do with BIOS.

For what it's worth, I think a lot of people would like to see the SMS BIOS released. We know there are features of the hardware that only it uses. (Specifically, how it manages to page itself into memory and then map the cartridge.) I think that numerous people studying the BIOS will give us an even clearer picture of how the hardware works.

By the way, I'm all for a "open" SMS/GG/SG-1000/SC-3000 save state. I can't really help contribute right now, but I will offer one idea: The format should have a "header" which includes pointers to various sections of the file. This will allow for flexibility if certain sections grow, shrink, or disappear.

Eric Quinn

Quote

> By the way, I'm all for a "open" SMS/GG/SG-1000/SC-3000 save state. I can't really help contribute right now, but I will offer one idea: The format should have a "header" which includes pointers to various sections of the file. This will allow for flexibility if certain sections grow, shrink, or disappear.

I agree completly. By having a header that is kinda set up in such a fashion that it tells file offsets and lengths of the fields it would probably work best. This would eliminate storing some data if it does not apply to a certain game. IE: Saving back up ram for Sonic. The game doesnt use it as far as i know and that would save 32k of space in the file.

Atani

Quote

>> By the way, I'm all for a "open" SMS/GG/SG-1000/SC-3000 save state. I can't really help contribute right now, but I will offer one idea: The format should have a "header" which includes pointers to various sections of the file. This will allow for flexibility if certain sections grow, shrink, or disappear.
> I agree completly. By having a header that is kinda set up in such a fashion that it tells file offsets and lengths of the fields it would probably work best. This would eliminate storing some data if it does not apply to a certain game. IE: Saving back up ram for Sonic. The game doesnt use it as far as i know and that would save 32k of space in the file.

RAM and VRAM should be RLE encoded. With a flag to disable RLE if needed.

Quote

>> Port 0x3F has to be saved (1 byte)
> Zoop, could you elaborate on this? I know it has something to do with BIOS.

This is the nationalization port if I recall correctly.
I haven't even thought about the BIOS when writing that line.

Quote

> For what it's worth, I think a lot of people would like to see the SMS BIOS released. We know there are features of the hardware that only it uses. (Specifically, how it manages to page itself into memory and then map the cartridge.) I think that numerous people studying the BIOS will give us an even clearer picture of how the hardware works.

It copy a function to RAM, which write stuff to port 3Eh, check in C000h for a result then jump to 0000h.
Basically all.
Still, the BIOS will be released.

Quote

> >> Port 0x3F has to be saved (1 byte)
> > Zoop, could you elaborate on this? I know it has something to do with BIOS.

> This is the nationalization port if I recall correctly.
> I haven't even thought about the BIOS when writing that line.

Sorry, my mistake. I guess I don't know my SMS I/O ports that well :)

Quote

> > For what it's worth, I think a lot of people would like to see the SMS BIOS released. We know there are features of the hardware that only it uses. (Specifically, how it manages to page itself into memory and then map the cartridge.) I think that numerous people studying the BIOS will give us an even clearer picture of how the hardware works.

> It copy a function to RAM, which write stuff to port 3Eh, check in C000h for a result then jump to 0000h.
> Basically all.
> Still, the BIOS will be released.

O.k., thanks.

Eric Quinn

Quote

> >> By the way, I'm all for a "open" SMS/GG/SG-1000/SC-3000 save state. I can't really help contribute right now, but I will offer one idea: The format should have a "header" which includes pointers to various sections of the file. This will allow for flexibility if certain sections grow, shrink, or disappear.
> > I agree completly. By having a header that is kinda set up in such a fashion that it tells file offsets and lengths of the fields it would probably work best. This would eliminate storing some data if it does not apply to a certain game. IE: Saving back up ram for Sonic. The game doesnt use it as far as i know and that would save 32k of space in the file.

> RAM and VRAM should be RLE encoded. With a flag to disable RLE if needed.

IMO, it's better to use "standard" compression like the kind
offered by zlib. RLE is OK for repetitive data, but you probably
wouldn't get optimal results.

Regarding the save state, it might be useful to have something
with tagged sections (like an LBM file), so emulators can
process the sections they need (ram, psg state) and ignore
the ones they don't handle (FM chip, odd peripheral, etc.)

There's already something like that for the NES, people who
are interested should check this link out:

http://www.nofrendo.org/snss/index.html

Of course the SMS doesn't have as many variations on the
cart hardware as the NES, but nevertheless it's a very
flexible way to handle data across various emulators.

Plus, there's no problem of old states not working when
a new section is added, since the routine that parses
the save state data can just ignore sections it doesn't
recognize.

My Homepage

Quote

> File CHASM.EXE is linked to a missing exportation DINPUT.DLL: DirectInputCreateEx

Gahgah! Well, a friend of mine who refuses to upgrade from NT4 to Win2k is going to make CHASMS DX3 compatible, so this problem *will* go away in the next version. Honest. ^_~

Quote

> Why by the hell do you say it is doubful that MEKA will support it ?

I apologize. I seriously didn't mean anything by it, I just figured that you've made MEKA propietary in so many other aspects, you probably wouldn't go for this either. I'd be delighted if you'd support it.

Quote

> Now If I can comment on the principle of "open", this should have been discussed right here
> before even a first public use. Say, you are open to yourself, right?

Yes, you're absolutely right. I intended to do this actually, but I've been sitting on this thing for a while and with finals and what not, it skipped my mind. Anyhow, this is exactly what the version number and extensions field is for. ^_~

Quote

> RAM size is dependant of the machine, and cartridge/mapper kind.

Dependant by machine: Right, since CHASMS doesn't emulate all the SC* and SG* (I don't even know how many of them exist :o) I haven't incorporated anything for savestate support for this. There's ... what, an SC-1000, SC-3000, and SG-1000 or something like that? How much RAM does each have? the RAM size can vary according to the Machine byte.

How does the RAM size vary by cartridge/mappers? Are you talking about SaveRAM? This is addressed in a seperate field.

Quote

> 64 bytes of ColorRAM are not needed for SMS, only 32 bytes are needed.

Yeah, but since it's 64 bytes for a full GG palette I figured the extra 32 bytes of space weren't going to kill anybody.

Quote

> Some systems does not even have kind kind of memory (I'm talking about SG-1000 and SC-3000)

Huh. Weird. Well, again, the format can be modified based on the Machine state.

Quote

> SaveRAM size should be speficicated, as it's entirely depending on the cartridge itself.
> No need to save both pages everytime. Some cartridge uses on-board EEPROM with 128 bytes
> of accessible data.

Interesting. I wasn't aware of any way to tell the difference (aside from detected how much of the RAM was written to). Also, I think someone else critized this, but the format already does not save the 32k of SaveRAM if it's not used in that game. (or if it does but hasn't been paged in yet)

Quote

> FM Chipset register has to be saved (64 bytes)
> As well as FM Chipset detection register
> Port 0x3F has to be saved (1 byte)
> Port 0xDF has to be saved (1 byte)

Ok, these will be added. (I didn't think not saving 3F would have any adverse effects, since according to MASSAGE you can't IN the value OUTed to it, but it could be wrong) .. I don't even know what DF does, but I'll add it anyhow.

Quote

> SC-3000 peripherals specific stuff (like printer, cassete) has to be saved if used.
> Which lead to a modular format.

As I have no knowledge of the SC-3000, if you would like to send me a list of what needs to be saved in the case of that Machine type, I'll add it to the format specification.

Quote

> Weither Country should or not be saved is an interesting question. It is saved in Meka.

The header already saves the Country.

Quote

> Weither Image is odd or even need to be saved (1 bit.. 1 byte?)

I'm confused.. what do you mean by image even or odd?

Quote

> More than two Gear-to-Gear specific registers need to be saved for sure. Not quite sure which, thought.

Well, I know there are more GameGear ports used in the serial IO thing (basically ports 0 through 6 need to be saved I guess). Actually, I'm surprised that slipped my mind. I guess that's because I added the GameGear stereo after I did the savestate format. Are there any more besides ports 0 through 6?

Quote

> As for PSG stuff. The current state of the generated wave should be saved to have accurate save/load during a voice play.

I'm not sure what you mean. It already saves snapshots of the volume/frequency/noisetable values. I know you need cycle-accurate timing for voices, but I didn't think you'd need them retroactively. You mean I should add a 'PC last modified' table for volume and frequency for each voice?

Does anything additional need to be saved for lightgun, paddle, or any other of the more obscure peripherals?

As for compressing the memory/vram/etc, that's exactly what the Extensions byte is for. Originally I was using ZLIB to compress those parts of the savestates, but I know there are emulators out there written in pure ASM that probably can't use ZLIB. For the time being, I didn't use compression in the CHASMS savestate to make it easier for anyone that's interested in getting the format to work. RLE is easier to implement, however. But, there are different ways of RLE formats, different ways of handling run tags and what not, so we'd have to settle of a standardized system and set of routines for handling them.

- vecna

Quote

> IMO, it's better to use "standard" compression like the kind
> offered by zlib. RLE is OK for repetitive data, but you probably
> wouldn't get optimal results.

Yeah, this is why I haven't used any compression in the savestates yet. I was using ZLIB for mine, so this makes sense from my perspective. This is what I was reserving the Extensions byte for.

Quote

> Regarding the save state, it might be useful to have something
> with tagged sections (like an LBM file), so emulators can
> process the sections they need (ram, psg state) and ignore
> the ones they don't handle (FM chip, odd peripheral, etc.)

Hmm... this is a good idea. I think I like the tagged sections better than having a big offset table in the header. Otherwise the table itself would also have to grow if a section was added.. and you're right, an emulator can just skip a tag it doesn't understand. I'll definitely put this in the format revision. Thanks for pointing that out.

- vecna

Quote

> IMO, it's better to use "standard" compression like the kind
> offered by zlib. RLE is OK for repetitive data, but you probably
> wouldn't get optimal results.

It's sufficient to reduce the size of the file of quite a lot compared to what it is.
About 25kb could reduce to 10 or 15 kb. We don't need smaller as long as it fit in a cluster ^_^

Quote

> > File CHASM.EXE is linked to a missing exportation DINPUT.DLL: DirectInputCreateEx
> Gahgah! Well, a friend of mine who refuses to upgrade from NT4 to Win2k is going to make CHASMS DX3 compatible, so this problem *will* go away in the next version. Honest. ^_~

Great ^_^ I'll be able to try it.
If it run well on my machine I might even consider installing Visual C to finish that damned port.
Last week I ported Meka to FreeBSD to play at school. It's slow on 16-bit X Servers due to palette uses which are nonsense in 16-bit modes, but in 8-bit it runs very fine just as on DOS.

Quote

>> Why by the hell do you say it is doubful that MEKA will support it ?
> I apologize. I seriously didn't mean anything by it, I just figured that you've made MEKA propietary in so many other aspects, you probably wouldn't go for this either.

Meka is proprietary because it's a pile of badly written shit. When I started it I didn't even know what was a list of a pointer.
As a result some piece of codes are very smart (pardon my arrogance ;) and some would shock you because how unefficient they are (i'm thinking about the GUI).
Adding that to the fact adding more systems and fixing all games lead to a few tricks here and tricks it's ugly, compared to what I could do now if I had an empty month.
My checksum routine isn't even a checksum, etc.
In Meka2 I'll try to have everything open - or re-use already defined format if available by the time.

Quote

> I'd be delighted if you'd support it.

Assuming it fits Meka needs/restrictions I will.

Quote

>> Now If I can comment on the principle of "open", this should have been discussed right here
>> before even a first public use. Say, you are open to yourself, right?

>> RAM size is dependant of the machine, and cartridge/mapper kind.
> Dependant by machine: Right, since CHASMS doesn't emulate all the SC* and SG* (I don't even know how many of them exist :o) I haven't incorporated anything for savestate support for this. There's ... what, an SC-1000, SC-3000, and SG-1000 or something like that? How much RAM does each have? the RAM size can vary according to the Machine byte.

SG-1000 = Sega Game 1000
SC-3000 = Sega Computer 3000
they are exactly the same machine expect that SC-3000 have a keyboard by default and port for a printer and audio ports for cassette.
Sega Super Control Station (SF-7000) add a Centronics printer port and a 3" drive and connect throught the cartridge port.
Both machines have 4 kb of RAM. But some cartridges have on-board RAM, etc.

Meka implement 8 of what I call mappers:
Standard (with optional SaveRAM as you know it)
32 kb of onboard RAM
Colecovision (remember when I told you about Meka being a pile of tricky shit? ^_^)
CodeMasters
Cartridge with onboard 93c46 EEPROM
SG-1000/SC-3000 (4 kb of RAM)
ActionReplay (in development)
Graphic Board (because it read/write to special location in memory)

Quote

> How does the RAM size vary by cartridge/mappers? Are you talking about SaveRAM? This is addressed in a seperate field.

Now I was talking about RAM in general. Beside each mappers requires different custom data.
For exemple, when you are storing 0xFFFC to 0xFFFF byte, keep in mind it is directly related to the current mapper.
CodeMasters cartridges does not have any uses of them, for exemple.

Quote

>> 64 bytes of ColorRAM are not needed for SMS, only 32 bytes are needed.
> Yeah, but since it's 64 bytes for a full GG palette I figured the extra 32 bytes of space weren't going to kill anybody.

Baaaaaad ^_^

Quote

>> SaveRAM size should be speficicated, as it's entirely depending on the cartridge itself.
>> No need to save both pages everytime. Some cartridge uses on-board EEPROM with 128 bytes
>> of accessible data.
> Interesting. I wasn't aware of any way to tell the difference (aside from detected how much of the RAM was written to). Also, I think someone else critized this, but the format already does not save the 32k of SaveRAM if it's not used in that game. (or if it does but hasn't been paged in yet)

There is no tricky way to know what ROM uses what mapper. It's simply impossible because the mapper is hardware embedded in the cartridge, not in the ROM.
That's why when the NES format was defined it has an header containing the mapper number.
Now it's too late for us I guess, so uses checksuming for the roms that need it.
(or maintains a 1000 entry database like me :-)

Quote

> > FM Chipset register has to be saved (64 bytes)
> > As well as FM Chipset detection register
> > Port 0x3F has to be saved (1 byte)
> > Port 0xDF has to be saved (1 byte)
> Ok, these will be added. (I didn't think not saving 3F would have any adverse effects, since according to MASSAGE you can't IN the value OUTed to it, but it could be wrong) ..

What is read from the controller ports depend of port 3F because of nationalization.
Btw 3F also contains when read the lightgun bits, but it doesn't have to be saved.

Quote

>> SC-3000 peripherals specific stuff (like printer, cassete) has to be saved if used.
>> Which lead to a modular format.
> As I have no knowledge of the SC-3000, if you would like to send me a list of what needs to be saved in the case of that Machine type, I'll add it to the format specification.

I don't know myself, they are not emulated yet.

Quote

>> Weither Country should or not be saved is an interesting question. It is saved in Meka.
> The header already saves the Country.

Sorry I must have missed it.

Quote

>> Weither Image is odd or even need to be saved (1 bit.. 1 byte?)
> I'm confused.. what do you mean by image even or odd?

I'm not sure about the words myself. Let's say it is needed to distringuish images 0/2/4/6.. and 1/3/5/7.. when you plan to emulates the 3D glasses.

Quote

>> More than two Gear-to-Gear specific registers need to be saved for sure. Not quite sure which, thought.
> Well, I know there are more GameGear ports used in the serial IO thing (basically ports 0 through 6 need to be saved I guess). Actually, I'm surprised that slipped my mind. I guess that's because I added the GameGear stereo after I did the savestate format. Are there any more besides ports 0 through 6?

Not at my knowledge. Beside port 6 is no related to the Gear-to-Gear, it's stereo. Which I remind is not yet emulated in Meka.. hmm..

Quote

>> As for PSG stuff. The current state of the generated wave should be saved to have accurate save/load during a voice play.
> I'm not sure what you mean. It already saves snapshots of the volume/frequency/noisetable values. I know you need cycle-accurate timing for voices, but I didn't think you'd need them retroactively. You mean I should add a 'PC last modified' table for volume and frequency for each voice?

Kind of. The case must be worked on, I might have opened my mouth too early.

Quote

> Does anything additional need to be saved for lightgun, paddle, or any other of the more obscure peripherals?

Just as standard joypad the necessary data should be generated by the emulator at each frame.
Thinking about it, hmm.. I think Sportpad emulation requires an additionnal bit.
Having checked, it's not necessary.
Never mind.

Quote

> As for compressing the memory/vram/etc, that's exactly what the Extensions byte is for. Originally I was using ZLIB to compress those parts of the savestates, but I know there are emulators out there written in pure ASM that probably can't use ZLIB. For the time being, I didn't use compression in the CHASMS savestate to make it easier for anyone that's interested in getting the format to work. RLE is easier to implement, however. But, there are different ways of RLE formats, different ways of handling run tags and what not, so we'd have to settle of a standardized system and set of routines for handling them.

I haven't thought about it when answering to Charles, but you are right. For that kind of reason ZLIB shouldn't be used.
Defining our RLE system shouldn't be hard.

So long as I can use the files to help make trainers :)

MUG U.K (tm) - PC, Sega & PC Engine trainer maker!

Author	Message
Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Open Savegame Format Posted: Tue May 02, 2000 7:14 am
	(approximate trasnlation) File CHASM.EXE is linked to a missing exportation DINPUT.DLL: DirectInputCreateEx Still, I'm using DirectX 5 (not 4, I verified), so I'm not complaining :) About the open savegame format. Why by the hell do you say it is doubful that MEKA will support it ? Thanks. Now If I can comment on the principle of "open", this should have been discussed right here before even a first public use. Say, you are open to yourself, right? --Now my comments-- RAM size is dependant of the machine, and cartridge/mapper kind. 64 bytes of ColorRAM are not needed for SMS, only 32 bytes are needed. Some systems does not even have kind kind of memory (I'm talking about SG-1000 and SC-3000) SaveRAM size should be speficicated, as it's entirely depending on the cartridge itself. No need to save both pages everytime. Some cartridge uses on-board EEPROM with 128 bytes of accessible data. FM Chipset register has to be saved (64 bytes) As well as FM Chipset detection register Port 0x3F has to be saved (1 byte) Port 0xDF has to be saved (1 byte) SC-3000 peripherals specific stuff (like printer, cassete) has to be saved if used. Which lead to a modular format. Weither Country should or not be saved is an interesting question. It is saved in Meka. Technically, it should be saved to have zero chances to screw a game. Practically it's not really needed. Weither Image is odd or even need to be saved (1 bit.. 1 byte?) More than two Gear-to-Gear specific registers need to be saved for sure. Not quite sure which, thought. As for PSG stuff. The current state of the generated wave should be saved to have accurate save/load during a voice play.

Eric R. Quinn Joined: 18 Sep 1999 Posts: 498 Location: Portland, Oregon USA	Posted: Tue May 02, 2000 2:47 pm
	Quote > Port 0x3F has to be saved (1 byte) Zoop, could you elaborate on this? I know it has something to do with BIOS. For what it's worth, I think a lot of people would like to see the SMS BIOS released. We know there are features of the hardware that only it uses. (Specifically, how it manages to page itself into memory and then map the cartridge.) I think that numerous people studying the BIOS will give us an even clearer picture of how the hardware works. By the way, I'm all for a "open" SMS/GG/SG-1000/SC-3000 save state. I can't really help contribute right now, but I will offer one idea: The format should have a "header" which includes pointers to various sections of the file. This will allow for flexibility if certain sections grow, shrink, or disappear. Eric Quinn

ATani Guest	Posted: Tue May 02, 2000 3:27 pm
ATani Guest	Quote > By the way, I'm all for a "open" SMS/GG/SG-1000/SC-3000 save state. I can't really help contribute right now, but I will offer one idea: The format should have a "header" which includes pointers to various sections of the file. This will allow for flexibility if certain sections grow, shrink, or disappear. I agree completly. By having a header that is kinda set up in such a fashion that it tells file offsets and lengths of the fields it would probably work best. This would eliminate storing some data if it does not apply to a certain game. IE: Saving back up ram for Sonic. The game doesnt use it as far as i know and that would save 32k of space in the file. Atani

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Posted: Tue May 02, 2000 3:56 pm
	Quote >> By the way, I'm all for a "open" SMS/GG/SG-1000/SC-3000 save state. I can't really help contribute right now, but I will offer one idea: The format should have a "header" which includes pointers to various sections of the file. This will allow for flexibility if certain sections grow, shrink, or disappear. > I agree completly. By having a header that is kinda set up in such a fashion that it tells file offsets and lengths of the fields it would probably work best. This would eliminate storing some data if it does not apply to a certain game. IE: Saving back up ram for Sonic. The game doesnt use it as far as i know and that would save 32k of space in the file. RAM and VRAM should be RLE encoded. With a flag to disable RLE if needed.

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Posted: Tue May 02, 2000 3:58 pm
	Quote >> Port 0x3F has to be saved (1 byte) > Zoop, could you elaborate on this? I know it has something to do with BIOS. This is the nationalization port if I recall correctly. I haven't even thought about the BIOS when writing that line. Quote > For what it's worth, I think a lot of people would like to see the SMS BIOS released. We know there are features of the hardware that only it uses. (Specifically, how it manages to page itself into memory and then map the cartridge.) I think that numerous people studying the BIOS will give us an even clearer picture of how the hardware works. It copy a function to RAM, which write stuff to port 3Eh, check in C000h for a result then jump to 0000h. Basically all. Still, the BIOS will be released.

Eric R. Quinn Joined: 18 Sep 1999 Posts: 498 Location: Portland, Oregon USA	Posted: Tue May 02, 2000 4:43 pm
	Quote > >> Port 0x3F has to be saved (1 byte) > > Zoop, could you elaborate on this? I know it has something to do with BIOS. > This is the nationalization port if I recall correctly. > I haven't even thought about the BIOS when writing that line. Sorry, my mistake. I guess I don't know my SMS I/O ports that well :) Quote > > For what it's worth, I think a lot of people would like to see the SMS BIOS released. We know there are features of the hardware that only it uses. (Specifically, how it manages to page itself into memory and then map the cartridge.) I think that numerous people studying the BIOS will give us an even clearer picture of how the hardware works. > It copy a function to RAM, which write stuff to port 3Eh, check in C000h for a result then jump to 0000h. > Basically all. > Still, the BIOS will be released. O.k., thanks. Eric Quinn

Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Posted: Tue May 02, 2000 4:50 pm
Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Quote > >> By the way, I'm all for a "open" SMS/GG/SG-1000/SC-3000 save state. I can't really help contribute right now, but I will offer one idea: The format should have a "header" which includes pointers to various sections of the file. This will allow for flexibility if certain sections grow, shrink, or disappear. > > I agree completly. By having a header that is kinda set up in such a fashion that it tells file offsets and lengths of the fields it would probably work best. This would eliminate storing some data if it does not apply to a certain game. IE: Saving back up ram for Sonic. The game doesnt use it as far as i know and that would save 32k of space in the file. > RAM and VRAM should be RLE encoded. With a flag to disable RLE if needed. IMO, it's better to use "standard" compression like the kind offered by zlib. RLE is OK for repetitive data, but you probably wouldn't get optimal results. Regarding the save state, it might be useful to have something with tagged sections (like an LBM file), so emulators can process the sections they need (ram, psg state) and ignore the ones they don't handle (FM chip, odd peripheral, etc.) There's already something like that for the NES, people who are interested should check this link out: http://www.nofrendo.org/snss/index.html Of course the SMS doesn't have as many variations on the cart hardware as the NES, but nevertheless it's a very flexible way to handle data across various emulators. Plus, there's no problem of old states not working when a new section is added, since the routine that parses the save state data can just ignore sections it doesn't recognize. My Homepage

vecna Guest	Posted: Tue May 02, 2000 5:12 pm
vecna Guest	Quote > File CHASM.EXE is linked to a missing exportation DINPUT.DLL: DirectInputCreateEx Gahgah! Well, a friend of mine who refuses to upgrade from NT4 to Win2k is going to make CHASMS DX3 compatible, so this problem will go away in the next version. Honest. ^_~ Quote > Why by the hell do you say it is doubful that MEKA will support it ? I apologize. I seriously didn't mean anything by it, I just figured that you've made MEKA propietary in so many other aspects, you probably wouldn't go for this either. I'd be delighted if you'd support it. Quote > Now If I can comment on the principle of "open", this should have been discussed right here > before even a first public use. Say, you are open to yourself, right? Yes, you're absolutely right. I intended to do this actually, but I've been sitting on this thing for a while and with finals and what not, it skipped my mind. Anyhow, this is exactly what the version number and extensions field is for. ^_~ Quote > RAM size is dependant of the machine, and cartridge/mapper kind. Dependant by machine: Right, since CHASMS doesn't emulate all the SC* and SG* (I don't even know how many of them exist :o) I haven't incorporated anything for savestate support for this. There's ... what, an SC-1000, SC-3000, and SG-1000 or something like that? How much RAM does each have? the RAM size can vary according to the Machine byte. How does the RAM size vary by cartridge/mappers? Are you talking about SaveRAM? This is addressed in a seperate field. Quote > 64 bytes of ColorRAM are not needed for SMS, only 32 bytes are needed. Yeah, but since it's 64 bytes for a full GG palette I figured the extra 32 bytes of space weren't going to kill anybody. Quote > Some systems does not even have kind kind of memory (I'm talking about SG-1000 and SC-3000) Huh. Weird. Well, again, the format can be modified based on the Machine state. Quote > SaveRAM size should be speficicated, as it's entirely depending on the cartridge itself. > No need to save both pages everytime. Some cartridge uses on-board EEPROM with 128 bytes > of accessible data. Interesting. I wasn't aware of any way to tell the difference (aside from detected how much of the RAM was written to). Also, I think someone else critized this, but the format already does not save the 32k of SaveRAM if it's not used in that game. (or if it does but hasn't been paged in yet) Quote > FM Chipset register has to be saved (64 bytes) > As well as FM Chipset detection register > Port 0x3F has to be saved (1 byte) > Port 0xDF has to be saved (1 byte) Ok, these will be added. (I didn't think not saving 3F would have any adverse effects, since according to MASSAGE you can't IN the value OUTed to it, but it could be wrong) .. I don't even know what DF does, but I'll add it anyhow. Quote > SC-3000 peripherals specific stuff (like printer, cassete) has to be saved if used. > Which lead to a modular format. As I have no knowledge of the SC-3000, if you would like to send me a list of what needs to be saved in the case of that Machine type, I'll add it to the format specification. Quote > Weither Country should or not be saved is an interesting question. It is saved in Meka. The header already saves the Country. Quote > Weither Image is odd or even need to be saved (1 bit.. 1 byte?) I'm confused.. what do you mean by image even or odd? Quote > More than two Gear-to-Gear specific registers need to be saved for sure. Not quite sure which, thought. Well, I know there are more GameGear ports used in the serial IO thing (basically ports 0 through 6 need to be saved I guess). Actually, I'm surprised that slipped my mind. I guess that's because I added the GameGear stereo after I did the savestate format. Are there any more besides ports 0 through 6? Quote > As for PSG stuff. The current state of the generated wave should be saved to have accurate save/load during a voice play. I'm not sure what you mean. It already saves snapshots of the volume/frequency/noisetable values. I know you need cycle-accurate timing for voices, but I didn't think you'd need them retroactively. You mean I should add a 'PC last modified' table for volume and frequency for each voice? Does anything additional need to be saved for lightgun, paddle, or any other of the more obscure peripherals? As for compressing the memory/vram/etc, that's exactly what the Extensions byte is for. Originally I was using ZLIB to compress those parts of the savestates, but I know there are emulators out there written in pure ASM that probably can't use ZLIB. For the time being, I didn't use compression in the CHASMS savestate to make it easier for anyone that's interested in getting the format to work. RLE is easier to implement, however. But, there are different ways of RLE formats, different ways of handling run tags and what not, so we'd have to settle of a standardized system and set of routines for handling them. - vecna

vecna Guest	Posted: Tue May 02, 2000 5:29 pm
vecna Guest	Quote > IMO, it's better to use "standard" compression like the kind > offered by zlib. RLE is OK for repetitive data, but you probably > wouldn't get optimal results. Yeah, this is why I haven't used any compression in the savestates yet. I was using ZLIB for mine, so this makes sense from my perspective. This is what I was reserving the Extensions byte for. Quote > Regarding the save state, it might be useful to have something > with tagged sections (like an LBM file), so emulators can > process the sections they need (ram, psg state) and ignore > the ones they don't handle (FM chip, odd peripheral, etc.) Hmm... this is a good idea. I think I like the tagged sections better than having a big offset table in the header. Otherwise the table itself would also have to grow if a section was added.. and you're right, an emulator can just skip a tag it doesn't understand. I'll definitely put this in the format revision. Thanks for pointing that out. - vecna

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Posted: Tue May 02, 2000 7:55 pm
	Quote > IMO, it's better to use "standard" compression like the kind > offered by zlib. RLE is OK for repetitive data, but you probably > wouldn't get optimal results. It's sufficient to reduce the size of the file of quite a lot compared to what it is. About 25kb could reduce to 10 or 15 kb. We don't need smaller as long as it fit in a cluster ^_^

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Lot of stuff Posted: Tue May 02, 2000 8:17 pm
	Quote > > File CHASM.EXE is linked to a missing exportation DINPUT.DLL: DirectInputCreateEx > Gahgah! Well, a friend of mine who refuses to upgrade from NT4 to Win2k is going to make CHASMS DX3 compatible, so this problem will go away in the next version. Honest. ^_~ Great ^_^ I'll be able to try it. If it run well on my machine I might even consider installing Visual C to finish that damned port. Last week I ported Meka to FreeBSD to play at school. It's slow on 16-bit X Servers due to palette uses which are nonsense in 16-bit modes, but in 8-bit it runs very fine just as on DOS. Quote >> Why by the hell do you say it is doubful that MEKA will support it ? > I apologize. I seriously didn't mean anything by it, I just figured that you've made MEKA propietary in so many other aspects, you probably wouldn't go for this either. Meka is proprietary because it's a pile of badly written shit. When I started it I didn't even know what was a list of a pointer. As a result some piece of codes are very smart (pardon my arrogance ;) and some would shock you because how unefficient they are (i'm thinking about the GUI). Adding that to the fact adding more systems and fixing all games lead to a few tricks here and tricks it's ugly, compared to what I could do now if I had an empty month. My checksum routine isn't even a checksum, etc. In Meka2 I'll try to have everything open - or re-use already defined format if available by the time. Quote > I'd be delighted if you'd support it. Assuming it fits Meka needs/restrictions I will. Quote >> Now If I can comment on the principle of "open", this should have been discussed right here >> before even a first public use. Say, you are open to yourself, right? >> RAM size is dependant of the machine, and cartridge/mapper kind. > Dependant by machine: Right, since CHASMS doesn't emulate all the SC* and SG* (I don't even know how many of them exist :o) I haven't incorporated anything for savestate support for this. There's ... what, an SC-1000, SC-3000, and SG-1000 or something like that? How much RAM does each have? the RAM size can vary according to the Machine byte. SG-1000 = Sega Game 1000 SC-3000 = Sega Computer 3000 they are exactly the same machine expect that SC-3000 have a keyboard by default and port for a printer and audio ports for cassette. Sega Super Control Station (SF-7000) add a Centronics printer port and a 3" drive and connect throught the cartridge port. Both machines have 4 kb of RAM. But some cartridges have on-board RAM, etc. Meka implement 8 of what I call mappers: Standard (with optional SaveRAM as you know it) 32 kb of onboard RAM Colecovision (remember when I told you about Meka being a pile of tricky shit? ^_^) CodeMasters Cartridge with onboard 93c46 EEPROM SG-1000/SC-3000 (4 kb of RAM) ActionReplay (in development) Graphic Board (because it read/write to special location in memory) Quote > How does the RAM size vary by cartridge/mappers? Are you talking about SaveRAM? This is addressed in a seperate field. Now I was talking about RAM in general. Beside each mappers requires different custom data. For exemple, when you are storing 0xFFFC to 0xFFFF byte, keep in mind it is directly related to the current mapper. CodeMasters cartridges does not have any uses of them, for exemple. Quote >> 64 bytes of ColorRAM are not needed for SMS, only 32 bytes are needed. > Yeah, but since it's 64 bytes for a full GG palette I figured the extra 32 bytes of space weren't going to kill anybody. Baaaaaad ^_^ Quote >> SaveRAM size should be speficicated, as it's entirely depending on the cartridge itself. >> No need to save both pages everytime. Some cartridge uses on-board EEPROM with 128 bytes >> of accessible data. > Interesting. I wasn't aware of any way to tell the difference (aside from detected how much of the RAM was written to). Also, I think someone else critized this, but the format already does not save the 32k of SaveRAM if it's not used in that game. (or if it does but hasn't been paged in yet) There is no tricky way to know what ROM uses what mapper. It's simply impossible because the mapper is hardware embedded in the cartridge, not in the ROM. That's why when the NES format was defined it has an header containing the mapper number. Now it's too late for us I guess, so uses checksuming for the roms that need it. (or maintains a 1000 entry database like me :-) Quote > > FM Chipset register has to be saved (64 bytes) > > As well as FM Chipset detection register > > Port 0x3F has to be saved (1 byte) > > Port 0xDF has to be saved (1 byte) > Ok, these will be added. (I didn't think not saving 3F would have any adverse effects, since according to MASSAGE you can't IN the value OUTed to it, but it could be wrong) .. What is read from the controller ports depend of port 3F because of nationalization. Btw 3F also contains when read the lightgun bits, but it doesn't have to be saved. Quote >> SC-3000 peripherals specific stuff (like printer, cassete) has to be saved if used. >> Which lead to a modular format. > As I have no knowledge of the SC-3000, if you would like to send me a list of what needs to be saved in the case of that Machine type, I'll add it to the format specification. I don't know myself, they are not emulated yet. Quote >> Weither Country should or not be saved is an interesting question. It is saved in Meka. > The header already saves the Country. Sorry I must have missed it. Quote >> Weither Image is odd or even need to be saved (1 bit.. 1 byte?) > I'm confused.. what do you mean by image even or odd? I'm not sure about the words myself. Let's say it is needed to distringuish images 0/2/4/6.. and 1/3/5/7.. when you plan to emulates the 3D glasses. Quote >> More than two Gear-to-Gear specific registers need to be saved for sure. Not quite sure which, thought. > Well, I know there are more GameGear ports used in the serial IO thing (basically ports 0 through 6 need to be saved I guess). Actually, I'm surprised that slipped my mind. I guess that's because I added the GameGear stereo after I did the savestate format. Are there any more besides ports 0 through 6? Not at my knowledge. Beside port 6 is no related to the Gear-to-Gear, it's stereo. Which I remind is not yet emulated in Meka.. hmm.. Quote >> As for PSG stuff. The current state of the generated wave should be saved to have accurate save/load during a voice play. > I'm not sure what you mean. It already saves snapshots of the volume/frequency/noisetable values. I know you need cycle-accurate timing for voices, but I didn't think you'd need them retroactively. You mean I should add a 'PC last modified' table for volume and frequency for each voice? Kind of. The case must be worked on, I might have opened my mouth too early. Quote > Does anything additional need to be saved for lightgun, paddle, or any other of the more obscure peripherals? Just as standard joypad the necessary data should be generated by the emulator at each frame. Thinking about it, hmm.. I think Sportpad emulation requires an additionnal bit. Having checked, it's not necessary. Never mind. Quote > As for compressing the memory/vram/etc, that's exactly what the Extensions byte is for. Originally I was using ZLIB to compress those parts of the savestates, but I know there are emulators out there written in pure ASM that probably can't use ZLIB. For the time being, I didn't use compression in the CHASMS savestate to make it easier for anyone that's interested in getting the format to work. RLE is easier to implement, however. But, there are different ways of RLE formats, different ways of handling run tags and what not, so we'd have to settle of a standardized system and set of routines for handling them. I haven't thought about it when answering to Charles, but you are right. For that kind of reason ZLIB shouldn't be used. Defining our RLE system shouldn't be hard.

MUG U.K(tm) Guest	Posted: Wed Jun 07, 2000 9:48 pm
MUG U.K(tm) Guest	So long as I can use the files to help make trainers :) MUG U.K (tm) - PC, Sega & PC Engine trainer maker!

Forums

View topic - Open Savegame Format