English Amiga Board

Go Back   English Amiga Board > Support > support.Hardware

Thread Tools
Old 01 January 2016, 22:04   #1
Posts: n/a
Floppy disk Help with DiskSpare checksum calculation


First of all, best wishes for 2016!

I'm new to this forum so forgive me for dropping in with a question like this without proper introduction. I could really use some help.

I've owned an Amiga 1200 with a harddrive but sold it at some point to free up the cash (with pain in my heart of course :S). I kept a lot of floppies that I figured I could read again once I could get my hands on an Amiga 1200 again but that didn't happen. The data is mod files, self made and existing, images I've painted with DPaint, lightwave scenes, scenery animator renders, Amos programs, text files etc. Would be great to look at it again!

The floppies are in bad condition. I haven't treated them as they should be, leaving them for years in a moldy moisty environment. But to my surprise many floppies and their data have survived. I've got a renewed appreciation for the venerable floppie

I want to rescue the data on my old floppies and thought it would be a fun project to use a PIC microcontroller, USB to serial converter and a standard PC floppy drive and an self written application on Windows to decode and rebuild the floppies on the PC.

After a lot of hours of debugging I'm now at a point I can read PC DOS and AmigaDOS / PFS floppies fine in double density format. I've successfully recovered a number of floppies 100% in good condition.

Back in the days, like everyone else had always too little storage to put my data on and came across DiskSpare. It could fit about 100KB more on a floppy.

I'm having a heck of a time to figure out what the checksum scheme is. I've found the code in WinUAE that 'decodes' DiskSpare, but I've found it does the reverse, it encodes the disk from sectors into MFM data. Although the checksum code should be the same but it doesn't seem to work on the floppies I have. Is it perhaps possible I used an older/newer version with a different kind of checksum scheme?

This is the code calculating the checksum where mfmbuf is an uint16 array.
        chk = mfmbuf[i++] & 0x7fff;
        while (i < 512 + 8)
            chk ^= mfmbuf[i++];
I'm using a uint32 array decodedamiga[] and use some bit shifts and & masking to get the same job done. It doesn't however match the checksum stored in the sector header unfortunately.
Here's the code I've come up with based on the code above. Sorry for the variable naming, I've been experimenting a lot and haven't renamed them properly back yet.

Test2 is the checksum result value, test is a temporary variable to hold the decodedamiga[] data (which is MFM encoded data).
                    uint test;
                    uint test2,testcount=0;
                    offset = 4;
                    test2 = ((decodedamiga[offset] >> 16 ) & 0x7FFF);
                    test2 ^= (decodedamiga[offset] & 0xffff);

                    for (j = offset+1 ; j < (256 + offset); j++)
                        test = decodedamiga[j] ;
                        test2 ^= ((test >> 16) & 0xffff);
                        test2 ^= (test & 0xffff);
What I've tried:
- I've checked, recheck and double checked the ranges, offsets etc. I'm pretty sure I've got this correct as I've restored a DiskSpare disk already, though I couldn't check data integrity using the checksums. I just read the disks and converted the data into a disk image and hoped for the best. It worked in one instance though it would be a great help if I could get the correct checksum.
- I think I'm also pretty sure I've got the correct header location for the checksum. I'm not sure about the decoding, but based on that the tracks and sectors decode properly, I'm reluctantly assuming the checksum is ok too.
- I've searched and searched for DiskSpare decode code on the internet and could only find the WinUAE source file. There was one other but it didn't include code to decode the MFM data unfortunately.
- I've tried the AmigaDOS way of doing the checksum in uint32 format in single uint32 mode.
- I've tried an extra for() loop with different offsets and lengths and checking it it matches the known checksum but alas, no match found.

What I haven't tried yet:
- What I've been wondering is that could DiskSpare be using CRC16 instead of a simple XOR without polynomal? It uses just 16 bits as a checksum while AmigaDOS uses 32 bits. CRC16 is a much stronger checksum I've heard.
- I haven't tried decoding the entire 512 bytes with even/odd spaced apart 512 bytes, like AmigaDOS sector data. Even so, with XOR I suspect it doesn't really matter in what order the data is processed. I've tried XOR-ing the high word before the low word and vice versa with the same resulting checksum.

I've been for days and still can't come up with a solution. I really hope someone out there can lend me a hand. If you need any more data, examples, code etc, I'm happy to provide them. If anyone is interested in my project I'm happy to share that too.

Old 02 January 2016, 12:03   #2
Posts: n/a
Never mind, I've found the problem. The test data I used was actually that bad The checksum works fine. Now I can finally get my data back whoohoo!


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
Problem with diskspare disk image mark_k support.WinUAE 5 23 May 2015 17:07
Matrix calculation questions (HowToCode) kae Coders. General 3 20 January 2012 02:42
Trackdisk and Diskspare exoticaga support.Other 11 09 April 2009 20:27
Diskspare isn't working with Winuae Gooberslot support.WinUAE 4 31 August 2008 13:00
Calculation of Amiga <-> PC transfer time andreas Retrogaming General Discussion 4 14 September 2001 22:50

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 00:42.

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