Things remaining to be tidied:

 - The starting in a non-numbered video mode; in s.vdu. Code deliberately
   bodged (and flagged with !!!) to force starting in 1920x1080x32bpp.
   I guess any HAL_VideoFeatures call that returns inability to handle a
   <= 8bpp mode might be a way to activate it? Then I guess the HAL needs to
   suggest a suitable default resolution.

   Alternatively, with later start.elf images perhaps we will be able to run
   in lower resolutions when booting.

 - There's code surrounding ARM_Analyse and particularly EvaluateCache
   where it didn't determine the correct cachetype and cachelinelen
   for this ARM. I've not tidied this properly yet; it should be obvious
   what's required.

      ARM ID reg &410FB767
      MRC 15,1,R0,C0,C0,1
        cache info = &1D152152
        ARMv6 format...ok

   I'm not sure who's best-placed to sort this cleanly; my knowledge of
   ARMs from that era is not extensive...I'd have to study the ARM ARM
   to ascertain the 'correct' way to determine cache properties.

 - The code in vdudriver that reads the framestore properties requires
   a GraphicsV claimant if an external framestore is required. I can
   knock up a simple asm module to do this, or we can switch to an
   internal framestore if that can be made to work. I like the latter
   idea because it gives us 'hardware scrolling' and possibly the
   screen cacheing (SA), both of which would benefit us with the
   currently unaccelerated display.

 - the centisecond timer interrupt currently needs to
   be a 'pretend Vsync' handler too at the moment. I'm unsure how you'd
   like to go about having this workaround used for R-Pi only