on Fri 05-11-1999 04:09 Vassilis Papathanassiou wrote:
>on Tue 02-11-1999 15:21 Ronald Andersson wrote:
>
----- snip ----- re: MagiCPC Modem 2 incompatible to HSModem
>
>Hmm, not exactly nothing ;-) it's RSVF compatible.

Ok, but I will never consider a serial driver without a BIOS layer and
no IOREC to be fully compatible with either HSModem or TOS design ideas.
Still, I think the problems are mostly solved now, except for the buffer
size and transfer speed settings.


----- snip ----- re: SETTER was intended as a general config program
>
>I had forgotten that. But even in this case both SETTER and DRVIN were
>written with one another in mind, I don't know any other program that
>can be configured with SETTER.

I did hear of one or two others, but I can't remember which.  It is not
all that convenient a method anyway, so I am not really surprised that
it never gained wider use.  There are better ways to configure stuff.


----- snip ----- re: that MagiCPC driver is not a real HSModem driver
>
>That is true. But in theory (I'll check it in pactice also ;-) it can
>be installed as the only driver without DRVIN etc at all.

Under MagiC the GEMDOS bender of HSModem is never installed, so that
driver never has any real contact with HSModem at all, as GEMDOS is
its only interface. They live in separate parts of the same OS, that
is all.


----- snip ----- re: installation of the driver as MagiC DEV
>
Actually HSModem's method of installing the GEMDOS part of a driver
is directly modelled on MagiC methods.  They even have the same
Dcntl code for it (DEV_M_INSTALL), though MagiC has extended its set
of codes with other alternatives too.  But as far as I can tell from
the disassemblies I've made, the HSModem drivers use DEV_M_INSTALL in
exactly the same way under singleTOS as they do under MagiC, when
the GEMDOS part of DRVIN is not installed.

Things don't get much more legal and compatible than that...  ;-)


----- snip ----- re: MagiC should allow 'deferred' boot of devices
>
>We have discussed this in the past IIRC and had to do with BNeT and
>BetaDos under MagiC and MiNT.

Yes, of course.  I remember it better now.


----- snip ----- re: more on SETTER compatibility
>
>Thinking of that, is any example/source/skeleton code available for
>writing a HS-MODEM (and thus SETTER) compatible driver ? I don't have
>any info on that.

No I don't think so.  At least I never saw any.  But I think I could do
a driver anyway, based on the excellent disassemblies of TTDIGGER.

Unlike other disassemblers, this allows me to keep on digging, interactively,
adding labels, bookmarks, comments, almost as if editing a source file, and
with the same effect on the source file which I can save at any time.  And
this can be done simultaneously for multiple files, which I really needed
with DRVIN and its modules.

The drawback of most other disassemblers is that you can only do a fairly
small part of the analysis interactively, and then you have to abandon the
disassembler and do the rest of the job the hard way, in a text editor.
(Sorry about the digression, but TTD really is an excellent tool.)


----- snip ----- re:  Xon/Xoff blocking MagiCPC
>>
>>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.
>>
>Maybe, I'm not sure though. I regard that as a bug of the worst OS ever
>on earth which is possible to block for less serious reasons. In our
>case there is a window$ process (ie MagiC PC) which uses a device owned
>by window$. The device has a problem and the whole process blocks. You
>can still work with win$ but not even kill the problematic process.
>This is the OS that dominates the world!

Which says more about how this world works, than about that OS...  ;-)


