Pack-ice on Amiga

[Giants]

I'm looking for ICE cruncher for Amiga (not decruncher but bruncher)
I know the source of Ice packer is available on the net : http://dhs.nu/news.php?t=single&ID=790
But, it's for Atari ST

If they are a good soul who wants to adapt and compil on amiga, I keep it
Or, maybe it's existe already a software to do this on Amiga ?
Crunching on ICE format !

Thks a lot

[dlfrsilver]

i think that yes an executable for Amiga exists.

[Giants]

And the name of the winner is ?

[Don_Adan]

Originally Posted by Giants

And the name of the winner is ?

IAM Packer.

[WayneK]

IAM packer is the one (ICE + Mirage Packer, I think from memory) indeed.

[Giants]

Thks
I going to find him.

[nocash]

After seeing "ICE!" and "Ice!" files being mentioned on http://www.amiga-stuff.com/crunchers-id.html I have just spent some days on trying to figure out how this fileformat is working... it's quite a mess, and - I think - nobody has ever fully documented or figured out how it works... but I think I have solved it:

Pack-Ice (by Axe of Confusion)
Pack-Ice is mainly used on Atari ST (but also used by some Amiga games/demos).

 Fileformat for 1.13:
  000h ..  Compressed Data (processed backwards)                ;-Data
  ...  4   Uncompressed Size      ;\at filesize-8               ;\Footer
  ...  4   ID ("Ice!")            ;/                            ;/
 Fileformat for v2.11 and up:
  000h 4   ID ("ICE!") (or "Ice!" for v2.20 and older versions) ;\
  004h 4   Compressed Size (filesize, including 0Ch-byte header); Header
  008h 4   Uncompressed Size                                    ;/
  00Ch ..  Compressed Data (processed backwards)                ;-Data
There are various Amiga games/demos that have "Ice!" replaced by hacked IDs:
  "-CJ-", "MICK", "PP20", "SHE!", "TMM!", "TSM!"
Most or all of these hacked files seem to use the old v2.1x variant with 32bit
bitstreams.

Pack-Ice Versions
There are several changes to the file format, without trying to maintain backwards compatibility with older files.
The format is perhaps intended for in-game decompression, but unsuitable for archiving or exchanging data.

  Version  ID             PictureSize   Bitstream   Disp
  v1.13    "Ice!"=Footer  None          32bit       (1..N)+lzlen-1       ?
  v2.11    Header="Ice!"  Fixed=FA0h    32bit       (1..N)+lzlen-1       tested
  v2.12    Header="Ice!"  Fixed=FA0h    32bit       (1..N)+lzlen-1       ?
  v2.20    Header="Ice!"  Fixed=FA0h    8bit        1, or (2..N)+lzlen-2 ?
  v2.31    Header="ICE!"  Fixed=FA0h    8bit        1, or (2..N)+lzlen-2 ?
  v2.34    Header="ICE!"  Variable      8bit        1, or (2..N)+lzlen-2 ?
  v2.4     Header="ICE!"  Variable+Bug  8bit        1, or (2..N)+lzlen-2 tested

Some variants can be detected, eg. the extra variable PictureSize exists only if the bitstream contains additional bit(s) after end of decompression.
The v2.20 variant does use the old "Ice!" ID combined with new 8bit bitstream, which is making it more or less impossible to detect/decompress v2.20 files.

Decompression
The decompression is simple, but requires some efforts for detecting (or guessing) and handling streamsize = 8 or 32.

  id=[src_start+00h..03h]                     ;\for v2.11 header and newer
  src=src_start+BitEndian32bit[src_start+04h] ; (different for v1.13 footer)
  dst=dst_start+BitEndian32bit[src_start+08h] ;/
  streamsize=32                               ;-for MOST older "Ice!" versions
  if id="ICE!" then streamsize=8              ;-for ALL newer "ICE!" versions
  if Byte[src-1].bit7=0 then streamsize=32    ;\when above guess is impossible
  if Byte[src-4].bit7=0 then streamsize=8     ;/
  if streamsize=32 then src=src-4, collected=BitEndian32bit[src];\stream fetch
  else                  src=src-1, collected=Byte[src] SHL 24   ; (max 31 bits,
  if collected.bit31=0 then error                               ;/and end flag)
  ;above must be 80000000h (bit31=endflag) or higher (bit31=rawlen+more bits)
 ;- - -
 @@decompress_lop:
  rawlen=GetBits(1)+00h, if rawlen=01h then                     ;\
    rawlen=GetBits(1)+01h, if rawlen=02h then                   ;
      rawlen=GetBits(2)+02h, if rawlen=05h then                 ; raw data
        rawlen=GetBits(2)+05h, if rawlen=08h then               ; (0..810Dh
          rawlen=GetBits(3)+08h, if rawlen=0Fh then             ; bytes)
            rawlen=GetBits(8)+0Fh, if rawlen=10Eh then          ;
              rawlen=GetBits(15)+10Eh                           ;
    for i=1 to rawlen, src=src-1, dst=dst-1, [dst]=[src]        ;/
  if dst<=dst_start then goto @@decompress_done                 ;-end check
  if     GetBits(1)=0 then lzlen=02h                            ;\
  elseif GetBits(1)=0 then lzlen=03h                            ;
  elseif GetBits(1)=0 then lzlen=04h+GetBits(1)                 ;
  elseif GetBits(1)=0 then lzlen=06h+GetBits(2)                 ; lz data
  else                then lzlen=0Ah+GetBits(10)                ; (len=2..409h
  if lzlen=2                                                    ; bytes,
    if     GetBits(1)=0 then disp=01h+GetBits(6)                ; with disp
    else                     disp=41h+GetBits(9)                ; 1..1120h+408h
  else                                                          ; bytes)
    if     GetBits(1)=0 then disp=21h+GetBits(8)                ;
    elseif GetBits(1)=0 then disp=01h+GetBits(5)                ;
    else                then disp=121h+GetBits(12)              ;
  if streamsize=32 then disp=disp+lzlen-1   ;old version        ;
  else...if disp>1 then disp=disp+lzlen-2   ;new version        ;
  for i=1 to lzlen, dst=dst-1, [dst]=[dst+disp]                 ;/
  goto @@decompress_lop                                         ;-next

