[comp.sys.atari.st.tech] 1st Word Bug

steveh@tharr.UUCP (Steve Hamley) (01/10/91)

The First Word Plus looping keyboard problem struck me again this week.

To recap, this is different to the Phantom Typist, where events seem to
get delayed, but you can usually do enough to save your work and reset.
1WP is more usually afflicted by a problem where in the middle of typing
it repeats your last few characters several times and then bombs.


Way back last February...

grahamt@syma.sussex.ac.uk (Graham Thomas) wrote:

> GST say it's something inside TOS (or GEMDOS or whatever layer
> it might be), so I was rather hoping the problem might go away with TOS
> 1.4.


To which kbad@atari.UUCP (Ken Badertscher) replied:

> Now why doesn't that surprise me?  Not to bash GST, but I have found
> that a lot of problems similar to this are a result of bad programming
> practices.  Not intentional, but just because the developer wasn't
> aware of some restriction or another.  It's all too easy to blame TOS.

> I would like to know exactly how the GST products get their keyboard
> input, in gory detail.  *IF* I knew that, then I might be able to
> figure out what causes the problem.  I strongly suspect that the
> problem is caused by  mixing input modes between AES/VDI/GEMDOS/BIOS.
> That has been known to produce results like this.  If it is _not_ that,
> then there is a good chance that it _is_ a bug in TOS, and I want to
> fix it!!!


If you don't like the look of gore, please turn away :-) The following is
the output from the utterly brilliant SYS_MON of the central loop in 1WP,
with comments by me based on a little extra detective work with a low level 
debugger. It makes interesting reading, but as to whether the way 1WP works 
causes this problem...

My copy of 1WP is version 3.14. The problem occurs in all ST versions of
TOS.


*****************************************************************
*
* This file was created by SYS_MON, the ATARI ST System Monitor,
* copyright by Karsten Isakovic, Berlin
*
* It is forbidden to publish this file or extracts of it without
* the copyright header !
*
* Return  Program Func     Stack    Function     Arguments
*   addr     name   no      addr        name

 $0BFEA4 WORDPLUS A_25   $0CF314  evnt_multi     KYBD BUT { 2,1,1 } M1 { leave
                                                 (567,48 ) (1  ,1  ) } MSG
                                                 TIMER  { 200,0 } Buf $0CD3BE
                                                 -> (567,48 ) B$00 K$00 Key
                                                 $3920 But $00 Event = MU_KYBD
* Waiting for a keyboard event, button event, leaving the current mouse
* position (so can turn the cursor back on, when disabled whilst typing), a
* message event, a time event (for flashing the cursor on and off).
* This particular event has returned a keypress for us to analyse.

 $0BFEA4 WORDPLUS A_107  $0CF346  wind_update    BEG_UPDATE -> 1
* Stop AES interfering whilst updating screen.

 $0BA26C WORDPLUS X_38   $0CF360  Supexec        CODE $0AA9D6 ->
* Disables the key repeat by making a supervisor mode call to a routine which 
* clears bit 1 of system variable $484, conterm. This seems to be so so you 
* can't enter keypresses faster than they can be processed. (You know the 
* problem, repeat a command key too long and you sit around waiting for the 
* screen to catch up.)

 $0BFEA4 WORDPLUS A_104  $0CF32C  wind_get       H 1 TOP   -> 1
 $0BFEA4 WORDPLUS A_79   $0CF330  graf_mkstat    -> (567,48 ) But $00 Key
                                                 $0000
 $0BFEA4 WORDPLUS A_104  $0CF2C2  wind_get       H 1 TOP   -> 1

* [Various VDI calls to update the screen deleted]

 $0BFEA4 WORDPLUS A_24   $0CF34C  evnt_timer     0,0-> 0
* Erm... Another event call?

 $0AA968 WORDPLUS B_11   $0CF356  Kbshift        Mode -1->  NoState
* Get the keyboard state. Presumably to get at bit 4 to test if Caps Lock has
* been altered, so can update the on-screen button.

 $0BFEA4 WORDPLUS A_107  $0CF346  wind_update    END_UPDATE -> 1
* Let AES attack the menus once more.

 $0BA26C WORDPLUS X_38   $0CF360  Supexec        CODE $0AA9CC ->
* Re-enable the key repeat.

* [Into another evnt_multi]
*
* End of SYS_MON file.
*****************************************************************


Comments anyone?

csbrod@informatik.uni-erlangen.de (Claus Brod (turo)) (01/10/91)

steveh@tharr.UUCP (Steve Hamley) writes:
>*****************************************************************
>*
>* This file was created by SYS_MON, the ATARI ST System Monitor,
>* copyright by Karsten Isakovic, Berlin
>*
>* It is forbidden to publish this file or extracts of it without
>* the copyright header !
>*
>* Return  Program Func     Stack    Function     Arguments
>*   addr     name   no      addr        name

> $0BA26C WORDPLUS X_38   $0CF360  Supexec        CODE $0AA9D6 ->
>* Disables the key repeat by making a supervisor mode call to a routine which 
>* clears bit 1 of system variable $484, conterm. This seems to be so so you 
>* can't enter keypresses faster than they can be processed. (You know the 
>* problem, repeat a command key too long and you sit around waiting for the 
>* screen to catch up.)

This is the only practical way to avoid this problem properly. I do
the same in an editor routine of mine. I _know_ that it is not OK
to do this as you are struggling with AES and XBIOS keyboard routines
at the same time, but there seems to be no better way, and it
works with all available TOS versions.

If someone out there (maybe @atari) knows some better way to handle
this, please let me know. We are not satisfied with this solution,
but it's the best we could find so far.

Apart from that, I really think the phantom typist is a TOS bug.
It occurs in many programs, not only in WPLUS. Some friend of
mine told me at the last Atari fair in Duesseldorf that he
thought he had found the reason for it, and that it lies in
an internal TOS routine that is responsible for some keyboard
functions. It is not only called as a normal subroutine but also
from an interrupt, and it is not properly guarded to avoid
problems when the interrupt occurs while the main program is
in this routine at the same moment. A description of this has
been sent to Atari US (to Ken Badertscher, to be exact), as
I have been told. So maybe Ken knows more about it now and can
shed some light on it?


----------------------------------------------------------------------
Claus Brod, Am Felsenkeller 2,			Things. Take. Time.
D-8772 Marktheidenfeld, West Germany		(Piet Hein)
csbrod@medusa.informatik.uni-erlangen.de
----------------------------------------------------------------------