Wild Mind - Compression: The first graphics compressors on Speccy (part 1).

Compression
Alone Coder

   The first graphics compressors on Speccy
were probably in Screen Machine by Joe
Gillespie(5'84) and included in The Artist set 
I(6'85). Perhaps there was an even older one 
program, but nothing has survived from it,
except for the name - Fill-Compressor by Base
Two Software(1983). 
 But in branded games the result of the work
I haven’t come across any screen compressors.
   The first known Spectrum computer─
text springs (tokens) - Text Compression
System, published as a listing in 
September1984. Such systems have been used─
appeared in some text adventures.
   In80s there were programs of incomprehensible
origin (from Eastern Europe?), eg─
example, some strange ancient compressor
screens with4 methods - COMPRES+.
 Then came domestic developments:
  - Balyasov compressor COMPRESS (1990,
Moscow)
 - ZX ARC(CoCo, Compressor v1.01 - 1991,
Mike Studio S.Peterburg 1782908)
 - ASC packer Sendetsky(1991, Lviv)
 Historically on Speccy (already in the first re─
clame Screen Machine) file compression nazy─
is doneby compression (to compress), and not by compression─
forging orarchiving. But the word "packaging" 
has taken root in the post-Soviet space.
   A packer with a depacker is known on the C64
1986 Cruncherhttp://csdb.dk/release/
?id=19112 (perhaps there were older ones). Here
a different naming tradition is visible, which
reflected on the Amiga.
   The most popular domestic compresses─
litters are sorted out in Inferno Guide #5. Basics─
This family uses LZ77 (see Info
Guide #7) with parameters encoding something 
typeGamma Code or Elias Delta Code, which─
short numbers would take up fewer bits. Because
there is no need to store either trees or tables, but
unpacking is usually done right on top of the package─
forged file, additional memory that─
kimdecompressors are not required. History
Almost finished with Spectrum compressors─
disappeared with the advent of a small family
compressors withHuffman code (RIP, mRIP,
ZXRar), then they usually just took ready-made 
development from other platforms. Arithmetic─
some coding (see example in Info Guide
#6) turned out to be too slow for the Z80. 
   But Spectrum compressors are still
can be improved. You can start with development
cross-platform compressors, especially
that greedy techniques are easier to implement there.
In this case, the task is mainly
developing a good unpacker.
   In this article I will list ideas that...
ry came up in long discussions on
irc.forestnet.org #mhm with lvd, hrumer,
jtn'om and others. 

     1. Optimal LZ (see Info Guide #6)
   Implemented for MegaLZ and Hrum formats
in mhmt. For Huffman, everything is more complicated - that's why
RIP and ZXRar have two presets - for text and
codes, plus fine settings in ZXRar/mRIP.
   Make an optimal mRIP - for one thing─
the third block will not need new packers for a long time
in the "slow unpacking with buffer" genre.

lvd>memory required N*file size (where N=50 
..100), the speed required is M*GHz, where M
unknown) it was not in vain that I promised a box of Coca-Cola
to those who will receive the same size on spec
in megales, like on PC my packer.

lvd>what optimal LZH should look like 
for post-Huffman? before encoding we have
list of all references to EACH byte. for LZH
we draw the prices of each and build them from back to front
path, and encode it from front to back into the output.
for Huffman - we encode the LZH output with it.
alone> first we pack to find out the lengths 
codes, then we repack it taking into account this
statistics. possible many times. but the prices are the same.
lvd>that is, we are building wholesale. LZH, encode 
Huffman, then rebuild LZH taking into account
new prices? and where is the guarantee of what it is
will converge to the optimum?
alone> no guarantee. 
lvd>and also, not each of all links can 
hit Huffman. so you made a list
all links, and then the optimal path. and y
not all links fromare included in your output
all possible! because Huffman will assign
new price because they fell on it.
alone> give those who did not hit a false length of 15. 
otherwise you won't be able to pass the next passage.
This is a normal penalty. On the last pass,
Naturally, all those who do not make it are excluded.
lvd>if they are not hit, this does not mean that 
there is a fine for them. suddenly if you shuffle
links, taking into account the new prices, a lot will come out
repeating others, and you slap them.
alone> well, 15 will give them a chance. but it won’t give 255. 
You can use a median filter by link lengths
drive away. if, for example, 5 and 7 were used, and
6 is not present, then it will be assigned the same code length.
lvd>or maybe build Huffman according toeveryone 
in general, links that are for each byte, and
set a price based on the results. Then wholesale, then
rehuffman and price correction. and so on.

lvd>hrumer: is there something like Dijkstra 
for LZ+Huffman? or even LZ+exomizer?
hrumer> Yes, there certainly are. It seems that 
It’s cooler, in 2014 the zip was improved a bit, 
I forgot what the algorithm is called. Format 
The zipper remains. But there is 10 times more time 
necessary. The exomizer already has LZ inside. What if 
Are you talking about whether there is an optimal code in it─ 
ration for computed Huffman codes - 
I think there is. But are they choosing cunningly? 
Huffman codes or not - I don't even know 
I'll put it down. We need to tinker with the sources. 
lvd>is there really Huffman there? I looked at the depacker 
there is something like a fixed number from the stream
selected, lookup in the table, link from it.
The number of different links is limited by the table.
optimal encoding is 100%
only for bare LZ. and in the case of Huffman
over LZ? Do you really need to remember all the links
for all positions, so that wholesale. xf+LZ then
build? so no gigabytes will be enough.
hrumer> As far as I remember, there are separate codes 
Huffman for distances of length 2 and distances 
greater than length 2. For characters Huffman codes 
are not used. And cunningly, but most likely 
standard canonical, trees packed 
type of plates on which these Huffman codes 
decode. There are also Huffman codes for lengths. 
lvd>well, that is, he invented heuristics 
some or solved the selection problem
optimal compression in the case of HF over LZ?
hrumer> As I understand it, the second one. But completely 
optimal or not - I don’t know. Apparently, with 
some approximation to the optimal one. A 
maybe just too many 
iterations. Found:http://dml.compkaluga.
ru/forum/index.php?showtopic=74084

hrumer> and who is Roman Petrov? author 
ripafirst? cool comrade did RIP! 
alx_bw>RIP Packer from Roman Petrov. 
from here from Yoshka.
alone> mRIP usually packs better than RIP, and 
The depacker fits into the BASIC. Format from RIP,
but simplified. Algorithm from ZXRar. Use mRIP─
there is a lazy evaluation packaging strategy, and
not in RIP. This is when a link is not placed,
if it is more profitable to put a symbol and another
link. Results for glitch service: three
blocks totaling 18K mRIP won 17 bytes.
alx_bw>what is the maximum block length? 
#a000 can?
alone> #8800, probably. It was done in real life 
from ZXRar. This is for the version with the shell, and in
version from the auto assembler it all depends on
everything. Because the result is written on top.
alx_bw>because I prepared such blocks─ 
I really press my RLE. Roughly speaking, it presses
same bytes. same interrupt table
if not initialized, but already ready.

Roman Petrov> 
   I developed this packager for school─
years, and then after entering university 
I didn't have the opportunitydo it, and 
I gave the source code to Roman Petrov, my 
namesake and good friend. 
alone> 
   And there were rumors that this was a thesis work
8) If it’s not a secret, how the for was developed─
checkmate? Why did it turn out to be so similar to Rar?
Roman Petrov> 
   Yes, although this is not a thesis
there was, I think, enough for a diploma there 
- considering what diplomas are written now 
in specialties teaching programming 
nyu :) The format was not developed at all─ 
studied: while studying at school and mastering the Z80 and ac─ 
sampler, I don’t remember why I suddenly decided 
develop a data wrapper - and, of course 
well, it should have been the most effective :) 
   At the beginning of development there is nothing at all
knew about compression algorithms, I didn’t read 
I remember where about Lempel-Ziv, I started developing 
your own packer. About variable length codes─ 
I didn’t know anything, I spied it, it seemed like 
HRUST is done, I started to come up with my own ideas 
yes. When already on the Internet, which then 
it wasn’t enough, I found out about Huffman codes - right away─ 
I was determined, of course, I implemented it. 
   In general, I literally lived for this “project”
(at school, of course, I didn’t know what prog was─ 
frame project). At night, in class, at any time 
free time looking for new solutions, thinking 
on quality/compression speed improvements. 
Every improvement was a real victory :) 
I think there are such enthusiasts among Spectrumis─ 
there were a lot of people. Actually, I was looking for a way to write─ 
perfectpacker what's like now 
I already understand that it’s hardly possible. One of the sa─ 
Our interesting parts of the project were, of course, 
unpacker, its size optimization and 
speed, the battle was for every byte and clock cycle 
processor, mostly for bytes, because I wanted 
fit it into 256(?) bytes (how many are there 
needed for a basic block). The task and 
I haven’t solved it, but I struggled with it a lot :) 
   As for the similarity to the RAR format - even
