Perhaps Krolypto should be updated so it's impervious to battery pulls.

Protip: you don't need MSD8X to use the MSD driver in USB8X. You can use the BASIC interface to read and write files, but you have to memorize the exact file names.

And yes, this means you don't need the extra RAM pages.

But have you tried either of the above procedures? My warning about garbage collect issues only applies <i>after</i> you Reset All Memory.

Am I the only person who memorized that?

interference

Huh. I thought the sector at 7Ch was unused.

I don't remember the boot code having a downgrade protection feature. Even if it did, it would have to be certificate-based. A certificate-based restriction could easily be undone by restoring your certificate from an older backup. What? You don't keep backups of your certificate? Shame.

Also, the TI-Boy issue can be solved by first copying the extra OS page to the 32 K sector, and then proceeding as normal. For that matter, you could patch the new OS to use that dang 32 K sector instead.

That looks a lot like headers from Z80-series programs. Unfortunately, that is not very flexible. I would suggest the following instead:
struct header {
    char[8] "NdlessEx"; // Identifies program as Ndless executable
    void (*main)(); // Pointer to main entry point, or 0 if no basic main entry point is specified
    void *relocationData; // Pointer to relocation data block, or 0 if no relocation data is present
    void *metadata; // Pointer to meta-data block, or 0 if no meta-data is present
    void *debugSymbols; // Pointer to table of debugging information, or 0 if no debugging information is present
    int 0; // Specifies that no additional pointers are present in the header block
};Following the header block, no particular structure is imposed on the file. The main function, meta-data, debugging symbols, and relocation data can be placed anywhere in the file and in any order. There is no requirement for any of these blocks to be located immediately after the header block; programs can have functions or data after the header block if desired. Future standards may replace the 0 integer after the final pointer with additional pointers as needed.

To run a program, the Ndless loader will first examine the meta-data in the file, if present and necessary by future standards. Ndless will then process the relocation table, if present. Finally, Ndless will jump to the main entry point.

The main pointer may be null if the program has no main entry point. This could be because the program is actually a library, in which case Ndless may still need to perform relocation, and the library can present its metadata and debugging data in a standard format. This may also be because the program is not a raw Ndless executable, but based on the standard because, for example, it adheres to a later standard and should not be run by earlier Ndless versions, or is a shell-only program, in which case the shell will find the main entry point in a implementation-specific way (while still taking advantage of Ndless's future native relocation, meta-data, and debugging abilities.)

The format of the relocation data structure is not specified here. Somebody with more experience in that area may wish to define that.

The meta-data block should be XML-encoded using the encoding the Nspire prefers. The XML data block may be parsed using TI's routines. This data may be presented to the user by a shell. Programs may choose to read their own meta-data to, for example, display their own version information. Programs should include, at a minimum, Version, Title, and Author tags. Additional Author tags may be present for group projects. Additional tags may include Date, Description, Icon, and Copyright. The meta-data block is also a good place to place information on additional libraries needed, and minimum hardware, operating system, and/or Ndless version requirements.

The format of the debugging data structure is not specified here. This may become a part of the Ndless standard; or, the standard may simply state that debugging data is specific to a particular combination of compiler/linker and debugger, whether in-system or via emulator.