KERNAL CRC call (not sure if right)

[Eirik Stople]

I vote for calling this a bug. Yes, we can have an "internal checksum" that is consistent internally, but, I think its value improves if it matches with something that is also standardized somehow, outside of the x16 kernal. Even though this breaks compatibility with current rom versions for data less than 256 bytes. This makes it also possible to improve the documentation, and, to point to an online calculator giving predictable results.

[Stefan]

I agree that we need to consider it a bug, even though fixing it could in theory break some existing program.

[Xiphod]

Well, I'd also prefer it to work consistently. I don't see any benefit on this "reverse" version.


Maybe it was something to support a "double CRC" check of sort? Like you can accumulate CRC on say 512 bytes, then double check it by reversing over the prior 256 bytes? Maybe either as a security thing (e.g. check that nothing is manipulating the memory) or protect against poor or unstable memory?


Don't think this was code borrowed from a C128 or anything. Can't think of any IEC device where this might make sense.

[Eirik Stople]

This is a plain old bug.
First you accumulate the CRC over a whole number of 256 byte chunks. This part works fine.
At the end, you accumulate the CRC over the remainder (starting from @2)
This part have the following bug: Y is set to byte count of the remaining part of the data, which is decremented to 0.
But, at the same time, Y is used as byte offset, using the "lda (r0),y" instruction.
This have the effect of accumulating the bytes of the remainder in the wrong order.