HDTenEightyP/NetNews huggingface dataset:
From: hutch@bellman.lanl.gov (John Hutchinson)
Subject: Re: FontGDOS WORKS!!!
Reply-To: hutch@bellman.lanl.gov
Organization: Los Alamos National Laboratory
Date: Thu, 27 Aug 1992 14:06:22 GMT

>In article <1992Aug26.160453.9574@pbhya.PacBell.COM> dbsuthe@pbhya.PacBell.COM
>(Daniel B. Suthers) writes (WRT FontGDOS):
>>Thank you, Atari, for releasing it as freeware. It makes my whole system much
>>more usable.  Now how about a quick note concerning the policy that it ONLY
>>be available from GEnie? (I can think of several good reasons, but I would
>>like Atari's)

Well, as I understand it, there was a 30 day restriction in regards to the
GEnie upload of FGDOS; in that period the files could not be posted anywhere
else but on GEnie.  Atari has taken a lot of flak over this policy but heck,
GEnie _is_ their official online service, ya know.  Besides, the 30 days is
up now, I'm sure, so it should be free for uploading to any public BBS.
---

___________________________ John "HUTCH" Hutchinson _________________________
_________________ Fair Dinkum Technologies     Member - IAAD  _______________
________________ "No worries, mate... it's from Fair Dinkum!" _______________
____________ email: hutch@bellman.lanl.gov   GEnie: FAIR-DINKUM _____________
Newsgroups: comp.sys.atari.st
Subject: Two questions..... (Power supply and color printing)
From: rlcollins@miavx1.acs.muohio.edu (Ryan 'Gozar' Collins)
Date: 25 Aug 92 15:24:08 -0500
Organization: Miami University Academic Computer Service"

     Two questions:

     1. My power supply died in my 1040 last year. Since then I've been
using an old PC ps, but the case has been off because. Does anyone know
of a cheap replacement? A replacement PS costs $65!!

     2. I've recently acquired a Dataproducts 1070 printer, which is Old
Epson and supposedly Epson JX-80 (color) compatable. What I would like
to know if there is any software out there that I could try to print in
color.

     Thanks!!!!!!!!!!

Later.......

------======={{{{{{{{((((((Ryan 'Gozar' Collins))))))))}}}}}}}}=======--------
"You can give her the usual		     rlcollins@miavx1.acs.muohio.edu
things: candy, flowers, promises 	      RC1DSANU@miamiu.acs.muohio.edu
you don't intend to keep."		      rcollins@apsvax.aps.muohio.edu
  -Cogsworth	 			      R.COLLINS1 on GEnie
(Beauty and the Beast)
	------======={{{{{{{{(((((())))))))}}}}}}}}=======--------
From: kjohnson@castor.cs.uga.edu (Kristopher Johnson)
Newsgroups: comp.sys.atari.st
Subject: Re: Falcon Graphics
Date: 31 Aug 92 11:37:14 GMT
Organization: University of Georgia, Athens

In article <10056@uqcspe.cs.uq.oz.au> warwick@cs.uq.oz.au writes:
>Dirk_Steins@k2.maus.de (Dirk Steins) writes:
>
>>k>Surprise!!!  The new AES that comes with MultiTOS not only has a new 3D
>>k>look to it, but it also allows icons to have up to 256 colors.
>
>>If you like you can have more than 256 colors in an icon. The new color icon
>>format supports up to 32767 planes in an icon. I think that should be enough
>
>
>When will Atari learn! Do they honestly think that 707730515522477394500
>776513872475800674065355736194083617192874136183317120422626798012678238
>324207537737936480828063246194904289772368924440969148125436595871963896
> ... 70 or so lines deleted ...
>627802009883170745594257184899273240365464850145512525265114388470616872
>059968021225958035827644544140839818914844082091399072651760361687603175
>939138924687191385405495674658146609121381363052314008413497903877056133
>4052316856188928 colours is truly enough in the real world?
>
>
>But seriously, surely 256 bitplanes would have been sufficient - giving
>a measly 115792089237316195423570985008687907853269984665640564039457584
>007913129639936 colours.  But then again, I'd rather deal with int's than
>unsigned char's.
>
>
>Or is the format 32767 COLOURS, rather than bitplanes?
>

