Hi Vassili,

on Sun 24-10-1999 05:05 Vassilis Papathanassiou wrote:
>on Thu 14-10-1999 20:12 Ronald Andersson wrote:
>>
----- snip ----- re: the SERIAL.STX sources I sent you
>
>I'm happy to say that I've made SERIAL.STX to work with MagiC PC's
>MODEM2 device driver.

Good.

>This driver pretents to have a MAPTAB structure,
>but it's not usable (or is Intel code).

Eh ?  Either it has a fully compatible structure, or it doesn't.
Any PC-specific variants are completely useless to our purposes.
Such an HSModem driver must be replaced, as it is incorrect !!!


>Still Serial.stx was wrong to NOT read the relevant flag from RSVF cookie,
>thus we could send or receive nothing.

I don't understand this.  No matter what the flags say there is no way
that STinG can use a MAPTAB structure based on Intel code.  Either the
code should be 68000 code, or it should be flagged as absent/unsupported.
Those are the only legal alternatives.


>It works fine now, with Fread-Fwrite-Fcntl and changed my_send() and
>my_receive routines(), but the Serial Setter CPX has problems to
>detect its speed (it says only 28800), and we have no other means to
>alter it (setter.prg or ttp does NOT work with device drivers).

Again I do not understand you.  SETTER.PRG does work with device drivers,
provided that they are compatibly programmed, as all HSModem drivers should
be.  I have myself used it to configure all HSModem device drivers I use.
This all sounds to me like a very badly programmed driver for the PC
MODEM2 device.


>It is also 'hardwired' with both handshake methods (Xon/Xoff and RTS/
>CTS are both enabled) and with IO buffers set to 256 bytes.

Eh ?  That is idiotic.  It is not possible to get reliable TCP/IP transfers
over a line that uses XON/XOFF handshaking, as those control bytes may also
occur in any and all packets.  The result will be massive packet loss and
hung transfers.  The same naturally goes for any kind of binary transfers
of non-TCP/IP traffic as well, so I fail to see why they did it this way.


>I'm using a small program to alter the baudrate and FlowCTRL but
>obviously Serial.cpx should do that and save the parameters.

Agreed, but that can only work if the driver is fully compatible with the
HSModem specs, which your other descriptions above make me doubt. Without
such compatibility it can't work right, and it would be silly to adapt the
CPX so as to compensate for errors made in incompatible drivers.  That will
lead to unending work for us, as all new drivers for non-Atari machines can
be expected to have initial compatibility problems.  That should instead be
reported to the authors of those drivers, so they can correct them.


>I'll try to change the IOREC also, since the 'legal' Fcntl method doesn't
>work for this also.

This sounds even more like something that we should not have to do.  It is
really the problem of whatever author produces that PC MODEM2 driver to make
sure that it uses compatible methods.


>I hope the old buffers are not at window$' memory
>area! Funny this, but even with 256 bytes buffers this new port is
>not at all slower than Modem 1 which uses DRVIN/MFP specially written
>for the PC and 8192 bytes buffers!

With a reasonably fast CPU and a decent interrupt structure it should never
be a problem to use 256-byte buffers with RTS/CTS handshaking.  That is true
on pure Atari machines too, but for some ports we have no such handshaking,
and it is then that the larger buffers become crucial, such as they are for
"Midi" and "Serial 1", and on Falcons for "Modem 1" as well.

So I would not waste time on that stuff if I were you, as that port seems
to have RTS/CTS (from what you said further above).  But do report to the
author of that driver that he has failed to make it HSModem compatible in
this respect too.  Such failures are obviously the main problems with it.


>>As you will see there are two versions of the sources.  The older one is
>>the one now distributed, and the newer one is what Peter was working on
>>for the next release, but I am unsure of any changes made (if any).
>>
>I've used the current version (1.15) and updated it to 1.16.

Does that mean that you have merged in the differencies Peter wrote, or
merely that you increased the number after adding your own stuff ?


>The only changes I've made are in XFER.C and SERIAL.C which I hope I'll
>send you later today, after I write some decision making code (ie if MagX
>and MgPC etc) since the old code will remain untouched for SingleTOS.

I have the source now, but have not had time to look at it yet.


>Speed under MagiC is improved a little  but I think Fwrite is much
>faster than calling Bcostat() Bconout() repeatedly for every byte.

That much seems obvious, and I take it that you mean this should be
implemented for other cases as well.  Correct ?

This may be well motivated, but the question is if this can lead to
blocking.  For example, what happens if we call Fwrite for a large amount
of data, for which there is currently no room in the buffers.  Blocking
in such a situation can not be accepted, even if the only alternative is
to transfer all data byte-by-byte.


>I had no problem up to now with the TT or MagiC PC's 'legal' Modem 1
>port. It's just my_receive() that took me a lot of time to implement,
>since Peter's code is highly depentent in finding the end of an
>incoming packet by just comparing every incoming byte!

I am afraid this is an innate problem of SLIP as such, as there is no way
to tell the 'other end' how large a SLIP packet is going to be.  The size
can only be known at the receiving end by checking for arrival of the END
code.  I had to cope with the same sort of thing in my PLIP driver too,
as the byte-for-byte protocol PLIP uses is identical to that of SLIP.


>Thus for Fread I had to find another method and not touch slip or ppp code.

Good, as this is probably quite sensitive to changes, not least because it
also includes the optional VJHC decompression.


>Please send me the Serial.cpx sources to make the necessary changes.
>I think that it contains some more bugs in detecting port speeds etc
>and according to Olivier it is the LIB_COM library that is responsible
>for this. If it's true, it should be a very fast update :-)

Ok, and if that is the case I have no argument against such a change,
but in view of what you said further above I must add that I am opposed
to some changes you seemed to imply there.  To be more specific, I am
opposed to any adaption of the SERIAL.STX, or the SERIAL.CPX that is
made to compensate for failed HSModem compatibility in alien drivers.

Such fixing is for their authors to perform, not for us !
Otherwise there will be no end to the patches we'll be forced to make.


Further above you mention that you need an extra utility program to set
the PC port to useful handshaking modes, which means that the changes can
not be properly tested without that program, or equivalent patch for the
SERIAL.CPX.  I will therefore delay beta release of the new SERIAL.STX
until either of those is available for inclusion in such release archive.


I will send you the sources you asked for in a separate mail.  This will
also include some other sources for my recent beta releases, as I am now
going to release them publicly, and expect that they will remain stable
for a while now.
