Softinka - Real Information Packer 0.2x - one of the most powerful compressor on the ZX.

<b>Softinka</b> - Real Information Packer 0.2x - one of the most powerful compressor on the ZX.

Real Information Packer 0.2x



   By the author - Roman Petrov (YoshkarOla), namesake and 
namesake of Yoshkar-Ola composer Megus'a. Man of Mystery. Write 
a single program, he disappeared into the uncertainty, and 
immediately had questions: from this level of programming? when 
and how the jewelry is so configured compression settings? why 
the conditions the growth rate length of the reference with an 
accuracy up to plus or minus bytes coincided with similar 
conditions in a format Rar2.x, although by the time the RIP  
This format does not made public? 

   In any case, it is one of the most powerful
compressors on the ZX, win it now can only ZXRar, moreover, 
whether ZXRar written before RIP, it is not clear who would be 
someone won ... On small files RIP fundamentally more 
profitable - because of the smaller volume tree length and 
unpacker. 


   There are 3 unpacker RIP: The original v0.21 size # 121, 
with parameters in the HL (from) and DE (where); DERIP + + +. H 
size # 112 (in contrast to the previous one, allows you to 
specify the address of the trees is independent of Address 
unpacker) and v0.25, sew to a packed file like Hrum, rather 
suboptimal. 

   Nail size - these are arbitrary
trees that are stored in a file in the packed
form, just like in the archives of Zip, Rar, etc.
The procedure for constructing the tree in fact brilliant. 
Bring it here does not make sense, it is repeated in the source 
DERIP, mRIP, RZXSFX etc. Without her incredible concise idea of 
using arbitrary trees in the code compressor remain

would be meaningless. Would have thought that such
trees worthy only archiver.

   However, users of the new compressor had to get used to a 
new problem: finding # 5C0 bytes (# 5C2 in DERIP + + +. H) 
memory under derevya.Eto no longer under the 256 bytes active 
part of the unpacker, in Hrust1. No, such a large volume should 
be somewhere to allocate. For example, in ekrane.Ne always 
permitted. Probably because of such problems RIP has not 
received a large spread in assembly of electronic media.


   Another problem - the rate of extraction.
It is significantly lower than that of the old compressor, even 
lower than that of the program UnRar. This shortcoming can not 
be eliminated - it is associated with lack of principle in a 
packed byte stream file. Begin affect processing cycles of 
trees, and acceleration is only possible at the cost of their 
substantial increase the unpacker and the buffer under the 
trees. 


   Bits are read from the byte from the 0-th,
ie outside the box.


   Format:
0 (2) - UnpLen, unpacked length;
 2 (2) - PakLen, packed length, counting
 with the next cell (4);
 4 - the beginning of information about trees. 18 Th
  tyrehbitnyh numbers (tetrads), indicating

  number of bits in haffmanovskih codes have

  wood used for the extraction work
  sneeze trees. For each of the codes 0 ... 17

  kept the length in bits (0 - no code ISPO
  box is used, the more often the code, so it should be
 shorter).

   Of these tetrads is uniquely constructed tree on which would 
be regarded as similar data on 288 characters, 32 workers of 
trees. Of course, those of similar data (they lie

etc.) are not necessarily 288 32 bytes (in the sense that 
characters Huffman) - they cleverly coded: 0 .. 15 - just a 
code of length, such as those tetrads, 16 - the end of the 
information; 17 - repeat 2 more times the previous length. 


   Tree of 288 literals conventionally call
maintree, and a tree out of 32 - just a tree.

   Trees are constructed from lengths of the following
 rules:

  1. If the tree is drawn so that the root
will be above the unit to the right, and the zeros on the left,
then the left sub-branches should be no longer than
Right. The lower edge of the tree branches should be gradually 
lowered (depth increases tsya) from left to right. 

  2. Within tiers (sets of leaves,
imeschih same depth) acts sorting: the smaller the character 
codes to the right of bolshih.T.e.naoborot relatively Rar. This

associated with a reduction unpacker.

   Once all the information about wood is, the bytes are 
extracted end of archive (In reverse) on a tree maintree,

