Great Giana Sisters SPS IPF bug?

[AmigaFan]

When played in WinUAE, the game crashes if you press the left mouse button to save your highscore. If the disk is not write-protected, the score is saved (you can see it in the highscore list next time you play the game); but it crashes whether write protection is on or not. Is it supposed to be that way?

[IFW]

It indeed crashes with write protection. You can always press the fire button on the joystick to skip high-score writing.

But it shouldn't be this way.

[Toni Wilen]

First, I don't see any crashes, only continuous reading of track 151.

I don't see anything obvious except after saving (which works fine), it tries to read track 151.

Perhaps there is something wrong with track 151. (which is not read if highscore is not saved, without saving it reads 149 and 150)

[AmigaFan]

Ok, it doesn't crash; the screen turns black and the sound loops, and it doesn't return to the title screen if you press the left mouse button (no matter if write protection is on or off). So is that a bug of the original game then or is the SPS disk image faulty?

[redblade]

I like the high score tune. It's one of my favourites the other being the Rainbow Islands high score tune

[IFW]

It seems that seeking randomly fails.
The game tries to read track 74.1 but where the head is when it fails is 75.1... the game infinitely retries and fails forever as the expected track is different from the current one.

Sometimes, saving does work...

It's unclear whether this is a bug in the game code or uae.

[Supamax]

It seems that seeking randomly fails.
The game tries to read track 74.1 but where the head is when it fails is 75.1... the game infinitely retries and fails forever as the expected track is different from the current one.

Sometimes, saving does work...

It's unclear whether this is a bug in the game code or uae.

If it's not too protected, perhaps Denis can copy it (with his original PowerCopy Pro) to a real floppy and test it on a real Amiga.
This would clarify if it happens in WinUAE only (I don't think so).

[Toni Wilen]

This could be caused by another undocumented floppy drive "feature", skip stepping if it happens soon after writing ends.

Game does appear to have unexplained step in write routine (few tens of cycles after write ends) and it works if it is ignored..

[mr.vince]

Ok, just to clarify, I did test this problem with an original copy (yes, an original copy I dared to put into the drive even though I know how much it's worth) and a disk with the IPF image written back to it (Cyclone20).

I did find out that there IS a difference between both.

Original: First, when loading each level, I can hear the drive doing a step-o-rama. This also happens when dying on the very same level. It steps around, then the level starts.

Saving the highscore DOES work. It works with a write protected or none write protected disk. It simply will not save anything onto a write protected disk.

Copy: Does not do the step-o-rama when restarting a level.

Saving the highscore DOES NOT work. Sorry, have to clarify this: it DOES save the highscore (edit: not sure about this, will investigate), but it's dead afterwards. So I assume the problem is not with saving the highscore. It is with what ever comes AFTER this. Maybe the head is in a wrong position, not sure. Or this is part of the protection system? But it does indeed save the highscore, you just have to restart the machine...

So. I am really wondering. Seems like the IPF is missing something, the original disk has. Or it has it, but is not written by Cyclone20. And: It's not emulated correctly by WinUAE with does the same. I assume, it might just be a specialty of the disk that is missing in the image. What makes me wonder is that the highscore can be saved. So. Confused... :)

[mr.vince]

Sorry for back to back post, BUT:

As it seems the problem does not arise at the point where it saves. I did test what happens when booting with version A and then swapping disks.

When booting from the original, saving will work on the copy. When booting from the copy, saving will not work on the original.

Also: depending on which version I do boot, the drive noise vanishes or comes back. The original that can save does do the drive see-o-rama all the time, the IPF version is silent...

Vague theory: Could it simply be we have two versions on the market? One with a save highscore bug (but "silent loading") and one with the highscore working (but drive noise, added because of changes made to fix the problem)? Might explain why the version you found was not modified... :)

Will try and make an X-Copy backup to see if this might be part of a copy protection (just think the two versions theory is a bit odd).

Best,
Chris

[Toni Wilen]

IPF version does extra step immediately after highscore track writing has finished. This extra step causes the problem -> following read uses wrong track.. (infinite retries)

I guess this more or less confirms that it isn't emulation problem :)

[IFW]

Yes, it is possible that there are two versions... wouldn't be the first, coincidentally Apidya has the same problem (Kaiko release has buggy save routine), but it was confirmed with the real disk as well.

The only way to know for sure is that we dump Chris's version and compare with the ipf.

[mr.vince]

So it would make sense (just to make sure you are on the right track anytime) to add a "search for trk00, step to track xx" routine if you were looking for a quick fix... right?

[AmigaFan]

Alright, I used my own (equally valuable ;)) original copy to test it the same way Mr. Vince did it:
My original copy does not cause any audible stepping of the drive when you die; the level is silently reloaded. When you try saving the higscore (I did not take off the write protection; I really don't want to save to the original disk), the screen goes black and it loops, just like the IPF does in WinUAE. Next I made a backup to try saving, and it also behaves the same way on a real Amiga 500 (and 1200) as the IPF does in WinUAE: After you input your name and press the left mousebutton it loops and doesn't got back to the title, but the score is saved.

[dlfrsilver]

Amigafan, why not trying to make a powercopy disk image of Giana ? :D

[mr.vince]

Alright, I used my own (equally valuable ;)) original copy to test it the same way Mr. Vince did it:
My original copy does not cause any audible stepping of the drive when you die; the level is silently reloaded. When you try saving the higscore (I did not take off the write protection; I really don't want to save to the original disk), the screen goes black and it loops, just like the IPF does in WinUAE. Next I made a backup to try saving, and it also behaves the same way on a real Amiga 500 (and 1200) as the IPF does in WinUAE: After you input your name and press the left mousebutton it loops and doesn't got back to the title, but the score is saved.

So well! I did a copy of mine (which has the highscore edited, but hey - it's the same on both versions because I could see the names on mine and on the IPF version, the names and scores that are there match on both versions except for one (the modified one) and another one - which was added by me to test) using X-Copy and it does work as well. And it also does do the stepping thing.

@Toni: I assume you're good at looking into a WinUAE machine states and are familiar with 68k assembler :), so could you please take a look (once we manage to get you a copy) at the loader? If I am right with my assumption the step-o-rama was put in at the binary stage without changing any other parts if the game. Let's just assume you have a master that works fine except for one defect, which happens because some routine modifies the current track position without updating the internal counter. So you could just edit the global loader, add a branch right where you'd be doing the original stepping, jump to somewhere at the "end of program memory" (some location that is save and can have code added) and add a "step to track00, then step to the track the loader is supposed to go to". Then execute the command you had to overwrite to insert the branch, then simply rts. The loader will see it's already at the position it is supposed to and will load. You won't have to change anything else in such a scenario, but you have an ugly sounding step-o-rama with every disk access, even at level restarts. Could also be they changed this by recompiling only one binary and then added this because they had some space left at the end of the "code tracks" before the "data tracks" start. But you should clearly find some step to 0, step to x routine that no one would put on his own free will except to work around a major bug.

I think that when looking at the disk data, we will only find one sector that has been changed to implement the new loader. If they had had the time to do things the right way, they would have changed the save routine itself. But I assume this would have

a) changed some disk layout

b) felt bad because they did not know if there was another mistake somewhere doing some more stepping in the wild


