Cadaver Save Disk
 

we have a contributor whos unable to save his game of Cadaver when using the IPF version.

its an interesting issue, he's tried creating a custom disk but it refeuses to save to it, is this a known issue, is there some specific disk that was distributed with this game solely for the purpose of saving on to?

not at all, well maybe a coder should check the save routine, but even the whdload coder didn't find any bug on save.

Does this guy own a version that we don't have already ?

its SPS ID 103.

The subway-spreadpoint crack says that there's a bug with the original games save routine.

It's probably better to use v1.03. Just checked the WHDLoad Readme.

It's normal then ?

nothing here says the savegame doesnt work though, just that it uses mfm.

in theory, it still worked on the real thing. so is this a winuae issue not being able to create the save disk in the correct way?

the guy must use the custom ADF option in winuae to create the MFM save disk.

check the first post ;)

if it works on a real machine it should work on winuae.

If this guy has a save disk already done on his amiga, then he should use RAWREAD,
to generate an extended ADF of the disk.

Something must be wrong somewhere....

Hello again, i have found what the reason is !

In fact, under winuae, the custom track length max when writing is $317C when Cadaver seems to need longer tracks than that (like $1800 in length or something).

You'll see that my extended ADF savedisk uses $3390 instead of $317C ;)

Please find a WORKING save disk in custom ADF in the zone. I have tested it myself, it works like a charm :D !!!

This means game requires slower real floppy drive rotation speed than standard or saving may fail? :)

thanks for the save disk....

i was kinda hoping to highlight and resolve a problem though, according to this thread right now if you owned an original release of cadaver you couldnt save your game at all, (since amiga drive speeds are not adjustable)

can anyone confirm this? seems a bit unlikely....but strange things do happen.

I'll check the save routine "soon". (maybe today, maybe not)

Toni, the standard max track length ($317C) used in winuae is not enough to create some save games. The save loading routine tries to format tracks longer than winuae in standard allow. It means that when loading back, the game sees $317C in length, when it should find $3390 or maybe a bit less if the process went right.

I have created this custom ADF with the custom floppy_write_length value setted to
0x3390 instead of 0x317C.

And it works. It means maybe that the nice option you have included when i asked you for it must be incorporated as "standard".

It works very well and doesn't make the games bugging when loading.
I have use your option on games like Killing game show, allowing me to create extended ADF and propose it when the IPF of it is not yet available for the reason we know.

No. Standard 300RPM drive can't write more than the current max. Bigger value WILL break other programs.

Do you mean that the cadaver save disk, which is created by a standard amiga drive
is impossible to copy ?

I can't agree with you Toni here. Or then please disassemble the save routine and tell what it does to the drive, and we'll be aware of what is really going on.

I stay on the fact that it's not normal that a standard amiga drive can CREATE the disk,
and that winuae CAN'T in standard.

Just look at cannon fodder save disk, a standard amiga drive write $1800 per track,
with a $4489 sync !!

The save routine can't work with the standard length used by winuae ($317C both sides or $18BE which is too small. That's why the guy says it doesn't work when he try to save !.

My guess is this : the save routine before saving datas in MFM encoding, must prepare the track structure. the routine try to
set more than $3190 + ~ - in length, or the problem with winuae is that it cuts at 317C. When loading back the routine finds
tracks with 317C$ in length instead of the size it has bought to save and create before. The result is that it's failing.

Winuae makes clearly the difference between a standard save routine, and a custom one. a program made to use a standard routine will use winuae standard track length and it will work.

When 0x3390 is enabled in the config file, it simply break the barrier of writing, it doesn't bug anything in standard DOS writting scheme.

At last, you know like me that's it's impossible to slow down a drive on amiga by software means, interceptor do you confirm this ?

Your system is working Toni, i have tested it carefully, and it works with all programs DOS or NDOS without breaking anything. thanks to you we have now unavailable games :D !!!

I only say the routine is buggy (or it uses NTSC max which is slightly more due to higher clock) if it tries to write more data because standard drive + Amiga can't write that much data (some drives run faster, some slower so it can work in some cases)

I won't change this.

There is nothing to change in winuae Toni. the system works very well.
My amiga with a standard drive can CREATE cannon fodder savedisk and cadaver too.
Winuae can't because $317C is not enough in size.

My drives can write $3180 with wwarp for example. See ?

Or it could mean that the amiga drive CAN be slowed down to write more.
317C is less than a real amiga drive can write.

Please check the save disk i put in the zone, and check the size of data written per track.

So? It still is faulty save routine, you should always leave enough spare (gap) when writing because no drive is same. There will be real drives that can't work with this routine.