051332@UOTTAWA.BITNET (05/08/87)
Received: by UOTTAWA (Mailer X1.23b) id 9249; Fri, 08 May 87 12:14:04 EDT Date: Fri, 08 May 87 12:09:20 EDT From: John Turnbull <051332@UOTTAWA> Subject: Bug report: 'The Russian Doll' sp. nova (?) To: INFO-ATARI16@SCORE.STANFORD.EDU I don't know if this is a new species of bug, or one of the known ones in a new morph ... The System: Monochrome (SM124) 1040STF and a NECP6 printer The disks: SSDD Maxels formatted to DSDD with David Small & Dan Moore's TWISTER with the net mods (82 tracks) The AUTO folder: John Franco's ETERNAL2.PRG dated 1/30/87 anon. VEROFF.PRG (this is the VEROFF half of VEROFFON.UUE from ATARINET) M.R. Singer's TIMEDATE.PRG V1.0 10/25/85 What I did: I was making up the masters for the DISK(s)-OF-THE-MONTH for the OTTAWA ST users group (NCAUG), uudecoding and de-arching goodies from ATARINET, and PROG-A16, and filing the ARCs and the .PRGs on separate disks from the ramdisk. The ARCs went on strait, but the .PRGs, .DOCs, et als were put in folders. (I must have created several dozen folders and copied them hither and yon during the session.) I 'discovered' that there was no need (or did not seem to be) to change the directory in the A window to copy from the RAM disk. I would make a copy of a .UUE file to the RAM disk, UUDECODE it, (UUDECODE.TTP from CANADA01), de-ARC it, and while ARC was still stuck in ... hit any key ... remove the .UUE disk, and put in the .ARC disk, then hit any key. BINGO, there is the ..ARC directory. Point to the .ARC, drag and copy into A. THEN make a .ARC directory. Point to the .ARC, drag and copy into A. THEN make a new folder in D, copy the .PRGs, .DOCs, and things to the folder, and pull out the .ARC disk, and put in the folder disk (NOTE: I have not left the D directory, and the quiet A directory still reads the .ARC directory). Then point to the new folder, click, drag, whizz-whizz- blink, and the A directory reads the contents of the FOLDER disk with the new folder! (look, I've saved several point-ESC cycles. At 3 in the morning, that seemed important!) What it did: Everything looked OK. If I put the FOLDER disk into the drive and hit ESC I got the FOLDER disk directory, but if I pointed to a folder and double-clicked to open it ... whizz-whizz-blink ... I got the same directory. All the folders 'THOUGHT' they had all the other folders inside them! (hence the name Russian Doll). If I did a show info on a folder, I got No. of Fol: 0; No of ITEMS: 0; and Bytes used: 0. Now if I closed the window and reopened it all was well. Show info did the normal thing and I could read and copy files. Questions: 1) is this new? (can I name it) 2) is it the 40 folder thing? ... and what are the symptoms 3) is it the underscore thing? (did I neglect to mention that I use _underscores_a_lot in filenames, and folders? I've never been burned before.) 4) is there some incompatibility in the programs that I used? 5) is there a TROGEN-HORSE on ATARINET or PROG-A16? (this beast seems to be infectious, the copies all have it). I could not resist testing some of the new thing just to see what they did. 6) is the procedure that I described above expressly prohibited on pg1 of the ST owner's manual? Any help or explanations would be appreciated. Thanks in advance. /JT John Turnbull, NETNORTH: 051332@UOTTAWA 30 Somerset Ave, BITNET: 051332@UOTTAWA Dept. of Biology, ARPANET: 051332%UOTTAWA.BITNET@WISCVM.WISC.EDU Univ. of Ottawa, uucp: ...!psuvax1!051332%uotawa.BITNET Ottawa, Ontario, JANET: 051332%uottawa@rl.earn CANADA, K1N 6N5. ICBM: 45 25' 33'' N 75 39' 05'' W
jmberkley@watmath.UUCP (05/09/87)
In article<8705081618.AA15013@ucbvax.Berkeley.EDU>051332@UOTTAWA.BITNET writes: >Date: Fri, 08 May 87 12:09:20 EDT >From: John Turnbull <051332@UOTTAWA> > >The System: >Monochrome (SM124) 1040STF and a NECP6 printer > >The disks: >SSDD Maxels formatted to DSDD with David Small & Dan Moore's TWISTER >with the net mods (82 tracks) I had some similar problems, but the best answer I could come up with was that the problem was in twister or in the quality of my floppy disks (SSDD Maxell's formatted to DSDD), not in my Atari. As soon as I got twister, I decided to change my heavily used disks over to a twister format. That worked OK, or at least it seemed to work OK. There were no errors from anything. However, after the dust had settled, most of my ARC'd files and some of my program files were corrupted! Whenever I copied a folder as a folder, individual files would be corrrupted. Whenever I opened the folder (and the destination folder) and then copied the files en-masse, things were fine. 'twould be nice if someone could tell me what happened and how to fix it. I really like using twister formatted disks (Uniterm loads up much, much faster :-) but have the uneasy feeling of impending doom. Kindly advice about buying better quality diskettes, etc., will be ignored - I'm an impoverished student after all :-) Mike Berkley, University of Waterloo ************************************************************************ *** Reply directly to this address, not to the address in the header *** * * *UUCP: {allegra,ihnp4,utcsri,utzoo}!watmath!watsup!mberkley * *Bitnet: mberkley@watdcs.BITNET * * * ************************************************************************
bammi@cwruecmp.UUCP (Jwahar R. Bammi) (05/10/87)
In article <8705081618.AA15013@ucbvax.Berkeley.EDU> 051332@UOTTAWA.BITNET writes: >Questions: >1) is this new? (can I name it) >2) is it the 40 folder thing? ... and what are the symptoms >3) is it the underscore thing? (did I neglect to mention that I use >4) is there some incompatibility in the programs that I used? >5) is there a TROGEN-HORSE on ATARINET or PROG-A16? (this beast seems >6) is the procedure that I described above expressly prohibited on pg1 It is NONE of the above. It is due to the short-cut you took. You absolutely have to do the point-ESC step, otherwise gemdos does'nt log in the new disk. The simple solution to this problem is to use a decent shell (like the one that we will be posting soon to the net -- plug plug). -- usenet: {decvax,cbatt,cbosgd,sun}!cwruecmp!bammi jwahar r. bammi csnet: bammi@case arpa: bammi%case@csnet-relay compuServe: 71515,155
braner@batcomputer.tn.cornell.edu (braner) (05/10/87)
[] If you create lots of folders anywhere (e.g. RAMdisk) you're in the 40-folders-bug's den. Watch out! (This is due to TOS keeping info about folders in a finite-size area.) If you access the same few folders repeatedly you are also courting disaster! (This is due to TOS creating multiple copies of info about the same folders (a bug that I consider separate from the 40-folders bug), and then the finite space...). You're safe if you remove the media periodically - but what about the RAMdisk (or Harddisk)? I've written a program (called 'Uproot') that forces TOS to believe the media has been changed on a specified drive. I hope it will be posted soon on comp.*.atari.st (it's "in the queue"). E-mail me if you're desperate. - Moshe Braner
pes@ux63.bath.ac.uk (Paul Smee) (05/11/87)
Sorry, I'm having a bit of trouble following your description, but I'll make a guess anyway. (While I don't believe I've seen any warnings about it in the Atari manual --mine's antique anyway, so probably not definitive -- it is true that) If you copy something from somewhere to drive <x> (for any <x>) and you have a window open on the screen which the system thinks is a folder (or the top level of) drive <x>, and that window does *not* in fact refer to (was not derived from) the actual disk which is presently really in drive <x>, then you're likely to get into all sorts of trouble. Sound like that could be your problem?
john@viper.UUCP (05/11/87)
In article <8705081618.AA15013@ucbvax.Berkeley.EDU> 051332@UOTTAWA.BITNET writes: >The disks: >SSDD Maxels formatted to DSDD with David Small & Dan Moore's TWISTER >with the net mods (82 tracks) The problem is with the original version of TWISTER. If you swap a twister formatted disk for another twister formatted disk, the desktop has problems detecting the change. The example you gave of clicking on a folder and having the same directory appear is a symptom. (Note: if you click on the folder a second time, the desktop will correctly open the folder and all is fine...) The problems you are having are partialy in the TWISTER and partialy your own falt for using the short cuts you were using,, (Although you would have found things to work differently if you were not using TWISTER disks so it's not really your falt :) The solution is to run-not-walk to your local CI$ node and check in the atari16 conference in the utilitys (I think) file area. There you will find a new version (Version 1.1) of twister called TWISTE.PRG. This version solves the problems in the original version. I've been using it for a couple of weeks and am -very- happy with the results. PS: I'd love to send the upgrade via the net, but I can't because the program is copyrited so please don't ask... (I imagine there will be an upgrade sent out in a future issue of the magazine, but I don't know for sure. They placed it on CompuServe as a courtesy to readers who were having problems, but with the stipulation that it not be distributed thru any other media...) --- John Stanley (john@viper.UUCP) Software Consultant - DynaSoft Systems UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john
dclemans@mntgfx.MENTOR.COM (Dave Clemans) (05/12/87)
There is a bug in the floppy driver in the current TOS ROM's that can very easily cause symptoms like those described in the article that this message references. Basically, the problem is that while the WD1772 floppy controller does have a built-in read multiple sectors command, that command is somewhat brain damaged; the only official way to terminate the read is to reset the controller (and taking any time hit that that reset causes). However, if you look at the floppy disk driver code you find that the driver is using the "read multiple sectors" command of the 1772 for all (all that I've found so far at least) floppy reads. And under "normal" circumstances the driver tries to never reset the controller; i.e. it puts the read length into the DMA controller, and depends on the floppy controller timing out because the DMA controller stops talking to it. This works "most" of the time... But if your really trying to push data through the system "fast" you have a non-zero chance of seeing a timing problem pop up. This problem does not affect floppy writes; only floppy reads. The best way to work around it, and still use "fast" formats, is to write the disk in whatever way you desire, but NEVER try to read more than one sector at a time (or to start out reading multiple sectors, but switch to single sectors if an error appears). An example of this is the "slowread" routine in the twister restore code. Unfortunately you don't always have control over the sizes of read requests made by various packages... dgc