This would require a few bits of flash though.

I've realised that we might be able to (fairly easily) extend the flash available...at a cost of slightly reduced flash life. Given the rather extreme (6.4million) cycle life expectancy, halving this to gain another 128bits (or 126 if you want to CRC it) of storage is tempting. Of course this does depend on there being enough time at powerfail to store all 256 bytes...

There's two strategies I see for this;
  • Writing hijack's block after the player block, 128 bytes lower in memory.

    Advantages: The integrity of the player block is ensured by placing hijack's block CRC calculation and flash write after the player flash write.

    Disadvantages: Overhead in having two flash writes.

  • Modifying the existing block to be 256bytes long.

    Advantages: 2 extra bytes of storage (we only need one checksum). Less overhead by only having one flash write.

    Disadvantages: Player block integrity is now codependant on having enough time to write all 256 bytes.
_________________________
Mk2a 60GB Blue. Serial 030102962 sig.mp3: File Format not Valid.