To: stik@ON-Luebeck.DE
Subject: Re: [2] STIK: Some news                                                             


On Thu, 17 Oct 1996 09:41:53 Peter Rottengatter <perot wrote: 
>
>On Thu, 17 Oct 1996, Ronald Andersson wrote:
>
>> On Mon, 14 Oct 1996 13:33:49 Peter Rottengatter <perot wrote: 

----- snip ----->> >re: STiK events through KB buffer stuffing

>> Hmmm, I'm afraid I see many problems with this method, since there is no
>> telling what an ACC might do as a result of receiving what it must take
>> to be keyboard commands of the user.  The results could be disastrous.
>
>Any accessory must interpret the scancode anyway, and ignore scancodes 
>it does not know. That's why some unassigned scancode was suggested. 
>MagicMac for instance has scancodes no original Atari ever had ! An 
>accessory that had problems with the MU_KEYBD scheme would not work on 
>the Mac, and thus nowadays it would be considered bad programming.

In practice most software adapts to various national layouts as well as to the
actual hardware differences by considering only the ASCII value returned, and
thus ignoring the actual scancode completely.  The necessary exception to this
is of course those keys which have no ASCII counterpart (arrows etc.) which are
normally recognized by scancode only, ignoring the ASCII byte.

Those naturally _have_ to be adapted for Atari compatibility by low-level drivers
if they are to be recognized by standard Atari software at all, since most such
software is older than the extended keyboard implementations.


>So I think _this_ particular problem does not exist.

Sorry, but I cannot agree fully.
The problem does exist, but can be solved by careful code selection.


If this scheme is to be used at all it is important to decide on a single scancode
and ASCII code (NUL ?) combination to be used uniquely for this purpose.  Like you
say, some systems are not restricted to the original Atari scancodes, and we do
not want to have any unnecessary hardware dependencies in STiK.

The ASCII part should IMO be 'NUL', since that is what Atari traditionally used
to indicate non-ASCII keys, but the scancode will have to be selected by learning
what codes are already in use for extended keyboard systems to avoid conflicts.

This means that we must resist the temptation of using different codes for various
types of STiK events, or to handle different channels etc, since that would make
the risk of conflict with extended keyboard codes greater.  All such info must
be kept in STiK-defined structures and tested by each client/module to determine
what kind of STiK-event this pseudo-key represents.


In order to ensure that multiple channels can be handled correctly, each client
call requesting STiK events should pass a structure/array address to STiK, to be
used similar to how AES uses its I/O arrays.  The structure must include a flag
stating what type of STiK event is intended, which should always be pre-cleared
so that an APP can recognize that the event was for another channel.

The inability to ensure that keyboard data reaches the intended client also means
that it will be necessary to continue 'stuffing' the event code into the buffer,
until the intended recipient responds, and this is where we can hit a brick wall.

If an ACC (or other APP) is currently 'topped', it doesn't matter how much we
stuff the code into the buffer, because the intended client will _never_ get it.


I see no satisfactory solution to this problem at all, since we need to be able
to direct these events to multiple channel handlers, whereas AES only sends keys
to the single APP it regards as being 'topped'.

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