Fixed it. Problem was actually on the encoding side not the loader. So
now RLE fully works, and gets to benefit from the yenc pre-rotation. The
rle codes only take 3 bytes now (usually). And I got the BASIC slightly
better.
Not that it helps as you say.
Now with XA in effect ALTERN.CO comes out only slightly larger with RLE
than without, but runs much slower.
Loading without rle takes about 2:23
with rle takes about 2:54
And I guess I have to revisit the bootstrapper because a simple cat at
9600 with xon/off enabled has been working perfectly and it only takes 7
seconds vs 45.
In the mean time, it's not quite true that cat alone is good enough, but
here is something a little better but still pretty quick n dirty.
tsend () {
local d=${2:-/dev/ttyUSB0} b=${3:-9600} s=([19200]=9 [9600]=8 [4800]=7
[2400]=6 [1200]=5 [600]=4 [300]=3)
((${#1})) || { echo "${FUNCNAME[0]} FILE.DO [/dev/ttyX] [baud]" ;return
; }
[[ -c $d ]] || { echo /dev/tty* ;return ; }
((${#s[b]})) || { echo ${!s[*]} ;return ; }
echo "100/200/K85/M10: RUN\"COM:${s[b]}8N1ENN"
echo " 8201/8300: RUN\"COM:${s[b]}N81XN"
read -p "Press [Enter] whean ready: " ;echo "Sending..."
stty -F $d $b raw pass8 clocal cread time 1 min 1 -crtscts ixon ixoff
flusho -drain
cat $1 >$d
printf '%b' '\x1A' >$d
}
And I think by rights it should actually open the port and hold it on a
file descriptor like pdd.sh does, and then set the settings with stty
while the fd is connected, because on some platforms running stty on an
arbitrary tty that you don't have open, like on your own terminal, the
target ttys settings may just instantly revert to something else as soon
as the stty executable exits. But this works ok on linux (the stty -F
option isn't portable either but whatever that's what makes it q&d.
On 3/14/26 18:51, John R. Hogerhuis wrote:
On Sat, Mar 14, 2026, 2:16 PM Brian White <[email protected]
<mailto:[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.
--
bkw
