Newsgroups: comp.sys.atari.st
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!mintaka!geech.gnu.ai.mit.edu!rjc
From: rjc@geech.gnu.ai.mit.edu (Ray Cromwell)
Subject: Re: Amiga is better then what???
Message-ID: <1991Jun27.184631.2685@mintaka.lcs.mit.edu>
Sender: news@mintaka.lcs.mit.edu
Organization: The Internet
References: <677913506.0@therip.FidoNet> <17330@chopin.udel.edu> <1991Jun26.192356.26253@informatik.uni-erlangen.de>
Date: Thu, 27 Jun 91 18:46:31 GMT
Lines: 233

In article <1991Jun26.192356.26253@informatik.uni-erlangen.de> csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) writes:
>don@chopin.udel.edu (Donald R Lloyd) writes:
>
>>	 I can get a 24-bit card for $299 (list).  It takes advantage of the Amiga's
>>built-in coprocessors.  For about $100 more I can get one that also includes
>>a slow-scan video digitizer.  This one (DCTV) has been demoed at shows paging
>>full-motion, full-color video off a HD and displaying it through this advice in
>>real time (Watched a few minutes of Back to the Future III...)
>
>A 24-bit card with complete screen drivers for all the applications you have?
>I doubt that.

  Why on earth would you run a word processor or shell in 24bits? EVen if
the Amiga had 24bit graphics built in I wouldn't run my Workbench on it
because it would slow down ALL screen rendering to  a sluggish 
halt without a something like a 34010 onboard. Instead, I'd have
the Word processor and GUI set to 8 or 16 colors (3d look) and the paint
program on another screen set to 24bit. All the current Amiga graphic
cards work with the OS because they are still using the custom chips
for their tricks. HAM-E and DCTV work with all paint programs and all
displayer programs. (even things like AmigaVision authorware)

>>	 Besides, if you have a problem with your 500, you FedEx it back to
>>Commodore (at CBM's expense) & it's promptly replaced or repaired & sent back.
>>If your 2000, 2500, or 3000 go bad, and your warranty is still valid (1 year
>>warranty on all models, w/option to purchase an extension), Commodore sends
>>someone to your home to fix it there.
>
>You must be kidding. At least here in Germany, nobody cares when your A2000
>breaks down. Especially Commodore won't care.

  In the US FedEx will come to your house, pick up your computer, and
repair it quickly. For A3000's someone comes to your house (onsite
repair). What other countries do is different since each Commodore
sub-company has different policies. Does Atari even exist in the US?

>>	 I've seen the so-called blitter on an ST.  I was not impressed.  The
>
>You have probably seen the desktop build up windows with and without a
>blitter, using TOS 1.02. This means you ain't seen nothing yet.
>Blitter support in TOS is not as it could be, and in general one
>is tempted to say that Blitters Are Not Important. You can speed up
>graphics a lot more by software.

  A blitter helps out alot if you only have a 68000/20.

>>Amiga's blitter performs most operations about as fast as a 14 MHz 68020
>>(according to Dave Haynie, a CBM hardware guy who frequents c.s.amiga.*).
>
>The ST blitter won't stand much behind in these terms. It's just that
>the Amiga OS and architecture much more relies on the fact that there
>is something like a blitter and therefore uses it much more than TOS.

  Yes, it's better integrated on the Amiga, and shared nicely as is
alll resources on the Amiga.

>>     Of course, for about $10 (probably less) you can pop a 68010 into your
>>Amiga & make up for that difference.  Unless Atari has finally released a 
>>non-TT TOS version that supports 680(1+)0 chips, ST owners don't have this 
>>option.
>
>TOS 1.06, TOS 2.05, TOS 3.01 and TOS 3.05 support the 68010. Nevertheless,
>you won't gain much from a 68010, as experiments have shown.

  And the ST doesn't gain much from running at a _slightly_ faster 
processor speed.

>>	 In what way are they more complete?  Do they include a shell environment
>>as well as a GUI?  Do they support multiple simultaneous screens of different
>>depths, resolutions, and pallettes?  (Can the ST even change resolutions yet
>>without a reboot?)  Shared libraries & interprocess communication? (Oops!
>>No need... no multitasking!  Sorry.)
>
>Sigh. We've had cooperative multitasking from the start. Applications
>and accessories can send messages to each other. And I don't think the
>Workbench is much of a real GUI - not before Kick 2.0, at least.

 Intuition is the GUI, workbench is the file/finder system (e.g. like
Finder on the Mac). I never used workbench before 2.0, but I haven't seen
many Atari users who used GEM either. GEM doesn't look too hot on that 
lo-res screen.

>>     Workbench is just as easy to use as any most other GUIs.  Double click 
>>the icon & away you go...
>
>Just try to view all files in a folder with the standard workbench.
>You won't get them. Instead, you have to confine yourself to a command
>shell. That's not the way GUIs were meant to work.

  You do in 2.0. There are _numerous_ workbench replacements/enhancements
out there. But 2.0 beats the pants off all of them. (2.0 kicks the
stuffings out of GEM too)

