Here's a detailed annotation of the 1k lines, by an interested second party. (Here's the overview page of the annotation effort.)
From there:
Quote:
NOTE ON THE OP DECODE MATRIX:
This is the most discussed part of the Bisqwit NES emulator because it looks like something you would see from an automated code obfuscation tool. This method is the natural consequence of this question: "How can we compress the 256 NES operations into 100 lines of code to quickly present it on YouTube?" Bisqwit answered this question, and it's very likely that you (the reader) will never need to do the same in your programming career. So to beginners, I would say to simply not worry about this specific method, and focus on semantics. The op decode matrix is more of a case study in applied information theory rather than programming. It wouldn't fly far in a production environment because team members would be screaming "readability refactor!".
But for those seeking enlightenment, Bisqwit himself discusses the method starting halfway through this video: http://youtu.be/QIUVSD3yqqE
An important concept buried in here is the idea that CPU instructions aggregate very low level tasks, usually following the sequence: fetch, operate, store. Bisqwit decomposed the 256 CPU ops in to 56 tasks you see prefexed with t(). The key is that each t() line does NOT represent a CPU operation; instead, each CPU operation executes multiple t() functions based on bitfield matches in augmented BASE64. Tasks are ordered roughly the same as in an actual CPU pipeline.
Example: Op code 0xAA is TAX - Transfer A to X.
TAX hits 5 tasks from the decode matrix:
Line 818 -> t &= A; Store register A in to temp operand t
Line 839 -> tick(); NOP
Line 864 -> X = t; Set register X to operand t
Line 869 -> P.N = t &= 0x80; Update flags negative bit to result sign bit
Line 870 -> P.Z = u8(t) == 0 Update flags register for zero result
In the future, I will try to re-encode this matrix in to lower entropy forms that make more sense to the reader. Binary form is quite easy to understand and retains the decoding method, but produces very wide lines.
This is the most discussed part of the Bisqwit NES emulator because it looks like something you would see from an automated code obfuscation tool. This method is the natural consequence of this question: "How can we compress the 256 NES operations into 100 lines of code to quickly present it on YouTube?" Bisqwit answered this question, and it's very likely that you (the reader) will never need to do the same in your programming career. So to beginners, I would say to simply not worry about this specific method, and focus on semantics. The op decode matrix is more of a case study in applied information theory rather than programming. It wouldn't fly far in a production environment because team members would be screaming "readability refactor!".
But for those seeking enlightenment, Bisqwit himself discusses the method starting halfway through this video: http://youtu.be/QIUVSD3yqqE
An important concept buried in here is the idea that CPU instructions aggregate very low level tasks, usually following the sequence: fetch, operate, store. Bisqwit decomposed the 256 CPU ops in to 56 tasks you see prefexed with t(). The key is that each t() line does NOT represent a CPU operation; instead, each CPU operation executes multiple t() functions based on bitfield matches in augmented BASE64. Tasks are ordered roughly the same as in an actual CPU pipeline.
Example: Op code 0xAA is TAX - Transfer A to X.
TAX hits 5 tasks from the decode matrix:
Line 818 -> t &= A; Store register A in to temp operand t
Line 839 -> tick(); NOP
Line 864 -> X = t; Set register X to operand t
Line 869 -> P.N = t &= 0x80; Update flags negative bit to result sign bit
Line 870 -> P.Z = u8(t) == 0 Update flags register for zero result
In the future, I will try to re-encode this matrix in to lower entropy forms that make more sense to the reader. Binary form is quite easy to understand and retains the decoding method, but produces very wide lines.
Quote:
In this video, I explain *how* did I come up with the short form for the Ins() function (which was actually automatically generated from data using the means described in this video).
However, I did not explain *why* I made it small. You can find _that_ explanation here: There are two reasons
NEW: Additionally, if you absolutely must know, I expanded the very content of the #define macro of the Ins() function and covered the 8-bit encoding that I used in detail at base256-explained.
However, I did not explain *why* I made it small. You can find _that_ explanation here: There are two reasons
NEW: Additionally, if you absolutely must know, I expanded the very content of the #define macro of the Ins() function and covered the 8-bit encoding that I used in detail at base256-explained.
