Info-Atari16 Digest         Tue, 30 Jul 91       Volume 91 : Issue 414
 
Today's Topics:
                          BibTeX locking up
                    DATA Transfer PDP 11 -> ATARI
                       Idea for a (DC?) program
                  Lattice C -- Single Pass? (2 msgs)
                         mntolb10 vs libolb71
                    PD BBS software for Atari-ST.
                         Reset-Proof Ramdisk
                       Robotz: Author, author!
                                 SALE
                             Spectre GCR
                      TT memory (was allocation)
                                TT RAM
                           Turbo-C (3 msgs)
 
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: 27 Jul 91 21:01:43 GMT
From:
 lll-winken!aunro!alberta!brazeau.ucs.ualberta.ca!unixg.ubc.ca!ubc-cs!fornax!bre
 mner@uunet.uu.net (David Bremner)
Subject: BibTeX locking up
To: Info-Atari16@naucse.cse.nau.edu
 
Problem: Bibtex C Version 0.99c ( atari.archive:atari/tex31/bibtex.zoo
) locks up when I run it, right after it says "The style file:
plain.bst"
 
I am running a 1040ST, with TOS 1.x, x < 4, 1 Meg of memory.
 
The only things in my auto folder are foldr140.prg, and supra hard
drive boot and clock-read.
 
Is this known to work on one meg ST's ?
 
I am running from within Bammi's minimal shell, but TeX runs O.K., so
I don't think thats the problem.
 
--
bremner@cs.sfu.ca                                         ubc-cs!fornax!bremner
 
------------------------------
 
Date: Tue, 30 Jul 91 12:37:15 MEZ
From: BIELEPF%DKNKURZ1.BITNET@CUNYVM.CUNY.EDU
Subject: DATA Transfer PDP 11 -> ATARI
To: ATARI-List <info-atari16@naucse.cse.nau.edu>
 
Hello ATARI-Fellows,
I have a problem with data transfer from a PDP 11 (steamboat) to an
ATARI.
Is there anybody who can help me with a complete solution or even with
some usefull comments?
It's realy urgent. I need the datas from the PDP 11, because it will break
down very soon.
Greetings, Klaus.
 
Klaus Oed, Biologie, Universtitaet Konstanz, 7750 Konstanz, Germany
e-mail: bielepf@dknkurz1.bitnet
 
------------------------------
 
Date: 30 Jul 91 11:32:46 GMT
From: mcsun!hp4nl!phigate!alp!johnj@uunet.uu.net (John Janssen)
Subject: Idea for a (DC?) program
To: Info-Atari16@naucse.cse.nau.edu
 
I just thought of a nice small program (utility?) to have.
 
The MEGA STE lets you start programs from function keys,
which is really nice. Only one problem remains...
Some programs need the cpu speed set back to 8 MHz
(think of the MIDI programs with their keys in the
rom port) while you want other programs to run
as fast as possible.
 
It would be nice to have a program that first sets cpu speed,
cache on or off (and probably blitter as well) as required
for the specific program you want to run, and then exits by
starting that specific program (handing the default
directories, etc to that program).
 
 
--
John Janssen         Email: johnj@echo.philips.nl
The Netherlands
Work: +31 40 756588  Atari Mega STE, MIDI, C-lab Notator and Unitor.
Priv: +31 77 513177  Astro -Birth/Place/Date/Time you > you.doc
 
------------------------------
 
Date: 29 Jul 91 21:24:03 GMT
From: noao!ncar!elroy.jpl.nasa.gov!usc!apple!portal!atari!apratt@arizona.edu
 (Allan Pratt)
Subject: Lattice C -- Single Pass?
To: Info-Atari16@naucse.cse.nau.edu
 