Wow!  I found out on GEnie from Atari that the new icons can not only be
very colorful (or colourful for you Europeans out there), but they can 
also be ANIMATED.  Yes, ANIMATED icons as a standard feature.  I think
they may have taken it too far this time. <grin>

Also mentioned from Atari is that they showed a direct-to-disk stereo 
16-bit digital sampling software packaged called "D2D" (cute, huh?) at
the show which includes sample editing functions.  They also demoed the
Falcon's DSP with some digital audio effects (reverb, delay, flange, 
chorus, etc.) software.

And in the latest Atari Explorer Online, it was revealed the Falcon030
will be bundled with several pieces of software including but not 
limited to several games written specifically for the Falcon (don't 
expect any 'too fancy' games here, but rather some 'old standards'
like a breakout clone and a few others), a talking clock program, a
calendar program, a phone/address program, and a few more.  No word 
on a Falcon BASIC, though. <grin>

Despite rumors that Atari won't actually deliver the Falcon030 in the
U.S. until at least April '93, Atari is still sticking by its initial
"limited quantities around mid-October" statement.

More news to come!


Steve
Newsgroups: comp.sys.atari.st
From: leikvoll@hsr.no (Morten Leikvoll)
Subject: Falcon and A/D
Organization: Rogaland University Centre
Date: Thu, 27 Aug 1992 08:10:37 GMT

There is much talk about if the Falcon has an A/D. It doesn't need one!
If they have build in a comparator (probably already in the DSP), the DPS can
emulate an A/D with the help of successive approximation...

-Morten Leikvoll (Is it short enough?)
From: kawakami@ocf.berkeley.edu (John Kawakami)
Newsgroups: comp.sys.atari.st
Subject: The "revolutionary" FALCON
Date: 31 Aug 92 08:16:37 GMT
Distribution: na
Organization: U. C. Berkeley Open Computing Facility

In article <27119@life.ai.mit.edu> dmb@rice-chex.ai.mit.edu (David Baggett) writes:
>mark.thomas@rose.com (mark thomas) writes:
>>     The Falcon has 8 CD quality audio ports. It does not take much
>>imagination to see the Falcon as a sampling device with capabilites
>>that today would cost about $6000. 
>
>Not to burst your bubble, but "CD quality" is a bit of an overstatement,
>or at least a huge assumption.  Just because the D/A's are spec'ed as
>"16 bit converters" doesn't mean they have the same sound quality as
>D/A's you'd find in CD players.  High-resolution D/A converters are
>very sensitive.  I expect that in a machine as cheap as the Falcon
>which has only been designed with sound as one capability (and not
>the primary function of the machine, as with a CD player), you'll only
>really get about 12-14 bits worth of real-world resolution.  This
>is marvelous for most applications (like adding little sound effects
>to your desktop), but not good enough for real studio work.

But what's "real studio work" really mean? It's just another elitist atti-
tude.  Look at the effect that samplers have had on the the Rap, House,
Jazz, Avant-Garde, etc. field. Look at what 4 track tape has done for
punk rock. Look at what "low quality" home video has done to network TV.
Look at what Quicktime, a noisy, low quality video format has done for
computer video. Look at what the Amiga and Video Toaster are doing to the
video industry.

The Falcon is a potential "discount studio" for bands and home studio
builders. It can allow the rank amateur to dabble in adding effects to
the sounds they record.

If Atari did the right thing, there is a port for direct connection to the
DSP so you can add on your own A/D and D/A circuits.

Of course, all of this is moot if the Falcon dies in the marketplace: remember
that as of today, it cannot run Mac or PC CD-Roms, it cannot even use the data
on Mac and PC CD-Roms. CD-Roms are the only popular medium which will allow
someone to use all of the Falcon's sonic and visual features.


-- 
John Kawakami                  kawakami@ocf.berkeley.edu
                               ucbvax!ocf.berkeley.edu!kawakami
Newsgroups: comp.sys.atari.st
From: ronw@cbnewsk.cb.att.com (ronald.g.wolenty)
Subject: Re: FOR SALE: SPECTRE GCR
Organization: AT&T
Distribution: usa
Date: Wed, 26 Aug 1992 14:43:45 GMT
Summary: *SOLD*

