I just removed the file size check entirely, which got REXCPM bootstrap
working with those cpm ramdisk image files that are even larger than
64k, and didn't seem to hurt anything else. I can't say for sure but I'm
pretty sure I even generated a directory listing from the dir with those
big files in there, though I never tried to load them of course other
than via the rexcpm setup files.
I'm taking another look at it now. His debug log and the fact that there
even IS a -c option in his binary means that he's using a version that
is new enough to have the file size check removed, and has the uppercase
/ case-insensitivity fix, and the debug log shows that he had already
renamed all the files to uppercase anyway, and shows that he wasn't
trying to load any .BA that needed to be renamed to .DO, basically
everything looks good. Should have worked.
However, I myself seem to be having a problem I wasn't having even
yesterday, and I haven't changed a thing. I even tried reverting to old
git commits which I used many many times and are well proven.
I even tried a different 100, different REX with a different TS-DOS in
it, different serial cable and usb-serial cables in case the DTR line
chose now to break inside...
Just in the course of looking into this question, I was trying to run
the rexcpm initialization files, and the bootstrap of rxcini.DO works
fine, but it hangs when you answer the prompt for the file name
"RXC_12", hang. Only a few tpdd transactions on the debug output, no
explaination why it should hang right there. I even tried using both the
same old version of dlplus, and the same old version of the rexcpm files
I actually filmed myself using sucessfully on camera:
https://youtu.be/tb0WYQCaF1I
And the same thing hangs on me right now.
I am fully ready to believe I somehow botched things modifying dl.c,
but, I tried old proven versions on all the same hardware.
I'm down to wondering if I need to reboot my laptop since it has updated
several times since the last time I rebooted and it has been begging me
to reboot for 3 or 4 days. :)
Or maybe I need to revert to an older kernel since I'm using the ubuntu
mainline-ppa kernels not the "safe" ones. Every now and then funny
things happen there.
--
bkw
On 7/9/21 9:25 PM, John R. Hogerhuis wrote:
On Fri, Jul 9, 2021 at 6:14 PM ExPLIT | Pawel Radomychelski
<exp...@mailbox.org <mailto:exp...@mailbox.org>> wrote:
Thanks John, will try Laddie Alpha
I alos think it has something to do with the size of the file,
because small file transfers over dl+ works normally.
Yes.
TPDD directory enumeration include a "file length" encoded as 2 bytes
with a range of 0 to 65,53*5*.
Binary ROM images are 32K = 32768, which is a length of file that can
technically be represented in an unsigned 16-bit integer (2 bytes). It
is less than 65,536.
But ROM */image files/* as used by REX are a hex representation, so they
are twice that big. Each binary byte is represented by 2 ASCII
characters encoding the upper and lower nibble of each byte, respectively.
Which means those files they are */exactly/* 64K = 65,53*6*
The length of a 64K file cannot be represented in a 16-bit integer. You
can only represent file sizes exactly one byte shorter... 65,53*5*.
The TPDD protocol actually supports files bigger than 65535 bytes but
the protocol is slightly different for representing file lengths greater
than 65,535.
So IF what I suspect is happening is happening, DLPlus still has that
bug. I used to maintain it but I don't remember.
Anyway I had to fix this for LaddieAlpha to make hex files work with REX.
-- John.
--
bkw
