From: gblock@csd4.csd.uwm.edu (Gregory R Block)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: Atari Falcon Discount Supermachine  Re: Sydnes is gone?!!
Date: 20 Aug 92 00:10:37 GMT
Organization: University of Wisconsin - Milwaukee

hyc@hanauma.jpl.nasa.gov (Howard Chu) writes:
: 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.

I totally disagree.  SCSI is a poor excuse for a general purpose bus.
However, it's there.

Just a note:  The point is, this ISN'T supposed to be the low-end
machine.  There's supposed to be one lower, with fewer features.

I don't think they can HAVE too many fewer features in this thing
without calling it an ST.

: 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

Why not?  It's expected:  Real-time summing of audio for playback
could easily be expected.

: 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 ..."

Any correctly written application doesn't hit hardware.  It uses the
operating system.  And since the only ones that generally hit hardware
are GAMES, I'll tell you.

If I run my multitasking-tracker program and Term, it's fine.  The
terminal doesn't beep, because I've already allocated the four
available audio channels for playback of Axel F.  With no slowdown of
the computer system.  See?  Term just fails to allocate, and so it
doesn't beep.  Period.  No real problem.

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

Except:  DSP's were designed for real-time use.  That's why they're
digital signal processors.  ;)  You manipulate data in real-time.
Otherwise, why not just throw another processor or something at it?
DSP's most common use is for realtime data manipulation (we'll leave
voice recognition stuff out).

: 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 ..."

I can see good points:  Having the OS play back audio FOR you.  Rather
than hitting the DSP yourself.  That way, if the system is eventually
upgraded to something with a more advanced DSP, all you need is an OS
rewrite of the particular areas that work with the 56001 to make it
work with your NEW DSP.

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

It's not just that:  ANYTHING that wants to use it.  Sound is the most
common example because it's the most widespread.  A better thing might
be that you're compiling away...  you load up a quick engineering
program while you're working on some of your homework that you made
yourself, and you're crunching FFT's, and the compiler beeps.  Or
tries to.  Because it just totally munged your FFT calculations by
feeding it data in the middle of your calculation...

: 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.)

:)  Of course, those of the Amiga forum here will say C= isn't much
different, though they obviously are.

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

Who knows.

: Ok, I'll let ya refute that statement.  }-)

:)

--
(: (: (: (: Have you overdosed on smileys today?  Why NOT!?! :) :) :) :) :)
(:	  "Flesh-pressing:  It's not just for politics anymore."         :)
(:	gblock@csd4.csd.uwm.edu			Gregory R. Block         :)
(: (: (: (: (: (: (: (: (: (: (: (: (:) :) :) :) :) :) :) :) :) :) :) :) :)
Xref: sparky comp.sys.amiga.advocacy:21541 comp.sys.amiga.applications:6609 comp.sys.amiga.programmer:12366