I get it, I am only checking one side in grow, I need to handle more of it.


This time I get 'X' (88) instead of 'T'.


T is 0h54 or 0b1010100. And X is 0b10110000 or 0h58. So I am pretty much a bit off by a single bit being in the wrong location. These are huffman codes so what I want is 0b10000100. What is something though is that I get that desired value when it is being read.


So it appears my read value from readFirstInt is shifted too high it seems. Since I read 0b100 which is 4, but I instead return 8 from it.


Changing the read to MSB fixes the issue. Normally I should not need to do it such as that, so the int conversion is lost somewhere.


Actually I get it. I offer integers with LSB so they get added in that order, although when I get those integers they are read in the same order.


When placing the lowest values are pushed in...

     ^^^^^^^^  -- 0b11110010

Then when reading the same order is used.

11 (0b1011) is added to become


Then 73 (0b1001001) is added

11010000 10010010

Then it is read as

11010000 10010010
   HHhhh hhh

Reading first values results in 0b00100001, which is 33. However the lowest six bits get chopped off so it is instead read as: 0b0000100. This is 4.


Thinking about it: 0b0010000 from lowest order. This is 16.


Just going to go with reading it as MSB since it works.


Must create the sliding window code and put bytes in there, also need to figure out how the sliding window reading works also.


For reading the distance, I can use an algorithm for that. Each distance group appears in sets of 4 extra bits, the first 8 values have zero extra bits and represent single directories. So essentially instead of a lookup table I can use a linear sequence calculator to determine the distance to use. Then if there are any extra bits then they can be read.


This graphing calculator I have is very handy during programming.


And the distance and length handling was actually quite simple. What I need to do now is have the actual sliding window implemented.


The distance starts at the furthest byte back, because otherwise it would not make sense.


So now I have a working sliding window. I just need to figure out where an infinite loop occurs now, most likely at the end of the read.


Was actually caused by the stop value being treated as an output byte value. So now the inflation algorithm passes and the resulting bytes are given. Now I need longer sequences that do other things. One thing I will need is random unique bytes that have nothing in common.


Ok so I have a random data input which is completely terrible at compressing as it ends up being larger.


Was doing lots of outside work before, rather tired.


I believe the ZIP is reading data from the incorrect location.