KryoFlux - Command System


Implemented a fairly intelligent command system that contains options that you can get or set. Getting an option always returns the current state - so if it’s been changed since the last call by either the user or the firmware for whatever reason, it returns that. Firmware state is always validated before changes, therefore all option values returned are valid.

Setting an option changes the option value to a 32 bit number, which is signed or unsigned depending on the option type. Generally, timing values are unsigned, everything else is signed. If an option value is invalid for whatever reason within the current context of the firmware (which may change its context) the option is set to a valid one if possible, or it fails correctly. Setting an option then returns the validated option value. This may or may not be different from what has been requested. Again, firmware state is always validated before changes, therefore all option values returned after a setting call are valid.

Options can be linked to hardware states, whenever a related option changes it ensures that all related states and options are changed as well after a request, although it only ever returns the originally requested option change as a return value since that is the one relevant for the call. Of course the rest can be queried any time through get calls. If a request requires some additional changes in the states those are usually done automatically as long as it makes sense.

All hardware access on the drive has been implemented. Any access from the firmware goes through these access routines, so the states are always known and correct. This is also required to comply with all the various timing and logical requirements of various drive types. All known drive requirements logical, or physical such as timing, are supported - no hardwired values whatsoever.

The firmware itself initializes itself to generic common modes, but all of these can be overridden through option settings sent from the host PC.

Even seeking to arbitrary track numbers (e.g. required negative ones for C64) is fully supported. No matter what command is being executed, it follows all rules and constraints to the letter. This of course may alter the originally set value in a set command, so the result must be observed. Changes that wouldn’t take effect until a certain operation requires the setting be delayed, but kept as the current valid state.

The actual option list:

  • c2Opt_S_Status=0
  • c2Opt_S_Descriptor
  • c2Opt_S_Diag
  • c2Opt_C_Reset
  • c2Opt_C_Motor
  • c2Opt_C_Density
  • c2Opt_C_Side
  • c2Opt_C_Track
  • c2Opt_C_Stream
  • c2Opt_V_Min_Track
  • c2Opt_V_Max_Track
  • c2Opt_T_Set_Line
  • c2Opt_T_Density_Select
  • c2Opt_T_Drive_Select
  • c2Opt_T_Side_Select
  • c2Opt_T_Direction_Select
  • c2Opt_T_Spin_Up
  • c2Opt_T_Step_After_Motor
  • c2Opt_T_Step_Signal
  • c2Opt_T_Step
  • c2Opt_T_Track0_Signal
  • c2Opt_T_Direction_Change
  • c2Opt_T_Head_Settling
  • c2Opt_T_Write_Gate_Off
  • c2Opt_T_Write_Gate_On

S: returns a string
C: is an option that changes state or cascading states when set. If read it leaves the system unaltered of course.
V: are variables
T: timing values in microseconds

The options always return a standard report format for easy parsing. The return message starts with a timestamp (the boards internal time in hex), then followed by the option requested with its value after reading, or if it’s a command, its value after the command has been validated and completed. Therefore an option set may return a very different value from what it requested.

  • Descriptor is just the board id.
  • Reset can be cold reset, setting generic drive timing values. It is possible to request a warm reset, and in that case all user defined options remain unchanged, and after the hardware initialisation has been performed all previous states return to their last valid values. E.g. you detect a hardware fault, request a reset then it will magically work from where it left off, apart from reading/writing as those are naturally disabled. When the board initialises itself for the first time it always performs a cold reset. Further reset types are user selectable.
  • Motor turns the motor on and off, and sets density and other changes as well.
  • Density allows to change drive density on the fly.
  • Side selects disk side.
  • Track seeks to any track requested that is within the limits set by the firmware or the user. E.g. It is possible to set the lower and upper limit of seeking to any number. Track seek detects hardware faults and automatically enters calibration during the next track set if that happens. You can see that happening if it ever returns 0xffff as a track number (this value is being used since negative track numbers can actually be valid!)
  • Stream enables the streaming of data on USB.
  • For the timing options: everything can be user defined and you probably don’t want to know what they mean :)

The command system is 95% tested and working, and the remaining stuff will be checked tonight.

It was noticed there is no READY line connected on the board, although drives do have it. Not a big issue, if a drive fails, its timing constants can be set with the options to make it work.


Reading will not be encoded like Cyclone20 does it. Instead RAW dumps will use a new encoding, and it will be the responsibility of the dumping software to convert to that from whatever formats it can read from hardware. That way, only the dumping software should be updated (if at all), not all the software dependent on the dumped files.