grahamt@syma.sussex.ac.uk (Graham Thomas) (01/31/90)
From article <22199@mimsy.umd.edu>, by bane@mimsy.umd.edu (John R. Bane): > The dreaded keyboard-repeat-and-lock crash bug is apparently not gone in TOS > 1.4. For those of you who haven't seen it before, what happens is after > several minutes of fairly steady typing in an editor (I use Word Writer), > the keyboard suddenly starts slowly retyping the last seven or so keys you > typed, over and over again. After about 10 repeats, your program crashes. > This is similar to various bugs which many people have encountered with First Word Plus. (No coincidence, probably. I understand that both Word Writer and First Word Plus were written by the same outfit - GST in the UK.) We used to get the 'repeat then crash' a lot with Wordplus v2. With UK version v3.14 we now mostly get a simple freeze - the program just seems to stop accepting keyboard & mouse input, and the only way out is to reboot. 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. Does anyone have any information on what the problem might be? It's frustrating, because there doesn't seem to be any way of replicating the problem. People can go for months without it striking, and then have it happen twice in a day. (Sunspots??? :-) ) For what it's worth, it hasn't happened to me so often since I installed Turbo ST (the software blitter, not the acceleration board Turbo 16), but it has happened a couple of times. It has happened to a wide range of people where I work, from techies to novices, from hunt 'n peckers to touch typists. Does anyone know of other programs where similar things happen? I recall some messages a while ago about WordPerfect hanging, but ours has been OK. I'm waiting for the bug to strike while I'm running Wordplus from within NeoDesk, so I can try sending a few wind_update() calls. Would this do any good? Thanks, Graham -- Graham Thomas, SPRU, Mantell Building, U of Sussex, Brighton, BN1 9RF, UK JANET: grahamt@uk.ac.sussex.syma EARN/BITNET: grahamt@syma.sussex.ac.uk ARPA: grahamt%syma.sussex.ac.uk@nsfnet-relay.ac.uk UUCP: grahamt@syma.uucp Phone: +44 273 686758
kbad@atari.UUCP (Ken Badertscher) (02/02/90)
grahamt@syma.sussex.ac.uk (Graham Thomas) writes: | 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. 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!!! | People can go for months without it striking, and then have it | happen twice in a day. (Sunspots??? :-) ) Yep, sounds a lot like the ol' cosmic rays. It is really unfortunate that this particular bug is not easily reproducible. Of course, if it were, it would probably have been fixed long ago... :-/ | I'm waiting for the bug to strike while I'm running Wordplus from within | NeoDesk, so I can try sending a few wind_update() calls. Would this do | any good? While you're at it, don't forget to sprinkle the chicken's blood on the keyboard and dance about, chanting at the monitor. -- ||| Ken Badertscher (ames!atari!kbad) ||| Atari R&D System Software Engine / | \ #include <disclaimer>
goldstein@carafe.enet.dec.com (Fred R. Goldstein) (02/02/90)
In article <2015@atari.UUCP>, kbad@atari.UUCP (Ken Badertscher) writes... >grahamt@syma.sussex.ac.uk (Graham Thomas) writes: > >| 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. > >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. ... no fair, Ken, it's not GST's problem. About a year ago I posted this same problem with Word Perfect Atari. It too drops into "slow mode" now and then, when it eats up the keyboard buffer about one key every few seconds, treats the screen as if the mouse button were stuck down, and if you're lucky lets you (slowly!) request a save before you have to reboot. Word Perfect Corp. says it's a problem with TOS. The net-consensus was that it's a problem with TOS. It occurs in numerous GEM programs, such as Word Perfect and 1ST_WORD+. It is VERY frustrating, and is one of the main reasons I bought a PClone recently! MS-DOSs eats it raw but at least it gets debugged. It takes maybe half an hour to an hour running Word Perfect to get the bug, though I'm sure it would take a lot longer if somebody were trying to debug it... Now would anyone from Atari like to try to FIX it? >While you're at it, don't forget to sprinkle the chicken's blood on the >keyboard and dance about, chanting at the monitor. Funny, Ken, but that does seem to be about the right way to keep an application running on the ST! --- Fred R. Goldstein goldstein@carafe.enet.dec.com or goldstein@delni.enet.dec.com voice: +1 508 486 7388 (Opinions are the author's own. Sharing requires permission.)
bright@ccu.umanitoba.ca (Bob Bright) (02/07/90)
In article <8040@shlump.nac.dec.com> goldstein@carafe.enet.dec.com (Fred R. Goldstein) writes: > >In article <2015@atari.UUCP>, kbad@atari.UUCP (Ken Badertscher) writes... >>grahamt@syma.sussex.ac.uk (Graham Thomas) writes: >> >>| 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. >> >>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. > ... >no fair, Ken, it's not GST's problem. > >About a year ago I posted this same problem with Word Perfect Atari. >It too drops into "slow mode" now and then, when it eats up the keyboard >buffer about one key every few seconds, treats the screen as if the >mouse button were stuck down, and if you're lucky lets you (slowly!) >request a save before you have to reboot. Just so; this is _definitely_ not a problem restricted to GST products. As Fred goes on to note, WP Corp. has been aware of The Problem for a long time; they claim that Atari Corp. has been uncooperative in helping them track down its source. Whatever; fact is, there's a real problem here, it's a royal pain in the *ss, and whether or not it's a bug in TOS is not entirely relevant. If it is a bug in TOS, then you as well as us should be interested in getting it fixed as soon as possible (another patch?; at any rate a fix for TOS 1.8). If on the other hand it really is a matter of developers breaking rules, you should be interested in identifying the rule or rules in question and warning developers of the consequences of breaking them as soon as possible. Apparently WP Corp. and GST are under the mistaken impression that they're not doing anything wrong, which is making my life miserable, not to mention harming their sales and ultimately Atari's. Fortunately, The Problem hasn't hit me in WP for a couple of weeks (even without the chicken blood and incantations :-). Prior to that it seemed like I was getting bitten every other day or so. I don't have any more of a clue than anyone else about how to replicate it, but for what it's worth, I've noticed that The Problem is not unconnected with mouse movement. I.e.: If I catch it before it gets out of hand (after the machine has started to crawl, but before it locks up completely), I can save my file and exit WP by moving the mouse slightly after each key press. Here's the scenario: 1. Machine slows to a crawl; keystrokes and mouseclicks have an effect only seconds after a key is pushed or button clicked. 2. I hit F7 ("Exit"). Nothing happens. 3. I move mouse slightly. "Save file?" dialogue pops us instantly. 4. I respond with "y". Nothing happens. 5. I move mouse slightly. File is saved, and "Exit?" dialogue pops up. 6. I respond with "y". Nothing happens... etc. Does this behaviour suggest anything to anyone? BBB -- Bob Bright <bright@ccu.umanitoba.ca> Dept. of Philosophy University of Manitoba Winnipeg, Man R3T 2N2 (204) 474-9680
phoenix@ms.uky.edu (R'ykandar Korra'ti) (02/09/90)
In article <1990Feb6.174024.13984@ccu.umanitoba.ca> bright@ccu.UManitoba.CA (Bob Bright) writes: >1. Machine slows to a crawl; keystrokes and mouseclicks have an effect > only seconds after a key is pushed or button clicked. >2. I hit F7 ("Exit"). Nothing happens. >3. I move mouse slightly. "Save file?" dialogue pops us instantly. >4. I respond with "y". Nothing happens. >5. I move mouse slightly. File is saved, and "Exit?" dialogue pops > up. >6. I respond with "y". Nothing happens... etc. >Does this behaviour suggest anything to anyone? >Bob Bright <bright@ccu.umanitoba.ca> Uh... Yeah! Actually, it does, and I don't even own an ST. (SO please: if my idea is completely off base, sorry for the bandwidth. Please don't bother with flames.) I had a lockup problem not entirely dissimilar with one of my Amiga systems a while ago, only the "fix" was to pop _any_ diskette out and back in. The problem turned out to be not software, but a bad CIA chip (Complex Interface Adaptor; chip that converted disk, serial, keyboard etc output into something the processor could handle; i.e. an I/O chip) that was sending noise on the signal lines. Replacing it fixed the problem. So here's the question: could this be a similar situation, caused by excessive RF interference or a bad run of chips? Somebody out there who likes taking apart their ST systems might want to try improvising with additional (and removing - see if it happens more) shielding. - R'ykandar. -- | R'ykandar Korra'ti, Editor, LOW ORBIT | phoenix@ms.uky.edu | CIS 72406,370 | | Elfinkind, Unite! | phoenix@ukma.bitnet | PLink: Skywise | QLink: Bearclaw |
csbrod@medusa.informatik.uni-erlangen.de (Claus Brod ) (02/12/90)
grahamt@syma.sussex.ac.uk (Graham Thomas) writes: >From article <22199@mimsy.umd.edu>, by bane@mimsy.umd.edu (John R. Bane): >> The dreaded keyboard-repeat-and-lock crash bug is apparently not gone in TOS >> 1.4. For those of you who haven't seen it before, what happens is after >> several minutes of fairly steady typing in an editor (I use Word Writer), >> the keyboard suddenly starts slowly retyping the last seven or so keys you >> typed, over and over again. After about 10 repeats, your program crashes. >> >This is similar to various bugs which many people have encountered with >First Word Plus. (No coincidence, probably. I understand that both >Word Writer and First Word Plus were written by the same outfit - GST in >the UK.) The bug also occurs in TEMPUS 2.0, so it's not a proprietary GST bug. It must be a quirk in AES; I don't think it's located in GEMDOS or lower- level routines for they are documented very well here in Germany, and someone would have come across the bug if it's been in GEMDOS or BIOS. Since we have recompiled GEMDOS and BIOS source code, but no AES and VDI source code, the only people to solve the problem are ATARI US. I once read a msg related to this problem that stated that you could escape the deadly repetition of the last few keys by pressing a combination of SHIFT, CONTROL and ALT keys. This allows for quick saving before system breakdown. Claus Brod (sorry, I can not be reached here, but I can read public replies)
bammi@dsrgsun.ces.CWRU.Edu (Jwahar R. Bammi) (02/14/90)
In article <2420@medusa.informatik.uni-erlangen.de> csbrod@medusa.informatik.uni-erlangen.de (Claus Brod ) writes: > Since we have recompiled GEMDOS and BIOS source code, but no AES and > VDI source code, the only people to solve the problem are ATARI US. > Who is "we". the reason i ask is that atariUS is refusing to distribute source code for gemdos/bios here like they used to with the developer kit. i am curious if atari germany if distributing it to developers there. -- -- bang: {any internet host}!dsrgsun.ces.CWRU.edu!bammi jwahar r. bammi domain: bammi@dsrgsun.ces.CWRU.edu GEnie: J.Bammi
hafer@tubsibr.uucp (Udo Hafermann) (02/14/90)
csbrod@medusa.informatik.uni-erlangen.de (Claus Brod ) writes: >The bug also occurs in TEMPUS 2.0, so it's not a proprietary GST bug. Add Calamus to the list. Calamus likes to crash for all sorts of reasons, but yesterday it definitely was the phantom typist. (Including the effect that you had to move the mouse slightly to get the system to react to keys and/or menu selections.)
csbrod@medusa.informatik.uni-erlangen.de (Claus Brod ) (02/16/90)
bammi@dsrgsun.ces.CWRU.Edu (Jwahar R. Bammi) writes: >> Since we have recompiled GEMDOS and BIOS source code, but no AES and >> VDI source code, the only people to solve the problem are ATARI US. >> > Who is "we". the reason i ask is that atariUS is refusing to >distribute source code for gemdos/bios here like they used to with the >developer kit. i am curious if atari germany if distributing it to >developers there. "We" means: There are some German ST users who delved into GEMDOS and BIOS very very deeply. Among them are Alex Esser, the author of a series of articles on GEMDOS in the German magazine "ST-Computer" (can be reached via FIDO), and Andreas Kraemer, author of a book called "TOS intern". In this book you'll find a completely recompiled listing of GEMDOS (taken from TOS 1.2). The book has quite a few bugs, but it serves well to gain some general insight in the workings and in the failings of GEMDOS. It is available from Heise Verlag, Hannover. (If you are interested, I can find out the complete address.) I know that some other German hackers have extracted parts of GEMDOS, some others have done the same for VDI and AES but this work is not completed yet. BIOS source code is available since 1985 as commented disassembler listings in severals books here in Germany. ATARI Germany definitely doesn't distribute any GEMDOS source code. Claus Brod
csbrod@medusa.informatik.uni-erlangen.de (Claus Brod ) (02/16/90)
hafer@tubsibr.uucp (Udo Hafermann) writes: >Add Calamus to the list. Calamus likes to crash for all sorts of >reasons, but yesterday it definitely was the phantom typist. (Including >the effect that you had to move the mouse slightly to get the system >to react to keys and/or menu selections.) Has anybody tried to push some of the SHIFT/CTRL/ALT keys when the phantom typist shows up? Somebody wrote somewhere that this might prevent the application from crashing so that you can save your work before system breakdown. Claus Brod