|
ForumsSega Master System / Mark III / Game GearSG-1000 / SC-3000 / SF-7000 / OMV |
Home - Forums - Games - Scans - Maps - Cheats - Credits Music - Videos - Development - Hacks - Translations - Homebrew |
Author | Message |
---|---|
|
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. |
|
|
Posted: Tue May 02, 2000 2:47 pm |
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
|
Posted: Tue May 02, 2000 3:27 pm |
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 |
|
|
Posted: Tue May 02, 2000 3:56 pm |
RAM and VRAM should be RLE encoded. With a flag to disable RLE if needed. |
|
|
Posted: Tue May 02, 2000 3:58 pm |
This is the nationalization port if I recall correctly. I haven't even thought about the BIOS when writing that line.
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. |
|
|
Posted: Tue May 02, 2000 4:43 pm |
Sorry, my mistake. I guess I don't know my SMS I/O ports that well :)
O.k., thanks. Eric Quinn |
|
|
Posted: Tue May 02, 2000 4:50 pm |
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. |
|
vecna
|
Posted: Tue May 02, 2000 5:12 pm |
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. ^_~
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.
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. ^_~
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.
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.
Huh. Weird. Well, again, the format can be modified based on the Machine state.
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)
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.
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.
The header already saves the Country.
I'm confused.. what do you mean by image even or odd?
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?
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
|
Posted: Tue May 02, 2000 5:29 pm |
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.
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 |
|
|
Posted: Tue May 02, 2000 7:55 pm |
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 ^_^ |
|
|
Lot of stuff
Posted: Tue May 02, 2000 8:17 pm
|
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.
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.
Assuming it fits Meka needs/restrictions I will.
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)
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.
Baaaaaad ^_^
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 :-)
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.
I don't know myself, they are not emulated yet.
Sorry I must have missed it.
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.
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..
Kind of. The case must be worked on, I might have opened my mouth too early.
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.
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)
|
Posted: Wed Jun 07, 2000 9:48 pm |
So long as I can use the files to help make trainers :)
|
|