I don’t know why this happened :) Most likely 
coincidence :) I'm, of course, in the last stages 
development, having received any access to 
Internet, greedily obtained information, but 
I don't remember using the RAR format - 
It seems that it had not yet been published then. 
   Later I read about arithmetic code─
roving, BWT, was interesting, but before the reality─ 
The implementation of these algorithms has not yet been achieved 
- entered the university, moved to the hated 
write to all spektrumists :) There were a couple more 
interesting programs that I have developed, 
but which no one saw: 
  - program for copying protected disks─
ket. Recently, floppy disks have become more protective─ 
Sorry, I set myself the task of writing a uni─ 
a universal copier that simply reads─ 
downloads all information from the floppy disk, including 
intersectoral, and copies. This is the program I 
wrote, everything worked quite well, even 
considering the buggyness of the disk drive controller 
(VG93). But there was a serious glitch in the account─ 
roller skater, he's on track 41persistently read from 
errors, tested on different computers. 
Those. copying the disk completely becomes─ 
It's impossible, there's nothing I can do about it 
I was able to, and abandoned the project. 
  - bootloader - I don’t know what they call it─
Yes, usually there were these on game discs 
to quickly load the game (cursor + menu). 
As is customary, 7 sectors, well, maxi─ 
a lot of functionality and performance there pos─ 
I tried to fit it in, overall I was the best 
common ones I have seen. 
   In general, for me it was the time when I
