English Amiga Board


Go Back   English Amiga Board > Support > support.Games

 
 
Thread Tools
Old 04 November 2011, 03:34   #81
Arnie
R.I.P Smudge 18-08-16

Arnie's Avatar
 
Join Date: Aug 2005
Location: Leicester/UK
Age: 62
Posts: 3,962
Done a quick test in WinUAE and the Hi-Scores still wont save........
Arnie is offline  
Old 04 November 2011, 22:27   #82
prowler
Global Moderator

prowler's Avatar
 
Join Date: Aug 2008
Location: Sidcup, England
Posts: 10,300
Yes, I've discovered the same thing myself this evening.

I'm going to leave those blocks alone for the time being unless I get some more captures of those cylinders (doesn't happen very often) or someone submits a bug report which cannot be solved in any other way.

However, there is some good news.

I have fixed another bad sector by getting a valid capture of the cylinder containing it. I wasn't even aware that it had, in fact, captured properly until I compared the resulting data with the latest WIP disk image. The continual reappearance of the Retry button is so monotonous that it sometimes induces a kind of hypnosis, and in that state I didn't notice that the progress bar had skipped to the next (adjacent) bad track.

It's another trivial fix, leaving just four to go!
Attached Files
File Type: zip Snakes-WIPB.zip (252.2 KB, 145 views)
prowler is offline  
Old 05 November 2011, 18:43   #83
clenched
Registered User

 
Join Date: Sep 2008
Location: Gainesville U.S.A.
Posts: 767
I can't tell any difference between 8,9,A,B. Another lock up bug the same as level 15 is also on level 31. What is happening is when the score is being accumulated it is caught in an endless loop. There is a series of longword constants (powers of 10) and the 100 is being overwritten. To demonstrate this, load an earlier WIP before any mine changes were made. WIP6 will do. Go to debugger and freeze this address w1 e687 1 f then go to level 15. Crashing into mine doesn't lock up anymore. The mine in question on level 31 is the first blue bomb on the sixth row. In one case here, the damaged longword was the 1000 rather than the 100. If it's any consolation, placing bombs at the same position in the DEMO causes the same trouble.
clenched is offline  
Old 06 November 2011, 01:23   #84
prowler
Global Moderator

prowler's Avatar
 
Join Date: Aug 2008
Location: Sidcup, England
Posts: 10,300
Thanks for continuing you work on this, clenched! I really thought you'd abandoned it!

I've spent most of this afternoon and evening tweaking the head alignment on a PC floppy drive atached to my Catweasel in an effort to read the remaining bad sectors properly. I have two of them in the bag and some better data for one of the blocks in Cylinder 1, all of which are included in the new WIPC disk image. Also, I can now confirm that your 'two light pixels' fix actually repaired that sector too!

The two sectors fixed today follow the Level 15 fix introduced in WIP8 with no bad sectors between, so let's hope the Level 31 problem is fixed in this version.

I think I'm going to need another drive to tweak to get the last two sectors fixed - they're proving very difficult. The problem is finding one with the motor easily accessible, but I do have one in mind...
Attached Files
File Type: zip Snakes-WIPC.zip (252.2 KB, 150 views)
prowler is offline  
Old 06 November 2011, 04:20   #85
clenched
Registered User

 
Join Date: Sep 2008
Location: Gainesville U.S.A.
Posts: 767
Prowler - WIPC had a positive effect. It wasn't the 31 bug but since one change fell within the overall tile data it was easy to predict where the change would happen.
$50e04 through $5489b = Level data (15,000 bytes)
$54057 - $50e04 = $3253 offset to WIPC changed byte
$3253 or 12883/300 = 42.943 level #
12883 MOD 300 = 283 remainder offset of tile within level
283/20 = 14.15 row
283 MOD 20 = 3 remainder column
Numbering from zero except for the level # which starts at 1
All this reduces to Level 43 row:14 column:3
This is the tile directly above the middle score digit. Go there and compare WIPC & WIPB. Obviously the new blue arrow is the correct one.
The other change that looked important to me was beyond the tile boundary so nothing to report on it.
Attached Thumbnails
Click image for larger version

