SquirrelJME/SquirrelJME

# 2016/03/12

## 00:03

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

## 00:29

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

## 10:56

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.

## 11:02

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.

## 11:08

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.

## 11:12

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.

## 11:15

When placing the lowest values are pushed in...

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

Then when reading the same order is used.

11 (0b1011) is added to become

    11010000

Then 73 (0b1001001) is added

    11010000 10010010

Then it is read as

    11010000 10010010
    F
     TT
       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.

## 11:25

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

## 11:31

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

## 12:47

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

## 12:52

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.

## 13:02

This graphing calculator I have is very handy during programming.

## 13:19

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

## 14:09

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

## 14:25

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.

## 14:39

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.

## 14:46

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

## 21:12

Was doing lots of outside work before, rather tired.

## 22:47

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