24 January 2009, 20:04 | #1 |
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?
|
24 January 2009, 21:40 | #2 |
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 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,570
|
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 |
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 |
Zone Friend
Join Date: Mar 2004
Location: Middle Earth
Age: 40
Posts: 2,129
|
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 |
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, 04:41 | #7 | |
Da Digger :)
Join Date: Nov 2008
Location: Monza, Italy
Posts: 2,822
|
Quote:
This would clarify if it happens in WinUAE only (I don't think so). |
|
25 January 2009, 13:12 | #8 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,570
|
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:20 | #9 |
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 |
04 February 2009, 15:44 | #10 |
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 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,570
|
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 |
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 |
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 |
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 |
CaptainM68K-SPS France
|
Amigafan, why not trying to make a powercopy disk image of Giana ?
|
04 February 2009, 20:31 | #16 | |
Cheesy crust
Join Date: Nov 2008
Location: Hawk's Creek
Age: 48
Posts: 1,383
|
Quote:
@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 Last edited by mr.vince; 04 February 2009 at 21:12. Reason: corrected at least one of the many typos |
|
04 February 2009, 20:36 | #17 | |
Moderator
Join Date: Jan 2003
Location: ...
Age: 52
Posts: 1,838
|
Quote:
Once your version has been dumped I'll take a look if it is actually a hack/fix by someone or fully duplicated. |
|
04 February 2009, 20:41 | #18 |
Registered User
Join Date: Jan 2009
Location: Germany
Posts: 62
|
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!
|
04 February 2009, 21:03 | #19 |
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 |
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) | |
Thread Tools | |
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 |
|
|