Classic byte sized checksum for speed (ie not as robust like CRC) is a sum
modulo 255 which is trivial to code in 8085 using ADD ADC and a 255 result
check.

Alan


On Thu, 12 Mar 2026 at 19:39, Brian K. White <[email protected]> wrote:

> On 3/12/26 04:24, Brian K. White wrote:
>
> > Maybe I should go back to adding the total length to the final
> > comparison after all.
> Did that. Seems to do what I wanted.
> So it goes like
>
> chk = (chk^val)+1
>
> perens needed!
>
> So even if 2 bytes are the same, the values being xored still change on
> every byte. Or I guess there must still be possible patterns that can
> trick it like a some kind of descending sequence maybe? I'm going to
> assume whatever the new failure modes are they are less common than
> strings of repeating values.
>
> For ALTERN the checksum came out a bit more than the file size plus 255,
> it was filesize plus 684 actually. Still fine in an int, but it means I
> don't know the theoretical range it might produce, and the value might
> go all over the place. If it can exceed INT, then might as well just go
> back to the simple sum plus length.
>
> I tried some pure random data where i just manually edit the first 6
> bytes in ghex to make it say top addr=maxram-len+6, len=len-6, exe=0
> (because I'm just overwriting the first 6 bytes to turn them into a co
> header)
> and generate a loader without call or savem
>
> The max possible file size is only about 12k not 29k. The loader and the
> bin both have to fit in 29.6k. Generating loaders of pure random data in
> the 10k to 12k range, the checksum hovers around the file size.
> Sometimes it's less than the file size. I guess the ongoing xors tend to
> flip high numbers to low numbers high, and just randomly hovers around
> the current progress until at the end it's "in the ballpark of the file
> size". With the files size limited to about 12k, even when the checksum
> ranges higher, it's still well within the limits of int. So fine. Though
> I wonder if there isn't some magic pattern of input data that would make
> this explode.
>
> --
> bkw
>

Reply via email to