Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #958 > unrolled thread

RE: LZW decompressor

Back to article view | Back to comp.sys.apple2.programmer

Contents

  RE: LZW decompressor Mark P M Lim <marklim@macgui.com> - 2013-11-08 09:36 +0000
    RE: LZW decompressor D Finnigan <dog_cow@macgui.com> - 2013-11-09 18:34 +0000
      RE: LZW decompressor Mark P M Lim <marklim@macgui.com> - 2013-11-10 02:37 +0000
        RE: LZW decompressor Mark P M Lim <marklim@macgui.com> - 2013-11-23 02:31 +0000
          Re: LZW decompressor markpmlim@yahoo.com.sg - 2013-12-24 18:51 -0800
            Re: LZW decompressor Mark P M Lim <marklim@macgui.com> - 2013-12-28 01:51 +0000
    Re: LZW decompressor denisbytezone@gmail.com - 2014-03-20 00:37 -0700
      Re: LZW decompressor Mark P M Lim <markpmlim@yahoo.com.sg> - 2014-03-20 22:28 +0000
        Re: LZW decompressor Denis Molony <denisbytezone@gmail.com> - 2014-03-21 16:26 -0700

#958 — RE: LZW decompressor

While attempting to build the AppleIIGS emulator GUS from its source code, I
noticed there is a folder named Disk. Within this folder, is an
implementation of a decompressor class called DecompressorShrinkIt written
by Andy Nicholas etal.

Overall, the source code for the decompressor classes appears to be
well-organised. In particular, the method GetCode looks neat. The decoding
logic of UnpackLZW appears to be similar to that of the unix utility
compress.

I imported the necessary source files into an XCode project, made some
modifications and tried to uncompress an item from a ShrinkIt archive. The
compressed file item could only be partially inflated; the XCode debugger
has features that allow one to view the contents of variables as well as
memory blocks. I tried with a few ShrinkIt archives but was unable to get
the original uncompressed file(s).

Just wondering if the decoder (UnpackLZW) is compatible with the encoder of
ShrinkItGS. The decoder was originally meant to inflate sdk (not shk) files 

Regards.

[toc] | [next] | [standalone]

#961

Mark P M Lim wrote:
> 
> Just wondering if the decoder (UnpackLZW) is compatible with the encoder
> of
> ShrinkItGS. The decoder was originally meant to inflate sdk (not shk)
> files

The Dynamic LZW/1 and LZW/2 used in ShrinkIt are not exactly the same as the
LZW algorithm used in Unix compress. There is an RLE step involved.
You should read the File Type Notes for NuLib; it explains some of these
changes.

Dynamic LZW/2 is only used in GS ShrinkIt.

-- 
]DF$
Apple II Book: http://macgui.com/newa2guide/
Usenet: http://macgui.com/usenet/  <-- get posts by email!
Apple II Web & Blog hosting: http://a2hq.com/

[toc] | [prev] | [next] | [standalone]

#962

D Finnigan wrote:
> Mark P M Lim wrote:
>> 
>> Just wondering if the decoder (UnpackLZW) is compatible with the encoder
>> of
>> ShrinkItGS. The decoder was originally meant to inflate sdk (not shk)
>> files
> 
> The Dynamic LZW/1 and LZW/2 used in ShrinkIt are not exactly the same as
> the
> LZW algorithm used in Unix compress. There is an RLE step involved.
> You should read the File Type Notes for NuLib; it explains some of these
> changes.
> 
> Dynamic LZW/2 is only used in GS ShrinkIt.
>

The unpacking process of LZWDecompressor will perform the RLE step after the
method UnpackLZW is called.

Regards.

Mark

[toc] | [prev] | [next] | [standalone]

#980

Hi,

After spending sometime looking at the various LZW programs on the Internet,
I think I have located the bug that prevents the ShrinkIt decompressor
method UnpackLZW() from decoding correctly.

