From: hyc@hanauma.jpl.nasa.gov (Howard Chu)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: Atari Falcon Discount Supermachine  Re: Sydnes is gone?!!
Date: 19 Aug 92 09:00:34 GMT
Article-I.D.: elroy.1992Aug19.090034.26983
Followup-To: comp.sys.amiga.advocacy
Organization: SAR Systems Development & Processing, JPL

In article <1992Aug19.065720.22424@uwm.edu> gblock@csd4.csd.uwm.edu (Gregory R Block) writes:
>I sure as hell won't buy a computer without a bus.  I didn't like the
>fact that the 500 was pretty unexpandable.  I wanted a general purpose
>bus with a coupl'a slots.  That's why I picked up the 2000 instead,
>plunking down the extra dough.
>
>A lot of people feel the same way.

Yes, I agree with you there. For the most part, I think SCSI will answer most
expansion needs. But yeah, it'd be nice to be able to cram in video or other
coprocessor boards or whatnot. I don't think it's a serious lack in a low-end
machine though; again, SCSI will probably be more than enough for the needs
of folks buying a low-end machine.
>
>For instance, let's say you have 8 samples you want to play through
>one channel.  You can do it.  You have the DSP sum all the samples in
>realtime and then have the OS play the summed data...  Oops.  That
>doesn't work, because to do that requires that the OS own the dsp.  Or
>the OS tries and screws up your realtime-summing.  So basically,
>you're forced to having to do the summing AND to play it.  And if any
>other application, since this IS a pre-emptive multitasking system,
>wants to use the DSP, say, an Engineering program that wants to use
>the DSP for some FFT's, well, I don't know what happens.
>
>But it might not be pretty.

I see your point, and I obviously don't know the answer, but it seems to
me a bit much to expect some kinds of real-time performance concurrent with
multitasking operation. As a simpler example, what happens on an Amiga when
you run two different programs that want to play sounds thru the sound chip?
I bet your answer is "it depends on how the apps were written. If they played
nice and don't access chip registers directly ..."

Consider another shared resource, a 68881/2 math processor. You use that
pretty transparently, the OS saves and restores floating point context for
you automatically. Great, but you can't get real-time performance out of it
then, can you? I guess my point is you can't have both real-time operation
and sharing...
>
>Again, it all depends on how they do it.  And there's already some
>stiff limitations in it because it's being used for a main function of
>the system:  all audio output (that isn't forcing its way into using
>ST-compatible sound chips).

Dunno quite what to say to that. I would sure be pretty peeved if they're
wasting OS ROM space with digitized samples for OS beeps and warnings. I'd
suspect that the ancient Yamaha sound chip is still the primary audio for
the system. Which still isn't a satisfactory answer, then it's just like
saying, "yeah, there's this really neato-cool chip in there that can produce
fantastic audio, but it's not being used ..."

Going back to the previous example - I remember back when I was just a
beginning hacker, trying to write a background-mode sound player on an
Apple II. And messing with the same thing (remember Pokey Player?) on
the Atari 800, then a background MIDI player on my ST, etc. It was all
really cool, I suppose, but looking back,
I have to ask "why would anyone want to do this *for real?*" I.e., it was
a neat hack and cool that it could be done, but hey, I can still get
better sound from a $20 walkman. So - the question - when/why would you
be trying to play these samples in realtime *and* run some engineering
program at once?
>
>No, but features like that DO belong in an operating system.  For
>instance, HotLinks is similar.  You publish, and your other apps
>subscribe, and they get updates.  However, it's not a part of the OS.
>It should be.  Just like clipboards should be.  Just like
>interapplication communication should be.  They're basic features that
>allow communication between application and application and between
>application and user.  They belong in the OS.
>
>The kernel is another story.  ;)

Ok. Sounds reasonable. (Clipboard's already been in TOS for a long time.)
So Atari has missed again by not explicitly setting a standard way to do
it. The feature can be added, but unless Atari adds it soon, it'll always
be seen as a hack. Got it. Rumor has it that initial systems will have
OS partly in ROM and partly on disk, so there's always the possibility
of providing this feature relatively quickly. (But then, this is Atari we're
talking about, who only released 2 OS updates in 5 years... Sigh.)
>
>:Multiscan,VGA, composite, and even RF are all supported. Even on my circa-1987
>: Mega ST I get 832 horizontal resolution using overscan, even on my Sony TV.
>: (Granted, XBR TV, composite input. Not really feasible for RF...)
>
>So it handles at least 15.75-31.5.  At least interesting.  Are all
>resolutions available in 15.75 and 31.5?  Or just the old,
>compatibility modes.

Probably just the old compatibility modes. I haven't seen any good description
of how the new video system is set up, there might be something clever going
on there. Of course, supporting a 640x480 mode at 15.75khz would require
interlace, and I vaguely recall some Atari designer being religiously opposed
to interlaced video on the ST. But since working in real video production
requires the ability to cope with interlaced NTSC, p'raps that restriction
is now gone.
>
>Though it does sound rather interesting, I still refute that the
>Falcon has lost much of the glory it was first given...

Ok, I'll let ya refute that statement.  }-)
-- 
  -- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA
 ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
 ::To the owner of the blue Mazda, license 742-XLT, your headlights are on...::
 ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Newsgroups: comp.sys.amiga.advocacy