To: perot@pallas.amp.uni-hannover.de
Subject: Re: [7] New STiK, more info and binaries                                        


On Tue, 7 Jan 1997 10:26:31  Peter Rottengatter <perot wrote: 
>
>
>On Tue, 7 Jan 1997, Ronald Andersson wrote:
>
>> ----- snip ----- re: patching BIOS to reserve port devices without GEMDOS
>>
>> >And what do you mean by overcomplex ? It's not at all complex in terms of 
>> >programming ...
>> 
>> Part of the complexity I meant was that all STiK parts that need BIOS calls
>> for port I/O will have to do this by simulating trap calls through the XBRA
>> links of your patch routines.  They cannot use normal trap calls for this,
>> because then the patch code needs to identify whether a caller is STiK or not,
>> which probably leads to even worse time loss.
>
>There must be some big misunderstanding, as this makes very little sense 
>in my ears. No parts from STiK, apart from SERIAL.STX, shall access the 
>serial devices ...

It was such code that I meant.  If the patched BIOS calls block access to the
ports used by STiK, then the SERIAL.STX cannot use not BIOS traps, but must
use the XBRA links of the patched routines to reach original BIOS.


>> But mainly I meant that any extra code is overcomplex in this regard, since
>> reserving devices like this should not be done on the BIOS level.  On BIOS
>> level it should always be possible to access all devices.
>
>You're probably right, which makes the Fopen() version sound even better.
>But there is still the ownership problem.

Yes, but I believe the 'p_run' method can solve those.


>> I did not intend that the GEMDOS trap should be patched at all to achieve the
>> blocking.  I simply want the Fopen to be used within some code that ensures
>> that the owner of the channel will be the TSR.  This way neither GEMDOS nor
>> BIOS will need to be patched.  If Andreas can tell us a method he prefers us
>> to use with MagiC then we add that alternative, but otherwise I favor using
>> the 'p_run' basepage patch method as a general solution to this problem.
>
>Seems like we finally agree on this ?!?

Yes, and I think we did all the time.  Neither of us wants any needless vector
bending, we just misunderstand the needs described at times.  Also, there are
some tricky problems involved, but I think we have now found solutions to them.


>> ----- snip ----- re: 'p_run' determining ownership (in MagiC 5 & MiNT?)
>>
>> I believe so, and I'm sure that some way can be found to do it anyway if not.
>> The GEMDOS code of MiNT is XBRA linked to the original GEMDOS of single-TOS,
>> so it is easy to access that 'deeper' level if MiNT routines make trouble.
>> Let's experiment a bit with this, before we decide anything.
>
>Ok, but there is another problem popping up. Maybe it is none, I need to 
>do more investigation. I haven't opened ports via Fopen before. I believe 
>on systems with the U: device I can only Fopen the AUX: channel. These 
            ^^^^
            ||||

>systems include all but MiNT and MagiC based ones ! How do I open the 
>Midi port under, say, TOS 1.4 ? How do I open SERIAL2 and MODEM1 under 
>TOS 2.5 at the same time ? Maybe I find the answer inside the DEVICE-LIB 
>source ...

I'm feeling a bit confused right now.  Surely you must mean "without" rather
than "with" at the plase I've marked with "^^^^" above.
                                          "||||"

If so, I am afraid you may be right, though I suggest you ask Harun for advice
on this.  He explicitly says in his docs that no one should use "AUX:" anymore.

If he has no good ideas on this, I suggest we use Bconmap() to set AUX: to
the port we need and then call Fopen/Fclose (AUX:...) to open/close it.  This
should at least set up the port properly for use (eg: Serial2/LAN switch),
though it is not clear whether it will also reserve the port from other use.

BIOS I/O calls should not use the AUX: port number (1), but the modern port
number from the BCONMAP structure.  Thus it should be no problem using this
method to open several ports in a row, since we are not dependent on having
AUX: remain set to any of them.

If port reservation is not made, we have two obvious alternatives:

1: We ignore it, and make it the user's responsibility not to attempt using
   applications on ports that belong to STiK.  (I prefer this in such case.)

2: We make a small patch for GEMDOS which only affects Fopen, and which can
   therefore be a little bit simpler and faster than a multifunction patch.
   (But I really do not want to patch this at all.)

Naturally the above method will only be used in singletasking, or when
"U:\DEV\" is not available.  In MiNT/MagiX/MagiC, with U:\DEV\ available
we use Fopen/Fclose with the proper U:\DEV\portname string.

The use of Bconmap() on older systems is of course dependent on the use of
HSMODEM, since those systems (incl TOS 1.4) have no such function in the TOS.
This is no real problem though, since reliable flow control operation on
those TOS (or any except MagiC in fact) is only possible by using HSMODEM.

-------------------------------------------------------------------------
Regards:  Ronald Andersson                     mailto:dlanor@oden.se
                                               http://www.oden.se/~dlanor
-------------------------------------------------------------------------
