English Amiga Board

English Amiga Board (http://eab.abime.net/index.php)
-   support.Other (http://eab.abime.net/forumdisplay.php?f=74)
-   -   Amiga floppy checksums (http://eab.abime.net/showthread.php?t=99013)

catphish 01 October 2019 02:41

Amiga floppy checksums
 
I'm working on a tool to read and write Amiga disks with a PC. All is going well, but I one thing about the disk format is confusing me - the sector checksums.


Checksums appear to be calculated by xor'ing the MFM encoded data, ignoring the clock bits. The result appears to be a checksum where all odd bits are zero.


This checksum is then encoded into 2 longs (one for odd bits and one for even bits). The result of this therefore seems to be that the "checksum odd" fields of the header are *always* zero. Is this actually correct? It seems like a bafflingly odd design if so.


This does appear to be the case with the disk I'm testing with, but I wanted some input on whether this is correct!


Thanks! I will likely have more questions and weird and wonderful disk formats soon.

lesta_smsc 01 October 2019 02:50

Just to clarify. Are you using a hardware interface to help as floppy disk controller? As far as I was aware, the PC cannot natively support Amiga disk format?

Sent from my SM-G925F using Tapatalk

catphish 01 October 2019 02:58

Yes. I have designed an STM32 based USB floppy controller and I'm now working on the software.

https://i.imgur.com/TEDFmct.jpg

lesta_smsc 01 October 2019 03:21

Fantastic! I'm not sure if it will help, but take a look at this project which uses Arduino for the same purpose. It is open source so you may be able to get some ideas for your situation in the code / concept?

http://amiga.robsmithdev.co.uk/

Sent from my SM-G925F using Tapatalk

ross 01 October 2019 09:26

Quote:

Originally Posted by catphish (Post 1348739)
This checksum is then encoded into 2 longs (one for odd bits and one for even bits). The result of this therefore seems to be that the "checksum odd" fields of the header are *always* zero. Is this actually correct? It seems like a bafflingly odd design if so.

Yes, and this is the reason why I deliberately decided to ignore it in my loader.
This increases the decoding speed and does not affect the correctness of the data.
(well, actually you could check if that value is actually zero ;)).
Could it be a legacy of encoding and decoding done with blitter in 1.x systems? (to align data)

catphish 01 October 2019 21:15

Thanks for confirming. I will ignore the odd checksum field. It doesn't even matter if the field is corrupt :)


All times are GMT +2. The time now is 09:49.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.

Page generated in 0.04103 seconds with 11 queries