* Firstly, I fixed a small bug in the Handler that caused data loss
on 128bit operations.

* The GIF is a marvellous and complicated little piece of hardware that
handles transfers between the EE and the GS. It can be "fed" by three
paths, PATH1 is from the VPU1 memory, PATH2 is from the VPU1 FIFO and PATH3
is directly from the main bus. Since we don't have any VUs implemented
we only care about PATH3 at this stage.

* Each primitive sent has the form of a linked list. The EE first sends an
128bit GIFTag that acts as the header and tells the GIF how much more
data to expect and what to do with it. The loop ends when the EE sends a GIFTag
with the EOP field set to 1. (EE User's Manual [150])

* Each data packet after a GIFTag can be processed in three different
ways depending on the FLG field of the tag; PACKED, REGLIST or IMAGE mode.
For now we only care about PACKED.

* When in PACKED mode, the EE will send NREG * NLOOP (specified in GIFtag) qwords
after the tag. Each qword can be processed in different ways depending on the desc
in REG field of the GIFTag. Page 152 of the EE User's Manual shows the different modes.
The REG field though is in reality a bit array of 4-bit descriptors. To understand
this better, here are the processing steps:

1. The first qword after the GIFTag is processed based on the least significant bits (64:67) (the first descriptor)
and is output

2. The second qword is processed based on the next descriptor (68:71) (second descriptor) and is output

3. Steps 1,2 are repeated NREG times.

4. Steps 2,3 are repeated NLOOP times

There are more variables we have to take into account with PATH3, because it can also be masked
by other PATHs which have higher priority. But that is for later. Don't worry though if you
didn't get it completetly. The GIF is nowhere near finished, so I will have more
chances to explain how it works. For more info you can read the GIF chapter of the provided EE User's Manual.