[Coco] DriveWire 4 - Turbo Mode + ROM *SOLVED!*

[Aaron Wolfe]

On Mon, Sep 23, 2013 at 1:36 AM, Bill Pierce <ooogalapasooo at aol.com> wrote:
>
> Yes, the "Write to server" has been broken for a long time. It writes, but the server doesn't reset properly. A reboot is always best after any changes to the config.
>


This has been an issue for a long time, yes, but I would not say it's
"broken" :)
More like undetermined.

The reason the button is labelled "Write to server" is because that is
what it does... and nothing more.  It's not labeled "Apply" or
something like that, because we have never figured out a good way to
implement that.  It isn't a technical issue really,as there would be
no problem just restarting the server, but that isn't necessarily what
the user would want.

In the Config menu there is an option to reset the device, which will
make things like serial parameters or TCP listening port changes take
effect, basically anything to do with the physical connection.  There
is also the option to restart the "instance" which will make things
like logging verbosity, certain limits and other parameters that
effect that particular coco to server relationship but not the entire
environment if you are running multiple cocos.
And then you can restart the entire server.  So three different levels
of "reset" depending on where these changes take effect.

Again, technically its not a problem to determine what needs to
restart to make any given changes take effect immediately and restart
it, the problem is knowing when/if the user actually wants to do these
things.

There is a lot of "state information" that has to be synced between
CoCo and server.  Things like what connections are open or listening,
MIDI instruments and settings, what windows are open if using
NineServer, etc. all rely on the CoCo and server being in sync.  It is
not practical (or at least I haven't found a way) to transmit this
entire state constantly back and forth over a relatively slow serial
line, so instead we have some sanity checks but mostly assume both
sides are in agreement and only transmit changes to state back and
forth.

This means that resetting the CoCo or restarting the server both cause
a potential mismatch that will cause Bad Things for the user's sanity.

Detecting a CoCo reset (so long as it stays plugged into the serial
port) is pretty easy, and the server watches for this.  When a reset
is seen, it resets its own state in step (closes all tcp connections,
resets all modems, midi, printers, etc).  So, it is (or is supposed to
be, remember I make a lot of mistakes :) safe to reset the coco at any
time and continue on doing anything you'd like to do.

The opposite is not nearly so easy.  In the first place, there is no
way to initiate communication from the server side.  A Coco in HDBDOS
will never ask the server if it has restarted, and the server cannot
tell it.  In OS9 there is more opportunity to communicate as the OS9
driver usually does poll the server periodically and we can return
various state information.  However, it is specifically in OS9's
multitasking environment where I worry the user may have ongoing tasks
that should not be interrupted automatically when a config change is
made in the UI.

So... I guess the short version is "I don't know how to apply config
changes sanely, so I leave it up to you".  A restart of both coco and
server will always work, but if you know the effects and want to
restart only the device or instance, the UI will also let you do that.
  If there is a "grand unification theory" that would let me know how
to properly implement automatic solutions here, I am all ears.