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