Name:	LeftB_RightC.png
Views:	234
Size:	17.1 KB
ID:	29752  

Last edited by clenched; 06 November 2011 at 07:20.
clenched is offline  
Old 07 November 2011, 01:02   #86
prowler
Global Moderator

prowler's Avatar
 
Join Date: Aug 2008
Location: Sidcup, England
Posts: 10,300
Thanks for that report, clenched!

I'm going to be fairly busy for the next couple of days, so I won't get a chance to continue with this until maybe Wednesday, but it's good to see that some measurable progress has been made over the weekend. I'm going to be really disappointed if I can't fix these two remaining bad sectors now.
prowler is offline  
Old 07 November 2011, 02:15   #87
clenched
Registered User

 
Join Date: Sep 2008
Location: Gainesville U.S.A.
Posts: 767
Normally I won't shake a stick at a snake on Sunday but now I'm making an exception. This concerns the $5A84F byte change between WIPB and WIPC. Load WIPB. Just coast on level one. Sooner or later a yellow 100 inside a purple ring with the flaw shown in the picture will appear. Load WIPC. I never saw the flaw again. I tested this by trashing this and some adjacent bytes to bring the damage to the forefront and that was it.
So score one more plus for WIPC.
Attached Thumbnails
Click image for larger version

Name:	100FromB.png
Views:	169
Size:	845 Bytes
ID:	29756  

Last edited by clenched; 07 November 2011 at 03:03.
clenched is offline  
Old 07 November 2011, 02:25   #88
prowler
Global Moderator

prowler's Avatar
 
Join Date: Aug 2008
Location: Sidcup, England
Posts: 10,300
Thanks again, clenched!

Quote:
Originally Posted by clenched View Post
$50e04 through $5489b = Level data (15,000 bytes)
As from WIPC, there should be no errors in the Level data, as I have fixed all the bad sectors in that region.

What I can say is that the remaining bad sectors are Disk Blocks 336 (offset $2A000-$2A1FF) and 1181 (offset $93A00-$93BFF).

Edit: All I can tell from the data I have gathered so far is that it's possible that changing the byte at offset $2A057 ($05), but not to $07, will fix the error on Block 336, but I can't confirm that yet. The error on Block 1181 is more difficult to pin down and may be non-trivial.

Last edited by prowler; 09 November 2011 at 01:36. Reason: typo
prowler is offline  
Old 07 November 2011, 21:39   #89
clenched
Registered User

 
Join Date: Sep 2008
Location: Gainesville U.S.A.
Posts: 767
If WinUAE's module ripper is used then here are the differences. The first one happens to coincide with WIPC block 336. You'll have to make the call since the demo warns of differing music. I didn't discover any trace of block 1181 in the demo.
C:\>fc /b snakedemo.mod wipc.mod
Comparing files snakedemo.mod and WIPC.MOD
0001A057: 0F 05
00028AAC: FC FD
00028AAD: FA BA
00028B74: 08 09
00028B75: 09 49
clenched is offline  
Old 07 November 2011, 23:14   #90
prowler
Global Moderator

prowler's Avatar
 
Join Date: Aug 2008
Location: Sidcup, England
Posts: 10,300
A really big thanks for helping me out with this, clenched!

I've managed to get one helluva big job completed today, so it now looks like I'll get some time to look at this tomorrow.

Could you upload your snakedemo.mod and wipc.mod rips for me please, mate? That would be a great help.

I'm going to repeat Saturday's floppy drive head alignment tweaking experiment using my KryoFlux before I try another drive. The Catweasel is more precise than the KryoFlux when there are two or more bad sectors on a track, but the KryoFlux has the edge when there is only one.
prowler is offline  
Old 07 November 2011, 23:27   #91
clenched
Registered User

 
Join Date: Sep 2008
Location: Gainesville U.S.A.
Posts: 767
They are in the Zone.
clenched is offline  
Old 07 November 2011, 23:36   #92
prowler
Global Moderator