programmed with the greatest efficiency─ 
working now, efficiency is lower, 
probably once every 5-10. 
   I don't currently have the sources
RIP, I would be interested to take a look at 
them, feel nostalgic and see how I 
coded while in school :) 
alone> 
   I tried to contact Megus. Exodus─
he did not distribute nicknames. Himik's ZxZ de─
compiled the program and released several
to versions. These are the decompiled results─
nicknames:http://opensourcezx.untergrund.net/
c_soft-packer-rip_src.html
 I decompiled ZXUnRar, which is for─
quit AIG, and developed for some time
program. Then my PC broke down and it became
there is nowhere to get archives for testing. I
I first wrote an archive generator without a computer─
forging, then with packaging (ZXRar).To
the program took as little as possible (so that
the locals were jealous :)), I decided to pack it
RIP. But his unpacker didn’t fit
into a basic block. So I simplified it a little
format and made my own RIP (mRIP) from the same
ZXRar, it turned out that RIP formats
and Rar are not much different. This mRIP I'm for─
released as a source code-autobuilder
programs (it is here:http://
alonecoder.nedopc.com/zx/SYS.rar ) - his
you need to INCLUDE to your programs, and it
he will pack them himself, glue the BASIC loader and
will write to disk. There is also a mRIP pro version─
then for packaging individual files. She too
is on that disk. Its sources are in the journal:
alonecoder.nedopc.com/zx/books/IG10.rar
Roman Petrov> 
   It’s strange that RIP developed in such a way─
Okay, so I gave the source code to Megus and 
I thought that he would give them to everyone for use─ 
tion. It’s strange, by the way, that on the Spectrum there’s a topic 
Open Source has not advanced, there is a lot of 
there was a close-knit community and practically 
no markets or business :) 
alone> 
   For a real RIP, I unpacked it─
vshchik (reduced it by a few bytes).
Roman Petrov> 
   This is cool! For me every byte was there
count, I almost broke my head trying 
cram it into 256 bytes :) 

        2. Supportto external data
   When packaging, you can use the data