>In article <040103.22763@timbuk.cray.com> marc@sequoia.cray.com
>(Marc Bouron) writes:
>>I also write my C programs with main() at the
>>`top', but I also religiously declare all the functions I'm going to use.
 
and jimomura@lsuc.on.ca (Jim Omura) writes:
>     It looks like it's a habit I'm going to have to get into.
 
I can't address the issue of whether the Lattice compiler really requires
this, because I don't know what version you have and I can't try it, but if
it does, it's wrong.  My ANSI C spec (admittedly a draft from 10/86) in
Section 3.3.2.2 (Function Calls) states:
 
        "If no declaration is in scope for an identifier used as the first
expression in a function call [that is, the function to be called], the
identifier is implicitly declared exactly as if, in the innermost block
containing the function call, the declaration
 
        extern int identifier();
 
appeared."
 
Thus, the behavior is not "implementation defined" but very specifically
defined by the spec.
 
============================================
Opinions expressed above do not necessarily     -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.      ...ames!atari!apratt
 
------------------------------
 
Date: 30 Jul 91 08:32:19 GMT
From: timbuk!marc@uunet.uu.net (Marc Bouron)
Subject: Lattice C -- Single Pass?
To: Info-Atari16@naucse.cse.nau.edu
 
In article <3004@atari.UUCP>, apratt@atari.UUCP (Allan Pratt) writes:
> ...
> I can't address the issue of whether the Lattice compiler really requires
> this, because I don't know what version you have and I can't try it, but if
> it does, it's wrong.  My ANSI C spec (admittedly a draft from 10/86) in
> Section 3.3.2.2 (Function Calls) states:
>
>       "If no declaration is in scope for an identifier used as the first
> expression in a function call [that is, the function to be called], the
> identifier is implicitly declared exactly as if, in the innermost block
> containing the function call, the declaration
>
>       extern int identifier();
>
> appeared."
>
> Thus, the behavior is not "implementation defined" but very specifically
> defined by the spec.
 
This is fine for functions which return int, but if the function in question
turns out to return void (as it very often does, I find) then this assumption
rather cocks things up.  I'd rather the compiler not make ANY assumptions, but
then I used Algol68 for a number of years, so I'm used to this (`strict')
philosophy.  Like I said, it's good programming practice...   :-)
 
[M][a][r][c]
 
 
################################################################################
#                           #  marc@sequoia.cray.com           #     .   .     #
#  Marc CR Bouron           #  M.Bouron@cray.co.uk     (ARPA)  #    _|\ /|_    #
#  Cray Research (UK) Ltd.  #  M.Bouron@crayuk.uucp  (DOMAIN)  #   (_|_V_|_)   #
#  +44 344 485971 x2208     #  M.Bouron@uk.co.cray    (JANET)  #     |   |     #
#                           #  ...!ukc!crayuk!M.Bouron (UUCP)  #               #
################################################################################
 
------------------------------
 
Date: 30 Jul 91 05:10:41 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!convex!rosenkra@arizona.edu
 (William Rosenkranz)
Subject: mntolb10 vs libolb71
To: Info-Atari16@naucse.cse.nau.edu
 
well, i have finally done it: i am switching from good ol' alcyon to
GNU c. i was able to daisychain my old sh204 onto a megafile 60 (for
the curious, the mf60 has both in/out ports and all u do is change
the sh204 to LUN 1 with the little switches inside and plug it in -
i use ahdi 3.0something - power the sh204 first, then the mf60, then
the st) so i have an extra 10-20 MB free. i have gcc up and running
(except the problem with redirecting stderr under gulam - but that
will be solved when i get mint and bash or ksh up, i hope). i am
still having problems with make (3.54 and 3.59) but i think i can
figure it out (once i get the sources, that is).
 
my question (for eric or bammi or whomever) is what is the relationship
between mntolb10 and libolb71? the latter was recently uploaded to a.a
along with gcc 1.40 (appearently). i am assuming that mntolb10 is not as
current as libolb71, but then again it is mint-ized. and what relation
to "official" gnu.olb are these, version number-wise? if i go with
mntolb versions, is is safe to use the includes and .olb's from mint
and trash the libolb versions? are there any problems with gcc 1.40
and gas 1.37 and ld 71 (i think), what i have now, with the latest
(version 10) mntolb? in otherwards, will i have to keep both sets
of .olb and includes hanging around? i probably will diff the include
files, just to amuse myself.
 
one more thing: will uniterm 2.0a run under mint? if not, will 2.0e?
 
just one more thing: does make 3.59 read the environment for macros
(else why the "setenv gcc path\gcc" in gnu.g)? i use gnu make under
unix, so i look forward to using it on the st.
 
