No Fragments Archive 12: Textmags & Docs/nf_archive_12.iso/MAGS/TEXTMAGS/ATARI16/INFO91.ZIP/INFO91/245.TXT

Text File | 1997-04-16 | 24.5 KB | 610 lines

Info-Atari16 Digest         Fri,  3 May 91       Volume 91 : Issue 245

Today's Topics:
                     Advantages of Improved Mice?
                            ATARI ARCHIVES
                               autogem
                                  C
                          c++ for the atari
                   Can GCC treat printer like file?
                       C compilers (was Re: C)
                       DESKJET printer drivers
                        floppy compatibility p
                   Glendale Conference Impressions
                    HELP!!!!!!!!!!!!!!!!!!!!!!!!!!
                     Info-Atari16 Digest V91 #242
                         Mega STe Questions.
                        Modem Capable Games fo
                           New TOS versions
                     ST GEM-based Word Processors
                     Two More Mega STE Question.
                     uudecoding multi-part files?

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 [e-mail].

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: 2 May 91 17:31:14 GMT
From:
 noao!asuvax!ncar!zaphod.mps.ohio-state.edu!caen!uflorida!mailer.cc.fsu.edu!bind
 ![e-mail] (Mickey Boyd)
Subject: Advantages of Improved Mice?
To: [e-mail]

In article <[e-mail]>, [e-mail] (Il
 Oh) writes:
>[e-mail] (Glenn Deardorff - GDP) writes:
>>I recently heard from someone who said that using an improved mouse
>>(improved over the standard Atari mouse, that is) significantly improved
>>the performance of his GEM windows - if I understood him right.  That is
>>to say, that windows would raise faster, grab the focus faster, etc.
>>just by using an improved mouse - so that GEM would like it was
>>significantly speeded up.  He said he used a "Golden Image" mouse.  Do
>>others that have bought better mice notice anything like this?  If so,
>>it would certainly seem like a worthwile investment.
>
>I seriously doubt that GEM would perform faster because of a better mouse.
>However, you would be able to use it faster.  A better mouse responds more
>quickly to your movements and clicks.  The Golden Image is supposed to be
>very good, a lot like the Microsoft Mouse for DOS machines.  I've tried
>the Beetle mouse, and it's also very nice.  I'm one of the lucky few.
>I've got a really good Atari mouse.

Beware!  Faster mice (ie higher dpi) are not always better.  At some point,
the ST hardware cannot handle the increased input, and you get the 'sticking
pointer' problem.  Try this:  move your Atari mouse very quickly in any
direction (I mean VERY quickly, like a snap).  You will notice that the
mouse pointer will kind of "shudder", but will not move in the desired
direction.  Basically, you are overloading hardware/software  with too much
mouse output.  Now, the higher dpi mice give more output per inch moved.  This
means that this overload is easier to attain with the higher dpi mice.  I
have a buddy who cannot use his Golden Image mouse because he would have to
"pace" himself to get it to work.  A better way to get a "faster" mouse is
through software acceleration, which should not have this problem (and you
can choose from direct, proportional, exponential, etc, types of acceleration).
There are several PD accelerators which work well (I use MouseDoubler2).  Thus,
if you are considering purchasing a third-party mouse, make sure that the
dpi is not too high (unfortunetely the marketeers seem to think that bigger is
better when it comes to dpi).  Failing that, you should find out if you can
set the dpi rate with a dip switch or pot or something.  I believe the Atari
mice are rated at 150dpi.  I have seen mice advertised at up to 400dpi (thus
meaning that you would have to move the mouse only about 1/3 as fast to get
it to "shudder").  You will often see ads proclaiming "No mouse accelerator
needed!" on such mice.  This is true, but the damn things force you to
slow down (and at least in my case, miss what I am trying to point at)!!
--
    ---------------------------------+-------------------------------------
             Mickey R. Boyd          |  "Kirk to Enterprise.  All clear
          FSU Computer Science       |      down here.  Beam down
        Technical Support Group      |      yeoman Rand and a six-pack . ."
      email:  [e-mail]  |
    ---------------------------------+-------------------------------------

------------------------------

Date: 2 May 91 16:48:00 GMT
From: @uunet.uu.net (JIM DEVONSHIRE)
Subject: ATARI ARCHIVES
To: [e-mail]

  How do I access files in the Atari archives. Do I have to subscribe,
pay a fee, join an organization? OR are they free to any interested
user?

Regards, Jim Devonshire at Erin Ontario Canada
---



------------------------------

