Save Game Manager for SEGA Saturn

[Pyrite]

"- allow flashing the cartridge with the SGM

-> no swap trick needed anymore

(It wouldn't have a cheat function,

but if we could read/write the AR save game format with SGM,

it would be a cool replacement)"

That would be great but I have one question about the satellite function I could care less about the cheats and its dreadful menus but the satellite function is very useful is it controlled by the firmware?

 

[RockinB]

Originally posted by Mr^Burns+Sat, 2005-09-03 @ 04:25 PM--><div class='quotetop'>QUOTE(Mr^Burns @ Sat, 2005-09-03 @ 04:25 PM)</div><div class='quotemain'>If there are anyother cheapskates like me trying to run this off CDRW and not getting it to work , try adding a dummy file to the iso and it will work , worked for me but i donno it might just have been my ancient RW

[post=139120]Quoted post[/post]​

[/b]

You mean you inserted a file INTO the data track of the ISO image? Hmmmmm, I do all my tests with CD-RW. From my experience I can say that the CD-RW modded Saturn doesn't read CD-RW such reliable as it does read CD-R. The laser got problems to find the right adjustment.

If that happens, whether it be while booting or in SGM loading a file from CD, stop the CD and let it spin again.

The more often you burned the same CD-RW, the more read problems will occur. So it does depend heavily on the quality of the CD-RW and the CD burner as well.

Apart from that, I don't know why you had to do this...

<!--QuoteBegin-Zheræ@Sat, 2005-09-03 @ 04:38 PM

"- allow flashing the cartridge with the SGM

-> no swap trick needed anymore

(It wouldn't have a cheat function,

but if we could read/write the AR save game format with SGM,

it would be a cool replacement)"

That would be great but I have one question about the satellite function I could care less about the cheats and its dreadful menus but the satellite function is very useful is it controlled by the firmware?

[post=139122]Quoted post[/post]​

[/quote]

That's ExCyber's business. But I do think the same. If ExCyber will take up this task, we could keep more or even all original functions of the AR.

 

[KuKzz]

Here's a silly idea: could we dump small saves to the screen in base64 (maybe with per-line hashes to avoid hair-pulling over typos)? I know most Saturn saves aren't really that huge (the internal SRAM is only 32KB). This post up through this sentence is roughly 1KB; here's what it looks like in base64:

Hehe,I remember in 3DO GameGuru you could transfer saves by inputting command on controller (it would say - left, right, a,a,b... and so on). It was basically the only way to transfer saves from one 3DO to another (as memory cards ar almost impossible to find), but I never tryed it .

 

[RockinB]

Originally posted by KuKzz@Sat, 2005-09-03 @ 10:37 PM

Hehe,I remember in 3DO GameGuru you could transfer saves by inputting command on controller (it would say - left, right, a,a,b... and so on). It was basically the only way to transfer saves from one 3DO to another (as memory cards ar almost impossible to find), but I never tryed it .

[post=139135]Quoted post[/post]​

Cool!

It would make sense to use different methods for transfering from Saturn to PC and vice versa. Because input peripherals differ.

So it would make sense using base64 to get save games out

and instead use pad button commands to get files into Saturn.

I just thought if I could let the Saturn SPELL the base 64 encoding, so you could hear it on speakers.

That would be cool with a voice recognition software. You turn it on, leave the room for a drink until it's finished. :thumbs-up:

Any software known to recognize spelling?

Unfortunately, this could not be used to get saves to Saturn.

 

[KuKzz]

IIRC that's how it worked. You turn on 2 3DO systems, launch gameguru on both, set on to receive and one to send. Then transfering system would spell commands on controller and you must input them on second system.

But i never tryed it (not owned 2 3do systems back in time and it would probably require 1 hour or so for save ).

 

[madmalkav]

How hard will get saturn to output stuff throught pad port to a db25 conector and read it on pc?

 

[ExCyber]

Originally posted by Rockin'-B+--><div class='quotetop'>QUOTE(Rockin'-B)</div><div class='quotemain'>Aside from base64, I've read about a more efficient textual encoding method years ago. It's been mentioned to reduce mail attachments significantly, but I can't remember it's name.[/b]

Sounds like you're thinking of yENC, which is much more efficient but requires 8-bit clean transmission, which isn't really feasible on a keyboard. base64 is nice in that it encodes a power of two character set (exactly 6 bits per character) and can be typed on just about any keyboard that can type English.

