Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 91 Issue 299
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.91May28102551@alfa.fct.unl.pt> 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 <signature.h> /* 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 <CMM.0.90.2.675111152.larserio@kvart.ifi.uio.no>, 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----------------
<GEM Bit Image> *.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 <A0b64gka@pfunk.hanse.de> blackbox@pfunk.hanse.de writes:
>In <CMM.0.90.2.675111152.larserio@kvart.ifi.uio.no>, 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----------------
>
><GEM Bit Image> *.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
******************************