End of Decompression, with optional bitplane-filter
This requires some logic for detecting the picture filter (modern HLL decompressors seem to leave that feature completly unimplemented).
And, the v2.4 disassembly contains a weird bug where it's overwriting the collected bits by the LSB of "(320*200/16)-1" value.
I don't know if that bug does actually exist in the v2.4 binary, or if somebody had just screwed up on "optimizing" the disassembled code.

 @@decompress_done:
  if dst<>dst_start then error
  ;- - -
  ;XXX skip below if VERY OLD version (with footer instead of header)
  if GetBits(1)=1 then
    ;unknown if this was ever used (all known files have above bit set to 0)
    ;- - -
    picturelen=320*200/16                                       ;-default len
    if src<>src_start+0Ch or collected<>80000000h then          ;-more data?
      ;WORKING v2.34 does support this without bugs             ;\
      ;BUGGED v2.4 now sets collected=9F000000h   ;<--outch     ; optional
      ;BUGGED v2.4 will thus read picturelen=3C00h..3FFFh       ; variable len
      if GetBits(1)=1 then picturelen=GetBits(16)+1             ;/
    dst=dst_start+BitEndian32bit[src_start+08h]
    for i=1 to picturelen  ;convert pixels (16x4bit) to bitplanes (4x16bit)
      for j=1 to 4         ;(only useful for Atari-ST-style bitplanes)
        dst=dst-2, x=BigEndian16bit[dst]
        for k=1 to 4
          x=x+x, plane0=plane0+plane0+carry  ;\
          x=x+x, plane1=plane1+plane1+carry  ; 16bit additions
          x=x+x, plane2=plane2+plane2+carry  ; with carry-out
          x=x+x, plane3=plane3+plane3+carry  ;/
      BigEndian16bit[dst+0,2,4,6]=plane0,plane1,plane2,plane3
  if src<>src_start+0Ch or collected<>80000000h then error
  ret

Bitstream reading
Bitstream reading is nothing special, but different for versions with 8bit and 32bit streams.
The bitstream is interleaved with uncompressed bytes (so the 32bit values may appear at unaligned locations).

 GetBits(n):
  val=0, for i=1 to n, val=val*2+GetBit
  return val
 ;---
 GetBit:
   collected=collected SHL 1    ;32bit shift            ;-get bit
   if collected=0                                       ;-fetch more...
     if streamsize=32                                   ;\
       src=src-4, collected=BigEndian32bit[src]         ; old version
       collected=((collected SHL 1)+1)                  ;/
     else                                               ;\
       src=src-1, collected=Byte[src]                   ; new version
       collected=((collected SHL 1)+1) SHL 24           ;/
   return carry         ;carry-out from above 32bit SHL shift(s)

References
http://demozoo.org/search/?q=pack-ice - Various Pack-Ice versions
http://web.archive.org/web/2/http://...source/axe.zip
The above packages do include source code for the decompressor (and in case of axe.zip, also for the compressor). Whereas "source code" means more or less poorly commented disassemblies of the binary code.
Note: The decompression functions exist in two variants (one using separate src/dst buffers, and one using a single buffer, which must be 120 (78h) bytes taller than decompressed size; anyways, the actual decompression logic is same for both variants).

Sample files
http://fileformats.archiveteam.org/wiki/Pack-Ice - several links to 8-bitstream "ICE!" files
http://cd.textfiles.com/atarilibrary...AG12/ARTICLES/ - 8-bitstream "ICE!" txt files
https://demozoo.org/productions/95848/ - v2.11, 32-bitstream "Ice!" txt file
https://demozoo.org/productions/111220/ - hacked 32bit-stream "-CJ-" files (with some ASCII strings in files "C" and "W")
I haven't found samples for following things - which would be be nice to have!
- very old files (with "Ice!" Footer, instead of Header)
- pictures that require to apply the additional Atari-ST-bitplane filter after decompression (either with or without the variable size)

[andy2004]

really nocash.. you had to resurrect an OLD as in 2018 post.

[WayneK]

This is the kind of necro-posting I approve of, coming back 5 years later with all the answers having done lots of hard work to prove it