Hi Vassilis,

on Wed 27-10-1999 15:43 Vassilis Papathanassiou wrote:
>on Tue 26-10-1999 19:34 Ronald Andersson wrote:
>
----- snip ----- re: MagiCPC Modem 2 MAPTAB struct
>>
>>Eh ?  Either it has a fully compatible structure, or it doesn't.
>>
>It doesn't :-)

Then that is not something STinG should get involved in.
Instead a separate patch program, such as you described should be used.


>There is only one point which is incorrect, the setting of send and
>receive buffers (see below).

Ok, but then it is no big deal anyway.  I'd go with the default sizes.


>>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.
>>
>Sorry if I'm missing something but from RSVF docs (english version of
>HSMDOC7E) it says that bit 5 of the flags byte of RSVF cookie should
>be 1 to signal that the "Interface is known to BIOS (Bco*-routines)".
>This is NOT the case for this driver, thus we can assume that MAPTAB
>is NOT valid.

So, this is the serious part.  Hopefully we will never see a similar
problem with any driver for singleTOS, as the solution you used will
not be possible there.


----- snip ----- re: configuring MagiCPC Modem 2 driver
>>
>>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.
>>
>SETTER works for drivers that are loaded after DRVIN and have a special
>structure.

I had assumed that we were speaking of an HSModem compatible driver, and
all such must boot after DRVIN, and must have SETTER compatible structure.
Evidently this is not the case here, so we are faced with the problem of
adapting to a driver that has nothing whatever to do with HSModem.

However, you have misunderstood SETTER.  It was originally intended to be
able to handle configuration of any program at all, and it is not at all
dependent on a program being started after DRVIN, as long as the program
does have the correct structure it will still be configurable. One example
of this is that DRVIN.PRG itself can be configured by SETTER.  ;-)

The problem here is rather that the driver you speak of is totally unrelated
to HSModem, and therefore does not support anything in the same way as all
HSModem drivers do, and so it has no SETTER struct at all.


>Modem 2 for MagiC PC is a device driver (MODEM2.DEV) thrown
>into the XTENSION folder and installs U:\DEV\MODEM2 in MagiC's 'legal'
>way, not like DRVIN. It can be renamed to MODEM2.PRG and run from the
>desktop also (like almost any MagiC XFS/DEV driver) but not after DRVIN.

I don't remember now if it was you or Peter that I discussed a similar
problem with earlier.  Whatever, it is a definite problem with MagiC
that it insists on loading all XFS/DEV drivers directly at boot, even
though some of them may need other programs started first. In some cases
this can be fixed by having an \AUTO\ program that alerts the driver when
the stuff it needs have been initialized, but that is not much help in
this case, as the driver wasn't written to interact properly with HSModem.


>So, I'm not sure if it's illegal to not be configured by SETTER.

There has never been any requirement that MagiC device drivers use SETTER.
That requirement only applies to HSModem drivers, which this is not.


----- snip ----- re: 'silly' handshaking defaults (Xon/Xoff + RTS/CTS)
>
>It's even worse with MagiC PC :-( With XON/XOFF the whole emulator is
>blocked and can NOT be killed even by window$ (!), thus for the first
>tests I had to reboot window$

I regard that as a bug in the emulator.  Nothing done at serial interface
level should affect the general emulation process. That should never block.


>(I'm sure you've heard how long it takes
>even for the fastest PCs to boot win98).

Actually most people I know avoid win98 so far, using winNT or win95.


----- snip ----- re: suitable patches for driver compatibility
>
>No, I'm not going to implement illegal calls in Serial.cpx for this driver.
>The problem is that the CPX is not completely correct when dealing with
>RSVF compatible ports

I'm not sure what you mean here.  Do you mean HSModem or something else ?


>(eg it says that SERIAL 1 on my TT can go up to 115200 bps which is not true).
>If the relevant Fcntl calls return wrong
>values for some drivers, it's something we'll learn very soon :-)

Agreed.  Wherever possible the values should be aquired by 'asking driver'
as that is the only point where up-to-date info can be expected, as there
are many 'speed-patches' around.  But this has to be tested on a large
number of different machines, as the same SCC.PRG (for example) is used
with various machines having different available speeds.

I must also question your results with SERIAL 1.  For me, on my TT, the
current SERIAL.CPX presents speeds ranging from 50 bps to 19200 bps,
just as it should do.

Are you sure you have installed MFP_TT.PRG correctly ?


----- snip ----- re: IOREC patch
>
>Unfortunately there are no compatible methods for this change. The Fcntl
>TIOCBUFFER belongs to suggestions not to implemented calls in current
>HS-MODEM drivers, thus the only way to alter the buffers is SETTER.
>This is where I agree with you, if this driver can't be supported by
>SETTER it should implement the Fcntl method and not have the buffers
>fixed to 256 bytes.
>
>And since the MAPTAB structure is not valid, changing the IOREC 'by hand'
>has also no effect, so MagiC PC users will have to live with this for the
>moment. But at least they'll be able to use one COMM port for their modem
>(probably with Masquerading) and the second for the network. This is the
>configuration I'm using for the last couple of days and it works fine
>so far.