In article <1992Aug25.213013.16269@cbnewsk.cb.att.com>, ronw@cbnewsk.cb.att.com (ronald.g.wolenty) writes:
>  I have a SPECTRE GCR with MAC ROMS and 3.0 software for sale.
> I will consider offers but the first offer of $300 takes it!  
> 

It has been sold - thanks for your replies!
Ron Wolenty
From: nelson@that_machine.Kodak.COM (Bruce D. Nelson)
Newsgroups: comp.sys.atari.st
Subject: Re: Double Klick Software Adresse wanted!!
Date: 3 Sep 92 20:20:40 GMT
Organization: Eastman Kodak Co., Rochester, NY

In article <1992Sep2.173150.26216@zooid.guild.org> kovarski@zooid.guild.org (Mark Kovarski) writes:
>
>I have heard that they have gone out of business. Anyone know if there is any
>truth to this matter?

Definitely not!!!

Mike ran into a little bit of a problem with his business partners, but
I understand it's been cleared up.

The address is:

Double Click Software
PO BOX 741206
Houston, TX 77274


--
Bruce Nelson                            | Phone: (716) 726-7890
Rochester Distributed Computer Services | Internet: nelson@kodak.com
Eastman Kodak Company                   |
Rochester, NY 14653-5221                |
From: bigham@acpub.duke.edu (Scott Bigham)
Newsgroups: comp.sys.atari.st
Subject: Re: Shadow-Term II
Date: 31 Aug 92 01:27:37 GMT
Organization: n. Arrangement in an orderly or logical fashion.  See "miracle".

From the Holy Book of <1992Aug30.174511.13276@mits.mdata.fi>
  as spake by paetau@mits.mdata.fi (Rasmus Paetau) :

>In article <1992Aug27.101623.6691@peponi.wcc.govt.nz> sheppard_r@kosmos.wcc.govt.nz writes:

>>the programer did not know what arcv was all about [...]

>  [...] I don't exactly know what this arcv is, but I think it's some
>kind of command-line extenser (that lets you write an over 128 byte
>parameter line)?

Yep.  Roger is referring to the ARGV standard, the official method for
passing long command lines to programs.

>                 I can't see any reason for using it with FZDT, as it
>isn't a .TTP program?

Well, if you want to download a _lot_ of files at once, you'll have to
hand XYZ a very long parameter list.  XYZ (presumably) prepares for this
eventuality by using startup code that knows how to parse arguments
passed to it via ARGV; the problem (apparently) is that FZDT doesn't
know how to _give_ args to XYZ via ARGV, thus losing the benefit of
long command lines.

[I'm merely inferring from Roger's description here; I've never used
FZDT, so I can't speak with authority.]

						-sbigham
-- 
Scott Bigham                   | The opinions expressed above are
bigham@hercules.acpub.duke.edu | (c) 1992 Hacker Ltd. and cannot be
                               | copied or distributed without a
                               | Darn Good Reason(tm).
From: sytang@lamar.ColoState.EDU (Shoou-yu tang)
Newsgroups: comp.sys.atari.st
Subject: Re: FontGDOS WORKS!!!
Date: 27 Aug 92 14:47:17 GMT
Organization: Colorado State University, Fort Collins, CO  80523


 Since a few netter is asking for it, it means probably a lot of them did not
 know it's already in atari.archive.umich.edu. [Someone has put it there, I do
 not have Genie access nor can I take the credit]. It's currently under
 /atari/new/fontgdos.lzh, I was looking for it for quite awhile and have been
 checking the a.a.u.e regularly and found it there last week.

 Tang
 sytang@lamar.colostate.edu
Xref: sparky comp.sys.atari.st:13038 comp.sys.atari.st.tech:4639
Newsgroups: comp.sys.atari.st,comp.sys.atari.st.tech
Subject: ZOO/ZIP/ARC/LZH
From: Steven.Wells@bbs.actrix.gen.nz
Date: Tue, 1 Sep 1992 01:43:04 GMT
Organization: Actrix Information Exchange
Keywords: Archivers, ZIP, ZOO, ARC, LHarc, Speed, Compression.
Summary: ZIP wins!  See for yourself!


Here is a comparison of the four most used Archiving utilities on the
Atari ST (And indeed - most 16 & 32 bit machines)