unpacker - hook it up on the left to the file─
lu.Usable for 4K intro.ROM data is better
don't use it - it can be different. Released
lvd in mhmt in2013. Not released yet. 
 This idea is also applicable for text compression
by any methods, up toPPMd - with UPA─
glue the typical “War and
world", and when unpacking, bring the unpacker
in the condition after unpacking it. Maybe ok─
It will be profitable to simply unpack it─
I'm drinking. Evgeniy Roshal is in the know :) Just for
The universal UnRar makes little sense.

hrumer> dictionary in the form of a depacker. cool :) 
alone> for codes that’s it) 
hrumer> if you pack the depacker itself, then finally 
everyone will gasp at the compression ratio. 
alone> recursively? ) 
hrumer> yeah. however, there is always an example 
RLE - LZ is recursive. 

       3. Use the subtleties of the OS
   For sizecoding can be used in ra─
packer state of memory and registers in
moment of file launch, take into account the launch address,
file name, etc. You can also generate
BASIC loader with a code inside the number and
string length, unused part of numbers...

lvd>when I wrote 4k on Omig, I was also wise 
with an executable. i.e. I took an unpacked executable─ny and tricky with the Amiga sections. so that
for example, all memory was allocated
described in sections. date and code were in one
sections, but the specified size was date+code, and
there was little code in the exe.
crinkler is navigating inside internal
windows process structure in order to
directly get the address of the functions
from the in-memory import table.
well, it won't work in Windows 8 (9.10).

           4. Automatic selection of method
hrumer> while doing optimization 
dehrusta, I, at some stage, considering 
3 encoding options, still only one 
then I left it and forgot about it. Because of this 
The crunch could have better compression. 
lvd>in general, your packers relied on 
some theory. research?
hrumer> if you haveopportunity to manage 
change the format of the saved data, then 
You can rotate a bunch. That's what he did. took 
a dozen toys that I liked, and on 
I tested them to see what works better and what works worse. 

hrumer> found a great fail in crunch1. there 
a lot of things unused, but what 
I found it about six months ago - it's awesome. :) 
alone> maybe it's fixed in mhmt? ) 
hrumer> in mhmt this is partially fixed, 
the codes are probably used, but the main thing is 
format problem, but in the original crunch1 
in one of the branches the codes are saved as 4 
bits, i.e. 1-16, and only 9-16 are used. :) 
well, and in a crunch to a bunch of unused 
codes... but I know that, but about the fact that 
I glitched and didn’t check something, yes... 
i.e. Oh my, we save 1 bit. how many times 
This kind of thing happens...probably a lot... 
we need at least a version where the calculation of this garbage is 
is underway. how many bytes were missing? 
alone> we still need to make a second version 
packer and depacker - for unpacking backwards
forward. and choose the one that is more profitable.
hrumer> yeah, I read the perversions of metalbrine and 
comrades using the example of exomizer2. 
alone> about packer optimization - I 
At one time the code was optimized for the packer.
instead of loops there are dupes and procedures - macros.
hrumer> + Roshchin also wrote an article about 
what packers love. 

lvd>if you take 2 different files (for example, 
code andgraphics), then ehomizer separately
it will compress them better than if you press them together.
alone> This will also happen in mRIP. 

lvd>software does not have to be 
multi-threaded. you just need to launch it
10 pieces at a time. or 100. pared─
cherishing is as easy as shelling pears - every CPU is looking for
matches in its own piece of the file. then you need
just glue together what they found.

    5. Setting up an unpacker for a file
   For example, in the PuCrunch compressor escape-
codes are customized for the file (and can
on the fly), and the codes to fillRLE
are taken from the table (16(?) sorted
by frequency of values) - seehttp://www.
ffd2.com/fridge/chacking/c=hacking17.txt
 This principle can also be applied to unitary equipment─
forging command codes (nowadays they are usually stored─
likebytes).
   For statistics, the most common codes in ROM
48K BASIC (when emulated):exx (6%), 
call (4.7%),jr z (5.6%),jr nz (3.5%), pre─
fixed (5.5%), prefix cb (5.4%), prefix
foriy (4.8%) - a total of 35%. You can pre-
view several contexts of 4-bit codes─
mand. For example, somewhere you need a lotld (hl),n:
inc hl, and somewhere there are a lotcall nn:ld (nn),hl. 

