kbrown@irs3.UUCP (Ken Brown) (02/06/88)
Does anyone know of a version of compress which will run an a Zilog (Z8000 based) system and handle 16 bits. The version I have will only work at 12 bits. If you have such a version could you email a copy to me. Thanks in advance, Ken Brown kbrown@irs3.UUCP
clewis@spectrix.UUCP (Chris R. Lewis) (02/13/88)
In article <188@irs3.UUCP> kbrown@irs3.UUCP (Ken Brown) writes: > >Does anyone know of a version of compress which will run an a >Zilog (Z8000 based) system and handle 16 bits. The version >I have will only work at 12 bits. If you have such a version >could you email a copy to me. This may be totally impossible, unless your machine allows programs of about 500K or more to run. Try this: Acquire a copy of the source for compress from 2.11 news and try building it with "M_XENIX" defined (regardless of what version of UNIX you're running). You will also have to change the "#define BITS 12" to "#define BITS 16" within the "#ifdef z8000 .... #endif". [Grep the source for M_XENIX, if it ain't there, you've got the wrong version of compress. Mail me if you need a copy] If you are running Xenix, you'll probably only have to override the BITS definition. I *think* this is what's happening: like a 286, a Z8000 is segmented with 64K chunks. Thus, the maximum array size is 64K. Which corresponds to 12 bit compression. Now, Xenix most often runs on 286 class machines with the same limitation. The compress in 2.11 has been recently hacked to run with 16 bits under Xenix by fooling around with multiple arrays. So, you have to override compress.c's selection of 12 bits for compression on a z8000, and use the M_XENIX hacking as well. If 16 bit compress is possible on your machine, this will get you most of the way... Good luck. -- Chris Lewis, Spectrix Microsystems Inc, UUCP: {uunet!mnetor, utcsri!utzoo, lsuc, yunexus}!spectrix!clewis Phone: (416)-474-1955
dag@chinet.UUCP (Daniel A. Glasser) (02/23/88)
In article <443@spectrix.UUCP> clewis@spectrix.UUCP (Chris R. Lewis) writes: +In article <188@irs3.UUCP> kbrown@irs3.UUCP (Ken Brown) writes: +> +>Does anyone know of a version of compress which will run an a +>Zilog (Z8000 based) system and handle 16 bits. The version +>I have will only work at 12 bits. If you have such a version +>could you email a copy to me. + +This may be totally impossible, unless your machine allows programs of +about 500K or more to run. + +Try this: Acquire a copy of the source for compress from 2.11 news and +try building it with "M_XENIX" defined (regardless of what version of +UNIX you're running). You will also have to change the "#define BITS 12" +to "#define BITS 16" within the "#ifdef z8000 .... #endif". +[Grep the source for M_XENIX, if it ain't there, you've got the wrong +version of compress. Mail me if you need a copy] + +If you are running Xenix, you'll probably only have to override the +BITS definition. + +I *think* this is what's happening: like a 286, a Z8000 is segmented +with 64K chunks. Thus, the maximum array size is 64K. Which corresponds +to 12 bit compression. Now, Xenix most often runs on 286 class machines with +the same limitation. The compress in 2.11 has been recently hacked to run with +16 bits under Xenix by fooling around with multiple arrays. So, you have +to override compress.c's selection of 12 bits for compression on a z8000, +and use the M_XENIX hacking as well. + +If 16 bit compress is possible on your machine, this will get you most +of the way... + +Good luck. +-- +Chris Lewis, Spectrix Microsystems Inc, +UUCP: {uunet!mnetor, utcsri!utzoo, lsuc, yunexus}!spectrix!clewis +Phone: (416)-474-1955 I have tried this for my Zeus (Unix III) system and it almost worked -- The Z8000 compiler (segmented) and possibly the Z8000 itself have a problem with objects that are exactly 64k bytes long when accessing the last element. I suspect that the same trick used for the XENIX_16 fix could be used with a small twist to reduce the sub-arrays to < 64k. I will try this some time soon, and if I meet with success, I will post the results. -- Nobody at the place where I work Daniel A. Glasser knows anything about my opinions ...!ihnp4!chinet!dag my postings, or me for that matter! ...!ihnp4!mwc!dag ...!ihnp4!mwc!gorgon!dag One of those things that goes "BUMP!!! (ouch!)" in the night.