Originally posted by Rockin'-B+--><div class='quotetop'>QUOTE(Rockin'-B)</div><div class='quotemain'>It would make sense to use different methods for transfering from Saturn to PC and vice versa. Because input peripherals differ.

So it would make sense using base64 to get save games out

and instead use pad button commands to get files into Saturn.[/b]

The principle seems sound, although it's not clear to me that pad buttons would really be faster than typing on an onscreen keyboard, simply because you would have to input so many of them. A standard Saturn pad only has 13 characters compared to 64 for base64, so encoding for pad input would mean a much larger input text. I think if we got an efficient layout (a 6x6 grid with a shift key seems like a start) for an onscreen keyboard the advantage of being able to hit pad buttons faster would quickly fade.

<!--QuoteBegin-Zheræ@

I could care less about the cheats and its dreadful menus but the satellite function is very useful is it controlled by the firmware?[/quote]Yes.

<!--QuoteBegin-madmalkav

How hard will get saturn to output stuff throught pad port to a db25 conector and read it on pc?[/quote]It shouldn't be especially tough if someone wants to do it. The biggest problem is getting the connector.

 

[RockinB]

I've started to blind-code some new features.

The pad button input and output is using 8 buttons with a shift button for the sake of code simplicity. So I can access nibbles of data directly.

A memory viewer has been implemented, too. Usefull for selecting the RAM range for AR firmware dumping.

What I'm stuck is the base64 thing. This sourcecode is written in cweb which is new to me. I have to build the tools from source first. Ah...wait....I just found a prebuild executable tool. Anyways, this source is far more unreadable. I doubt every claim the author states.

 

[RockinB]

A compression ratio example:

SEGA Touring Car (jp)

consists of files:

records (222 blocks)

versus AI (49 blocks)

and in case you got a backup memory cart:

ghosts 1-5 (each 942 blocks)

= 4981 blocks total

--> your memory cart is almost full

Now saving these files as a compressed file

results in a size of 490 blocks, which is just 9.84 percent of original summed filesize.

Ideas:

I'm currently trying to beat some of VBT's highscores .

As an extension to the highscore table in the web, we could share ghost car files and drive against them!

What you think?

There are some popular racing games which save ghosts (or maybe even allow saving of replays).

With the new base64 feature, everyone can dump the ghost files.

Feature ideas:

- support for custom filenames for compressed virtual drives

- for people like me who don't always have a working battery inside the saturn