It was performed on an Atari 520STFM with 1meg of RAM.  Using a 300k
FAST-RAMdisk for all file operations.  Write verify was turned off.
No TSR's or ACCessories were loaded.

Results may differ very slightly on some machines.  (Speed will
obviously increase when being used on accelerated machines)

Comparisons of, ZOO, ZIP, ARC and LHarc are described below.  This is 
using versions, that to my knowledge are the latest versions available 
to the general public.  It is not definitive, but it gives a good idea 
of which techniques are best to use when you want quick & effective 
compression - (or slow and in-effective).   The results are quite 
surprising with the popular LHarc coming after both ARC and ZIP in 
the overall ratings, and being beaten by the default compression 
mode of ZOO!!

De-compression has not been tested - as times are usually pretty 
similar in rating.


Text:   (181246 bytes)

Time taken:

ZOO (Default)   44 secs
ZIP (Default)   45 secs
ARC             46 secs
ZIP (Deflate)   51 secs
LHarc           74 secs
ZOO (Slow mode) 100 secs


Compression:    (% of original size)

ZIP (Deflate)   33.5
LHarc           35
ZOO (Slow mode) 35 (61 bytes bigger than LHarc)
ZIP (Default)   36
ZOO (Default)   41
ARC             41 (739 bytes bigger than Default ZOO)



Binary: (155722 bytes)

Time taken:

ZIP (Default)   36 secs
ZOO (Default)   45 secs
ARC             50 secs
ZIP (Deflate)   61 secs
LHarc           62 secs
ZOO (Slow mode) 90 secs


Compression (% of original size)

ZIP (Deflate)   37
LHarc           38
ZOO (Slow mode) 38 (10 bytes bigger than LHarc)
ZIP (Default)   41
ZOO (Default)   56
ARC             58


The overall ratings - taking into consideration, the time taken, 
and the relative compression gained within that time (the total 
averages), are as follows:

                                              Speed    Compression

The winner:  ZIP (Default)                    1st      3rd
#2        :  ZIP (Deflate)                    4th      1st
#3        :  ZOO (Default)                    3rd      4th
#4        :  ARC                              2nd      5th
#5        :  LHarc                            5th      2nd=
Last      :  ZOO (High compression method)    6th      2nd=


Versions used:

ST-ZIP v2
LHarc v2.01L
ARC v6.02
ZOO v2.14
-- 
        Wells_S@Kosmos.WCC.Govt.NZ     /     Steven.Wells@BBS.Actrix.Gen.NZ 
                   $$$$$$$$ Nil Mortifi Sine Lucre $$$$$$$$
From: geoffc@zebedee.UUCP (Geoffrey Coan)
Subject: Re: uucico 3.42
Newsgroups: comp.sys.atari.st
Date: 26 Aug 92 23:41:22 GMT
Distribution: world
Organization: Geoffrey Coan (disorganisation)
X-Version: Rodney's UUCP modules 02/11/90 V1.18

In article <1992Aug24.045506.18193@peponi.wcc.govt.nz> shore_c@kosmos.wcc.govt.nz
(Craig Shore) writes:
> In article <H.05k1RsHq5vE@jonh.wimsey.bc.ca>, jhenders@jonh.wimsey.bc.ca ( John Henders ) writes:
> >geoffc@zebedeeUUCP (Geoffrey Coan) writes:
> >
> >>My main question is though, what's cicostat.prg for ???   I've setup ..
>
> I haven't figured out how to get alias working yet... it works on a local
>  basis, but mail from the outside world doesn't get redirected.
> So, I came up with a cleaver alternative... I created the user cicostat,
>  and gave it my user directory as well (i.e. 2 user names share the same
>  directory)... it works fine.
> 
Quite a neat idea

> As it looks like he's run the program without cicostat as a user/or an alias
>  for it, the results from it will be in the mail boxes of postmaster
>  andthe bounced message in root. cicostat sends the message to cicostat
>  from root.
> 
Yes, correct it did, and since postmaster is defined as 'geoffc' I got it OK.

> Now can someone tell me how the program Kosten works? it also does something
>  with the uucico adm file.
> 
Where did you find Kosten ?   Is it part of hermes ?   Incidently, is
hermes still on atari.archive as telecomm/herm100b.lzh - because I can't
find it if it is.