Date: 2 May 91 18:08:00 GMT
From:
 news-server.csri.toronto.edu!torsqnt!tmsoft!masnet!rose![e-mail]
 .net (JIM DEVONSHIRE)
Subject: autogem
To: [e-mail]

To: [e-mail]


  Thanks for the feedback. I've tried a few variations but without
success. My brother mentioned that he thought "Little Green" may
be interfering with the execution of the "Bootmaker"  program.

  I'll remove LG completely from the configuration process.

  Yes, I've used a text editor and looked at the file(s) contents
but I really don't know what I'm looking for. There is bin code and
ascii text intermingled in the bootmaker and autoboot programs.

  The auto boot program shows the file path and name of the program
to be autobooted "a:\pro24.prg" as well as machine language?

  P.S. Do you "correspond" with anyone in Christchurch or Manchester or
Portsmouth?

Regards....Jim,  Erin, Ontario, Canada.
---



------------------------------

Date: 2 May 91 14:56:20 GMT
From: mcsun!hp4nl!utrcu1!mi.eltn.utwente.nl![e-mail] (Klamer Schutte)
Subject: C
To: [e-mail]

In <[e-mail]> [e-mail] (Joe Gaudreau
 (Dances with PostScript)) writes:

>Look for Borland C++ sooner or later - The rumor line says this is hot!

Has anybody run this for the ST??? I will be >>very<< interested!
(How about this deal: I get the program, and i will translate the docs ???)
(Assuming docs are still in german.)

Klamer
--
Klamer Schutte
Faculty of electrical engineering -- University of Twente, The Netherlands
[e-mail]       {backbone}!mcsun!mi.eltn.utwente.nl!klamer

------------------------------

Date: 2 May 91 03:59:45 GMT
From: noao!ncar!elroy.jpl.nasa.gov!usc!rpi!uupsi!TALOS![e-mail] (Jerry
 Gitomer)
Subject: c++ for the atari
To: [e-mail]

[e-mail] (Thorsten Kramp) writes:

:Hi folks,

:a friend of mine is looking for a C++ implementation for the
:Atari ST (I only know about MPW C++ for the Macintosh, which
:I use, and the Borland and Zortech compilers for PCs). Any
:hints would be helpful - tnx 1.0e6 in advance.

        GNU g++ from the free software foundation is available
        on OS-9 (and I think on GEM -- although I can't remember
        who ported it or where it is).

--
Jerry Gitomer at National Political Resources Inc, Alexandria, VA USA
I am apolitical, have no resources, and speak only for myself.
Ma Bell [phone]  (UUCP:  ...uunet!uupsi!npri6!jerry )

------------------------------

Date: 2 May 91 16:21:44 GMT
From:
 noao!ncar!zaphod.mps.ohio-state.edu!think.com!spool.mu.edu!snorkelwacker.mit.ed
 u!bloom-beacon!eru!hagbard!sunic!isgate!krafla![e-mail] (Adam David)
Subject: Can GCC treat printer like file?
To: [e-mail]

In <[e-mail]> [e-mail]
 (L.J.Dickey) writes:

[discussion of PRN: LST: AUX: CON: etc. deleted]

>Is there a standard filename for the serial port?

Try stdaux, some compilers reserve that name for the serial port. Don't know
about gcc though.

--
Adam David.  ([e-mail])

------------------------------

Date: 2 May 91 15:07:26 GMT
From: mcsun!hp4nl!utrcu1!mi.eltn.utwente.nl![e-mail] (Klamer Schutte)
Subject: C compilers (was Re: C)
To: [e-mail]

In <[e-mail]> [e-mail] (Dave
 Halliday) writes:

Some changes to the C compiler table

->name       memory  src   price  ANSI Debuger      Notes
->----------------------------------------------------------------------------
->GNU C      2Meg+   yes    nil    Y   poor for ST  UNIX origins
->Sozobon C  520K    yes    nil    N   none??       PD
                                      Low Level
->MW C       520K    no    #110    N   Src Level    No longer updated
->Prospero C 520K    no    #100    Y   Src Level    Links to other Prospro langs
->Turbo C    ??      no     ??     Y   Src Level    Only in german
            R 1Meg+
->Lattice V5 R 1Meg+ no    #110    Y   Low Level    Optomiser
->Laser C    R 1Meg+ no    #100    N   Src Level    Very fast compile times
->----------------------------------------------------------------------------

->Notes: Prospro C links with other Prospro product because it uses the GST
->format and not a propriety format. Some other compiler may offer GST link
->format also (I know Lattice C offers both GST and Lattice libraries.)

