While browsing the HiTech C subdirectory on my Z80 system, I came upon the file MAIN.C which appears to be a version of LBRATE for CP/M and HiTech C. There were also 4 header files for the various decompression methods but there were no corresponding C
files. LBRATE was written by Russel Marks for Linux I believe and I have searched high can't find where this file came. I do have a zip file with the Linux source, docs and makefile. Does any one have the complete HiTech C, CP/M, version of LBRATE?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence Nelson <[email protected]> wrote:

While browsing the HiTech C subdirectory on my Z80 system, I came upon
the file MAIN.C which appears to be a version of LBRATE for CP/M and
HiTech C. There were also 4 header files for the various decompression methods but there were no corresponding C files. LBRATE was written by
Russel Marks for Linux I believe and I have searched high can't find
where this file came. I do have a zip file with the Linux source, docs
and makefile. Does any one have the complete HiTech C, CP/M, version
of LBRATE?

To me that sounds like it might be a modified version intended just to
e.g. list the contents of LBR files while "correcting" the filenames
that were modified by compression.

I feel like lbrate proper would run very badly if at all on CP/M - it
rather extravagantly decompresses each file to RAM in full before
writing it, which makes for nicer code in some ways but would be
completely absurd on an 8-bit machine.

-Rus.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, 2 February 2023 at 10:07:53 UTC, Russell Marks wrote:

Lawrence Nelson <[email protected]> wrote:

While browsing the HiTech C subdirectory on my Z80 system, I came upon
the file MAIN.C which appears to be a version of LBRATE for CP/M and
HiTech C. There were also 4 header files for the various decompression methods but there were no corresponding C files. LBRATE was written by Russel Marks for Linux I believe and I have searched high can't find
where this file came. I do have a zip file with the Linux source, docs
and makefile. Does any one have the complete HiTech C, CP/M, version
of LBRATE?

To me that sounds like it might be a modified version intended just to
e.g. list the contents of LBR files while "correcting" the filenames
that were modified by compression.

I feel like lbrate proper would run very badly if at all on CP/M - it
rather extravagantly decompresses each file to RAM in full before
writing it, which makes for nicer code in some ways but would be
completely absurd on an 8-bit machine.

-Rus.

I had a go at modifying lbrate 1.1 to compile with hitech c. It can be compiled, but not linked.
There are two problems
1) two additional routines are required.
memmove which is easily implemented and
strerror which is more problematic due to the fact that errno support isn't particularly well supported in the CPM libraries.
2) After providing dummy routines for memmove and strerror, the code fails to link properly, because the overall size exceeds 64k
Name Link Load Length
(abs) 0 0 0
text 0 0 738d
data 738d 738d 12a0
bss 862d 862d f821
i.e. total size is 97,870 bytes even with dummy routines, with heap being another demand above this.

The main culprit is readlzw.c which allocates 5 arrays of int [4096], an array of unsigned char [4096] and an array of int[5003].
The total data+bss usage for the various files is
File data+bss
readlzw.c 55132
readlzh.c 7094
main.c 3619
getopt.c 508
readhuff.c 90
readrle.c 4
total 66447
The data space requirement alone exceeds the memory space even without the library data+bss demands.
Without a radical rewite or removal of, lzw support it does not look like a CP/M lbrate version is viable.

Mark

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, February 3, 2023 at 7:01:50 AM UTC-5, Mark Ogden wrote:

On Thursday, 2 February 2023 at 10:07:53 UTC, Russell Marks wrote:

Lawrence Nelson <[email protected]> wrote:

While browsing the HiTech C subdirectory on my Z80 system, I came upon the file MAIN.C which appears to be a version of LBRATE for CP/M and HiTech C. There were also 4 header files for the various decompression methods but there were no corresponding C files. LBRATE was written by Russel Marks for Linux I believe and I have searched high can't find where this file came. I do have a zip file with the Linux source, docs and makefile. Does any one have the complete HiTech C, CP/M, version
of LBRATE?

To me that sounds like it might be a modified version intended just to e.g. list the contents of LBR files while "correcting" the filenames
that were modified by compression.

I feel like lbrate proper would run very badly if at all on CP/M - it rather extravagantly decompresses each file to RAM in full before
writing it, which makes for nicer code in some ways but would be completely absurd on an 8-bit machine.

-Rus.

I had a go at modifying lbrate 1.1 to compile with hitech c. It can be compiled, but not linked.
There are two problems
1) two additional routines are required.
memmove which is easily implemented and
strerror which is more problematic due to the fact that errno support isn't particularly well supported in the CPM libraries.
2) After providing dummy routines for memmove and strerror, the code fails to link properly, because the overall size exceeds 64k
Name Link Load Length
(abs) 0 0 0
text 0 0 738d
data 738d 738d 12a0
bss 862d 862d f821
i.e. total size is 97,870 bytes even with dummy routines, with heap being another demand above this.

The main culprit is readlzw.c which allocates 5 arrays of int [4096], an array of unsigned char [4096] and an array of int[5003].
The total data+bss usage for the various files is
File data+bss
readlzw.c 55132
readlzh.c 7094
main.c 3619
getopt.c 508
readhuff.c 90
readrle.c 4
total 66447
The data space requirement alone exceeds the memory space even without the library data+bss demands.
Without a radical rewite or removal of, lzw support it does not look like a CP/M lbrate version is viable.

Mark

Thanks all for responding. Yeah, I have since read the documentation for the Linux version and found out LBRATE does indeed keep everything in memory so obviously as Mark states, "it does not look like a CP/M version is viable." Still puzzling as to
where I got main.c modified for compilation with HiTech-C . Unlikely that I did the mods since I am a HiTech-C ludite. In fact I haven't done much C programming since System 7 Unix.

Lars

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)