Then I think we should leave it as-is.  Why change a winning team ?


----- snip ----- re: fixed 256 byte buffer size
>
>Hmm, I'd prefer the buffers to be at least MTU size. If you check XFER.C
>a little (the old or new my_send/my_receive routines) you'll find out
>that for large blocks we have fragmentation in 'serial level', ie the
>driver comes in the next pass to complete the transfer.

Yes, I know, and in fact several MTU sizes would be even more preferable,
as we may have interrupt driven multi-connection traffic too.  That is why
I always use 16 KB for buffers on my machines, even on ports that do have
RTS/CTS handshaking.  But this is only to gain an edge in speed and in the
'unblocked' capacity.  The basic needs for safe transfer are satisfied by
the RTS/CTS handshaking itself, even with fairly small buffers.


>>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).
>>
>Yes, fortunately every PC serial port has all the pins connected.

That is the main thing of importance here, and any buffer patching wanted
can be done by a separate patch program for that specific purpose, if and
when you decide how this can best be done.  That patch program can then be
supplied as an auxiliary program for MagiCPC STinG users, without being a
part of STinG or SERIAL.CPX .


----- snip ----- re: reporting to the author of the MagiCPC Modem 2 driver
>
>Well, the author is unknown to me! This driver is included in ..\MAGIC\
>UTILITY folder and contains a TXT file explaining some things ending
>with "Heidelberg, d, 19.06.1998". That means ASH has to be contacted but
>since the driver works OK with I-Connect (I've also verified that), I
>don't beleive they'll get much interested.

Tough luck then, as I think you are right.  They'll probably ignore this.
Still, I think the results you already have achieved are acceptable as-is.


----- snip ----- re: Peter's versions 1.15/1.16 of SERIAL.STX
>
>>Does that mean that you have merged in the differencies Peter wrote, or
>>merely that you increased the number after adding your own stuff ?
>>
>Trying to be fast I started with v 1.15 but checking v 1.16 later I could
>not find any changes Peter did in the code. Maybe I'll have to search
>more but for the moment we can consider Peter's v 1.15 and 1.16 equal.

Ok, but please check completely for any differences, as you are now more
familiar with this code than I am.  It would be a pity to miss some new
improvement Peter had prepared, just by overlooking it. On the other hand
it is possible that he barely got started on the additions, in which case
the two versions would be equal, except that 1.16 might need more stuff
added that never got finished. In such case we should simply forget that
version and regard 1.15 as the basis for new work, just like you did.


----- snip ----- re: using Fwrite rather than Bcostat+Bconout
>>
>>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.
>>
>There is no way to block anything during Fwrite. If we use Fwrite for
>a large block we'll get back the number of bytes actually written and
>complete the transfer in the next pass.

Yes, of course, I know this is how it should work.  The problem with this
is that it places the responsibility for unblocking behaviour in the low
level driver and its separate implementation of the Fwrite call.  Whether
this can lead to blocking or not is thus out of the hands of STinG. With
real HSModem drivers that should not be a problem, as they share a common
method, but non-HSModem drivers must each 'roll-their-own', which could
include blocking for some cases.  Hopefully this will never be the case.


>This is not different from the
>'old' (or SingleTOS) method, only that in this case my_send() calls the
>equivallent of Bcostat (through MAPTAB) for every byte to be sent.
>If Bcostat returns 0L it saves the current index and comes back in the
>next pass to continue sending. Thus for a 500 bytes block (and assuming
>the buffer has enough free space), the 'old' method does 1000 calls, ie
>500 times jsr (a0) where a0 points to Bcostat and 500 times jsr (a0)
>where a0 points to Bconout. And just to 'play it' an assembly speed
>freak ;-) for a while, it also saves/restores the buffer, code and status
>pointers to memory for every byte!!

Unfortunately some such 'waste' is unavoidable, as the latter is also done
during reception through SCC/MFP/ACIA etc.  And there it is unavoidable...


>Fwrite just moves the number of bytes it can to the output buffer and
>returns. Obviously a lot faster!

As you say, that is obvious.  My only problem with it is that we then
rely on an alien implementation to ensure that STinG stays unblocking.

But I suppose we have little choice here really, as Fwrite appears to
be the only way that driver can be accessed, and if ASH could do this
once then they can do it again, so we can't expect any different from
any future MagiCPC (or MagiC, or MagicMac) drivers released by them.
Thus using Fwrite this way could be the only way to keep them compatible.


Hmmm.  I wonder.  Although normally reached through the GEMDOS dispatcher,
thus making it illegal in interrupt code in singleTOS, it is possible that
the Fwrite implementation of HSModem is not inherently sensitive to this.