alone> You haven't experimented with yet 
short bytes?
hrumer> no. but I'm thinking of doing night time 
coding :) 
alone> I’m thinking: all packers pack the file 
in a row. Is it possible to win if you pack
in some complicated order? Like
the picture is drawn in all sorts of hobbits.
hrumer> overhead costs will appear. but 
should pay off. but the difficulty will increase. 
there was an idea, but it was realized - 
pack the screen. when unpacking it doesn’t unpack─ 
throw out zeros :) 
alone> Still purely for code compression old 
the idea is to separate commands from data, although
rude. There were several ideas:
  A) honestly look at the length of the commands - this is
160 bytes of code approximately.
  B) make rules in the packer according to which
it will be possible to customize the code.
  B) catchdata only in ld commands.
With LZ you need 2 streams each from their own address─
tion, which are then glued together. But if they are
rules by which it will be possible to customize
code, then maybe it will come out with general addressing.
The jr parameters, by the way, differ greatly in
distribution from the parameters ld. Jp/call -
also its own, and the low byte is random,
and the high one correlates with the high byte
addresses and the high byte of the past jp/call.
The low byte can be made to be divided
by 4, for example. With your hands.
hrumer> this is why he appeared in the crunch 
"insert byte". On PC, as I understand it, in bo─ 
in most cases they don’t bother, just 
relative addressing is replaced by direct addressing 
I think, and then after unpacking, apparently, 
tno. the rest is tricky to implement. 
from real current options, window reset at 
changing code/graphics/text from #4000 to, 
for example, #100 followed by increasing numbers. 
alone> Another idea - count on each byte 
heuristics (let's say 4 bits), climb on it
into an array and take data from there in short
code. You can also update on the fly.

LeafS874> According to the script - there is an idea to do it 
command callmacro n, where n is the macro number.
And in the macro there is one command or several,
you can read the parameters. There will be few of them.
This is how you can describe all the commands, but then
you need to encode with Huffman - it will be fat
interpreter. In mind, the compiler itself should
find team statistics and select for them
code lengths. Like a packer.Another interesting observation - a lot of calls
comes immediately after the next ret.
Calling a directly adjacent subroutine─
frames, and do the rest with rel. address with
extensible code. You can write all the commands─
do it via callmacro, then n is necessary
encode with Huffman (the code can be picked up
compiler). Essentially a packaged program,
but at the same time executable!
hrumer> LeafS874: Alone, I already recognize you 
by handwriting! ) 
LeafS874> Byte alignment is only necessary 
for entire procedures. Macros with parameters
You can use call interpreter_getNbits.
For a hike, only about 20 uni is enough─
real macros, like in the pi-code of the compilator─
rov. Accessing variables in a script is cheaper─
better than in the machine code - you only need their number,
not an address. 7 bits may be enough for prog─
frames like ACEdit. Their numbers, of course, too
You can use Huffman, but you need a table somewhere) A
I have another idea about packaging: separate
commands and data. But so as not to look where
that, with the depacker itself, you can encode them
in the code itself. For example, we align everything
4 byte commands.
0 0 0 kmd - single-byte command
0 0 kmd param - command with 1-byte
 parameter or 2-byte
0 kmd pairs pairs - understandable
Kmd kmdkmd kmd - 4-byte
Offsets will be divided by 4. Two bits
cut it off. You can generate such code by anyone
macro assembler. For 4-byte it may be
It’s better to parse it as kmd kmd param kmd.
hrumer> Perverted idea! ) Working. ) 

hrumer> don’t take all the codes for lengths, but on─ 
example, exclude odd lengths 7,9,11,13, 
and the like. Let's save 1 bit per encoder─ 
lengths 6,8,10,12. in 50% of cases without on─ 
masonry, and taking into account optimal coding 
it will not be 50% without overlays, but higher, up to 80%. 
and leave the remaining 20% to chance, 
or make repeat distance for length 1. 

