[Coco] DriveWire 4 seg fault under Linux Mint...

[Aaron Wolfe]

On Nov 13, 2014 4:49 PM, "Tormod Volden" <lists.tormod at gmail.com> wrote:

> > needed).  This has been the behavior for many years before I started
> > working on DW, I don't know all the ramifications of changing it and
there
> > may be more than are easily thought of.   I don't think this is safe to
> > change.
>
> OK, I think we can leave it like this, having the "expand" parameter
> is good enough.
>

Come to think of it, I could change default setting on named obj mounts
only, since these are new and wouldn't be used by any existing software.
Have expand set to false for named obj should be OK, someone can change it
if they need to anyway.

> >
> > The DW spec uses a timeout of 200ms to indicate an operation has failed.
> > In some cases, DW intentionally waits this long so that the timeout
will be
> > seen by the coco and it can behave accordingly.  Any implementation
should
> > respect this part of the protocol.  I don't know whether this particular
> > instance is intentional or not,  but it sounds like something the client
> > should be handling better in any case.
>
> Ah, I hadn't realized the timeout was part of the signalling, I
> thought it was just for robustness.
>
> Then we certainly need to fix the Becker routines.
>
> In this case though, returning a read error $F4 would be appropriate,
> wouldn't it?

This is from fuzzy memory, but I believe sending read errors just causes
the coco to retry.  In the case a retry isn't appropriate (source is gone,
things will not work out) then the timeout is used to fail the entire deal.

(This may be wrong, but it was something like that as I recall)

> I would prefer the change of file size. If someone is using non-256
> files it would be part of the game that they change size on rewrite.
> If the file is going to be changed anyway, I don't see any practical
> problem it being padded. Since we simply cannot write non-256 files
> over DriveWire, the client shouldn't try to write to it if it doesn't
> want the file size changed.

I think that if we limit this behavior to named object mounted items it
will be OK.  Doing things differently for them than for standard disk
inserts makes me less worried about people doing silly things to themselves
or unexpected consequences with older stuff.

I hope to have time this weekend to put out a version with fixes and these
changes in it.