rona@hpdml93.HP.COM (ron abramson) (12/15/88)
Tony Giaccone) writes: >I'm currently in the market for a new computer, and have been thinking >seriously about purchasing an Atari-ST for two main reasons. First is >the price, Atari's seem to be more reasonably priced then Mac's or >Amiga's the two main competing machines (for me anyway). The second >reason is the built in MIDI support. >There are also several good reasons for not buying an ST. First no one >in my area (Rochester, N.Y.) seems to carry the ST line. In fact the >one salesperson who knew what an ST was told me he had just sold his >ST and that the store had discontinued sales of the machine a few months > etc... >Third, I have no idea what kinds of >development tools are availible for the ST. All this brings me back >to the thought of purchasing a Mac. >So, can anyone out there give me more good reasons for buying an ST. >I'm looking for an ST evangelist. Someone who can convince me that an ST >is the correct choice. I suggest that if you've got some good points to Based on the responses so far, it might be tough to find an evangelist. Sorry, I'm not one either! However, I do like my ST for what I use it for and how much I paid for it. I HAVE NOT found the OS to be overly buggy for casual use. I HAVE found some decent (if not state-of-the-art) software. And, its a pretty fast machine with lots of versitility due to the generous number of ports. In general, your reasons for not buying an ST sound pretty reasonable to me. On the other hand, I don't care to spend several thousand dollars buying a Mac. Could you tell us: 1. How many hours a week will you use your computer? 2. What applications would you like to run? 3. How much money are you willing to spend? When I was shopping for a computer my answers to the questions above made the Atari the best choice. Since then, the AT clones have gotten pretty reasonable, however... Good Luck! Ron Abramson P.S. These opinions are mine! (I think) ----------
to_stdnet@stag.UUCP (12/23/88)
From: dynasoft!john@stag.UUCP (John Stanley) [peter@sugar.uu.net (Peter da Silva) writes...] > TOS, of course, doesn't let you do this... its memory management has a fatal > bug that forces everyone to roll their own. but I'll wager that if you free > something twice in a complex 'C' program and let it run long enough it'll > crash. You'd loose the wager if the C program used the dLibs (public domain) C librarys for the ST.... You can free memory blocks at random locations from here to doomsday and the machine will fall apart from old age before the program will crash... dLibs has been extensively tested by some of the best crazies I know of. :^) I'd safely say that anyone developing in C on the ST who is not using this library is probably working far harder than they need to. (When/where can I collect on your wager? :^) -- PS: Please note that my Reply-To address gets munged by the gateway I'm currently using for news access so you can't just <r>eply to this article and have your message get to me. Please use the address below. --- John Stanley (dynasoft!john@stag.UUCP) Software Consultant / Dynasoft Systems
peter@sugar.uu.net (Peter da Silva) (12/27/88)
In article <681@stag.UUCP>, to_stdnet@stag.UUCP writes: > [peter@sugar.uu.net (Peter da Silva) writes...] > > TOS, of course, doesn't let you do this... its memory management has a fatal > > bug that forces everyone to roll their own. but I'll wager that if you free > > something twice in a complex 'C' program and let it run long enough it'll > > crash. > You'd loose the wager if the C program used the dLibs (public domain) C > librarys for the ST.... You can free memory blocks at random locations > from here to doomsday and the machine will fall apart from old age before > the program will crash... Well, Hackercorp has a library front end that does much the same thing. However, I hope that you don't depend on the behaviour of dLibs... or if you do I hope you don't ever port your program to another machine. Hackercorp's memory management routines are machine-independent, and when they detect an error they inform you. That way you can fix your bugs (freeing memory twice is a bug) instead of hiding them. I hope dLibs does as well. > (When/where can I collect on your wager? :^) Third-party hacks don't count. -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`
apratt@atari.UUCP (Allan Pratt) (12/28/88)
In article <681@stag.UUCP> to_stdnet@stag.UUCP writes: > [peter@sugar.uu.net (Peter da Silva) writes...] > > > [TOS's] memory management has a fatal > > bug that forces everyone to roll their own. but I'll wager that if you free > > something twice in a complex 'C' program and let it run long enough it'll > > crash. I do not consider this a bug. Who does? The fact that you attempted to free a block twice is a bug. It is *nice* when an OS guards against programmer errors like this, and even nicer when the OS is completely bulletproof, but it's not a bug when it's not. Secondly, the Malloc system call is not intended for general memory management: the overhead in memory and time for using it are prohibitive. Also, of course, it has limits. The fact that there are limits *is* a bug, but it's a design flaw and it's too late to fix it because people (A) break the rules of memory ownership and (B) rely on undocumented side effects. (There were net.wars about this earlier.) ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
peter@sugar.uu.net (Peter da Silva) (12/29/88)
In article <1271@atari.UUCP>, apratt@atari.UUCP (Allan Pratt) writes: > In article <681@stag.UUCP> to_stdnet@stag.UUCP writes: > > [peter@sugar.uu.net (Peter da Silva) writes...] > > > > > [TOS's] memory management has a fatal > > > bug that forces everyone to roll their own. but I'll wager that if you free > > > something twice in a complex 'C' program and let it run long enough it'll > > > crash. > I do not consider this a bug. Who does? The fact that you attempted to > free a block twice is a bug. I agree with this emphatically. The original debate, which has been lost in the mists of time, is that the Amiga memory allocation is flawed because it doesn't watch for this bug. I was saying that the same thing probably would happen on the ST under the same circumstances, and that this wasn't a problem with the ST or the Amiga... but with the program in question. > Secondly, the Malloc system call is not intended for general memory > management: the overhead in memory and time for using it are > prohibitive. The problem is that most 'C' runtime environments deal with the problem by Mallocing all available memory and doling it out. This is a problem because it screws up when you try to call another program and the exec call fails because there's no free memory. I sympathise with you, by the way. I can see your frustration building up as you try to keep the horde of PC hackers out of the innards of your box. I suppose it's too late to file the serial numbers off OS-9 and call it TOS-II. -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`
"Martin_Cooper.osbunorth"@XEROX.COM (01/09/89)
I recently purchased a Mega 2 after doing a lot of comparison with alternatives, including the Mac, the Amiga and various flavours of PC. The Atari came out tops for a number of reasons, most of which I've not yet seen mentioned by anyone else. First I should say what I was looking for. First, I wanted something that could handle high-end MIDI applications. Second, I wanted something I could use for relatively high-end word processing. And third, I wanted something that could give me a run for my money as a software development base. For MIDI, the Atari stands head and shoulders above anything else. The closest rival, not surprisingly, is the Mac, but it loses for a couple of reasons. The most obvious is the price of the Mega 2 vs. a Mac. Also, don't forget that you have to buy a MIDI interface in addition to a Mac in the first place, which pushes the price even higher. The second reason is a little more subtle. All the best MIDI software is available for either the Mac or the Atari, and in many cases both. What's interesting is that where the same software is available for both, the Atari version is ALWAYS cheaper. (By the way, this is not limited to MIDI software.) My guess is that companies find they can jack the prices up on the Mac and get away with it, so they do. Why would I buy an Atari for word processing? Because of a remarkable degree of compatibility with laptop PC's, which I also use. Not only is the disk format compatible (at least if IBM-formatted), but I can also get WordPerfect for the Atari (for much less money than an IBM version, incidentally), so I can use the same WP software on both systems, and freely interchange the data disks. Then there's software development. The Atari has system software designed in such a way the you can plug in at any level, including right at the bottom. So you can write software for it on top of GEM or right down in the guts, ignoring all the top level stuff. Then of course, there aren't many Unix-compatible systems available for under $1000, either (1040ST + Minix < $1000). Oh, and of course, there's the display. Personally, I have a great aversion to the pokey little screen on the Mac, which, being built in, you can't do a whole lot about. And if you want a colour display, well, you're kinda stuck. I've had my Mega for about two months, and I have no complaints. There's a ton of software out there for it, a huge amount of it public domain or shareware. I keep hearing about how bad Atari's support is, although I have no personal experience of this, but from what I see on this list, I'm not sure that matters. If Atari can't help, the net probably can anyway. Go for it! Martin. ----------------------------------------------------------------------------- -- Martin Cooper, Xerox Corporation | Long live Mesa, the Pilot cried. -- -- Internet: Cooper.osbuNorth@Xerox.com | The usual disclaimers apply. -- -----------------------------------------------------------------------------