So I really really assume that there must be two versions. I just wonder how they managed to have two versions out in the few weeks it was available for sale. I once again assume that they did find the mistake right after the first batch had been duplicated and they did test some of the first finished product. Then had to come up with a solution fast so a new master could be rushed to the replication facility.

It's ugly to know that the disk that did not have the data changed (but might have been the same version) has been sold to BastiBS.

@AmigaFan: Can you please check your label? Mine has a number on it: 585122. I think they did not have the time to print new labels but, just in case...

Chris

[IFW]

So it would make sense (just to make sure you are on the right track anytime) to add a "search for trk00, step to track xx" routine if you were looking for a quick fix... right?

That is correct.
Once your version has been dumped I'll take a look if it is actually a hack/fix by someone or fully duplicated.

[AmigaFan]

@AmigaFan: Can you please check your label? Mine has a number on it: 585122. I think they did not have the time to print new labels but, just in case...


Yes, it is the same. So if there really are two versions, I suppose I have the original and you have the updated one. Interesting!

[mr.vince]

I really think this was a fully duplicated run. I just do not think I have anything that has been fixed on one copy. Well, could be they did rewrite that single track at Time Warp but... hey, you know that packaging? :)

Anyway, we could also try and ask Thomas Hertzler. He is still kicking and still running Blue Byte, although now as part of the Ubi Soft family. He should know...

[AmigaFan]

Do you really think he'll remember? It's been ~22 years, after all. Your explanation does make sense, though. It sounds like a quick and dirty hack. If a single track was changed using another drive, shouldn't you be able to see it using the SPS imaging software?

[IFW]

Yes, you can see that.

We are 99% positive that there are two versions.
Unforunately the only dump we have of the other version is severely damaged... so waiting for Chris's disk to be dumped.

[mr.vince]

Soooo... given the fact that the backup I did with the original highscore table copied back in works well, let's cross our fingers that all the tracks we need (only about 8 as far as I remember) are in good shape.

Chris

[IFW]

For those waiting for the results:
this game now officially holds the record of having a running replacement combined with a two weeks worth of shelf-life :)

You may want to thank Chris for driving a few hours just so he could get his copy dumped asap.

[mr.vince]

No worries, just wanted to make sure the right version did not get lost. The only real pain was having the motorway completely blocked twice, resulting in a traffic jam that really deserves being called that way.

I still feel it was worth it. You might also want to thank István for standing by so we could make sure we had a good image, as this was done with the help of some friendly chap from a1k.org and I did not want to occupy his living room the whole afternoon. :) So also thanks Chris25-NRW!

[AmigaFan]

Well done! Thanks for investing so much time :)

So did you find out what exactly was modified, and if it was done by re-writing a single track?

[mr.vince]

From what István told me, 10 tracks do differ, the rest is the same. Might be that they just added the stepping routine, recompiled the source and did a new master. Because of code insertion early in the program code this would mean pushing the rest further back so a small change can make 10 tracks differ.

Bootcode is the same.

[IFW]

Like Chris said; the game code has been changed, nothing else.

[mr.vince]

BTW this is now in the database as a second release...