(-> save games won't be kept in backup RAM):

An option to assign a default compressed virtual drive to be uncompressed into system memory automatically.

Maybe this is only useful if 2 other features are implemented: flashing AR with SGM and access of AR save games.

 

[kahuna]

Originally posted by Rockin'-B@Thu, 2005-09-08 @ 12:59 PM

Feature ideas:

- support for custom filenames for compressed virtual drives

- for people like me who don't always have a working battery inside the saturn

(-> save games won't be kept in backup RAM):

An option to assign a default compressed virtual drive to be uncompressed into system memory automatically.

Maybe this is only useful if 2 other features are implemented: flashing AR with SGM and access of AR save games.

[post=139369]Quoted post[/post]​

I'd like to see both features, but the most important one, and maybe the easiest for you to implement would be the naming of virtual drives. I'd like to know what's on a virtual drive before I uncompress it. The names would also be useful for categorizing the drives like "fighting","racing","rpg".

 

[AmyGrrl]

Originally posted by kahuna@Thu, 2005-09-08 @ 02:40 PM

I'd like to see both features, but the most important one, and maybe the easiest for you to implement would be the naming of virtual drives. I'd like to know what's on a virtual drive before I uncompress it. The names would also be useful for categorizing the drives like "fighting","racing","rpg".

[post=139371]Quoted post[/post]​

I agree, I think direct AR support and being able to name a virtual drive would be great. Some pretty kewl tools are coming out for the saturn... I love it... =^_^=

 

[RockinB]

Additional compression examples:

Daytona USA CE (jp, Xband):

records file 64 blocks

ghosts file 965

-> compressed size 322 blocks which is 31.29 percent of 1029 blocks

Manx TT Superbike (jp):

record file 81 blocks

4x ghost file each 470 blocks

-> compressed size 764 blocks which is 38.96 percent of 1961 blocks

Which other games got big save files or optional replay/ghost saves?

SEGA Rally

Fighting Vipers?

 

[Zaksund]

Heh, there's always Virtual On. Good luck holding more than 2 match replays in memory at a time in that game.

 

[vbt]

Originally posted by Rockin'-B@Thu, 2005-09-08 @ 07:59 PM

Ideas:

I'm currently trying to beat some of VBT's highscores .

It's almost impossible on some games :lol:

As an extension to the highscore table in the web, we could share ghost car files and drive against them!

What you think?

Nice idea, I'll see how to add this feature I can export all my game saves. I think the only drawback is that people need a PAR. Don't hesitate to send yours, I'll put them and update the site.

 

[RockinB]

Another compression example:

SEGA Rally (second best to SEGA Touring car)

records file: 80 blocks

ghost file: 977 blocks

uncompressed size: 1057 blocks

-> compressed size: 165 blocks

-> ratio: 15.61 percent

Originally posted by vbt+Tue, 2005-09-13 @ 07:31 PM--><div class='quotetop'>QUOTE(vbt @ Tue, 2005-09-13 @ 07:31 PM)</div><div class='quotemain'>

I'm currently trying to beat some of VBT's highscores

It's almost impossible on some games :lol:

[/b]

Unfortunatly that's right. It's your luck that all my racing savegames are lost and I had to start from zero again.

But I could improve my records significantly and I get closer and closer...

<!--QuoteBegin-vbt@Tue, 2005-09-13 @ 07:31 PM

As an extension to the highscore table in the web, we could share ghost car files and drive against them!

What you think?

Nice idea, I'll see how to add this feature I can export all my game saves. I think the only drawback is that people need a PAR. Don't hesitate to send yours, I'll put them and update the site.

[post=139580]Quoted post[/post]​

[/quote]

For PAR dumped save games, we need a tool to remove the zero bytes that have been added. I don't know if Slinga cared about that with his SaveGameCopier.

Anyways, what I'm talking about is dumping base64 encoded save games with your PC keyboard (No PAR required!). These text files can be burned directly on CD and decoded in Save Game Manager. No external tools needed.

Because these text files can be posted in forums easily, I'm planning to make a save game forum at my board.

I'm currently driving SEGA Rally, SEGA Touring Car, Manx TT Superbike, GT24, Daytona USA CE.

All their save games and more are on my backup memory cart (compressed).

So I will dump those and put them on my next SGM release CD.

 

[RockinB]

WIP info:

I've added a nice top level menu, which can access all (new and old) functions of the new SGM.

The button meanings of the original SGM app have not changed.

Flashing AR with any file/firmware is implemented, as well as dumping the AR firmware (or memory in general) to a file.

Custom file names and comments for compressed archives, memory dumps and button code save game import is done (adapted from MineSweeper ).

The Memory Viewer, button code viewer/editor to import/export saves with the control pad are pretty far.

Now I started doing the base64 encode/decode feature.

I'll proceed tomorrow witht that.

 

[RockinB]

Sorry guys, but i found a

edit: calm down, I could verify there is no error.

FATAL ERROR IN THE SAVE GAME MANAGER !!!

You MUST STOP using it now, until the new version is out!

(Anything saved to a virtual drive can most likely be lost)

Don't get my wrong, I have used the SGM (original released version) a lot myself and have not found any error in my files yet.

It might be possible that no error occurs, but it can not be guaranteed, that any data written to a virtual drive is preserved as is.

So I hope when I unpack all the compressed files I made before, that all file data is like it should be.

I discovered memory errors in my new version and this way I found the problem.

Sorry again, I hope your files are not lost .

 

[RockinB]

I'm almost finished with the new version. All new features are in, I just need to fix some base64 stuff and possibly make a special viewer for base64 text files (currently just use the memory viewer).

So please, I need beta testers to try out the new SGM! Raise your hand and help me!

 

[RockinB]

NO BUG IN SGM!

I was just kidding .

No, while being under the shower, I got the idea that possibly the error is totally neutralized in the original SGM and thus being not present at all.

So I had a look and yes, the bug neutralizes itself absolutely. Only new things in my WIP version made it become a bug.

So I'm very happy :banana , because what I dislike most is bugs in my programs .

 

[vbt]

Originally posted by Rockin'-B@Sat, 2005-09-17 @ 04:14 PM

NO BUG IN SGM!

I was just kidding .

No, while being under the shower, I got the idea that possibly the error is totally neutralized in the original SGM and thus being not present at all.

So I had a look and yes, the bug neutralizes itself absolutely. Only new things in my WIP version made it become a bug.

So I'm very happy :banana , because what I dislike most is bugs in my programs .

[post=139694]Quoted post[/post]​

Good news, do you still need testers ?