->The R in the memory section indicates that 1meg of memory is recomended but
->the compiler can be run in 520K.

->As a recomendation I would say the following if you have lots of memory, hard
->disk and no need for commercial support or documentation go for GNU C. If on
->a budget and have a less powerfull setup Sozobon should serve you well. If
->good profesional support is your prime thought I would recomend Prospro C.
->Turbo C is good if you read german. If executable efficiency is your prime
->criteria then Lattice C can't be beeten (though Turbo C is close). Finally if

I think TurboC is a bit faster in execution times than Lattice C. But TurboC
has 16 bits ints where Lattice has 32 bits -- thats the difference.

->compile speed is required then Laser C is the best bet (I'ts one pass

Hmmm. TurboC is also one-pass. And very fast compilation!
Also its integrated edit-compile environment is a very nice way to write
&& debug GEM programs (also due to its build-in online GEM manual).

->compiler compiles at an order of magnatude faster than many of the
->other compilers.)

When one wants to compile U*IX programs conformance to U*IX libaries is
also important. Of the compilers i know the order of compliance is:
GNU - MWC - Sozobon - TurboC.
I don't know about the other ones.

->So each compiler has its strengths.
True.

->For those wondering what my bias is I own GNU C and Lattice C Vsn5.

I own GNU (but not enough memory :-(), Sozobon (slightly buggy &&
slow compilation), MW C (Unix like environmemt), Megamax (Old version of
LaserC), MJ C (An old PD C version -- slow, subset of K&R) and TurboC
(Fast in compile && execute, but ANSI only -- a drawback sometimes).

Klamer
--
Klamer Schutte
Faculty of electrical engineering -- University of Twente, The Netherlands
[e-mail]       {backbone}!mcsun!mi.eltn.utwente.nl!klamer

------------------------------

Date: 2 May 91 13:27:13 GMT
From: mcsun!ukc!strath-cs!glasgow![e-mail] (Alan Wilson)
Subject: DESKJET printer drivers
To: [e-mail]

Whilst on the subject of printer drivers in general, could someone post
details of the 'printer.sys' file most commonly found referred to in the
 'assign.sys' with driver ID 21 ? I have a printer which emulates an Epson, but
 most
Epson drivers do not use the quadruple density graphics mode which my printer
has. I have tried hacking the printer.sys file... I can get the printer into the
correct mode, but the driver only sends enough data for 960 dots per inch,
whilst I want 1920. A posting of this files structure would be of great help
to me - output from timeworks is really horrible, I'm sure my printer can do
 better.

Alan Wilson


--


###############################################################################
#  /\        / Alan   # USEnet :  wilsona!glasgow!mcsun!...                   #

------------------------------

Date: 2 May 91 16:46:00 GMT
From:
 news-server.csri.toronto.edu!torsqnt!tmsoft!masnet!rose![e-mail]
 .net (JIM DEVONSHIRE)
Subject: floppy compatibility p
To: [e-mail]

To:[e-mail]

Sorry, I can't answer your "byte" questions, but as to your
incompatibilities, I know there are a couple of programs which will
allow your PC to read Atari 3-1/2" disks from your PC's 3-1/2"
drive. The program I use is called STTOPC.arc or zip.

Regards, Jim Devonshire at Erin Ontario Canada

---



------------------------------

Date: 2 May 91 17:41:36 GMT
From: mcrware!mwca![e-mail] (Bill Sheppard)
Subject: Glendale Conference Impressions
To: [e-mail]

In article <[e-mail]> [e-mail] (Steve
 Whitney) writes:
`In article <[e-mail]> [e-mail] (Plinio
 Barbeito) writes:
``In article <[e-mail]> [e-mail] (Jack
 W. Wine) writes:
``>>[e-mail] (Plinio Barbeito/) writes:
``>This is really puzzling news!  If Atari built a factory in Israel, it can't
``>possibly be dedicated to only floppy controller chip production...
``
``Sorry to have implied that.  I don't know if it will be dedicated to
``that sole purpose.  That's all that Bob mentioned about it, though.
`
`I didn't think he said it would be a factory.  Sounded to me like they had
`hired people to reverse engineer the WD1772 and do a layout for one that
`would run faster.

Both the San Jose Mercury News and the Jewish Bulletin reported that Atari
and the Israeli government are negotiating (close but nothing signed yet)
for Atari to open a manufacturing plant in Israel, with significant incentive
(financial) from the Israeli government, who are hoping to start a high-tech
business park.  The plant would apparently produce most types of Atari hard-
ware (though I believe the Singapore plant would remain) and would give
(again, I'm not positive) Atari major advantages in dealing with the EC.
--
 ##############################################################################
 # Bill Sheppard  --  [e-mail]  --  {uunet,sun}!mcrware!mwca!bill  #
 # Microware Systems Corporation  ---  OS-9: Seven generations beyond OS/2!!  #
 ######Opinions expressed are my own, though you'd be wise to adopt them!######

------------------------------

Date: 1 May 91 20:01:00 GMT
From:
 arizona.edu!cerritos.edu!nic.csu.net!usc!sdd.hp.com!caen!sol.ctr.columbia.edu!i
 ra.uka.de!smurf!artcom0!hb.maus.de!ac2.maus.de![e-mail] (Lutz
 Frank)
Subject: HELP!!!!!!!!!!!!!!!!!!!!!!!!!!
To: [e-mail]

Hi Jeffery,

jd> Atari Megafile 30 in partition D have become invisible. The problem
jd> started when I was using Cheetah to copy some files from logical drive E
jd> to D. For one copy it either said that it couldn't find the drive path

I got the same problem using CHEETAH on BGM-partitions of my harddisk.
There I could only save one of the BGM-partitions. Cheetah destroyed the
root sector of the destination hard disk.
If you have a monitor like DISKUS you can try to restore the root-sector.
(I didn't have had this programm at this time - I lost all since last
backup ... ;-( ). Now I have a collection of copies of my root sectors on
a special disk - just for case of emergency ...

Kind regards
             Lutz

------------------------------

Date: Fri, 03 May 91 12:24:28 CDT
From: Mike Dorman <[e-mail]>
Subject: Info-Atari16 Digest V91 #242
To: Atari List <[e-mail]>

About the ICD adapter software--

In their distribution, they explicitly state that it may not be redistributed
on BBSs and such--the only online site you may get it from is GEnie.

Possibly the one failing of an otherwise very level-headed company.

Mike.

-------------------------------------------------------------------------------
: Michael Alan Dorman   :                                                     :
: [e-mail] : Hobbies are things people do when they should be    :
: BIX: syssupport       :   sleeping.  --M.A.D.                               :
: GEnie: M.DORMAN2      :                                                     :
: PostalNet:            :                                                     :
:   Box 8068            : Stonehenge was built by two drunks with no          :
:   Tuscaloosa, AL      :   witnesses.  --P.S.McGhee                          :
:               35486   :                                                     :
-------------------------------------------------------------------------------

------------------------------

Date: 2 May 91 19:40:01 GMT
From: oahu.cs.ucla.edu![e-mail] (Steve Whitney)
Subject: Mega STe Questions.
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>I doubt anyone in the US has seen a Mega STe 1 yet, but the reports on
>the F-Net feeds are that Atari has purposely crippled the system (similar
>to the way they crippled the Mega ST2) to prevent upgrading it.
>
>The pc board is cut off where the host adapter would be, and the plastic
>case has been redesigned to prevent intalling a hard drive mechanism.

NO NO NO.  The case has not been "redesigned" to prevent anyone from
installing a hard disk in it.  The case is not finished on the Mega STe1.
To install the hard disk, they apparently have to remove some posts from the
mold, and in the no-hard-disk version, they, naturally, haven't done this.
I can't speak to the host adapter issue, but I doubt very much that the PC
board has been deliberately cut off to prevent you from installing one.  I
have even heard that Atari is working with a host adapter manufacturer which
might provide an add-on for the MSTe1.

>BobR
--
  Steve Whitney - UCLA CS Grad Student                       (())_-_(())
 Soon to be working at Silicon Graphics                       | (* *) |
     Internet: [e-mail]          UCLA Bruin-->    {  \_@_/  }
          GEnie:    S.WHITNEY                                  `-----'

------------------------------

Date: 2 May 91 16:47:00 GMT
From:
 news-server.csri.toronto.edu!torsqnt!tmsoft!masnet!rose![e-mail]
 .net (JIM DEVONSHIRE)
Subject: Modem Capable Games fo
To: [e-mail]

To: [e-mail]

One modem capable game I use is Battle Chess. My brother and I play
on a regular basis.

Regards: Jim Devonshire, Erin, Ontario, Canada
---



------------------------------

Date: 2 May 91 16:03:59 GMT
From:
 noao!ncar!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!snorkelwacker.mit.e
 du!bloom-beacon!eru!hagbard!sunic!isgate!krafla![e-mail] (Adam David)
Subject: New TOS versions
To: [e-mail]

In <[e-mail]>
 Shervin.Shahrebani.Of.250/[e-mail] (Shervin Shahrebani Of
 250/744) writes:

>You don't need Pinhead if you have TOS 1.4 and above.  I have a Mega STE and
>have experienced the problem as well but Pinhead is nothing compared to the
>TOS's built in fast load.  Why bother when TOS has it already?  I know
>pinhead may be compatible with a few more packages but there is nothing to
>it.

Doesn't Pinhead simply compress executables into a self-extracting form that
takes less disk space and therefore less time to load?
Is this what TOS 1.4 fastload does, or is there any benefit in using both
methods?
The time to load an application program is perhaps not a very significant
factor if the program is just to be loaded in and much time then spent working
in the program. On the other hand major savings in disk space matter quite a
lot to most users - from single floppy machines up to Gigabyte hard disks.
The shorter load time is just a useful side effect of the data compression and
is paid for by the time taken to compress the files (also the extra CPU load
during uncompression in a multiprogramming environment).

--
Adam David.  ([e-mail])

------------------------------

Date: 2 May 91 16:25:54 GMT
From:
 noao!ncar!zaphod.mps.ohio-state.edu!wuarchive!csus.edu!ucdavis!csusac!csuchico.
 edu![e-mail] (Ed Krimen)
Subject: ST GEM-based Word Processors
To: [e-mail]

In article <[e-mail]> [e-mail] (Fabian Hahn) writes:
A
>
>Even though you mentioned that you do not need a document processor
>I would like to use the opportunity to plug Wordflair II. I use
>Wordflair II for all my text processing on the Atari (the reason for that
>is that I have written some parts of it).
>

Aw, gee whiz, juuuust a little bias here. :~)  But at least you told us.

