ASCLZPAK, MSP1.6, Lazy Pack
ASC Screen Crusher
One of the first major display of packers, ASCLZPAK (1991)
identified the main ideas of the structure of most subsequent
photon RIAT and the corresponding depakerov.
Namely, although the data in the file yet, and
are just bytes, but the first is implemented fairly optimal
sequence viewing screen - broken columns. When
This screen is logically divided into 3 thirds and attributes,
where attributes are linear, and third consist of columns of
bytes. This method gives the ability to compress slightly worse
ways to complete the columns, but here is simpler conversion of
a linear model to the real screen.
Acquaint the reader with the idea of linear
Model ZX screen.
Is it that every address on the screen one correspondence
with the virtual address in a linear model and the sequence of
addresses screen generated by the order of viewing (in this
case - broken columns) looks on
linear model of consistency in a row
going virtual addresses. T.e.pri brute force of virtual
addresses linear models - real address on the screen will move
polygonal columns. Of course, it needs to use
procedures for converting virtual addresses to
real.
Typically, the initial address of the real
and virtual screens match up to
address attributes are not restated.
Here is the conversion of the display address from the
virtual to the real on ASC'u (Scary, but keep in mind that he
first!):
LD A, H
AND # 58
CP # 58
JR Z, atr
LD C, A
LD A, L
AND 7
OR C
LD C, A
ADD HL, HL
ADD HL, HL
LD A, H
AND # 1F
LD H, A
LD A, L
AND # E0
OR H
LD L, A
LD H, C
atr
Unpacker ASCLZPAK, according to tradition, move and adjusts
for this three pairs of cells under the current program address.
Dangerous use of the stack there.
Move around the screen is a real address, and to coordinate
this (standard solution) applied three registraschetchika:
A '= 8 × column + 3-room-thirds;
B '= string inside familiarity;
C '= row number within a third of familiarity.
Packed data located directly after programmy.Format simple:
% 0bbbbHHH, LLLLLLLL - link back, disp =
= HHHLLLLLLLL, puts = bbbb +3
% 10000000 - end of file
% 10bbbbbb, bytes - bbbbbb bytes to take from
flow
% 11bbbbbb, B - B repeat bbbbbb +3
time (may be repeated up to 66 byte times, ie
more than one link)
Maxsoft Screen Packer 1.6
Packer Maxsoft Screen Packer 1.6
supports 3 modes of extraction and related
with these 3 different unpacker:
1. Directly on the screen, broken
columns;
2. Through the buffer broken columns;
3. Directly on the screen in screen
structure.
The last option is the simplest, but
has, understandably, lower quality compression.
Unpacking the same through the buffer does not differ from the
extract on the screen. Therefore, the following will be
considered namely unpacking mode to screen (1) - RTD in the
terminology, the author of the program (RealTime
Depack). It should be noted that the extractor
MSP1.6 is the most complicated screen unpacker from all with
whom we shall deal. If we compare more and
with the code, then the next can be delivered unless
that deHrust 1.x.
In the compressed data stream has two
- Bit and byte. Sampling bits from a stream produced by pairs
of bytes (ADD HL, HL: DJNZ: POP HL: LD B, C), c using two
additional registers: B - Counter, C -
constant 16. Start byte stream (DEC
SP: POP AF) accounts for a third byte of the file, after the
first two bytes of the bitstream. In what alternate flows
depending on the structure fayla.Bitovy stream - control.
For seekability depakera Index
the main stack is stored in a register
IY, and not in memory. Also, two adjacent cells of the program
adjusted to the address of its Location:
DI
CALL # 52
DEC SP, SP
POP DE
LD HL, # 110
ADD HL, DE
EX DE, HL
LD BC, # 98; address ldto
ADD HL, BC; (see below)
LD (HL), E
INC HL
LD (HL), D
Thus, realized the similarity subroutine call nxtde, which
is quite understandably, makes the usual operation of
translation DE pointer to the next byte of the screen
structure of the broken columns:
nxtde INC DE
LD A, D
CP # 58
JR NC, atr
DEC DE
INC D
LD A, D
AND 7
JR NZ, atr
LD A, E
ADD A, # 20
LD E, A
JR NC, sub8
INC E
BIT 5, E
RES 5, E
JR NZ, atr
sub8 LD A, D
SUB 8
LD D, A
atr JR ... ; Shift in the JR
; Can take 2 razl.znach.
(Attributes - linearly).
Call is as follows:
LD A, # 8B; offset exjr
ldto = $ +1
ldjr LD (atr +1), A
JR nxtde
exjr EX DE, HL
LD A, # 90; offset okjr
JR ldjr
okjr EX DE, HL
Said fragment always takes place
through, that is, we solved the problem exactly
displacement of both direction - HL and DE (input and output
when copying, respectively). This is due to the fact that the
movement the screen is a real address, as in
ASCLZPAK.
Header file has not, should he direct for the unpacker. The
first byte byte stream (the third byte of the file) is
the first byte of the screen, followed by the bit stream:
% 0 - just bytes (of a byte stream)
% 100 - puts = 3
% 1010 - puts = 2 (note, the code
longer than the previous one. This must mean
that references a 2 rarer ssy lok with a length of 3)
% 1011, B: -1 = end of file, -2 = 16-bit
value puts (POP BC), another puts = B +
+10 (Puts = 10 .. 263)
% In 1100 - puts = 4
% In 1101 - puts = 5
% 11100 - puts = 6
% 11101 - puts = 7
% 11110 - puts = 8
% 11111 - puts = 9
If the puts are not equal to 2, then made
decoding the high byte offset (positive disp):
% 1 - 0
% 0000 - 1
% 0001 - 2
% 00100 - 3
% 00101 - 4
% 00110 - 5
% 00111 - 6
% 010 000 - 7
% 010 001 - 8
% 010 010 - 9
% 010011 - 10
% 010100 - 11
% 010101 - 12
% 010110 - 13
% 0101110 - 14
% 0101111 - 15
% 0110000 - 16
% 0110001 - 17
% 0110010 - 18
% 0110011 - 19
% 0110100 - 20
% 0110101 - 21
% 0110110 - 22
% 0110111 - 23
% 0111000 - 24
% 0111001 - 25
% 0111010 - 26
% 0111011 - 27
% 0111100 - 28
% 0111101 - 29
% 0111110 - 30
% 0111111 - 31
(Links to all short length of 2, ie
dispH = 0)
Codes dispH> 27 can not be used in the screen, and it gives
the format some unwanted redundancy.
Next byte from the byte stream defines the low byte offset.
Subtract the bias from the current address in the virtual
screen (IX addresses it in a linear model) implemented a witty:
DEC SP
POP AF
SUB LX
CPL
CCF
LD L, A
LD A, HX
SBC A, H
LD H, A
After this virtual address in HL converted into the screen
and copies the block. Then, everything described is repeated,
etc.
Lazy Pack 2.0
Unfortunately, this packer screens
can use not all - for no apparent reason on most versions of
TR-DOS program while maintaining destroys directory of the
drive. But the format is considered worthy of rhenium.
In the format used by almost all the good ideas on the
compression of screens, which only implemented LC5.2, but along
the unpacker Lazy 2.0, of course, loses LC 5.2.
There is bit and byte streams in
simplest form: bitstream retrieved byte to the register D ', B'
= counter C '= constant 8 for placement in B'. The first
byte of the file belongs to the bit stream.
Virtual address of the screen in a linear model is contained
in IX, the real address - in DE.
Unpacker is not tied to the screen is called with: HL =
address of the packed screen. Do not use the stack (input
in HL '). Unpacks the screen # 4000, but
this number is an easy fix to any multiple of
# 2000. If you change a little code, and
any multiple of # 800. Extractor reaches
shifting ability, organizing in MEMBOT
BASIC system variables into three three JP
internal unpacker routines, let's call them get, down, and bit.
Definition your address extractor makes a DEC
SP, SP, so you need to make sure that interrupts are disabled.
get (+ # aa, # 5c97) - extracts from the bitstream into the
battery number 0 ... 23 following tree:
% 1 - 0
% 01 - 1
% 0010 - 2
% 0011 - 3
% 000 100 - 4
% 000 101 - 5
% 000 110 - 6
% 000 111 - 7
% 00001000 - 8
% 00001001 - 9
% 00001010 - 10
% 00001011 - 11
% 00001100 - 12
% 00001101 - 13
% 00001110 - 14
% 00001111 - 15
% 00000000 - 16
% 00000001 - 17
% 00000010 - 18
% 00000011 - 19
% 00000100 - 20
% 00000101 - 21
% 00000110 - 22
% 00000111 - 23
down (+ # cc, # 5c9a) - recalculate the address in
DE, to conform to the following
byte on the screen (in order of broken columns).
bit (+ # ea, # 5c94) - take one bit of
bitstream (the result in the carry flag).
Format:
% 1 - just take a byte (a byte out of the flow ka);
% 0 - call get.
If result = 7:
Read a byte from the byte stream.
If it is not -1, then puts = byte +25, otherwise
call get (putsH), then extract from
byte stream putsL.
If the result is <7:
Add 2, we puts = 2 .. 8.
If the result is> 7:
Add 1, we puts = 9 .. 24.
Next, call the get (dispH) and take a byte
dispL of byte potoka.Realizuem floor chennuyu link, etc.
Specific code out of the unpacker is not provided. Unpacking
itself controls the end of the screen.
Prepared by Coder