prowler's Avatar
 
Join Date: Aug 2008
Location: Sidcup, England
Posts: 10,300
Wow, that was quick! Thanks, mate!

If that byte at .mod offset $1A057 fixes Block 336 (and that's just the sort of trivial fix which has done the trick on several of the other disk blocks), then I can devote all my attention to salvaging the troublesome Block 1181 tomorrow, the better to get it fixed and finish the job at last!
prowler is offline  
Old 09 November 2011, 01:48   #93
prowler
Global Moderator

prowler's Avatar
 
Join Date: Aug 2008
Location: Sidcup, England
Posts: 10,300
Hi clenched,

I didn't actually get to trying any disk salvaging today, because I didn't have any time left after getting to grips with the module business (read on and you'll see what I mean).

Quote:
Originally Posted by clenched View Post
C:\>fc /b snakedemo.mod wipc.mod
Comparing files snakedemo.mod and WIPC.MOD
0001A057: 0F 05
00028AAC: FC FD
00028AAD: FA BA
00028B74: 08 09
00028B75: 09 49
The module starts at offset $010000 in the Snakes.adf file and is contiguous (i.e. not fragmented), so that the byte at offset $01A057 in the wipc.mod file appears at offset $02A057 in the Snakes.adf file. Not only is this on Disk Block 336 as you said above, but this is also the byte which I had suspected of causing the bad sector. Thus, it is almost certain that changing this byte from $05 to $0F to match the Demo module will also fix the bad sector!

However, the other two-byte differences at offsets $028AAC and $028B74 in the wipc.mod file appear at offsets $038AAC and $038B74, respectively, in the Snakes.adf file on Disk Block 453, which is valid. Therefore I think that these changes may deliberately have been introduced for the Demo music as a kind of 'watermark' to distinguish it from the full version music (for intellectual property reasons, I guess). For this reason I would prefer to leave the original code in Disk Block 453.

I extracted the module from the Snakes.adf (WIPC) image by deleting the code before offset $010000 and after offset $033C40 from what was left, and I saved the resulting file as adf.mod.

Then I discovered something interesting:
C:\>fc /b adf.mod wipc.mod
Comparing files adf.mod and WIPC.MOD
00008C3E: 0E 00
00008C3F: 16 00
0000A6B6: 0C 00
0000A6B7: 12 00
0000C12C: 06 00
0000C12D: 07 00
0000E5EC: 06 00
0000E5ED: 0E 00
00010680: 11 00
00010681: FA 00
00011128: 05 00
00011129: 05 00
000132C6: 06 00
000132C7: 08 00
00014A78: 08 00
00014A79: 08 00
00015C8A: 06 00
00015C8B: 08 00
000177F2: 0A 00
000177F3: 15 00
00017CBA: 06 00
00017CBB: 06 00
00019AF8: 05 00
00019AF9: 05 00
0001D3E0: 04 00
0001D3E1: 04 00
0001EBE2: 02 00
0001EBE3: 05 00
0001FFEE: 08 00
0001FFEF: 09 00
0002130C: 08 00
0002130D: 09 00
00022CD0: 05 00
00022CD1: 05 00
000245E0: 09 00
000245E1: 0B 00
0002666C: 06 00
0002666D: 0D 00
00027A36: 06 00
00027A37: 06 00
00028E6E: 02 00
00028E6F: 01 00
0002AC24: 06 00
0002AC25: 06 00
0002C0F0: 06 00
0002C0F1: 17 00
0002D6DA: 06 00
0002D6DB: 06 00

I don't understand why all these bytes have been cleared in the wipc.mod file when I had expected the two files to be identical. Could WinUAE's module ripper possibly be buggy?

I have played all three files with Java Mod Player v1.9.4.4, and I can discern no differences between them.

Disk salvaging will resume tomorrow...
prowler is offline  
Old 09 November 2011, 04:55   #94
clenched
Registered User

 
Join Date: Sep 2008
Location: Gainesville U.S.A.
Posts: 767
Prowler - I can see the first different byte being read in by the trackloader and being cleared just prior to the title screen. So the ripper can't be at fault if there is even any fault at all. Anything made from a memory dump is subject to differ from the ADF.
Maybe you can bring some of that new GM clout to bear and get this game entered in the EAB/LEMON contest so it can get a proper shakedown.
clenched is offline  
Old 09 November 2011, 16:19   #95
Don_Adan
Registered User
 
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 52
Posts: 1,282
Quote:
Originally Posted by prowler View Post
Hi clenched,

I didn't actually get to trying any disk salvaging today, because I didn't have any time left after getting to grips with the module business (read on and you'll see what I mean).



The module starts at offset $010000 in the Snakes.adf file and is contiguous (i.e. not fragmented), so that the byte at offset $01A057 in the wipc.mod file appears at offset $02A057 in the Snakes.adf file. Not only is this on Disk Block 336 as you said above, but this is also the byte which I had suspected of causing the bad sector. Thus, it is almost certain that changing this byte from $05 to $0F to match the Demo module will also fix the bad sector!

However, the other two-byte differences at offsets $028AAC and $028B74 in the wipc.mod file appear at offsets $038AAC and $038B74, respectively, in the Snakes.adf file on Disk Block 453, which is valid. Therefore I think that these changes may deliberately have been introduced for the Demo music as a kind of 'watermark' to distinguish it from the full version music (for intellectual property reasons, I guess). For this reason I would prefer to leave the original code in Disk Block 453.

I extracted the module from the Snakes.adf (WIPC) image by deleting the code before offset $010000 and after offset $033C40 from what was left, and I saved the resulting file as adf.mod.

Then I discovered something interesting:
C:\>fc /b adf.mod wipc.mod
Comparing files adf.mod and WIPC.MOD
00008C3E: 0E 00
00008C3F: 16 00
0000A6B6: 0C 00
0000A6B7: 12 00
0000C12C: 06 00
0000C12D: 07 00
0000E5EC: 06 00
0000E5ED: 0E 00
00010680: 11 00
00010681: FA 00
00011128: 05 00
00011129: 05 00
000132C6: 06 00
000132C7: 08 00
00014A78: 08 00
00014A79: 08 00
00015C8A: 06 00
00015C8B: 08 00
000177F2: 0A 00
000177F3: 15 00
00017CBA: 06 00
00017CBB: 06 00
00019AF8: 05 00
00019AF9: 05 00
0001D3E0: 04 00
0001D3E1: 04 00
0001EBE2: 02 00
0001EBE3: 05 00
0001FFEE: 08 00
0001FFEF: 09 00
0002130C: 08 00
0002130D: 09 00
00022CD0: 05 00
00022CD1: 05 00
000245E0: 09 00
000245E1: 0B 00
0002666C: 06 00
0002666D: 0D 00
00027A36: 06 00
00027A37: 06 00
00028E6E: 02 00
00028E6F: 01 00
0002AC24: 06 00
0002AC25: 06 00
0002C0F0: 06 00
0002C0F1: 17 00
0002D6DA: 06 00
0002D6DB: 06 00

I don't understand why all these bytes have been cleared in the wipc.mod file when I had expected the two files to be identical. Could WinUAE's module ripper possibly be buggy?

I have played all three files with Java Mod Player v1.9.4.4, and I can discern no differences between them.

Disk salvaging will resume tomorrow...
You compared uninitialised (from disk) and initialised (from memory) version of tracker module. Initialised tracker module has cleared 2 bytes for every sample.
Don_Adan is offline  
Old 09 November 2011, 23:27   #96
prowler
Global Moderator

prowler's Avatar
 
Join Date: Aug 2008
Location: Sidcup, England
Posts: 10,300
Quote:
Originally Posted by clenched View Post
Prowler - I can see the first different byte being read in by the trackloader and being cleared just prior to the title screen. So the ripper can't be at fault if there is even any fault at all. Anything made from a memory dump is subject to differ from the ADF.
Quote:
Originally Posted by Don_Adan View Post
You compared uninitialised (from disk) and initialised (from memory) version of tracker module. Initialised tracker module has cleared 2 bytes for every sample.
Thankyou both for the info. After more than three years as an active member on these forums there's still much to learn, and that's what keeps it so interesting.

Quote:
Originally Posted by clenched View Post
Maybe you can bring some of that new GM clout to bear and get this game entered in the EAB/LEMON contest so it can get a proper shakedown.
Only by persuading a sufficient number of participants to vote for the game could anyone achieve that, but we're not quite ready for that yet in any case.

This evening, I finally fixed the last bad sector in the disk image. I could not get a valid capture of it whatever I tried, but when I found that read errors were often triggered by a particular byte on that disk block, I saw that it was possible - likely even -that only this byte was invalid. So I searched the disk image for another instance of the byte sequence including this one, suitably modified, and I discovered that the entire content of Disk Block 1181 appears a total of 34 times. That's pretty conclusive!

So now we have Release Candidate 1, incorporating fixes for Disk Blocks 336 (as described previously) and 1181.
Attached Files
File Type: zip Snakes-RC1.zip (252.2 KB, 123 views)
prowler is offline  
Old 10 November 2011, 21:52   #97
Arnie
R.I.P Smudge 18-08-16

Arnie's Avatar
 
Join Date: Aug 2005
Location: Leicester/UK
Age: 62
Posts: 3,962
Excellent work Prowler, unfortunately the Hi-score still wont save but maybe it never did.
Arnie is offline  
Old 10 November 2011, 22:42   #98
prowler
Global Moderator

prowler's Avatar
 
Join Date: Aug 2008
Location: Sidcup, England
Posts: 10,300
I suspect only pickaweapon will be able to answer that question, but he hasn't been near or by here since WIP1!
prowler is offline  
Old 11 November 2011, 22:36   #99
clenched
Registered User

 
Join Date: Sep 2008
Location: Gainesville U.S.A.
Posts: 767
Rattlesnake venom continues to overtake game victim

Level 17 the "VSN" level makes an excellent test bed for bug testing. I suggest using boring speed, unlimited lives mode and making a savestate first. This is because precise snake movement is needed and the game can lock up too. Take one bomb tile. There are four (4) sides and sub divide each side into two halves. There are eight (8) possible places to make contact with a mine. Contact with a different section can cause a different bug. These include lockups, trashing snake graphic, red ring graphic and others. For a quick test your target is the topmost yellow mine in the letter S.

1 - Approach from the top and hit the right side of top face, overwrites a 10 then lockup.
2 - Approach from the top and hit the left side of top face, overwrites a 100 then lockup.
3 - Approach from the bottom and hit the right side of bottom face, messes up snake, blue mine gfx. The 1up powerup is damaged beyond recognition.
4 - Approach from the bottom and hit the left side of bottom face, increased damage to snake gfx.

A lot of this goes unnoticed because the bulk of the memory affected consists of tiny bitmaps with lots of zeros so they were cleared anyway. I'm convinced this is a game bug, that it is due to a multiplication error, and can be in no way attributed to the salvage operation.
clenched is offline  
Old 18 November 2011, 23:18   #100
antonvaltaz
Registered User
antonvaltaz's Avatar
 
Join Date: May 2009
Location: Mirfield, West Yorkshire, UK
Age: 39
Posts: 511
I'm quite interested in this (I too had that demo from The One)... so is it fair to say that the last version Prowler released is more or less accurate?

Sorry, I'm not very technical, but it sounds like it's pretty much recovered?
antonvaltaz is offline  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
Looking for a snakes game lordofchaos Looking for a game name ? 4 06 January 2012 17:36
The One Amiga 59 (Aug 1993) : Snakes game registered? Rakki request.Old Rare Games 3 17 July 2011 15:57
Snakes/Super Twintris DeAdLy_cOoKiE request.Old Rare Games 0 12 June 2007 10:00

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 20:53.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.09798 seconds with 14 queries