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?

Lawrence Nelson <larsnelson@adelphia.net> 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.

On Thursday, 2 February 2023 at 10:07:53 UTC, Russell Marks wrote:
> Lawrence Nelson <larsn...@adelphia.net> 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

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 <larsn...@adelphia.net> 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