Great Giana Sisters SPS IPF bug?

AmigaFan · 24 January 2009, 20:04

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 · 24 January 2009, 21:40

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 · 24 January 2009, 22:01

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 · 24 January 2009, 22:53

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 · 24 January 2009, 23:31

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

IFW · 25 January 2009, 03:50

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 · 25 January 2009, 04:41

Quote:

Originally Posted by 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.

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 · 25 January 2009, 13:12

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 · 04 February 2009, 15:20

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 · 04 February 2009, 15:44

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 · 04 February 2009, 15:52

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 · 04 February 2009, 16:05

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 · 04 February 2009, 16:30

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 · 04 February 2009, 17:36

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 · 04 February 2009, 18:19

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

mr.vince · 04 February 2009, 20:31

Quote:

Originally Posted by 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.

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 · 04 February 2009, 20:36

Quote:

Originally Posted by 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?

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 · 04 February 2009, 20:41

Quote:

Originally Posted by mr.vince

@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 · 04 February 2009, 21:03

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 · 05 February 2009, 12:47

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?

24 January 2009, 20:04	#1
AmigaFan Registered User Join Date: Jan 2009 Location: Germany Posts: 62	Great Giana Sisters SPS IPF bug? 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?

04 February 2009, 15:20	#9
mr.vince Cheesy crust Join Date: Nov 2008 Location: Hawk's Creek Age: 48 Posts: 1,383	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... Last edited by mr.vince; 04 February 2009 at 15:45. Reason: more information added

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Great Giana Sisters - Postmortem	david10595	MarketPlace	21	18 February 2009 15:56
[Request]Great Giana Sisters	Retro1234	project.Sprites	7	14 January 2009 13:51
Great Giana Sisters Remake!!!	Bloodwych	Retrogaming General Discussion	15	01 May 2005 22:22
[Found] -> Great Giana Sisters	Lev	Looking for a game name ?	14	13 September 2002 15:57
The Great Giana Sisters	djmullet	support.Games	27	17 April 2002 16:28

24 January 2009, 21:40	#2
IFW Moderator Join Date: Jan 2003 Location: ... Age: 52 Posts: 1,838	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.

24 January 2009, 22:01	#3
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,519	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)

24 January 2009, 22:53	#4
AmigaFan Registered User Join Date: Jan 2009 Location: Germany Posts: 62	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?

24 January 2009, 23:31	#5
redblade Zone Friend Join Date: Mar 2004 Location: Middle Earth Age: 40 Posts: 2,127	I like the high score tune. It's one of my favourites the other being the Rainbow Islands high score tune

25 January 2009, 03:50	#6
IFW Moderator Join Date: Jan 2003 Location: ... Age: 52 Posts: 1,838	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.

25 January 2009, 13:12	#8
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,519	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..

04 February 2009, 15:44	#10
mr.vince Cheesy crust Join Date: Nov 2008 Location: Hawk's Creek Age: 48 Posts: 1,383	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

04 February 2009, 15:52	#11
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,519	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

04 February 2009, 16:05	#12
IFW Moderator Join Date: Jan 2003 Location: ... Age: 52 Posts: 1,838	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.

04 February 2009, 16:30	#13
mr.vince Cheesy crust Join Date: Nov 2008 Location: Hawk's Creek Age: 48 Posts: 1,383	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?

04 February 2009, 17:36	#14
AmigaFan Registered User Join Date: Jan 2009 Location: Germany Posts: 62	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.

04 February 2009, 18:19	#15
dlfrsilver CaptainM68K-SPS France Join Date: Dec 2004 Location: Melun nearby Paris/France Age: 46 Posts: 10,436	Amigafan, why not trying to make a powercopy disk image of Giana ?

04 February 2009, 21:03	#19
mr.vince Cheesy crust Join Date: Nov 2008 Location: Hawk's Creek Age: 48 Posts: 1,383	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...

05 February 2009, 12:47	#20
AmigaFan Registered User Join Date: Jan 2009 Location: Germany Posts: 62	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?

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)