>
>I get all this with decent looking output (yes it works great with FSM)

All righty, now, does it come with FSM GDOS?  If not, how do we get it?
If not, we still get to use crummy ol' GDOS until Atari decides to release
FSM GDOS?

BTW, does FSM GDOS work as a direct replacement to GDOS, like G+Plus, or
do the programs which currently run GDOS, have to be modified to look for
FSM?


--
   |||   Ed Krimen [[e-mail] or [e-mail]]
   |||   Video Production Major, California State University, Chico
  / | \  SysOp, Fuji BBS: 916-894-1261

------------------------------

Date: 2 May 91 14:12:45 GMT
From: mcsun!ukc!newcastle.ac.uk!milfield![e-mail] (Dave Halliday)
Subject: Two More Mega STE Question.
To: [e-mail]

This question was propted by the resent discussion about TT hard
drives.

(1) Can the Atari ASCI-SCSI addapter and software on the Mega STE
support more than one SCSI device?

(2) Am I correct in assuming that the Mega STE comes with a battery
backed real time clock?

Thanks,

Dave H.
([e-mail])

------------------------------

Date: 30 Apr 91 15:17:03 GMT
From:
 arizona.edu!cerritos.edu!nic.csu.net!usc!elroy.jpl.nasa.gov!lll-winken!aunro!er
 sys![e-mail] (Greg Granger)