> BTW: Tried to mail my reply to the first message, but it bounced :-(
Hmm, I think the new uucico has trashed my path as everything is coming
as zebedeeUUCP (rather than zebedee.UUCP).  Even this isn't right as my site
isn't registered anywhere - the only way I've ever got stuff through is to
force the path through as '..!uunet!ibmpcug!jshark!zebedee!geoffc' - anyone
any better ideas ?

> 
>  Craig.
> 
> * Craig Shore  | Phone (voice)  | Internet:shore_c@kosmos.wcc.govt.nz    *
> * 20 Tasman Pl,|  +64 3 3852501 |         :craig@yonder.equinox.gen.nz   *
> * Christchurch, New Zealand     | SLNET: 250:700/1266 FIDONET: 3:770/180 *

Geoffrey
--
are you ready to SKYDIVE ??                                       Geoffrey Coan
well all right then, if you say so ...   ..!uunet!ibmpcug!jshark!zebedee!geoffc
From: "robert buonincontro" <robert.buonincontro@canrem.com>
Newsgroups: comp.sys.atari.st
Subject: beware of the falcon!
Date: 1 Sep 92 19:48:32 EST
Reply-To: "robert buonincontro" <robert.buonincontro@canrem.com>
Distribution: comp
Organization: Canada Remote Systems


 That article came from Europe. In europe the Ataris biggest compeition
is the Amiga. The article makes sense with Atari not being able to
market the Falcon properly. I talked to a few people who work at EA and
they are pissed at the way Atari handled the Lynx. THey said that they
could have outsold Nintendo Gameboy by now. I even talked to a guy
working at Atari in Toronto and they said that Atari doesn't have to
money to mass produce the Links the way they would like too.

 As far as the Atari Falcon being Ataris last chance. Do you know how
many Atari employees are working in Canada? 3!
--
Canada Remote Systems  - Toronto, Ontario/Detroit, MI
World's Largest PCBOARD System - 416-629-7000/629-7044
Newsgroups: comp.sys.atari.st
From: heinenb@messua.informatik.rwth-aachen.de (Benedikt Eric Heinen)
Subject: Problems with GNUmake 3.60
Summary: How to use RCS from make?
Keywords: GNUmake GNU make problems question programming c RCS rcs
Organization: Rechnerbetrieb Informatik  /  RWTH Aachen
Date:  2 Sep 92 16:31:56 GMT

Hi all,

  I got some problems with the GNUmake V3.60 that I got from a.a.
I wrote a makefile to compile and bind a lib I wrote before. I RCSd the
first few files and tried to make the lib another time. But there is a 
problem. make calls co with "co xgetrc.c,v xgetrc.c". Using that command line,
co tries to extract xgetrc.c two times from xgetrc.c,v! But after the first
extraction, co states that there already is an extracted xgetrc.c and inter-
actively asks, whether that one should be used or whether the existing file
should be replaced by the new one. Is there a way to tell make to call co with
"co xgetrc.c,v" instead of "co xgetrc.c,v xgetrc.c"?
And another question: is there a way to tell make to auto-delete the files
it checked out just before compilation and to leave the source files that 
already existed at the moment when make was startet?

yours,

     Benedikt Heinen

Xref: sparky comp.sys.atari.st:13123 comp.sys.atari.st.tech:4664
Newsgroups: comp.sys.atari.st,comp.sys.atari.st.tech
Subject: Re: ZOO/ZIP/ARC/LZH
From: Steven.Wells@bbs.actrix.gen.nz
Date: Wed, 2 Sep 1992 20:16:55 GMT
Organization: Actrix Information Exchange

In article <1992Sep2.143343.29691@cs.unca.edu> mcmahan@cs.unca.edu (Scott McMahan -- Genesis mailing list owner) writes:
> Zoo says 'default' -- but it has a higher compression option too!
> It takes longer, but does a better job. This tradeoff should be
> taken into account.
> 
> Zoo is a lot more user-friendly than the other archivers, too. :)
> 
> Besides, to function with an atari getting stuff from the net, you
> really need *all* archivers installed on your system, or at least
> on your net-connected (UNIX) system so you can unpack and repack 
> the archives before downloading them.