If so, then a link to that driver could be 'dug up' from the XBRA chain
of GEMDOS and used to allow direct calling of the HSModem Fwrite function,
without involving normal GEMDOS or any other GEMDOS extensions.  This may
make it possible to use the Fwrite method in singleTOS as well, where it
could have serious impact on the maximum speed.

I think that some disassembly is needed to analyze this situation, to make
certain exactly what the situation is.  What will work, and what not.

The goal in this should be to create a new function inside SERIAL.STX, that
I will (for now) call Ser_Fwrite.  That function will simply make a jump
through an internal vector to reach another function that is a tailor-made
Fwrite implementation for the running OS.  For MagiC that can be a normal
PureC shell function for Fwrite, but for singleTOS it could be a custom-made
function using the HSModem GEMDOS vector (found as described above) to call
HSModem Fwrite directly.  Even if that does not work in some circumstances,
or for some ports, we can then use another function that simply emulates the
Fwrite behaviour using Bcostat and Bconout.  Since the needs may well vary
with each port, we may need to add an internal struct or array that holds a
separate Ser_Fwrite function vector for each serial port, or we may define
such a vector as part of an add-on element to present structs.

Although I normally want to avoid routine duplication, this is one case in
which the gains make the effort worthwhile, and at present I only see three
possible cases that need to be covered.

1:  Normal use of GEMDOS Fwrite
2:  Direct call to GEMDOS part of HSModem for Fwrite
3:  Emulation of Fwrite by Bcostat and Bconout

The last is of course identical to traditional methods, while the first is
what you use for MagiC, so it is only the second variant that needs to be
added, plus the new shell function that makes the usage fully symmetrical
and some initialization code to set up the vectors.


----- snip ----- re: END markers in SLIP/PLIP packets etc
>
>This is also true for PPP. It just uses a different END 'mark' but the
>method is analogous to SLIP (ie it has to 'escape' every byte in the
>packet that matches the 'mark' byte.

Actually there are other reasons for such 'escapes' too, having to do with
transfer security.  It is important that no 'command' bytes can occur as
part of any transfer data block.  That need is not directly related to
the use of END markers, and does not need to incur the same time losses.

But with END markers no assumptions for incoming data blocks are valid
until the received block is complete, which adds many complications for
the receiving code.  For example, RAM buffers must always be allocated
in MTU size, which is wasteful, and fixing that by reallocation after
receiving the complete block leads to wasting time as well.


>>>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.
>>
>Yep, and we'd have to replace larger number of subroutines based on
>MagX/not MagX which you (and I ;-) want to avoid.

Agreed.


----- snip ----- re: SERIAL.CPX sources for patching port speeds etc.
>>
>>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.
>>
>Agreed. If you find anything illegal in SERIAL.STX or SERIAL.CPX I'll
>accept their rejection immediately :-)

I haven't seen what you want to change in the latter yet, but I advice
you to doublecheck your present setup.  The bad results you mentioned
for speed detection on your TT do not match what I get here.  Here the
results with the present SERIAL.CPX are correct !!!


>>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.
>>
>Sure. As long as the bugs are not on our side.

Agreed.


>>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.
>>
>Yes, my (very) small program basicaly does an Fopen (U:\DEV\MODEM2, FO_RW)
>and then Fcntl (han, (long)&speed, TIOCBAUD); and then a Fcntl (han,
>(long)&flags, TIOCFLAGS). The latter can be done by SERIAL.CPX also but
>then it destroys the speed setting, ie whatever the speed, it decreases
>it by one (!) eg 28800 results in 28799.

That sounds very odd.  Could it be a failed attempt at 'round-off' ?
If so, then it should simply be corrected.


>I found out that it can accept all speeds, this is really crazy!
>(and illegal of course).

I'm not sure what you mean here.  Of course the CPX itself must be capable
of passing any speed to drivers, although it is then up to them to decide
which speeds are actually usable.  As the choice is done by clicking on a
speed item in a popup I do not see how it is possible to enter 'all speeds'.

Only those presented in the popup can be selected, which is definitely legal
as long as that list is correct.  On my system it is, but apparently not on
yours...  That needs to be investigated before patching the CPX !!!


>>I will therefore delay beta release of the new SERIAL.STX
>>until either of those is available for inclusion in such release archive.
>>
>Sure, although it would be good to be tested a little with MagiC in true
>ATARIs.

Ok, I will try it a bit myself and then make a beta release of it.


>>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.
>>
>Thanks, already received them, my reply will come in the relevant
>subject(s).

Good.


>URGENT: I'm leaving for Rhodes in half an hour (flight is 5.30 in the
>morning) since my wife's father is in the hospital. I hope it's not
>something serious, in any case I'll be back on Monday.

I too hope it was not serious, though I misdoubt it, as it is now tuesday
with no further mail from you. But don't feel rushed now. I understand that
you may need to give your attention to your family at a time like this.
