On Sat, Mar 14, 2026, 2:16 PM Brian White <[email protected]> wrote:
> 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 > > > > I wouldn't expect code files to have runs of anything unless they have uncompressed embedded graphics. More likely the repeated stuff is common instructions and operand bytes. So you'd need a Huffman code type algorithm for optimally representing 8085 byte frequencies. I would expect zero and RET to happen a lot for example. I think beyond that you get into lz77/lz78 and to find longer patterns that tend to appear in an 8085 program. -- John. >
