RLL is a pretty old subject of study...

This is required for efficient magnetic storage (disk, tape), radio and optical communications, even optical storage (CD/DVD/etc.) so references date back to the 60s...

Some pretty smart designs have been tried and yet I have not seen the "flipping trick" or it was long ago and I have forgotten. I remember one table-based RLL scheme (for the MiniDisc ?) with 2 consecutive tables, the first depending on an accumulator of drift. But flipping the whole byte and adding a flip bit ? This would only be possible with the advanced, multi-level encodings such as MLT3 or more. So I think this method is "pretty novel" despite the simplicity that could have been implemented in the 80s.

The method I develop currently uses 20 bits per word and ensures that the longest run of 0s lasts for 10 bit cycles. This comes from

- the flipping circuit ensures that no more than 4 bits per byte are cleared, or at least 8 set per 20-bit word,

- the mark and flip bits (2 each) are placed between the bytes and their values are not particularly constrained (apart from the mark bits limited to 00, 01 and 10). So in a 20-bit word, these 4 bit can easily be cleared.

The word format is :

1. 2 mark bits,
2. 8 data bits (4 bits set at least),
3. 2 flip bits (polarity TBD),
4. 8 more data bits

The permutation above gives the previously cited maximum distance of 10 0s. The only constraint is that the mark bits must come first to discern the control words from data. Then the flip bits are located "diametrally opposed" to the mark bits so everything is at equal distance, assuming all mark&flip bits are cleared.

With these conditions there are 2 worst cases : inter and intra-word.

• Inside a word, we get xx-11110000-00-00001111 (10-long)
• between consecutive word we also have xx-xxxxxxxx-xx-11110000 00-00001111-xx-xxxxxxxx

So we see why the symmetry is important : the worst case has the same length in either direction.

This was the situation 2 days ago. Today, the bitcounts 4 and 5 have been strictly fixed. The log 15. Popcount (better) has defined that these counts do not flip, so they are output to 0. But this level is arbitrary. What if a flip bit was 1 when encoding a 4-bit-set data ?

The flip bits would then act as "guards" that cut the worst case sequences in half. The flip bits can return to their previous "prefix" positions, in front of their respective data byte.

• Inside a word, this becomes xx-1-11110000-1-00001111 (4-long)
• between consecutive word we also have xx-x-xxxxxxxx-1-11110000 00-1-00001111-x-xxxxxxxx (6-long)

This is significantly better, only for the insignificant price of an inverter and moving one signal somewhere else !

.

So the source code needs a quick little fix, but what is now the worst case ?

That would be an inter-word combo :

xx-x-xxxxxxxx-1-11110000 00-0-00011111-x-xxxxxxxx (still 10-long)

This is easily broken if the flip bits are suffixes.

xx-xxxxxxxx-x-11110000-1 00-00001111-1-xxxxxxxx-x (6-long !)

The new worst case becomes this combo:

xx-xxxxxxxx-x-11111000-0 00-00001111-1-xxxxxxxx-x (still 10-long !)

To reduce these situations to 9 bits, there is only one solution : one mark bit must be located somewhere else, in the middle of the word.

We end up with pairs of 10-bit halfwords, both with the format m f dddddddd or m dddddddd f

• Prefix mode : x-1-11110000 0-0-00011111 ==> 9 bits !
• Suffix mode : x-11111000-0 0-00001111-1 ==> 9 bits too !

Here is the illustration in practice:

and the updated circuitjs link.

At this point I don't see any reasonable trick/way/method to reduce this distance below 9.