Thanks I may switch to that just to remove all chance of the value going out of bounds.
Mean time I got run-length encoding working, but not 100%. If XA is not 0 (if shift-all-bytes-before-encoding is enabled) then the decoder reports bad checksum (though the binary might be mostly fine since at least once I was able to call to the exe address anyway and it ran, so maybe a last byte or first byte problem.) But if I set XA=0 which just disables that extra rotation, checksum passes. But disabling that extra rotation increases the output a lot. First, without it, you simply lose the advantage it conferred, moving the bytes around so that fewer bytes need to be encoded. But also hits rle itself hard because short runs of low ascii values, like 5 or 10 nulls, means both the null and the byte that says "9 copies" both need to be encoded into 2 bytes each. The XA rotation would have moved both of those up to where they would both be a single byte each. So most rle sequences come out to 5 bytes instead of 3. And then on top of that the basic code is just not elegant yet, and it means adding the rle prefix to the list of byte values that must be encoded if they appear in the payload, and that increases the output size. All in all the test file I've been using for everything gets larger not smaller because it only has a few short runs in it. bkw On Thu, Mar 12, 2026, 7:16 PM Alan Cox <[email protected]> wrote: > 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 >> >