>>>(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.
>>
>Let's get prepared for the next disaster: win2000!

No, let's be consistent.  They've kept using the last two digits of the
year as version id for quite a while, so the next one is 'windows zero'.


----- snip ----- re: Serial 1 speed settings in SERIAL.CPX
>>
>>Are you sure you have installed MFP_TT.PRG correctly ?
>>
>I think so. Now I have to recheck if some options for enhanced STs are
>active.

I'm not sure exactly what that driver allows, but there are many speedup
options for MFP, and HSModem supports some of them.  Some do allow the
hardware rate to be set to 115200,  and while that is not useful on an ST,
a TT should be  able to use it.

I just checked in the docs, and there is a setting called RSVE, named after
the MFP speedup Harun Scheutzow himself designed.  With this setting the
port should go up to 115200, so that is probably it.


----- snip ----- re: more on MagiCPC Modem 2  (current methods acceptable)
>
>For the moment we have no other option anyway. I did a quick disassembly
>of this driver and it contains calls to Intel code! This is a method
>I'd like to know since there are several peripherals on the PC I'd like
>to access, like eg. the ethernet drivers.

I can think of several ways to include such an ability in an emulator.

1:  Define a specific 68000 opcode (an illegal one) to cause emulation to
    halt and native Intel code execution to proceed at the next word after
    the special opcode.  The drawback is that some system procedure needs
    to be called to switch back then.  The advantage is that Intel code
    and 68000 code can be mixed rather freely.

2:  As above, reserve an illegal 68000 opcode, but define this as a
    procedure call for native Intel code, so that the procedure returns
    into the calling part of the emulator which then proceeds with the
    68000 emulation at the address after the address argument of the
    special call opcode.

3:  Instead of special opcodes it is possible to have reserved system
    routines that do the same thing.

To identify the method with certainty you need many examples of such calls,
but fewer examples may suffice, when complemented with some experiments.


----- snip ----- re: serial Fwrite must be unblocking
>
>I think I know what you mean, Fwrite implementations that will try and
>retry to send the asked mumber of bytes until a timeout. This is not
>the case with HS_MODEM (based on its docs) since both Fcntl and Fread
>Fwrite return the number of bytes that can be transfered non blocking.

I have disassembled MIDI.PRG, SCC.PRG, and MFP.PRG, and I can verify
that their ddev_read and ddev_write subroutines (used for Fread/Fwrite)
do not block.


----- snip ----- re: for the MagiCPC driver Fread/Fwrite are necessary
>
>Yes, that's why I suggested to keep this method for MagiC in general
>since AFAIK MagiC Mac uses a similar method to access additional serial
>ports (at least for the very few Mac users with a second serial port :-)

I am fairly sure that this is so.  It is mentioned in some docs.


----- snip ----- re: using, calling, or emulating Fread/Fwrite
>>
>>1:  Normal use of GEMDOS Fwrite
>>2:  Direct call to GEMDOS part of HSModem for Fwrite
>>3:  Emulation of Fwrite by Bcostat and Bconout
>
>If we get into trouble for the second method we can use the results to
>avoid using the first (!) and thus save passing through the GEMDOS
>handler which will be again a bit faster.

Yes, but I have chosen an even faster method for the latest versions.


>For the third method and knowing that interrupts are disabled we can
>write directly to the IOREC buffer and update its head and tail. I've
>used it in the past without problems and it's faster than any other
>method.

This is the basic method on which I based my new version.  It uses this
method in exactly the same way as the HSModem modules do in ther ddev_read
and ddev_write routines, except that the information is accessed through
the 'MAPTAB *handler' entry of a 'SERIAL_PORT' struct.  The result is
a ddev_read and a ddev_write simulation that fits any port with a valid
MAPTAB struct.  This replaces both alternatives 2 and 3 above.
The new routines are named 'sim_Fread' and 'sim_Fwrite' in CALLS.S.
(I also added 'sim_Bconstat' and 'sim_Bcostat' to replace Fcntl calls.)

Ports that do not have a MAPTAB struct (by RSVF flag) are only accepted
for STinG use under MagiC, and then they will use normal Fread/Fwrite
and Fcntl calls for the stuff that normal ports use 'sim_xxx' subs for.
I added a new flag to the 'SERIAL_PORT' struct to keep track of this.

This means that for normal ports there is no difference between usage
under MagiC and usage under singleTOS. And both are quite fast, as no
system functions need to be called to make the same kind of Fread and
Fwrite operation that HSModem would make if called.


Btw:
You have missed part of the point of circular buffers.  When defined
to have only one 'reader' and one 'writer' there is never any need to
disable interrupts to read/write data from/to the buffer.  The 'head'
index is only updated by the 'reader', and the 'tail' index is only
updated by the 'writer', and the updating rules are such that there
can never be any conflict, even if either of these functions is made
by an interrupt.  HSModem and its modules never disable interrupts for
that sort of access.  They only disable interrupts as needed to protect
some hardware accesses.

Sounds too good to be true ?  And yet it is true.  Think about it.


----- snip ----- re: SERIAL.CPX problem setting speed of PC Modem2
>
>do
>{
>    last = --spd;
>    if (Fcntl (handle, (long) & spd, TIOCOBAUD) == EINVFN)
>        break;
>    speed[index] = & speedbuf[10 * index];
>    sprintf (speed[index++], "  %6ld ", spd);
>} while (last >= spd);

>The driver in question returns the correct speed if one asks for it
>(using -1 for speed) but for the above code it seems to return spd
>on the second pass, thus last is not >= to spd and the loop exits.
>This explains why the popup only contains one speed entry which is
>decremented by 1 for every 'click' on it. Obviously this is a bug
>in the driver and not in serial.cpx although we could do something
>for it...

I know what causes that.  It is not a bug, but a misimplementation.
I mean that the code does what they wanted to do, but that was wrong !

Many of the system functions that allow a system parameter to be set
also return the old value when this is done. So should TIOCOBAUD, if
called with a value that is acceptable.  That is evidently what this
driver does all the time, indicating that the author did not know of
the exception used when unacceptable values are set.

NB: many TOS programming documents do not mention this at all...

What you get is that the driver attempts to set the requested speed,
with results we are unsure of, and in any case returns the speed that
was set previously.

On the next pass, the same thing happens again, only this time the
'previous value' is the one used before, which is why you see the
value as 'delayed' one loop.  That 'delay can be eliminated simply
by repeating the same call twice.

However, there is a bug in this code.  It simply assumes that the
speed setting fails, and that a valid 'next lower' value is then
in 'spd'.  That is not a valid method.  The state should be tested
by checking for Fcntl return value of ERANGE.  Only when that is
returned can we rely on 'spd' to be a valid 'next lower' value.

The CPX uses a test value of one hundred million bps, so if a test
for ERANGE with that value fails, that proves the driver incompatible.
I am quite certain that this PC Modem 2 driver would fail that test,
as will any other driver designed by its standards (future ASH stuff ?)
So this may be a good way to identify such problem ports.

The test for EINVFN should be done before the loop, as it is not
sensible to test over and over if the function itself is valid.
That should only be done once per port.

Unfortunately none of this will make the driver implementation work.
Probably it just takes the given speed number and calculates a timer
value that gives the closest possible approximation of that speed,
and uses this to set up whatever baudrate timer the PC uses, and
never bothers to test legality of the parameter in any way.


----- snip ----- re: illegal speed acceptance
>
>Sorry (see above) I was talking about the device driver not serial.cpx.

Ok, I understand this now.

>I've used an extra array with PC speeds in the CPX and detecting that
>we are at MgPC and the driver is MODEM2 this is used instead of the
>normal method. It currently works OK for my tests but of course it's not
>100% correct to get the speeds that way. Still it might be better for
>MagiC PC users to use the CPX that way than to give them an external
>program, since in this external program they'll have to supply the speed
>somehow (it can't be fixed of course).

And then we'd have to make new releases of the CPX every time ASH feels
like changing something..., such as what baudrates should be supported.
Or when some PC standard changes, or whatever...
No thanks.

One solution here is to use a special patch program for it.  The driver
is simply not compatible enough to work well with any CPX setter, unless 
the author wants to rely on alien systems for forced updates.

Alternatively, if we must support this garbage in the CPX, it should
not be done by compiled-in constants...  that would not be acceptable.
Instead, use a simple text file holding on separate lines the rates
that should be allowed for this port.  This way the text can be fixed
without affecting the binary.

Or, show 'Unknown' as available speed in the popup, and provide some
editable field for the user to enter the speed in. But I am unsure if
the CPX can have variable objects, and we can not have an editable
speed field for normal ports.

Best alternative (if feasible).  Convince ASH that this is the sort of
mistake they have to correct, as no comms programs will be able to use
the standard methods to find the available baudrates either, as it is.


----- snip ----- re: your wife's father
>>
>>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.
>>
>Well, his bile had three 'stones', one of them 1cm in size which blocked
>the entrance to his pancreas (medical report ;-) The situation was a bit
>serious but not so serious with today's standards. A surgery is needed
>in a few days since it's not possible now for them to use other methods.

1 cm is a bit much I guess, but for smaller stuff I've heard that they can
use ultrasonics to pulverize them without surgery.


>This is the third day I'm here but I came back with a muscle pain in my
>back which made even breathing difficult! (no, it's not a heart attack ;-)

I hope you get better quickly, and as you say 'made' above I guess you
feel some better than that already.


>Seems the weather gets colder and I didn't noticed that...

It happens every year here.  Lots of people catch colds during autumn and
early winter simply because they don't switch to winter clothes in time.
And while most people associate 'colds' with coughing and runny noses,
it can affect most parts of the body, frequently as inflamed muscles.