heck, one more thing: how does gcc 1.40 support floating point now?
is pml incorporated into gnu.olb now? do i need pml.olb? i tried a
small project (a simple calculator entirely in yacc - which went thru
bison and gcc without a hitch) and did nothing special to compile
(i.e. no "-lpml" or whatever). it worked fine.
 
i have been able to compile BSD system software virtually unchanged
(e.g. 4.2BSD ls.c compiles with 2-3 changes - like kill utmp.h stuff),
which will be a huge timesaver. porting should be a joy (compared to
16-bit alcyon). and i expect mint to be just as nice to work with.
i like the fact that the gnu library is already fairly POSIX compliant
(like dirent.h rather than sys/dir.h). saves me lots of time. i can
kick myself for recently taking the time to update my own dirent stuff
for alcyon (made it POSIX compliant). on that note, if any sozobon
users want readdir/opendir/closedir/rewinddir/seekdir/telldir (dirent
stuff), drop me a line. i will post it.
 
now with gcc and RCS, i can start on nroff 2.0, or possibly look into
porting groff (BTW: has anybody started this?)...
 
-bill
rosenkra@convex.com
--
Bill Rosenkranz            |UUCP: {uunet,texsun}!convex!rosenkra
Convex Computer Corp.      |ARPA: rosenkra@convex.com
 
------------------------------
 
Date: 30 Jul 91 04:16:12 GMT
From: math.fu-berlin.de!grasp1!frmug!elrond@uunet.uu.net (Bertrand Petit)
Subject: PD BBS software for Atari-ST.
To: Info-Atari16@naucse.cse.nau.edu
 
In article <fido_2_282/301.10_288bc26b@linn.fidonet.org>,
 Robert.Elsinga@p10.f301.n282.z2.fidonet.org (Robert Elsinga) writes:
> In a message of <10 Jul 91  21:03:43>, elrond@frmug.fr.mugnet.org
> (2:320/100.1) writes:
>
>  e> From: elrond@frmug.fr.mugnet.org (Bertrand Petit)
>  e> Newsgroups: alt.bbs,comp.sys.atari.st
>  e> Organization: Minix User Group France
>  e>
>  e>
>  e> I am seeking for a public domain or freeware BBS software for the
>  e> Atari-ST. I can't afford shareware because i have bought QuickBBS ST
>  e> and dropded it last week. This program is a shame: full of bugs. I
>  e> nearly must reboot the computer between each calls.
>
> What? I can't believe that... I know several QBBS/ST BBS and *none* of them is
> having trouble of some sort... but maybe you did something wrong? All the
> other people who are using QBBS/ST 1.02 are very happy with it!
>
 
        I have droped QuickBBs for many reasons but the most important is it's
lack of fiability. I have expressed to Jon Webb my desapointment in the fidonet
QUICKBBS echo with full details.
 
        This is a little summary of my troubles:
        -Sometimes (very often) the system locks completely or crash. This can
append at anytime in any part of the sotware. I'm not the only one who have this
kind of misfunctions, i know anthoer quick bbs sysop who have reported the
same things.
        -Somethimes (very often too) messages were saved with physcho hallo-
genic heaer. These header can contain everything: strings of menus, internal
strings of quickbbs or even 68000 code. Sometimes, somewere a pointer is
trashed and give this strange result.
        -Informations about the curent user are to small for doors programs
and give back modified informations to the main program is nearly impossible.
 
        I can't renember exactly all bugs i have founds (Jon is advertised for
almost of thems) so i can't give a full list in this message.
 
        I have decided to write my own bbs. It's on the way and will be
operational in one or two months.
 
--
|    Bertrand Petit          |         Signature is under construction         |
|    alias                   |                                                 |
|    >Elrond le demi-Elfe<   |         Be sure to wear your helmet             |
 
------------------------------
 
Date: 30 Jul 91 13:33:51 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!usc!orion.oac.uci.edu!maxwell.oac.uci.edu!jvance1@
 arizona.edu (Joachim Vance)
Subject: Reset-Proof Ramdisk
To: Info-Atari16@naucse.cse.nau.edu
 
In article <31385@know.pws.bull.com> aa384@cleveland.Freenet.Edu (Doug Wokoun)
 writes:
