wip tileset explanation

content/interference-fixes.typ

@@ -1,9 +1,99 @@
+#import "/lib.typ": todo
+
 = Preventing Interference <timing>
 
+The protocols as described are very sensitive to the exact timing that the EID counter is
+incremented. The fundamental cause for all types of interference is that we spawn a reference and
+measurement item with too much delay, and some unexpected entity (or entities) spawn in-between. To
+mitigate interference, then, we need that window to be *as short as possible* while still allowing
+us to spawn transmission entities in that window.
+
 == Tilesets
 
+The fundamental principle here is to use tile-tick priority (TTP) to set a global order. See
+Charlie's great video on TTP for details. #todo[link video]
+
+The core principal is that repeaters have higher priority than other components. For example, if a
+repeater and comparator are scheduled to activate in the same tick, the repeater always (with one
+exception, if the comparator faces into a diode and the repeater does not) activates before the
+comparator does. By choosing a regular building pattern, we can avoid this exception entirely.
+
+// Among repeaters, they activate in the order in which they were scheduled. And among comparators,
+// they activate in the order in which they are scheduled. But every repeater activates before any
+// comparator (aside from that one exception). This gives us a *stable sort* which we can use to
+// globally define update order with arbitrary precision.
+
 === Binary
 
+The simplest tilesets are made entirely of comparators and 2gt repeaters. Repeaters activate before
+comparators, so if we think of it like sorting words alphabetically, we can identify repeaters with
+"A" and comparators with "B".
+
+So, suppose we have a "binary tileset" that is 2gt long. There are two options, A and B. If we
+alphabetize these, we see the A (repeater) always executes before the B (comparator). With such a
+short tileset, that seems trivial; things get more interesting as we add more elements.
+
+```
+<--
+cmp  (B)
+rep  (A)
+```
+
+Now let's use 2 components for a 4gt tileset. There are now four options, AA, AB, BA, BB. We can
+alphabetize these and see the order.
+
+```
+<------
+cmp cmp (BB)
+cmp rep (BA)
+rep cmp (AB)
+rep rep (AA)
+```
+
+To break this down: the bottom two (AA, AB) end in repeaters, so they must come first. Among those,
+(AA) comes first. Among the top two (BA, BB), (BA) comes first. It's standard alphabetizing. Just as
+the order of the alphabet creates an ordering over all words, the ordering of the comparator and
+repeater creates an ordering of all tilesets.
+
+The 6gt tileset. There are now eight options.
+
+```
+<---------
+...
+```
+
+As the tilesets get larger, it's less useful to lay out the entire tileset and more useful to find
+the next and previous lanes.
+
+For example, take this 7-diode tileset.
+
+```
+cmp rep rep cmp rep cmp cmp
+<--------------------------
+ B   A   A   B   A   B   B
+```
+
+We can easily find the next lane by thinking of this not as a *word* but as a *number*. We have two
+options, and one is greater than the other.
+
+```
+cmp rep rep cmp rep cmp cmp
+<--------------------------
+ B   A   A   B   A   B   B
+ 1   0   0   1   0   1   1
+```
+
+We can think of this tileset as a 7-bit binary number, in this case the value 75. We can find the
+next lane by simply incrementing by one.
+
+```
+ 1   0   0   1   0   1   1    (75)
+                       + 1
+ 1   0   0   1   1   0   0    (76)
+<--------------------------
+cmp rep rep cmp cmp rep rep
+```
+
 === Lexicographic
 
 === Mixed Priority Jamming