>>CLI(1):artm        
>>CLI(2):iprefs      
>>CpuBlit V1.00      
>>AssignX            
>>FaccII             
>>ForFacc            
>>RexxMaster         
>>CLI(4):c:snap      
>>CygnusEd           
>>CLI(3):loadwb
>>jr-comm           
>>DMouse            
>>Virus_Checker     
>>jrcomm-clock      
>>SD                
>
>If you look at this list closely, you'll realise that most of the
>processes mentioned are equivalents of TSRs. CpuBlit is a text output
>speeder (BTW, interesting to know that you're using CpuBlit while
>you're claiming that your blitter is much faster than a ST blitter).
  That's because the poster probably has an A3000 with a 68030. CPUBlit
ONLY gives a speed increase on the maximum resolution screens and only
for things like text rendering. It would slow down massively trying to do what
the blitter does (like combine 3 DMA channels of data using one of the
256 logic operations, plus masking ans shifting, and filling the pattern.)
The key phrase here is "parallel processing". Letting the blitter
do something takes the load off the CPU.

>DMouse is a screen saver/mouse speeder package. Virus_Checker is also
>of the TSR type. If you think about it, you'll see that the list
>above was no good example for real multitasking. When working with
>my ST/TT, I have at least that many processes and resident programs in
>my computer.

  But TSR's don't share the CPU, one of them runs until it completes
it processing and then the next one does. The more of them you have
running in an interupt/os patch routine the more sluggish  the computer
will get. You should never hog interupts. TSR's on the Amiga under 2.0
are done using commodities.exchange which allows you to set up handlers in
the input.device that watch for certain hot-keys/events. While they are
waiting, they are taking ZERO cpu time.
  How about what I am doing now? Right now I have a terminal loaded,
in the background I have lharc unarcing some gif pictures I downloaded
earlier which are passing the output names to a script which runs them through
GIF->IFF. Meanwhile, I have 2 shells open and one of them is running
a corewars simulator which is battling two programs (mice vs mortar).
In addition to this, I am getting no visible slow down on my terminal
which is running at 19,200 baud on a USR HST.

>Don't get me wrong: 
>I don't question the usefulness of preemptive multitasking. It's just
>that you gave a bad example of your usage of this feature.
>
>>	 How is this superior to the Amiga's 4 channel 8 bit stereo sound?  (8 bit
>>on all 4 channels, not just 2 of them).  There's even software (Octaplayer?)
>>that supposedly pushes out 8 voices.  Of course, unlike the ST, the Amiga's
>>sound is driven by yet another coprocessor, so it takes almost 0 CPU time to
>>play a musical score or a digitized sound (as a background process in your
>>multitasking environment, while you work on something else).
>
>I couldn't care less if my computer has 3 or 4 digital voices. It just
>doesn't matter. If you're making professional music, you can't make use
>of the home-computer bleep-style digital channels the STe and Amiga

   Amiga channels don't bleep. They have 4 DMA channels to themselves,
8 bit sound, 4khz to 28khz. You can change the sampling rate on demand
and can attach DMA channel to have one channel module the volume and 
frequency of the other (allows you to get synthesis effects)

>offer; instead, you will use MIDI devices (that's why the ST has a
>MIDI port built-in). If you're running standard applications, you don't need 
>sound except the occasional beep when you've done something wrong.

  Except when you run things like Amigavision or hypertext/authorware 
applications where you want to combine animations with digitized sound. 
For CDTV it's a nice addition, along with it's 16bit sound and it's MIDI
port.

>For your information: The STe/TT digital sound chip has an own DMA
>channel, just like the Amiga.

  But does it have DMA for each channel? Can you change the DMA rate?
I heard the STe's DMA sound is fixed at one frequency/sampling rate and
can't change it.

>>	 Applied Engineering and Commodore both make Ami HD drives.  The problem
>>with HD drives on the Amiga is that the floppies are controlled by a coprocessor
>>(yes, another one!) that allows me to do things like formatting a floppy (which
>>I'm doing now via the SD process listed above) with little loss of CPU time.
>>This coprocessor, though, cannot handle the throughput speeds of high density
>>drives (twice that of the older drives), so workarounds have had to be found.
>
>To my knowledge, there is no HD drive for the Amiga that handles standard
>MFM disks. A real pain when shuffling data to a PC.

 The new HD drive on the A3000 has 3 modes. 880k, 1.44mb, and 1.76mb.
1.44mb mode was the main reason for making it. You can also buy
$200 SCSI floppy drives.


>>     No?  Why not?  That .86 MHz doesn't make much of a difference... especially
>>if the ST also has to use the CPU to do I/O and/or graphics stuff at the same
>>time.  Oops!  Forgot again... no multitasking.  Never mind.
>
>See above. The floppy controller and the ACSI bus have an own DMA channel.
>In the TT, there is a second SCSI DMA channel.

   The A3000 has 32-bit for it's harddrive , and it normally gets
xfer rates of up to 2mb/second (and this only eats 5% of the CPU time
while doing it.) The Amiga has over 25 DMA channels. The A3000 now has 
8 integrated custom chips to handle them.

>>	 If I remember the TT specs correctly, the only grahics mode the TT has
>>that can outdo a stock Amiga 3000 (or any other model, if it weren't for the
>>flicker in interlace mode on <3000 Amigas) is the 1024x960 mono mode which
>>needs a special monitor.  With the CBM A2024 monitor or Moniterm Viking, any
>>amiga can do 1008x800 (1008x1024 in PAL mode) mono.
>
>1280x960. 72 Hz. Without a special graphic card. IMHO, a big advantage and
>one of the reason why I bought a TT.

(A2024)  1024x1024 PAL on the Amiga without a graphic card, just need a nice
monitor. (The 1024x1024 also has 4 grey colors for the 3d GUI look)
With Commodore's A2410 you get up to 1024x1024 with 256 colors out of
16.7 million.


>----------------------------------------------------------------------
>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
>----------------------------------------------------------------------


--
/ INET:rjc@gnu.ai.mit.edu     *   // The opinions expressed here do not      \
| INET:r_cromwe@upr2.clu.net  | \X/  in any way reflect the views of my self.|
\ UUCP:uunet!tnc!m0023        *                                              /

