I've long wanted a config file for this project, but never got around to actually implementing one.  I decided to give it a go.  I found a useful opensource (apache 2) INI file reader project: "minIni", which is designed for embedded (and moreover already had IO bindings to the MDD filesystem library I am using), so this made support much easier with not having to write the parser myself.

My main motivation for the config file was to specify some useful parameters such as:  

• auto load a floppy so I don't have to go through the hypervisor every boot
• specify an alternative ROM to use, instead of always Level II BASIC

Other less critical but nifty parameters are:  

• control how long the splash screen art is displayed
• support alternative splash screens with ease
• change foreground/background colors on the color board
• alternative key bindings for various hypervisor functions

There is been a placeholder file in the root of the distribution SD card image for some years now, named 'trs80.cfg'.  Up to now, it was zero length, but now it has various entries coincidentally set to the baked-in defaults.  It should be self-evident how it works, but there are some caveats:

The file contents should be treated as case-sensitive.  'Splash' is not the same as 'splash', and changing it will not result in the desired setting having effect.

Related in particular, is specifying key bindings.  This is a limited feature, but you can assign the 'F' keys to various functions listed in the file.  They must be named like 'F10', not 'f10'.  The keys may be preceded by any of three modifier characters: 's' for shift, 'c' for control, and 'a' for alt.  So, 'sF10' means 'shift-F10' and 'scaF9' means 'shift-control-alt-F9'.  There are also a couple special keys named:  'Pause', 'SysRq', 'PrtScn'.  I don't really anticipate using the keybinding feature that much myself, but I've always been concerned about the 'Pause', 'SysRq', 'PrtScn' buttons, because keyboard manufacturers have a tendency to move those and sometimes make them hard to get to (sometimes requiring yet another 'shift' key).  Also, if you have a habit of accidentally hitting the reset button, maybe you want to make that harder by also requiring 'alt' or something on it.

The ROM feature is for loading a custom ROM.  There are two baked-in ROM images, referenced by the well-known (and case-sensitive!) name of 'level1' and 'level2'.  Otherwise, it is assumed to be a filename of a file in the 'rom' directory of the SD card.  Also, a custom ROM cannot easily have cassette traps of the same sorts as I have implemented for 'level2', and plan for 'level1', but if you know your ROM is derived from either the level1 or level2 rom (e.g. System80, or maybe something you hacked yourself), and that the cassette routines are in exactly the same place, then you can 'force=level2' to make those traps be applied, anyway.  (Later, I plan to implement some 'syscall'-esque mechanism for truly custom ROMs; e.g. perhaps supporting a CP/M build).

There will be other features added over time that will likely extend the file's content beyond what I have described here.  E.g. 'media' only preloads the first disk drive at present, but I'll probably extend that for all four, and also the two tape decks.