Right at the top of the method DecompressorError
DecompressorShrinkIt::UnpackLZW() is the following code snippet:

          ................

	while (! putByteErr)
	{
		if (GotClearCode())
		{
			SetGotClearCode(false);			
			SetAtBit(0);					
			SetCurrentEntry(0x0101);

          ................

Commenting out the statement SetAtBit(0) allows an entire archived text file
to be decoded correctly.

However, the CRC of the uncompressed data (fCRC16.CRCword.crc) does not
tally with fOriginalCRC.

Regards.

Mark

[toc] | [prev] | [next] | [standalone]

#1008

Hi,

Since my last post, I came across an SHK archive that couldn't be decompressed. Further investigation revealed the compression was done with ShrinkIt's LZW1. After some thought and experimentation, I decided to uncomment the SetAtBit(0) statement; the decompression proceeded without any problem. Some minor changes to the source code will allow the UnpackLZW method to decompress a SHK archived item without crashing as a result of stack space being used up.

Here's the code snippet:

DecompressorError DecompressorShrinkIt::UnpackLZW(bool isType1)
{
	uint16_t code;
	DecompressorError putByteErr = 0;
	
	while (! putByteErr)
	{
		if (GotClearCode())
		{
			SetGotClearCode(false);
// the 2 statements below are required if it's LZW1 decompression;
// if omitted, performing a LZW2 decompression will result in a crash
			if (isType1)
				SetAtBit(0);

			SetCurrentEntry(0x0101);



Now the above method UnpackLZW works for SHK files that were compressed using either ShrinkIt's LZW1 or LZW2. Incidentally, all traces of Carbon Code had been removed from the original source code and replaced with C++ file i/o methods. One could write a ShrinkIt-compatible (decompressor) program that could be compiled and executed in 32-bit or 64-bit modes. A LZW encoder will have to be written for it to have the same functionality as the original ShrinkItGS.

Regards.

Mark

[toc] | [prev] | [next] | [standalone]

#1012

Hi,

Sorry, there is a typo error in one of the comments. It should read

// if omitted, performing a LZW1 decompression will result in a crash

Regards.

Mark

[toc] | [prev] | [next] | [standalone]

#1193

Hi

I've recently spent some time rewriting those unpack routines in Java. I use them in my DiskBrowser program (https://sourceforge.net/projects/applediskbrowse/). The source is out of date, but let me know if you want an up-to-date copy.

I have tested it on all the .sdk files I can find over at asimov (120 so far) without any problems.

Denis

[toc] | [prev] | [next] | [standalone]

#1194

denisbytezone wrote:
> Hi
> 
> I've recently spent some time rewriting those unpack routines in Java. I
> use them in my DiskBrowser program
> (https://sourceforge.net/projects/applediskbrowse/). The source is out of
> date, but let me know if you want an up-to-date copy.
> 
> I have tested it on all the .sdk files I can find over at asimov (120 so
> far) without any problems.
> 
> Denis
>

Hi, 

Thanks for the offer. I would be interested if it's is written in C++.

Regards.

Mark

-- 
Mark Lim PM

[toc] | [prev] | [next] | [standalone]

#1195

On Friday, 21 March 2014 09:28:11 UTC+11, Mark P M Lim  wrote:
> denisbytezone wrote:
> 
> > Hi
> 
> > 
> 
> > I've recently spent some time rewriting those unpack routines in Java. I
> 
> > use them in my DiskBrowser program
> 
> > (https://sourceforge.net/projects/applediskbrowse/). The source is out of
> 
> > date, but let me know if you want an up-to-date copy.
> 
> > 
> 
> > I have tested it on all the .sdk files I can find over at asimov (120 so
> 
> > far) without any problems.
> 
> > 
> 
> > Denis
> 
> >
> 
> 
> 
> Hi, 
> 
> 
> 
> Thanks for the offer. I would be interested if it's is written in C++.
> 
> 
> 
> Regards.
> 
> 
> 
> Mark
> 
> 
> 
> -- 
> 
> Mark Lim PM

I added a file (LZW.tar) to the file list. It has the code I used to test the routines on some known .sdk disks. Let me know if anything is not clear.

https://sourceforge.net/projects/applediskbrowse/

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web