Subject: uudecoding multi-part files?
To: [e-mail]

[e-mail] (John_Altendorf) writes:

> Can anyone please explain the requirements for file names in order to
> uudecode a multi-part file?  I seem to recall something like the file
> names must be sequentially named file.uaa, file.uab file.uac etc.  Also
> it seemed that the ----end---- line of the file had to have some notation
> in it.  Please clarify my misunderstandings.
>
>
> John Altendorf             [e-mail]
> Hewlett-Packard
> Corvallis, Oregon


I believe to uudecode one file into multi-parts, you have to use the -x
(where x is the no. of lines that you want in the uue file).  To UUE, say
for instance, a 100K file called DUMMY.LZH, on the command line, type:
-700 DUMMY.LZH.  This will create a series of uuencoded files that are 700
lines long (except for the last file, which will be the remainder, but not
necessarily 700 lines long).

Greg Granger

| INet:  ersys![e-mail]           |
| Fnet:  Greg Granger (Node 532) Dark Knight (Node 595)|
| Post:  5906-188 Street  Edmonton, AB  Canada T6M-2A9 |
| Tele:  [phone]  OR  [phone]          |

Greg Granger             ersys![e-mail]
Edmonton Remote Systems:  Serving Northern Alberta since 1982

------------------------------

End of Info-Atari16 Digest
******************************