18 May 2018, 20:29 | #1 |
Registered User
Join Date: Nov 2017
Location: france
Posts: 109
|
Pack-ice on Amiga
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 |
18 May 2018, 20:59 | #2 |
CaptainM68K-SPS France
|
i think that yes an executable for Amiga exists.
|
18 May 2018, 21:50 | #3 |
Registered User
Join Date: Nov 2017
Location: france
Posts: 109
|
And the name of the winner is ?
|
19 May 2018, 04:19 | #4 |
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 56
Posts: 2,054
|
|
19 May 2018, 13:16 | #5 |
Registered User
Join Date: May 2004
Location: Somewhere secret
Age: 50
Posts: 366
|
IAM packer is the one (ICE + Mirage Packer, I think from memory) indeed.
|
19 May 2018, 14:32 | #6 |
Registered User
Join Date: Nov 2017
Location: france
Posts: 109
|
Thks
I going to find him. |
22 May 2023, 06:16 | #7 |
Registered User
Join Date: Feb 2016
Location: Homeless
Posts: 67
|
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). Code:
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. 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. Code:
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 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. Code:
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 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. 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 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). Code:
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) 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) Last edited by nocash; 22 May 2023 at 06:49. |
22 May 2023, 15:45 | #8 |
Banned
Join Date: May 2006
Location: n/a
Posts: 278
|
really nocash.. you had to resurrect an OLD as in 2018 post.
|
23 May 2023, 11:40 | #9 |
Registered User
Join Date: May 2004
Location: Somewhere secret
Age: 50
Posts: 366
|
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
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Which Amiga pack did you get? | alexh | Nostalgia & memories | 157 | 07 August 2023 20:08 |
Amiga suitable battery pack | DrF | support.Hardware | 24 | 08 September 2007 21:20 |
Good ice hockey game for Amiga | macce2 | Retrogaming General Discussion | 22 | 14 May 2007 15:22 |
Good ice hockey game for the Amiga | macce2 | Retrogaming General Discussion | 18 | 05 June 2005 09:55 |
Amiga Galactic Pack | Galaxy | HOL contributions | 0 | 30 May 2005 15:14 |
|
|