Document the new bytecode format.

README.md

@@ -24,17 +24,10 @@ Don't believe me? Watch the demo reel!
 <iframe width="373" height="210" src="https://www.youtube.com/embed/m_s1iw8eW7o" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
 </div>
 
-**Important note.** On 2019-02-09 I did a hardware redesign and moved the pins on
-the board. Sorry for the inconvenience, but it means you don't have to modify
-the board any more to make it work. If you built the hardware prior to then,
-you'll need to adjust it.
-
-**Another important note.** On 2019-07-03 I've revamped the build process and
-the (command line) user interface. It should be much nicer now, not least in
-that there's a single client binary with all the functionality in it. The
-interface is a little different, but not much. The build process is now
-better (simpler). See [the building](doc/building.md) and
-[using](doc/using.md) pages for more details.
+**Important note.** On 2020-04-02 I changed the bytecode format (and firmware).
+Flux files will need to be upgraded with `fluxengine upgradefluxfile`. The new
+format should be more reliable and use way, way less bandwidth. Sorry for the
+inconvenience.
 
 Where?
 ------

doc/building.md

@@ -261,8 +261,8 @@ You should now have a working board, so it's time to test it.
      [get in touch](https://github.com/davidgiven/fluxengine/issues/new).
 
   8. Do `fluxengine test bandwidth` from the shell. It'll measure your USB
-	 bandwidth. Ideally you should be getting above 900kB/s in both directions.
-	 FluxEngine needs about 400kB/s for a DD disk and about 850kB/s for a HD
+	 bandwidth. Ideally you should be getting above 800kB/s in both directions.
+	 FluxEngine needs about 300kB/s for a DD disk and about 600kB/s for a HD
 	 disk, so if you're getting less than this, try a different USB port.
 
   9. Insert a standard PC formatted floppy disk into the drive (probably a good

doc/technical.md

@@ -22,19 +22,17 @@ FluxEngine, where a different datapath state machine thingy (the PSoC5LP has
 24, all independently programmable) to interpret the bytecodes, generate a
 stream of pulses to the disk.
 
-The bytecode format represents an interval between pulses as a byte, a pulse
-as a byte, and the index hole as a byte. Timer overflows are handled by
-sending multiple intervals in a row. However, the USB transport applies a
-simple compression system to this in order to get the USB bandwidth down to
-something manageable.
+The bytecode format is very simple with a six-bit interval since the previous
+event in the lower six bits and the top two bits are set of a pulse or an index
+hole (or both, or neither).
 
 An HD floppy has a nominal pulse frequency of 500kHz, and we use a sample
 clock of 12MHz (every 83ns). This means that our 500kHz pulses will have an
 average interval of 24. This gives us more than enough resolution. At this
 speed, in the 200ms that a 3.5" disk takes to rotate, we will see about
-100,000 pulses. Each one is encoded as two bytes, one for the interval and
-one to generate the pulse; so that revolution generates 200kB of data.
-(Extremely approximately. The actual figure is less.)
+100,000 pulses. Each one is encoded as a single byte; so that revolution
+generates 100kB of data.  (Extremely approximately. The actual figure varies
+depending on what data is stored on the disk.)
 
 (The clock needs to be absolutely rock solid or we get jitter which makes the
 data difficult to analyse, so 12 was chosen to be derivable from the