>
>From: pv@polari.UUCP (Paul Varn)
>
>       Even if I put Eternal first in the Auto folder, it does the bombs and
>the rest of the boot proceeds.  The copy of Eternal I have I got as part of an
>archive called SYSTEM2.ARC, so I don't know how current it is.
 
  I remember having problems with Eternal too.  Try EDISK v2.1.  I
don't think that Eternal2 (v2 was the latest version of Eternal) even
works correctly with 4meg.  EDISK was based on Eternal2 and is written
by Volker A. Brandt.  Here is a short excerpt from the docs:
 
EDISK features:
 
 - Works with 4 MB RAM.                                            (V1.6)
 - ECONF companion program configures RAM disk directly.           (V1.6)
 - EDISK displays a message on restart.                            (V1.6)
 - Fast data transfer to/from even-address buffer, using "movem".  (V1.8)
 - 'Real' boot sector, thus enabling disk editors etc. to run.     (V2.0)
 - Driver fits into RAM disk boot sector, thus saving 512 bytes.   (V2.0)
 - Configurable size (10 to 3900 KB), 16-bit FAT for speed.        (V2.0)
 - 'Virtual 2nd FAT', ie. we save one FAT but pretend to have two. (V2.0)
 - RAM disk volume label shows version and boot time.              (V2.1)
 
Due to the 'virtual FAT trick', the RAM disk actually provides more
space than an equivalent 'real' disk. It does require that it is first
in the auto folder so that it can control the hard-disk vectors, as is
the case with all reset-proof ramdisks that I know of.  Tho, I do run
Pinhead 1.8 Before EDISK 2.1 for faster booting.  You can find EDISK
2.1 on Atari Archive under utilities/edisk21.arc.
 
Joachim Vance
jvance@bonnie.ics.uci.edu
 
------------------------------
 
Date: 30 Jul 91 15:06:49 GMT
From: haven.umd.edu!wam.umd.edu!dmb@purdue.edu (David M. Baggett)
Subject: Robotz: Author, author!
To: Info-Atari16@naucse.cse.nau.edu
 
Does anyone know who wrote Robotz, recently posted to atari.archive?
The doc file that came with it gives no information at all.  If there
was a post here about, I missed it.  (Sorry.)
 
For those who haven't gotten a copy, get it.  It's a good version of
the old arcade game Berzerk, with that "ultra shaded metallic" look,
decent game play, and good digitized sound effects.
 
(I couldn't get it to run correctly from the hard drive though, so
make sure you try it from a floppy first.)
 
Dave Baggett
dmb@wam.umd.edu
 
------------------------------
 
Date: 30 Jul 91 06:13:13 GMT
From:
 noao!ncar!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!boulder!horto
 n.Colorado.EDU!chuj@arizona.edu (CHU JEFFREY)
Subject: SALE
To: Info-Atari16@naucse.cse.nau.edu
 
School money needed so must sell the following.
 
Must sell the ATARI SC1224 $170.00 or best offer.
It's the JVC model, perfect viewing.
Includes CURTIS CLIP.  In excellent condition, no bumps or scratch.
 
Also Indus GTS-100, take best offer.
Front digital readout with 2 LEDS, BLACK SLIMLINE in perfect shape.
 
--NO REASONABLE OFFER REFUESD--
 
Contact me by E-mail please.
chuj@horton.colorado.edu
chuj@spot.colorado.edu
 
------------------------------
 
Date: 30 Jul 91 13:59:38 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!magnus.acs.ohio-stat
 e.edu!dhbutler@arizona.edu (David H Butler)
Subject: Spectre GCR
To: Info-Atari16@naucse.cse.nau.edu
 
In article <1991Jul29.142017.8877@sae.com> malay@sae.com (Bob Malay) writes:
>Hey,
>I just got a brand new GCR w/ROMS and I was wondering if anybody out there
>can give me a list of Mac goodies that I should be on the look out for,
>particulary, version numbers. Like what version of System/Finder is the
>definitive one to use?
>
>Bob Malay
 
I thought I might as well post my answer in case anyone has any similar
questions.
 