immediately throw in stek.Lyuboy literal
Є256 - the end of this process, and starts
actually unpack.


   Unpacking happens in cycles, each of
which begins with the reading of a character on a tree maintree:

 0 .. 255 - it just bayt.Pomestit vyho ne flow;
 257 .. 260 - puts = 1 .. 4. Next, the tree tree

  reads the code length disp:

   0 - use old disp;

   1 .. 4 - disp = 1 .. 4

   5.7 ,..., 31 - disp form% 10 .., from 3 to 16

    bit.Dochityvayutsya missing bits disp,

    starting with the oldest;

   6.8 ,..., 30 - disp form% 11 .., from 3 to 15

    bits. Similarly. This shows that once
    up window does not exceed 49,151.

  This encoding is fully consistent with disp
  em format Rar (see Inferno # 4). More then
  On almost (256 <> 257) matches as follows:

  When disrЄ256 incremented puts. When

  disrЄ # 2000 again incremented puts!
 Implemented by copying.
 261.263 ,..., 287 - codes of lengths puts (puts =

  =% 10 ..) from 3 to 16. Additionally, the read
  vayutsya (respectively) 1 .. 14 bits for at
  dtsepleniya% to 10 .. Next, read disp,
 as above;
 262.264 ,..., 286 - similar, but puts =% 11 ..
 From 3 to 15 bits. Next disp, as above;
256 - finish unpacking.


   After unpacking from the stack are removed
bytes of the end of the file (the maximum number of I
unknown).


              mRIP (mrip4.H)


   Format differs from the original RIP
 the following details:

   1. No UnpLen, PakLen in the beginning;

   2. No end of file bytes in the beginning;

   3. No Code "to repeat the previous disp";

   4. No correction puts at disrЄ # 2000;

  5. Tetrad lengths of wood for building codes, working trees 
are in reverse order. 

   As a result depaker fit in BASIC-block, and was created a 
convenient avtosborschik for system applications. On small 
programs, it beats RIP'a one sector due to the size unpacker. 
On long can theoretically lose. But in practice before this 
does not come from the restrictions file size, pakuemogo mRIP. 
That's what its limits:


   mRIP not move before unpacking the unit, so the address of 
the end of the packed Block should be higher than the end 
address unpacking. And the address of the end of the packed

block does not depend on you, and the length of this
packaged unit plus mark OTKUDA. A
this label (the current version # AA00) in its
turn depends on the maximum size
block and tags maintree (in current version
# F881), since unpacking generated
trees that have somewhere to store, and blacked out the screen 
does not work: not enough place in the Gaza BASIC.


   Restrictions is not only to extract, but also in packaging: 
packaging at a very large file may not have enough memory.

Can hope to pack the memory of # 6000
to # E000 (pg0), but not all the memory.


   To connect mRIP to the program must:



  1. Assigning labels begin, end, GO - pa zmery program and 
address its launch; 

   2. Form a program name in # 5CDD;

  3. At the beginning of the program to install the stack
paint the screen and the border, to deal with
constants of the keyboard: REPPER and REPDEL ...
Desirable LD (IY +1), # CC for fearlessly using your program 
memory  # 5bxx. Sam mRIP just does not do this;


  4. At the end of the main source code to put
INCLUDE "mrip *".

   It is recommended to write it "mrip *", and
not "mrip4", because the version could mRIP
change. If you, for example, to distribute their source code, 
the recipient can be another version, he will have kudato 
climb, something to fix ... (Most people can not tolerate any 
gestures.) And you will also be easier to update on its version 
mRIP diskah.Zachem update? Sometimes it is very unpleasant to 
rummage, to search for the MOST RASPOSLEDNYUYU version on all 
disks, and there completely all the old yes old ...



   If defined label make, and assembly occur without pressing 
Caps Shift - can used for propagation with mkacepodobnymi 
pickers. 

   For the organization of the debug run, which changes the 
code, enter (if necessary) after the INCLUDE the following: 



                 ORG $

                 CALL 8026

                 JP NC, nenado

                 <Your pokes>

                JP GO


   Restriction on the size - do not cross
Address # 5c00.


                       Prepared by Coder