ZOO is only user-friendly if you are being pointless and running UNIX
on an ST.  RUnning it from standard GEM, you can't re-direct it's
output, which is a real nuisance!  ZOO, ARC, and LHarc can all be told
where to put their extracted files/archived files once they have
extracted/archived them!

I have shown the 'High compression' method of ZOO.  It takes a LONG
time - and gets about the same compression as Lh5 (LHarc), it's slow
speed is it's only MAJOR draw-back, optimising the code a bit, and
speeding up the routines would make it quite usable! (Also adding a
re-direction for the GEM users, the numbers of which seem to be very
small in an Atari message area - seems quite illogical!)

ZOO's compression isn't bad as seen here:

Compression (% of original size)

ZIP (Deflate)   37
LHarc           38
ZOO (Slow mode) 38 (10 bytes bigger than LHarc)
ZIP (Default)   41
ZOO (Default)   56
ARC             58

10-bytes difference is not much - especially as the file-size is
always rounded up to the nearest 1k, as more than one program can't
occupy the same sector on the disk - so GEM reserves it for that
program/file, and so a 689 byte file, is actually 1k big (1024 bytes).

Unfortunately - this good compression, loses out on the speed:  (Note
'Slow Mode' is the 'High Compression' mode of ZOO)

Time taken:

ZIP (Default)   36 secs
ZOO (Default)   45 secs
ARC             50 secs
ZIP (Deflate)   61 secs
LHarc           62 secs
ZOO (Slow mode) 90 secs

it took 28 seconds longer than LHarc to compress to virtually the same
filesize. the file it was compressing was only 150k.  Zip's Deflate
mode was only 1-second quicker than LHarc, but it got almost 2% better
compression! (No biggy, but it's an improvement!)
-- 
        Wells_S@Kosmos.WCC.Govt.NZ     /     Steven.Wells@BBS.Actrix.Gen.NZ 
                   $$$$$$$$ Nil Mortifi Sine Lucre $$$$$$$$
From: ucacmsu@ucl.ac.uk (Mr Stephen R Usher)
Newsgroups: comp.sys.atari.st
Subject: Re: GEM.. what needs to be fixed, and soon!
Date: 4 Sep 92 08:55:11 GMT
Organization: Bloomsbury Computing Consortium, London

In article <ABADDON.92Sep1121112@suprenum.supr.scm.liv.ac.uk> abaddon@supr.scm.liv.ac.uk (Kevin o donovan) writes:
>>>>>> On 28 Aug 92 09:54:13 GMT, ucacmsu@ucl.ac.uk (Mr Stephen R Usher) said:
>
>> As to whether better interfaces appear on other machines, it doesn't really
>> matter. As the Atari machines are a small minority the coding interface of
>> the machine has to be addapted so that it looks like one of the big boys
>> (however awful that may be) so as to persuade big time developers even to
>> look in the direction of the Atari. (If all it needs is a quick recompile
>> of, say, the PC code of a word processor, or anything, without any rewriting
>> then a software house is more likely to support it.)
>
>No, no, no, no! I didn't buy an ST so that I could run PC (for example) look
>alike software on it. If having access to that software is important to you
>then you should be using a PC. I don't think anyone here honestly sees atari 
>taking on the likes of IBM, much as we'd like them too (more people using your
>software means more people likely to pay for it), but to suggest that they 
>should just attempt to blend in instead... They're are enough PC clones in the
>world already, without Atari starting to churn them out.
>

Firstly, Atari already churn out IBM PC clowns, the ABC range of computers.

Secondly, for the Atari non-intel based machines to be taken seriously at
all they have to run a set of de facto standard software. It doesn't really
matter if the Atari specific software is more powerful or even cheaper, it's
just a fact of life. The only way I can see for this to happen is to produce
and release to developers an interface library which will allow them to just
compile and sell their code from another machine. Maybe the interface
library could emulate the MAC-OS system calls (though I guess Apple would
have something to say about that).

>Kev

Steve

PS. This is NOT a flame.

--
Addresses:-
JANET:-		ucacmsu@uk.ac.ucl or	steve@uk.ac.ox.earth (preferable)
Internet:-	ucacmsu@ucl.ac.uk or	steve@earth.ox.ac.uk (preferable)
Newsgroups: comp.sys.atari.st