1)   The system version to use should either be 6.0.5 or 6.0.7 the differences
are: 6.0.5 is ROCK SOLID on both the Mac and Spectre, but does not support True
Type. 6.0.7 has a few bugs (nothing too bad, but you will have a few more
resets from time to time), but supports True Type fonts. Also, Spectre sound
does not work with 6.0.7, but it does with 6.0.5 and under. I'm currently
running 6.0.7 and having very few problems, occasionally I get "Finder out of
memory" errors when they should not exist (I tried increasing my Finder memory
allocation, and it did no good).
 
2)   ATM. Everyone with a Mac should have ATM. First, there are lots more ATM
fonts than there are True Type, and also you can convert ATM (type 1
postscript) into Calamus and Pagestream formats. ATM also prints in about 1/2
the time of True Type (I've timed it myself), and looks just as good. True Type
is nice because you don't have to have seperate screen and printer versions of
the fonts however. Also, True Type includes all the System fonts, which is nice
(and why I went to 6.0.7).
 
3)   You might want Resedit. I used resedit to alter all my mac Icons and Menus
to look more like NeoDesk on the Atari so I would get less confused when going
between systems. I also used it to make my Mac seem less "User Condesending",
no more cutsey little menu names (ERASE DISK, come on!) Changed it to "Format
Disk" like it should be. Changed "SET STARTUP" to "BOOT PARAMETERS" and so on
and so forth. This can be really helpful if you are always pulling down the
wrong menu...
 
4)   There are lots of neat utilities out there to make your Spectre (or Mac)
look really neat! I would stay away from these, they work just fine on the GCR,
but the take up memory and make startup take longer. This is a pitfall many Mac
users fall into (I know one guy that uses over 40 INITS, takes him about 2 and
a half minutes to boot up!). Also, remember that you don't need a screen saver
for the GCR because you can switch the monitor off, this can save you more
memory. You could say the Mac is not exactly memory efficient, I have a Mega 4
and run into lots of memory errors with big applications (PageMaker &
UltraPaint).
 
5)   Mulitfinder works fine on the GCR, but try it with just finder for a while
and see if you really need multifinder; If you don't then you will again save
lots of memory.
 
6)   Word processors: I prefer WriteNow 2.2, it is quick, reasonably powerful,
and easy to use. It has a Dictionary and Thesaurus, both of which work very
nicely.
 
If you have any other questions just knock...
 
David Butler
(dhbutler@magnus.acs.ohio-state.edu)
 
(P.S. I hope this entire message gets posted, the editor here on Magnus often
deletes parts, generally the original posted message I'm trying to answer, even
though it is sitting there behind the > just fine on screen in my editor,
anyone have any suggestions, I am using FSE (full screen editor)).
 
------------------------------
 
Date: 29 Jul 91 21:28:02 GMT
From: noao!ncar!elroy.jpl.nasa.gov!usc!apple!portal!atari!apratt@arizona.edu
 (Allan Pratt)
Subject: TT memory (was allocation)
To: Info-Atari16@naucse.cse.nau.edu
 
chuck@cpg.trs.reuter.com (Chuck Menard) writes:
>You may not want a TT - STe is much cheaper...
 
Well, yeah, if you don't care about running a 32MHz 68030 with a 32MHz
68882 for math and more memory and faster memory and VMEbus for expansion
and more serial ports and a 256-color mode and a 16-color mode at
640x480...  If you don't care about any of that then sure, go with the STe!
 
============================================
Opinions expressed above do not necessarily     -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.      ...ames!atari!apratt
 
------------------------------
 
Date: 30 Jul 91 07:19:06 GMT
From: mcsun!unido!sbsvax!sbuvax!univwa@uunet.uu.net (Bernhard Stumpf)
Subject: TT RAM
To: Info-Atari16@naucse.cse.nau.edu
 
Hi there,
 
I have some questions concerning memory upgrade in TT030:
 
I have a TT030/6/48MB, achieved in Germany in 11/90:
 
        - How can I upgrade the ST RAM? (now: 2MB)
          What kind of RAM Chips do I need?
          Where are they sitting? Socketed on motherboard?
 
        - How I can I manage to upgrade TT RAM? (now: 4MB)
          (same questions as before)
 
I know that I may need a so called daughterboard, is this beast already
built in with my 4MB TT RAM?
Where can I buy such a thinW?
 
 
 
