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