hrumer> lvd: I watched exomizer. good 
invented with trees, with an unpacker. 
The author may still release version 3, he’ll take it 
and enter the code that is responsible for 
tree update :) 
lvd>I saw the filling in the depacker 
plates, from which they are then selected
offsets. are these the same trees?
hrumer> yeah, I call them trees. 
There are signs. 
alone> what is the exomizer principle itself? 
hrumer> exomizer - trees only for 
lengths and offsets. the whole trick is in the packer, 
which tries to calculate the optimal 
trees, and then optimally encode. 
I'm inside the packerI didn’t dig into the exomizer, 
but in the depacker all the ears stick out :) 
alone> I had an idea to recalculate 
literals by table into sorted by
frequency, and then do the bit lengths through
code. There are several options for this code.
It's not Huffman, but it's still cool, that's all
256 bytes per tree.
lvd>well, that's what the ehomizer does, apparently. 
or something similar.

lvd>a zx7? They say it presses harder than the ehomizer. 
hrumer> zx7, it seems, normal, a feature in 
that an offset up to 128 bytes is shorter 
coded.+ packer searches for optimal pairs. 

hrumer> Alone, did you watch crinkler? :) 
alone> what's there? 
hrumer> and there..and I have no swear words 
no, what's there. 
alone> does he pack well? 
hrumer> Packs well. on 4k demo 
calculated at the link level, or something, 
selecting where to store what. when unpacking 
uses a ton of memory. depacker is short. 
this is what I remember. I watched it a couple of years ago 
more details. but there is a brain explosion. you will 
take a look - be strong :) 
alone> using memory at 4k is logical. 
You can also make LZ78 there.

alone> by the way, did you understand LZMA? 
hrumer> LZMA - no, but so, I read it lightly. 
There was some bourgeois in his blog who went nuts 
from the tricks that are there. there's a coupletricks, and then some kind of mind-blowing thing─ 
new and additional compression... data... catch the link: 
http://cbloomrants.blogspot.ru/
2010/08/08-20-10-deobfuscating-lzma.html

lvd>there is one problem. for crunch there are 2 
depucker. one is fast, but through the stack (pop
xl selects data). the other is slow, but
without a stack. slow so much that it knocks you out─
rait from IX. made by replacing pop xl with boot─
zku hl from ix. Well, instead of pop hl you need
attach ld a,[hl]:inc hl. the bastings were
(in svn it is), but it came up against saving the flag─
gov over long pieces of code. Thankfully MY PA─
ker allows you to change the format this way
:) instead of 16-bit bit sets, do
8-bit. double profit - fast andstackless crunch depacker will come out.

        6. Packer for leaflets
   When packaging text for use in
There is no point in turning letters into4 bi─
ta (5 bits were in the ZX Time leaflet). You─
it is better to encode syllables (or mora consonants─
naya-vowel) with one number (this can be
more than a byte) and compressed with Huffman.

jtn> I made two-letter tokens in z80-6. 
I counted everything and sorted it. 
alone> do you depack in real time? 
jtn> yes. there are rle+tokens in real time. 
alone> and presses hard? 
jtn> 30 percent, if I'm not lying. 
alone> I mnu Huffman realtime squeezed 
146K to 97K. ZX-Guide #3 "Monday-2".
jtn> so the scrolling is almost frame-based. 
alone> I have a completely frame one. 23 lines. 
jtn> how do you unclench Huffman in realtime? 
alone> there I have a Huffman length 
limited to 8 bits.
jtn> well, that means I’m done without reloading 
+ 2 fonts. 4x8 and proportional 
(shifted 8 times). and all in 128k. text 
like net about 70k. 
alone> 200K is possible without frame, I 
I once thought. but this is all 128 times.

   Another option: Fast Recursive Coding
Based on Grouping of Symbolshttp://arxiv.
org/ftp/arxiv/papers/0708/0708.2893.pdf

        7. Extensible Link Codes
   You can narrow and expand link codes
in different places in the file. One example was in
Hrust1, but the options are innumerable. 

