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

[Tormod Volden]

On Thu, Nov 13, 2014 at 11:17 PM, Aaron Wolfe <aawolfe at gmail.com> wrote:
> 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.

Excellent!

>
>> >
>> > 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.

The spec says the coco can retry with ReRead if it gets a checksum
error, but not on read error.

>
> (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.

Thanks a lot!
Tormod