Info-Atari16 Digest Tue, 28 May 91 Volume 91 : Issue 299 Today's Topics: Atari 540ST Questions Atari Mortis (2 msgs) Atari TT AtariUser Magazine Bug in TT hardware? Fix for Neodesk print spooler IMG gormat (2 msgs) Mega STe Question (or Problems) Patches for TOS 1.4 Publishers (II) ST code or C source for uncompressing .hqx & .sit files: Wanted! ST User Virus! (2 msgs) TOS 1.4 bug? Welcome to the Info-Atari16 Digest. The configuration for the automatic cross-posting to/from Usenet is getting closer, but still getting thrashed out. Please send notifications about broken digests or bogus messages to Info-Atari16-Request@NAUCSE.CSE.NAU.EDU. Please send requests for un/subscription and other administrivia to Info-Atari16-Request, *NOT* Info-Atari16. Requests that go to the list instead of the moderators are likely to be lost or ignored. If you want to unsubscribe, and you're receiving the digest indirectly from someplace (usually a BITNET host) that redistributes it, please contact the redistributor, not us. ---------------------------------------------------------------------- Date: 29 May 91 00:57:55 GMT From: noao!asuvax!ncar!elroy.jpl.nasa.gov!swrinde!mips!apple!equinox!mammoth!takem_b@ arizona.edu (Brian Takemoto) Subject: Atari 540ST Questions To: Info-Atari16@naucse.cse.nau.edu In article spa@fct.unl.pt (Salvador Pinto Abreu) writes: >on 28 May 91 05:43:31 GMT, >mforget@ersys.edmonton.ab.ca (Michel Forget) said: > >>> 3) How good is the mouse system on the unit? > >> The mouse isn't bad at all. It has two buttons, and looks fairly good. >> It is a nice mouse, but there are third party mice available if you don't [stuff deleted] >I wonder which Atari mouse you're talking about. All Atari mice I've >used are the most dreadful rodents I've ever come across, second to >none, not even the "original" VAXstation-100 mouse (ever seen one of >these?) feels as bad. > [ more stuff deleted] I've seen good mice from Atari and still own (and swear by) my original Atari mouse which is at least a couple years old and has been HEAVILY used and abused by my brother playing Dungeon Master I and II. Keep in mind that this mouse was made in Japan and not country XYZZY. I do swear by MY mouse, but I have also seen others that were "most dreadful rodents"... I've found that the Japan mice keep good tracking, button touch, and feel with standard care and cleaning... I cannot say the same for most others. ------------------------------------------------------------------------------- takem_b@mammoth.unr.edu (or ?) ucbvax.berkley.edu!mammoth.unr.edu!takem_b #include /* unfriendly control codes with ascii self portrate */ Anything that can go wrona@x3%se Pnews: segmentation violation. core dumped. ------------------------------ Date: 28 May 91 18:01:43 GMT From: noao!ncar!elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!magnus.acs.oh io-state.edu!csn!boulder!horton.Colorado.EDU!chuj@arizona.edu (CHU JEFFREY) Subject: Atari Mortis To: Info-Atari16@naucse.cse.nau.edu In article <1111@stewart.UUCP> jerry@stewart.UUCP (Jerry Shekhel) writes: >saj@chinet.chi.il.us (Stephen Jacobs) writes: >> >>Sure enough, in selected applications, >>the TT beats the pants off anything based on an Intel chip. In a lot of >>other applications, it runs pretty much even with a 25 MHz 80486. And the >>price is in the 80386 range. >> > >Not to flame you or anything, but I seriously doubt all three claims. Perhaps >you could provide some numbers to substantiate them? I doubt it too, there was a demo of the TT here by an ATARI club, the representative said the TT 68030 was equal to a 386-20 machine and only 2 MIPS, I found this hard to believe since there was so much talk of it, I still think it does close to 8MIPS, but since there is so much people disagreeing with the performance of the TT, I don't know what the real MIPS on it. Also does anyone know how many MFLOPS the TT does? Like I said the TT is not equivalent to the i486 and probably not the new 386-40. The 386-33 is running 7.92 MIPS and the i486-25 is 11.1 MIPS. THIS IS NOT A FLAME (I am a ATARIAN and probably always will be) Jeff ------------------------------ Date: 29 May 91 01:20:24 GMT From: noao!ncar!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!sun-barr!ccut!wnoc-tyo-news! toumon!wucc!ytsuji@arizona.edu (Y.Tsuji) Subject: Atari Mortis To: Info-Atari16@naucse.cse.nau.edu It is really off the point talking about what is the _maximum_ MIPs of a 030 machine. TT is likely to be less than 2.0 MIPs. Even if the CPU got a vast cache memory, the access time to the actual DRAM is often the decisive factor. Good CPU boards usually have 80-ns-4-MEGAbit DRAMs and when successive addresses are accessed the Column Address Strobe is repeated, reducing the access time dramatically. If these modern techniques are missing, the instructions already on the cache memory may be executed very fast, but the overall performance will be deadly slow. I once used a 020 machine at 10 MHz but it was actually much slower than our ST because it had to be swapping memory to/from disks as it was a virtual memory machine! The actual performance can be measured only by using a typical application program on them: I think my ST at 8 MHz is fast enough for my need. Cheers, Tsuji ------------------------------ Date: 28 May 91 19:39:36 GMT From: IFI.UIO.NO!larserio@ucbvax.berkeley.edu (LarsErikOsterud) Subject: Atari TT To: Info-Atari16@naucse.cse.nau.edu Even in little Norway ALL developers (execpt me who has a MEGA STE) has a TT, even some users have TTs and MEGA STEs... Lars-Erik / ABK-BBS +47 2132659 / ____ ______ ________________________ Osterud / larserio@ifi.uio.no / /___ / The norwegian ST __________/ ______________________/ ____/ / Klubben, user association ------------------------------ Date: 28 May 91 21:55:27 GMT From: kodak!uupsi!dorsai!bigd@cs.rochester.edu (David Shapiro) Subject: AtariUser Magazine To: Info-Atari16@naucse.cse.nau.edu Can somebody mail to me an INTERNETable address of one of the editors at AtariUser Magazine? 8888888888888888888888888888888888888888888888888888888888888888888888888888 8 David Shapiro 8 The Gooey (GUI) BBS 8 8 bigd@dorsai.com 8 212-876-5885 9600 CSP 8 8 212-876-5885 9600 CSP (data) 8 Home of GUI-Net (tm) 8 8 R/O Routable at ->GOOEY on: 8 Home of the GUI BBS list 8 8 RIME (RelayNet), Intelec, MIDILink, GUI-Net 8 First NYC BBS with CSP 8 8 InterZone!, V-Net, TR'OL Works, NYNet, TRI-Net8 Since 12/90 8 8888888888888888888888888888888888888888888888888888888888888888888888888888 ------------------------------ Date: 28 May 91 13:02:52 GMT From: noao!ncar!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!news-server.csri.toronto.edu !utgpu!utzoo!lsuc!jimomura@arizona.edu (Jim Omura) Subject: Bug in TT hardware? To: Info-Atari16@naucse.cse.nau.edu In article <1991May27.101719.2923@rhrk.uni-kl.de> seimet@rhrk.uni-kl.de (Uwe Seimet [Chemie]) writes: > >Did anyone ever try to save the last four bytes of TT-RAM on the TT's >internal hard disk? This operation always fails because the scsi >controller reports a bus error. (You don't get any bombs, because it's >not a processor-related error. The hard disk driver simply aborts with >the usual alert.) >This problem doesn't seem to be driver dependant. It looks as if the >controller tries to access not only the last bytes of TT-RAM but some >bytes on higher adresses, too. Of course, at these adresses there is >no RAM, so this explains the bus error. If the last byte to transfer >lies at least four bytes below the end of the physical RAM everything >is fine. >Is there any reasonable explanation or is this some kind of hardware >bug? > It sounds like the 68030 has "pre-fetch" active. You can shut this off "manually". Check a 68030 instruction list. The only problem might be that the "pre-fetch" might be built into the driver and not over-rideable without writing your own driver. That's probably not going to be a problem, but I've never seen the code so I can't say. -- Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 lsuc!jimomura Byte Information eXchange: jimomura ------------------------------ Date: 29 May 91 02:53:14 GMT From: unccvax!cs00bd@mcnc.org (brian daniels) Subject: Fix for Neodesk print spooler To: Info-Atari16@naucse.cse.nau.edu Help! Has anyone posted the fix to the fix for the Neodesk print spooler acc? I saw some chatter about it a few weeks ago, but nothing since.... Thanks in advance, Brian -- --------------------------------------------------------------------------- Reality is what YOU make of it. Brian Daniels (cs00bd@unccvax.uncc.edu) "My opinions are mine and do not represent those of my host computer" --------------------------------------------------------------------------- ------------------------------ Date: 28 May 91 04:55:22 GMT From: noao!ncar!elroy.jpl.nasa.gov!swrinde!emory!ox.com!math.fu-berlin.de!unidui!unid o!mcshh!malihh!pfunk!blackbox@arizona.edu (Michael Kistenmacher) Subject: IMG gormat To: Info-Atari16@naucse.cse.nau.edu In , LarsErikOsterud writes: >Does anyone have an EASY TO UNDERSTAND description of the .IMG Gem bitmap >file format. I have written some scanner software but today I use the DEGAS Isn't the description of the IMG-format implementef in the monthly posted picture-format list ? Just a moment, i take a look..... --------------cut---------------- *.IMG 1 word version number of image file [1] 1 word length of header in words [usually 8] 1 word number of color planes [1 for monochrome] 1 word pattern length in bytes [1-8, usually 2 for screen images] 1 word pixel width in microns (1/1000 mm, 25400 microns per inch) 1 word pixel height in microns 1 word line width in pixels 1 word number of lines ------- ? words header length defined in 2nd word of header ? bytes data NOTES: If the image is a color image (planes > 1), the planes are stored separately starting with plane 0. There is, however, no standard way of storing the color palette. Some programs may save the palette in separate files, some may extend the header. For this reason, you should never assume the header is 8 words long, always get the header length from the 2nd word of the header. Also, the line width in the 7th word is the number of pixels in a line. Since the data is encoded in byte-wide packets, the actual unpacked line width is always a multiple of 8, and may be 1-7 pixels longer than the length specified in the header. For each byte x in the data section, x = 0 Pattern/scanline run. Read the next byte, n (unsigned). If n > 0 then: Read a number of bytes equal to the "pattern length" word in the header. Repeat this pattern n times. If n = 0 then: Scanline run. Data for the next scanline is to be used multiple times. Read the following record: 1 byte flag byte [$FF] 1 byte number of times to use next scanline data The data for the next scanline follows, compressed normally. x = 80 (hex) Uncompressed bit string. The next byte determines the number of bytes to use literally. The literal data bytes follow. otherwise Solid run. The value of x determines what to draw. The high bit specifies whether the pixels are set or cleared. A 1 indicates a byte-run using $FF, a 0 indicates a byte-run using $00. The low 7 bits, taken as an unsigned quantity, specify the length of the run in bytes. -------------end--------------- -- ------------------------------------------------------------------------------ | listen to the coolest ! | Michael Kistenmacher / blackbox | | Music from the Galaxy ! | 2000 Hamburg 61 / Schippelsweg 64 | | !!! P-Funk !!! | West Germany / ++ 49 40 552 37 66 | ------------------------------------------------------------------------------ ------------------------------ Date: 29 May 91 01:40:46 GMT From: noao!ncar!elroy.jpl.nasa.gov!swrinde!mips!atha!lsuc!jimomura@arizona.edu (Jim Omura) Subject: IMG gormat To: Info-Atari16@naucse.cse.nau.edu In article blackbox@pfunk.hanse.de writes: >In , LarsErikOsterud writes: >>Does anyone have an EASY TO UNDERSTAND description of the .IMG Gem bitmap >>file format. I have written some scanner software but today I use the DEGAS > >Isn't the description of the IMG-format implementef in the monthly posted >picture-format list ? Just a moment, i take a look..... > >--------------cut---------------- > > *.IMG > >1 word version number of image file [1] >1 word length of header in words [usually 8] >1 word number of color planes [1 for monochrome] >1 word pattern length in bytes [1-8, usually 2 for screen images] I've been meaning to ask this for a while now, and this seems like a good time. What is this "pattern length" all about? It can't be the length of the data bytes. That would be 32000 rather than 2. >1 word pixel width in microns (1/1000 mm, 25400 microns per inch) >1 word pixel height in microns Does most software actually take this into account for anything or can you leaave the pixel dimension 0? >1 word line width in pixels >1 word number of lines >------- >? words header length defined in 2nd word of header > >? bytes data > >NOTES: If the image is a color image (planes > 1), the planes are stored >separately starting with plane 0. There is, however, no standard way of >storing the color palette. Some programs may save the palette in separate >files, some may extend the header. For this reason, you should never >assume the header is 8 words long, always get the header length from the >2nd word of the header. Also, the line width in the 7th word is the number This is one of the reasons I'm making IFF/ILBM my main "supported file type". No matter how you feel about the Amiga/Atari/Mac wars, the IMG "standard" just isn't sufficiently defined and has not real underlying rational. I don't know if I would embrace the whole of the IFF standard -- it's really just a mish-mash. But the ILBM part is rational and practical. -- Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 lsuc!jimomura Byte Information eXchange: jimomura ------------------------------ Date: 28 May 91 19:46:35 GMT From: noao!ncar!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia .edu!ira.uka.de!fauern!faui43.informatik.uni-erlangen.de!csbrod@arizona.edu (Claus Brod) Subject: Mega STe Question (or Problems) To: Info-Atari16@naucse.cse.nau.edu ralph@laas.fr (Ralph P. Sobek) writes: >As just a reminder, there exists KILLDRV which turns off that darn >floppy disk light. It was either posted to USENET or is available >from atari.archive. Both source and binaries should be available: KILLDRV will just turn out the LED and not the floppy motor, right? ---------------------------------------------------------------------- Claus Brod, Am Felsenkeller 2, Things. Take. Time. D-8772 Marktheidenfeld, Germany (Piet Hein) csbrod@medusa.informatik.uni-erlangen.de Claus_Brod@wue.maus.de ---------------------------------------------------------------------- ------------------------------ Date: 28 May 91 18:34:02 GMT From: bloom-beacon!eru!hagbard!sunic!fuug!field!field!kimmo@ucbvax.berkeley.edu (Kimmo Lahtinen) Subject: Patches for TOS 1.4 To: Info-Atari16@naucse.cse.nau.edu Roger.Sheppard@actrix.gen.nz (Roger Sheppard) writes: >You don't need FolderFix with TOS 1.4. Actually you *need* sometimes Folderfix also with TOS 1.4. I noticed it when I was installing TeX 2.0. The installation documentation said that you will need a forderfix, and I did not believe it, so my installation was terminated on one point. There was very many files and folders, so the limit in TOS 1.4 might be higher, but there is a limit. But there was no corruption or other problems, so I added a folderfix to my ICD driver and continued instalation. >PinHead can help as it can be programed to clear memory that the OS. >does not clear, and from what I believe is faster than the OS. The main idea behind fastload bit and PinHead is that we do not zero whole memory before program load. By the way about the fast load bit. Some accessories do not behave well when it is on. >-- >Roger W. Sheppard 85 Donovan Rd, Kapiti New Zealand... -- Kimmo Lahtinen E-Mail : kimmo@field.fi or Finnish Meteorological Institute lahtinen@pouta.fmi.fi Phone : +358 0 758 1322 Possesed by a Spirit G3 Fax : +358 0 758 1396 ------------------------------ Date: 28 May 91 20:47:20 GMT From: noao!ncar!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!rpi!crdgw1!gecrd vm1!syspmzt@arizona.edu Subject: Publishers (II) To: Info-Atari16@naucse.cse.nau.edu In article <1991May22.021421.23656@lsuc.on.ca>, jimomura@lsuc.on.ca (Jim Omura) says: > > Ok. So now we know that STart may be gone from the North America >scene, and what's left is pretty much just a couple of "fanzine" >things. We'll hope that this improves. . . . >what is exactly the situation with "ST World"? Are they really >trying for a come-back? I thought the whole thing was sold to >"ST User"? If so, will they be accepting submissions for publication? >Is there a mailing address? > I always thought of "ST Format" as a games magazine, but I >bought the May '91 issue and it has coverage of desktop publishing >and the monthly disk has a bunch of programming utilities (admittedly >nothing new). That looks promising. > What's "ST User" been like lately? I haven't even seen it >around for about a half a year now, so I'm wary about sending anything >to them. Can I further the request, and ask what Atari magazine readers of the net find most useful? If possible, could someone post/send addresses for those magazines? I've been trying for 2 weeks to find any Atari magazine locally so that I could look at current mail order prices, and, since I just upgraded my machine, consider once again subscribing. In the large Capital District of NY I haven't been able to find so much as a game magazine that even mentions Atari on the cover! I know that STart is gone, but Amiga's have 3 serious magazines with available distribution around here; Atari has none. I'll probably end up subscribing because of this, but what's going on here? Phil Z ------------------------------ Date: 28 May 91 20:20:26 GMT From: fs7.ece.cmu.edu!o.gp.cs.cmu.edu!redmond@sei.cmu.edu (Redmond English) Subject: ST code or C source for uncompressing .hqx & .sit files: Wanted! To: Info-Atari16@naucse.cse.nau.edu I'd like to try converting some mac fonts to GDOS format, but all the ftp font archives have the mac fonts compressed using something that creates .sit and .hqx extensions. Does anybody know of any way I can uncompress these files on either my ST or a unix system (before down loading) ? Thanks in advance, Red/. ------------------------------ Date: 28 May 91 20:25:55 GMT From: noao!ncar!elroy.jpl.nasa.gov!usc!rpi!news-server.csri.toronto.edu!utgpu!utzoo!l suc!jimomura@arizona.edu (Jim Omura) Subject: ST User Virus! To: Info-Atari16@naucse.cse.nau.edu In article <10099@suns2.crosfield.co.uk> imt@crosfield.co.uk (ian taylor) writes: >(This is probably only of interest to UK netters, although I believe ST User >magazine is available internationally by mail order) > >Has anyone had problems with this months (June) ST User cover disk? >I think that there is a free virus included on the coverdisk, which mangled >the directory of two of my disks before I eradicated it. This is the second >time that ST User has done this, and frankly I am bloody unimpressed. Anyone >who's got this disk, beware. Having read this message I immediately checked a bunch of my floppies. I used a recent version of VKiller. I *did* find a virus, but I'm not certain it came from the June ST User disk. VKiller reported the "Green Goblin" virus. I'm not sure where this virus usually resides, but when I checked my June ST User disk VKiller reported no virus present. It didn't find a virus on any of 10 other disks I also checked. This brings to mind that 1 of the things I looked at from the Net recently was this "only_ste.lzh" sound demo package. Now this is a strange package with what seems to be a whole disk compressed into an ".MSA" file which in turn was LHARC'd. I unpacked this kit just this morning. When I unpacked the disk I used the MSA.PRG auto-formatting command. It seems to me that this method of packaging might allow for transporting of boot sector or other viruses. Has anybody else unpacked this demo kit recently? -- Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 lsuc!jimomura Byte Information eXchange: jimomura ------------------------------ Date: 29 May 91 01:21:48 GMT From: noao!ncar!elroy.jpl.nasa.gov!swrinde!mips!atha!lsuc!jimomura@arizona.edu (Jim Omura) Subject: ST User Virus! To: Info-Atari16@naucse.cse.nau.edu In article <1991May28.202555.16251@lsuc.on.ca> jimomura@lsuc.on.ca (Jim Omura) writes: >In article <10099@suns2.crosfield.co.uk> imt@crosfield.co.uk (ian taylor) writes: >>(This is probably only of interest to UK netters, although I believe ST User >>magazine is available internationally by mail order) >> >>Has anyone had problems with this months (June) ST User cover disk? >>I think that there is a free virus included on the coverdisk, which mangled >>the directory of two of my disks before I eradicated it. This is the second >>time that ST User has done this, and frankly I am bloody unimpressed. Anyone >>who's got this disk, beware. > > > Having read this message I immediately checked a bunch of my floppies. >I used a recent version of VKiller. I *did* find a virus, but I'm not >certain it came from the June ST User disk. > > VKiller reported the "Green Goblin" virus. I'm not sure where >this virus usually resides, but when I checked my June ST User disk >VKiller reported no virus present. It didn't find a virus on any of >10 other disks I also checked. This brings to mind that 1 of the things >I looked at from the Net recently was this "only_ste.lzh" sound >demo package. Now this is a strange package with what seems to >be a whole disk compressed into an ".MSA" file which in turn was >LHARC'd. I unpacked this kit just this morning. When I unpacked >the disk I used the MSA.PRG auto-formatting command. It seems to >me that this method of packaging might allow for transporting of >boot sector or other viruses. Has anybody else unpacked this demo >kit recently? >Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 I have now checked about 2/3 to 3/4 of all my floppies (a few hundred). I found viruses on 6 disks (including the one I reported earlier). The pattern of infection does NOT point to either the June 1991 ST User magazine disk, nor to the 'only_ste.lzh' file. Rather, it looks like I probably received an infected disk about a year ago. Luckily, it just never had much of a chance to spread on my disks. I won't go into why this is so. I have a fairly good st dumb luck. It's probably a good idea for everyone to check their disks anyway in case I'm wrong, but I don't think there's anything particular to worry about. >lsuc!jimomura >Byte Information eXchange: jimomura -- Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 lsuc!jimomura Byte Information eXchange: jimomura ------------------------------ Date: 24 May 91 20:45:38 GMT From: mcsun!ukc!axion!tharr!steveh@uunet.uu.net (Steve Hebditch) Subject: TOS 1.4 bug? To: Info-Atari16@naucse.cse.nau.edu In article <1991May23.154113.24096@cbnewsc.att.com> lincoln@cbnewsc.att.com (charles.e.lincoln) writes: >Every now and then when I double-click on a GEM application, >instead of running it, the desktop gives me the show/print/cancel >dialog box. When I click on cancel and double click on the >application again, it always runs normally the second time. There's a bug in the TOS 1.4 desktop that I've come across which prevents installed programs from running properly when the full name is 30 characters long. e.g. I've got Tempus installed so that clicking on any .MOD extender file runs it with that file. However, clicking on 'f:\modula2.sys\def\tqm\ vdi.mod' just gives the Show / Print / Cancel dialog instead. -- --- steveh%tharr.uucp@ukc.ac.uk Freebie usenet & 13 megs of Atari sox ---- ...ukc!axion!tharr!steveh Tharr: 0234 841503 ----- ------------------------------ End of Info-Atari16 Digest ******************************