1
0
mirror of https://github.com/TomHarte/CLK.git synced 2024-11-25 16:31:42 +00:00

Added aside on Configurable::Device, at least to name check it.

Thomas Harte 2019-03-07 12:13:22 -05:00
parent 70524e4daf
commit ca648c21bb

@ -125,6 +125,14 @@ Make sure that when you instantiate your instance of the OpenGL scan target, or
This is a nice-to-have for a port, but very optional. Some machines provide activity LEDs, e.g. for drive activity or for caps lock. If the dynamic machine can vend an activity source then an activity observer can be posted to it. That observer will immediately receive an enumeration of LEDs and drives attached to the system, and will subsequently receive notification of both audible drive events (i.e. activity a user could observe) and LED changes. This is a nice-to-have for a port, but very optional. Some machines provide activity LEDs, e.g. for drive activity or for caps lock. If the dynamic machine can vend an activity source then an activity observer can be posted to it. That observer will immediately receive an enumeration of LEDs and drives attached to the system, and will subsequently receive notification of both audible drive events (i.e. activity a user could observe) and LED changes.
## Runtime Configuration
Machines that provide further runtime configuration options — e.g. if they can support both RGB and composite outputs, which of those is connected — provide that information reflectively via `Configurable::Device`. This is the route that the SDL port uses for determining command-line options and then for forwarding user selections.
The Mac port uses the same mechanism for forwarding user selections but the relevant configuration dialogues are hand-designed. I'm on the fence as to whether that's actually a bad idea.
_As per comments elsewhere, I'm still considering the ramifications of the type of reflection used here, which requires quite verbose coding effort. I think I'm bending towards other options before rolling this out to static configuration and, one day, possibly debugging._
## Providing Time Revisited: the Best-Effort Updater ## Providing Time Revisited: the Best-Effort Updater
The best-effort updater, `Concurrency/BestEffortUpdater.hpp` is a helper class currently used by both the Mac and SDL ports, though it's entirely optional. It provides a thread-safe `update` method that can be called to request that 'more' emulation occurs. It will tell a delegate how long to run emulation for, but it will do so only if a call to the delegate isn't already happening. The best-effort updater, `Concurrency/BestEffortUpdater.hpp` is a helper class currently used by both the Mac and SDL ports, though it's entirely optional. It provides a thread-safe `update` method that can be called to request that 'more' emulation occurs. It will tell a delegate how long to run emulation for, but it will do so only if a call to the delegate isn't already happening.