Laser Compact 4.0
I'm not interested in older versions, though, and found
their appearance. Therefore, will begin immediately with the 4
th. Format it simple (The information is intact bytes), but the
code unpacker very curious.
As in the previously described screen compressors, LC
considers 6912 screen with three 8-znakomestnyh lines consisting
column B, and lying on a linearly
addressable attributes.
The file begins byte, which contains
byte values gap between the beginning and the end of the
attributes of the screen.
0 = full screen
1 = lower 2 / 3
2 = lower 1 / 3
8 = upper 2 / 3
9 = middle 1 / 3
16 = Upper 1 / 3
Bytes that is used in the unpacker
in itself, but at the same time converted to the beginning of
the screen and its height:
LD A, (HL)
LD LX, A; gap
AND 3
RLCA
RLCA
RLCA
OR 64
LD D, A; top of the screen
LD E, 0
LD A, (HL)
INC HL
AND # FC
LD C, A
LD A, 88
SUB C
LD C, A; the end of the screen
Unpacking differs from its predecessors by the fact that the
address on the screen are converted from the virtual to each
byte: registers HL (virtual address from)
and DE (which) is calculated e DE '.
LD A, H LD A, D
CP C; end of the shield CP C
JR NC, JR NC,
XOR L XOR E
AND # F8 SCF AND # F8
XOR L PUSH AF XOR E
EXX ADD A, LX EXX
LD D, A EXX LD D, A
EXX LD D, A EXX
XOR L EXX XOR E
XOR H POP AF XOR D
RLCA LD A, E RLCA
RLCA JR NC, RLCA
EXX LD A, L EXX
LD E, A JR LD E, A
Let me remind you that the LX is for full screen
0.
The procedure of transition to the following address
otsutstvuet.Eto enabled, not much
inflating the extractor, to realize a link with
Copy bytes backward. What else
more interestingly, the code of the operating mode of the main
loop at all times kept unpacker the flags:
Z, NC - A repeat of one byte
Z, C - Copy HL - in the DE + +
NZ, NC - taking the bytes directly from the
Flow (HL ')
NZ, C - Up to HL + + DE + +
Number of passes cycle in any case lies in B.
After the first byte, as described above, in the stream is
packed screen, coded as follows:
% 11000000 - end of the screen;
% 11xxxxx0, bytes (NZ, NC) - just the bytes from the
flow. The number of bytes% xxxxx = 1 .. 31;
% 11xxxx01, B (Z, NC) -% xxxx = 1 .. 15 identically bytes;
% 11000001, length, bytes (NZ, NC) - up to 256 identically
bytes (0 = 256); % 11xxxx11 (Z, NC) -% xxxx = 1 .. 15 zeros;
% 11000011, length (Z, NC) - 16 .. 256 zeros;
% 0pppphhh,% llllllll (NZ, C) - Short ssy
LKA:-disp =% 11111hhhllllllll, puts =% pppp +
+1 = 2 .. 16;
% 10ppphhh,% llllllll (Z, C) - Short ssy
LCA to be copied in reverse order:
-Disp =% 11111hhhllllllll, puts =% ppp +1;
% 00000HHH,% ppppppph,% llllllll (NZ, C) -
Long link:-disp =% 1111HHHhllllllll,
len =% ppppppp +1,
% 10000HHH,% ppppppph,% llllllll (Z, C) - length
Naya reference to copying in the reverse order, the same way.
Lack of size in large quantities
how to write one and then zhe.Krome of
Although 0 is coded simply special codes
for # ff is not provided. The idea was not brought
to the end ...
Laser Compact 5.2
In this version, deleted codes turned up, but added packaging
Links to Haffmanu.V therefore, the competition between LC4.0
and LC5.2 can win as one and another.
With the advent of Burial Laser Compact format LC5.2 has
become almost standard. "Almost" because they have not agreed
an extension (in Hrumer'a. PLC, a Sinn'a. plc), a universal
viewer BV did not learned how to open this format.
As before, LC is considering screen
a 3 (however, depends on the screen is
or part of) the lines of broken columns, plus attributes.
Address translation for this is as follows (almost identical
to LC4.0):
LD A, D
CP HX
JR NC,
XOR E
AND # F8
XOR E
LD B, A EXX
XOR E ADD A, E
XOR D EXX
RLCA LD B, A
RLCA LD C, E
LD C, A
Inside the screen, if present it is linear in the broken
column (ie, as it is unpacking), again acting
Compression of the family LZ. Dictionary size
# 1700 bytes, maximum line - 255/256
bytes. (If bias> 768 string length is encoded as one less.)
Bit and byte streams are implemented
similar format Hrust2.x, except that in one of the branches of
reading bits:
SLA D
JR NZ, $ +6
LD D, (HL)
INC HL
RL D
RL is used instead of SLI (since the initial
D value is 0, not 128). Program
ZX_Emul 0.33 is not always emulate this piece correctly. This
occurs, apparently due to improper billing flags after the
command SLI D. Replacement to SLI RL (with Preliminary entering
128 in the register D) this problem can be solved. In the
Appendix you can find patches to the ZX Guide # # 3,4 in the
form of sectors which need to be written on named place of disk.
Inside unpacker does not only act
negative bias, as is usual in
Hrumer'a but negative length links
(Cycle INC LX: JR NZ). This is due to the fact that
byte offset and length of links are extracted in the same
section of code. By diruyutsya they following table:
(See cycle DLC5, which is passed unpacker 2 times in a row,
once for -Puts = LX, a second time to-dispH = A ')
code-disp puts
1 FFxx 2
011 FExx 3
001 FDxx 4
01011 FCxx 5
01001 FBxx 6
00011 FAxx 7
F9xx 00001 bytes *
0101011 F8xx 8
0101010 F7xx 9
0101001 F6xx 10
0101000 F5xx 11
0100011 F4xx 12
0100010 F3xx 13
0100001 F2xx 14
0100000 F1xx 15
0001011 F0xx 16
0001010 EFxx 17
0001001 EExx 18
0001000 EDxx 19
0000011 ECxx 20
0000010 EBxx 21
0000001 EAxx 22
0000000 E9xx 23
(*) Read bytes from the byte stream, if
zero, the unpacking is interrupted, or
after decrementing take his ANTIdlinu links. Ie same LX, which
increases to reach zero.
After receipt-dispH extracted from the byte stream-dispL. As
already noted, when disp> 768 increases puts.
All that said the format would read as follows:
Title:
+0 "LCMP5"
5 length of the file, starting with the "code size
Screen
6 additional length of the header
which can begin after this bye
Ta. (In practice, [6] = 0, and from dop.oblast
absent.) Fragment unpacker, taking into
equation describing this item format, a few huts
accurate: LD A, (HL): INC HL: LD E, A. .. In some
In some cases benefits cut as Zago agile, and the beginning
of the unpacker. 7 + [6] code screen size. Thanks to the stop
roumnomu solution is the high byte
distance from the end of the pixel part
screen to atributov.6 possible values:
0 = full screen
1 = lower 2 / 3
2 = lower 1 / 3
8 = upper 2 / 3
9 = middle 1 / 3
16 = Upper 1 / 3
Decoded as: x'3 = 0/1/2 - beginning number of
belorussian thirds; x '# FC = 0/8/16 - work up
line 24/16/8, respectively.
8 + [6] 1-byte of the screen in uncompressed form.
9 + [6], the first byte of the bitstream, etc.
Bitrate:
% 1 - to take a byte from the byte stream;
% 0,-puts,-dispH (-dispL from byte flow
ka) - a link back to copying. Cheats
for disp and puts are given in the table above.
When disp = 1, obviously, is a repetition of the previous
byte, etc.
A few words about the ideas of compression ...
Since the relative percentage of the attributes in the
picture is small, the creation of special compression method
was not appropriate for them. In the meantime, if you use
compression byte stream for Huffman, specific attribute bytes
are in a state of ruin the whole tree. It is thought the
number again.
Established fact that is not necessarily
use the wrapper LC to achieve close to the limit (though who
knows what are they?) degrees of compression. Expanding the
number of screens in columns and each naXORiv other adjacent
bytes, we usually get an array compressed program ZXRar (in
mode Rar) to levels less than obtained Laser Compact'om. But
some screens XOR was contraindicated. Of course, the win
should be considered in comparison with the files LC5.2, packed
with lazy evaluation, or other "smart" method of optimization
options, but so far no such LC (as well as a Hrust1.x). This
idea number two.
In connection with the preceding has been suggested that
naXORivanie 0.1 bits of the column on the left of 6.7 bits to
the right column will better tree. Experiments have not given
better compression ratio, perhaps only
because the attributes were not separated. This
idea number three and the groundwork for future experiments.
Prepared by Coder
