DPCM Nibble Processing optimization (Explanation)

Let's represent DPCM byte format as follows: ABh. Let's also pretend you've read the byte already and you've come to the decoding step right now.

First off, we need to decode the high nibble. Normally, we would like to bitshift it by 4 and load corresponding index form a DPCM delta table. But we can optimize the decode process by avoiding bitshifting. Thus, we need a different data location on our DPCM data, like so:

Offset	Decode table data
0000h	00 .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
0010h	01 .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
0020h	02 .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
0030h	04 .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
0040h	08 .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
0050h	10 .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
...

So, you may see how the offsets of the table listed corresond byte fetched, where the high nibble remains unshifted. So, if the high nibble is 1, the byte will have the form of 1Xh, and we would like to read table from offset 0010h to decode it correctly.

The table eventually takes 100h bytes, so you may think of a huge space loss here. Apparently, we can put every single byte of the table to a good use, something we'll need to pull off the next optimization.

Normally, a programmer wants to bitmask the currently processing nibble to filter out grabage (the other nibble we don't need at the moment), this to ensure we'll access the only correct and unique table entry to decode the nibble in the question. Apparently, as the table is 100h bytes now, we have nothing to loose, which means, we can see it to decode every of possible 256 byte values correctly. Like, if the byte read is 10h, we would like decode nibble 1 correctly, and load the value of 01 from the table. If we've read 11h, 12h etc, we basically need the same, as the low nibble doesn't count. All those offsets are free in our new DPCM table, so we can set any to return the right value despite the low nibble. Eventually, the new table will look like this:


Offset	Decode table data
0000h	00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010h	01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
0020h	02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02
0030h	04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04
...

Now we can instantly decode the first nibble no matter what the other nibble is. Now, I think you get the idea it figure out the table to support low nibble yourself. This way, you won't even have to apply AND or bitshifts operations to the DPCM byte read, this is the ultra fast decoding in its truly.