hrumer> I had an idea to make codes for 
offsets and lengths of different lengths, but from the edge─ 
hope that their lengths are increasing, and 
carefully use in depacker(+update 
as I moved through the file).but I couldn't 
write a compact implementation on z80 :( 

alone> I wrote sound packaging using the method 
DAKX, sometimes compresses twice as much.
but for the code it is unknown what will happen.
hrumer> I haven’t even fully moved in yet 
about DAKX. it's like just coding it 
number, and the larger the number, the more bits? 
1 - %1. 2 - %10, 3 - 110. etc. 
and the last number is all ones. right? 
alone> no, the current width is stored there─ 
yes, it is updated depending on the number.
if the numbers are small, narrow the code, es─
whether large - expand:http://alonecoder.
nedopc.com/zx/books/zxgХhtml/dakx.htm
this can also be applied to links in LZ!
hrumer> I sent it to myself, I’ll think about it. 
By the way, I’m parallel to the loophole compact 
I'm racking my brains. is there a short version 
on z80 suchcodes: 0.1x0.1x1x0.1x1x1xx 
(as in LCS) but! when cutting the code length to 
1,2,3,4,5,6,7 bits. 
alone> I haven’t seen this. 
hrumer> in LC you can win great on 
this. but a short implementation of this is 
I have to rack my brains. 

alone> Is it possible to win if all the tags and 
will transitions be at even addresses?
hrumer> no, I’m poking around and collecting statistics 
according to Burnashevsky sishny hrumZ.5. looked, 
How are the lengths distributed? on some 
files with only even lengths from 6 can 
win. but I haven’t calculated how much yet. 
with lengths = 1, it also depends on the file. 
on some you can win if the length 
take maximum = 4, not 8. 
alone> You can win if you don’t use it 
length 1,2 and encode 3, etc. like old ones
1, etc.?
hrumer> all the expected winnings will be gobbled up 
"unpacked" bytes, encoded with 9 bits. 
By the way, I found a more advantageous one (by 
unpacking speed) length coding. 
The beats are simply recorded differently. 
;alternative:
 LD B,256-16
DPCH LD A,%01000000
DPC2
 SLA C
 JR NZ,$+6
LD C,(HL)INC HL
RL C
RLA
 JR NC,DPC2
;--
 JR NZ,LENXX;12/7 finished with lengths
INC B ;4
 INC B  ;4
 INC B  ;4
 JR NZ,DPCH ;12/7 if not 16, then more
                 ;take. there are 16, but A = 0,
               ;and further in B the result is already.
 DEC B  ;4 here you can also do
               ;DJNZ to this address. but this
               ;longer by 1 byte, but,
               ;possibly faster
LENXX
 ADD A,B  ;4
 DEC A  ;4 ;or remove this and above
              ;load B,15 with transition.
CP 256-16+4;7 extendednumber.
 JR Z,DPCS;B<>1;B=4 ;12/7
ADC A,256-16-1;correction. ;7
alone> And what codes do you get? 
hrumer> yes, the lengths are the same. 
alone> And if b is not incremented in the loop, but 
decrement, no gain? In the loop only
djnz, and the output is add a, b (or sub b) 3 times
hrumer> I thought about decrementing, but there after 
In this case, the length must be corrected through subtraction. 

hrumer> still from real ones, but not implemented─ 
nyh - unpacked bytes: if "A" is not packed─ 
fell, and behind it “BCDEFG...” were not packed, 
then it shouldn’t be the case that A goes away─ 
flax, and BCDEF...separately. This means the code that 
shows an unpacked block, should not 
go after the unpacked byte. So this one 
the code can code something else. but this 
pennies... still real, but pennies - 
insert character. if inserted character 
matches the character that was D byte 
ago, then this could mean something... 
alone> In this situation, you can move 
all link length codes are set to 1.
hrumer> by the way, for the text, apparently, after 
packing of bytes 100-300 can be length not from 1 
take it, but with 2. and for graphics you need to test it. 
those. min len first = 1, then =2. 
alone> What if there is no length 1 at all? How much 
loss? In RIP the length is generally from 3
begin. But Huffman is there.
hrumer> no length = 1 - on textseven 
winning, and without any pressure from Haffan. on 
graphics too. 
alone> then you need to change the crunch format) 
hrumer> adjust minlen directly in 
flow, yeah.