Snakes!

[Arnie]

Done a quick test in WinUAE and the Hi-Scores still wont save........

[prowler]

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!

[clenched]

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.

[prowler]

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...

[clenched]

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.

[prowler]

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.

[clenched]

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.

[prowler]

Thanks again, clenched!

Originally Posted by clenched

$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.

[clenched]

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

[prowler]

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.

[clenched]

They are in the Zone.

[prowler]

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]

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).

Originally Posted by clenched

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...

[clenched]

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.

[Don_Adan]

Originally Posted by prowler

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.

[prowler]

Originally Posted by clenched

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.

Originally Posted by Don_Adan

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.

Originally Posted by clenched

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.

[Arnie]

Excellent work Prowler, unfortunately the Hi-score still wont save but maybe it never did.

[prowler]

I suspect only pickaweapon will be able to answer that question, but he hasn't been near or by here since WIP1!

[clenched]

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.

[antonvaltaz]

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?