Thank you for your help.
 
 
greetings  Bernhard
 
 
 
 *****************************************************************************
 *                                                                           *
 *                        Dipl.Ing. Bernhard Stumpf              | | |       *
 *     /      ___   /     University of the Saarland             | | |       *
 *    /----. /__. -/-     D-6600 Saarbruecken                    | | |       *
 *   /____/ ___/  /_.                                           /  |  \      *
 *                        phone : ++49-681-302-41.43           /   |   \     *
 *                     e-mail: bestu@sbuvax.rz.uni-sb.de      /    |    \    *
 *                                                                           *
 *****************************************************************************
 
------------------------------
 
Date: 30 Jul 91 05:20:25 GMT
From:
 math.fu-berlin.de!unido!fauern!faui43.informatik.uni-erlangen.de!faui09!dkreine
 r@uunet.uu.net (Dirk Reiners)
Subject: Turbo-C
To: Info-Atari16@naucse.cse.nau.edu
 
michaels@kaa.informatik.rwth-aachen.de (Michael Schwingen) writes:
 
>included. As an owner of TurboC2.0 ('Profi-Pack' - incl. Source-Level
>debugger etc.), the update would cost me 150.- DM - I think that's pretty
>much money for the minor improvements I would get :-(
 
Yep, I agree on this point.
 
The biggest part of the development cost was already funded by
Heimsoeth/Borland, so IMHO ASH didn't have to invest much money
into it yet. A nominal fee for the conversion would be acceptable,
but 150.- DM are a bit above that.
 
I don't consider it a wise decision of ASH trying to get rid of
the large customer-base TC had (How large was it, anyway?).
Thousands of potential updaters are not to be neglected, me thinks.
 
Maybe ASH should think about that again ...
 
          Dirk
 
P.S.: What about going to dnet.atari or sub.sys.st with this dis-
          cussion, it's getting pretty german ...
--
--- dkreiner@faui09.informatik.uni-erlangen.de
(invisible .sig following)
 
------------------------------
 
Date: 30 Jul 91 13:19:18 GMT
From: math.fu-berlin.de!unido!urmel!ikki!michaels@uunet.uu.net (Michael
 Schwingen)
Subject: Turbo-C
To: Info-Atari16@naucse.cse.nau.edu
 
gaudreau@juggler.East.Sun.COM (Joe Gaudreau (Dances with PostScript)) writes:
 
>Could you provide more information on what the update involves/costs/etc.
 
>Is there English documentation [yet] !?!?!?!?
 
I don't know about english docs. If you have the TC2.0 professional pack
(that is TC + MAS + Turbo-Debugger), the update costs 150DM. They only
want to know your BORLAND serial numbers. If tou have older TC versions
or do not have the Assembler/Debugger, the update gets more expensive.
I have not got the address of ASH at hand - sorry.
-------------------------------------------------------------------------------
Michael Schwingen, Ahornstrasse 36, W-5100 Aachen, Germany
michaels@messua.informatik.rwth-aachen.de
PLEASE KEEP MAIL FROM OUTSIDE GERMANY SHORT-I HAVE TO PAY FOR INCOMING MAIL
 
------------------------------
 
Date: 30 Jul 91 13:22:19 GMT
From: math.fu-berlin.de!unido!urmel!ikki!michaels@uunet.uu.net (Michael
 Schwingen)
Subject: Turbo-C
To: Info-Atari16@naucse.cse.nau.edu
 
dkreiner@faui09.informatik.uni-erlangen.de (Dirk Reiners) writes:
 
>I don't consider it a wise decision of ASH trying to get rid of
>the large customer-base TC had (How large was it, anyway?).
>Thousands of potential updaters are not to be neglected, me thinks.
 
>Maybe ASH should think about that again ...
 
Maybe they will if only enough Borland customers complain at the 'Atari-Messe'
in duesseldurf and do not order the update immediately ...
-------------------------------------------------------------------------------
Michael Schwingen, Ahornstrasse 36, W-5100 Aachen, Germany
michaels@messua.informatik.rwth-aachen.de
PLEASE KEEP MAIL FROM OUTSIDE GERMANY SHORT-I HAVE TO PAY FOR INCOMING MAIL
 
------------------------------
 
End of Info-Atari16 Digest
******************************
