HDTenEightyP/NetNews huggingface dataset:
From: glens@natinst.com (Glen Sescila)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Falcon '030 BUS: 16 or 32 bit?
Date: 18 Nov 92 13:23:52 GMT
Organization: National Instruments, Austin, TX
NNTP-Posting-Host: falcon.natinst.com

In article <H.QHklPxgdMm2@fredrik.atari.no> jornmoe@fredrik.atari.no writes:

>  The Falcon030 has a 24bit Address Bus and a 16bit Data Bus. The
>  expansion port on the machine represents that bus.
	.
	.
	.
>  Note that the Apple LC and the Classic II use the same trick and some
>  chips do have full 32bit access like the video logic.

	WHAT?  If the shifter has full 32-bit access to memory how much more
glue could it take to allow the processor 32-bit access?  I mean the memory
is already 32-bit wide for the shifter after that it would seem trivial to
get the processor to have 32-bit access.  If this is true I may be holding
on to my savings for another year or so. :-(  Oh well, by then I should have
enough saved up for whatever is available.

See ya then.
-----------------------------------------------------------------------------
"Now You're Playing With Power Without The Price!"  Glen Sescila   |||
                                                                  / | \
My opinions do not necessarily reflect those of my employer and probably are
exact opposites.	InterNet: glens@natinst.com
-----------------------------------------------------------------------------
Newsgroups: comp.sys.atari.st.tech
From: hutch@bellman.lanl.gov (John Hutchinson)
Subject: Current Notes (was "Using an IBM keyboard...")
Reply-To: hutch@bellman.lanl.gov
Organization: Los Alamos National Laboratory
Date: Fri, 20 Nov 1992 20:17:05 GMT

In article 759171@cix.compulink.co.uk, apelled@cix.compulink.co.uk (Adam Pelled) writes:
>
>In article <1992Nov17.153244.11952@newshost.lanl.gov>, hutch@bellman.lanl.gov (John Hutchinson) writes:
>>The D.E.K.A. keyboard adapter kit has received some pretty good reviews of
>>late (most recently in Current Notes, Nov 92, pg 75).  Adopting a MSTE
>>keyboard would be the easiest, but if you must go with a PC unit, the D.E.K.A.
>>thingie offers a good solution, it seems.
>
>    This Current Notes; What is it, and where can i get it from ?

Current Notes is a U.S. based Atari magazine which began life years ago as a
newsletter for a consortium of Atari user groups in and around the Washington
D.C. area.  It has evolved into a nice mag with a color, glossy cover and 
about 80 pages per issue.  Perhaps the best thing about it is that it is
written by users for users and true to its name, its info is "Current."  It's
not as classy as ST Format, but you can usually believe what you read in it. :)

Subscription rates in the U.S. are $27 per year; foreign rates are $36/year.

Current Notes Subscriptions
122 N. Johnson Road
Sterling, VA  20164
(703) 450-4761
---

___________________________ John "HUTCH" Hutchinson _________________________
_________________ Fair Dinkum Technologies     Member - IAAD  _______________
________________ "No worries, mate... it's from Fair Dinkum!" _______________
____________ email: hutch@bellman.lanl.gov   GEnie: FAIR-DINKUM _____________
From: aeg03@rrz.uni-koeln.de (Jan T. Kim)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: GFA: SWAP *x%,x$() problem worked around
Date: 23 Nov 1992 03:05:37 +0100
Organization: Regional Computing Center, University of Cologne
Reply-To: kim@vax.mpiz-koeln.mpg.dbp.de
NNTP-Posting-Host: rs1.rrz.uni-koeln.de

In <1eo71mINN1889@rs1.rrz.Uni-Koeln.DE> aeg03@rrz.uni-koeln.de (Jan T. Kim) writes:

[description of trouble deleted]

One more observation: GFA seems to fail to keep track what data types are stored in which area. The result of

PRINT TYPE(*stb$())

is -1, which is supposed to indicate that the passed pointer does
not  point  to  any valid data type. However, it should be 5 (for
pointer to an array of strings). I still don't know what's  going
wrong, but then, that's Richter's or GFA's business...

>Unfortunately, it doesn't seem to be possible to write a function
>for  swapping  arrays manually. The problem is, swapping seems to
>swap the internal pointers to the array descriptors  rather  than
>the descriptors themselves. But maybe, I'll have to work on this.
>I'll post to the net if I can find the reasons for the problem or
>ways to work around it anyway.

Today, I don't see what made me post that a  working  around  the
problem  by  swapping  the  array descriptors won't work. I found
that it works perfectly. Instead of the  swap  command,  you  can
use:

PROCEDURE swapstrarr(VAR p_x%,y$())
  LOCAL p_y%,arrbase_x%,arrbase_y%,anzdim_x&,anzdim_y&
  p_y%=*y$()
  arrbase_x%={p_x%}
  anzdim_x&=INT{p_x%+4}
  arrbase_y%={p_y%}
  anzdim_y&=INT{p_y%+4}
  SWAP arrbase_x%,arrbase_y%
  SWAP anzdim_x&,anzdim_y&
  {p_x%}=arrbase_x%
  INT{p_x%+4}=anzdim_x&
  PRINT {p_x%+4},anzdim_x&
  {p_y%}=arrbase_y%
  INT{p_y%+4}=anzdim_y&
RETURN

At least, this seems to do the trick for me now.

Greetinx, Jan

 +- Jan Kim -- X.400:    S=kim;OU=vax;O=mpiz-koeln;P=mpg;A=dbp;C=de -+
 |             Internet: kim@vax.mpiz-koeln.mpg.dbp.de               |
 |                                                                   |
 *----=<  hierarchical systems are for files, not for humans  >=-----*
From: mhughes@comtch.spk.wa.us (Mark Hughes)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: GFA Basic Manual Wanted
Keywords: GFA,atari,wanted
Date: 20 Nov 92 16:27:01 GMT
Organization: Waffle BBS at CompuTech Spokane, Washington

matthew@hitech.com.au (Matthew Smith-Stubbs) writes:
> 	I got a copy of GFA Basic from a CoverDisk on the magazine ST Format.
> The only problem is they gave you a refernece manual on disk but you had to
> order the full manual (this was a bit pricey for my budget ). So I need to
> order a GFA Basic manual from the supplier (whoever that is) or by a secondha
> one (unlikely), or a cheap new one. Any suggestions ?

  Yeah - wait until GFA 4.0 comes out and order it...  Here's the 
address and phone number for Richter, who now makes GFA for the ST.  
Until then, the quick reference file is pretty useful (I have 3.0, and 
use the doc file constantly while programming, so I don't have to hunt 
through a 500-bjillion-page manual).
 
    Richter Distributor,
    Hagenerstrasse 65,
    5820 Gevelsberg,
    Germany.
 
    Phone: + 49 2332 2706
    Fax: +49 2332 2703

  Hope this helps.
 
 - Mark Hughes (Caves of Steel 509-624-2078)  mhughes@comtch.spk.wa.us
Newsgroups: comp.sys.atari.st.tech
From: Alan Edwards <EDWR@UNB.CA>
Subject: VIDEO questions
Organization: The University of New Brunswick
Date: Wed, 18 Nov 1992 13:20:25 GMT

I have been using Ataris for years to do MIDI things, but
recently have decided to get into using video projection
in my concerts.
I need to know a few things:
1. is unmodulated video available from the Mega? (this is what
    I need to give to the projector)
2. what is required to do external genlock. The Mega is capable
    of this...but I have not seen any boxes that hook up to
    do it.
Thanks to anyone who can answer these for me.
Alan

Newsgroups: comp.sys.atari.st.tech
From: hutch@bellman.lanl.gov (John Hutchinson)
Subject: Re: GFA Basic Manual Wanted
Reply-To: hutch@bellman.lanl.gov
Organization: Los Alamos National Laboratory
Date: Mon, 23 Nov 1992 17:01:07 GMT

In article g8mmuB1w165w@comtch.spk.wa.us, mhughes@comtch.spk.wa.us (Mark Hughes) writes:

<< stuff deleted >>

>  Is there a review of GFA 3.7?  I'd like to keep 
>straight compatibility with the DOS/Windows/Amiga (and someday Mac and 
>OS/2) versions...  The C-translator is a great concept, if it works right 

No, GFA 3.7 has not even been offcially announced yet.  Well, it's been
"mentioned" by GFA, I guess, but release won't be until the end of December
at the earliest (and that's ambitious, IMHO).
---

___________________________ John "HUTCH" Hutchinson _________________________
_________________ Fair Dinkum Technologies     Member - IAAD  _______________
________________ "No worries, mate... it's from Fair Dinkum!" _______________
____________ email: hutch@bellman.lanl.gov   GEnie: FAIR-DINKUM _____________
From: fettig@coli-gate.coli (Thomas &)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Falcon '030 BUS: 16 or 32 bit?
Date: 19 Nov 92 13:05:25 GMT
Reply-To: fettig@dfki.uni-sb.de
Organization: U of Saarbruecken, Dept. of Computational Linguistics
X-Newsreader: TIN [version 1.1 PL7]


 Is it really true that it has a 16-bit processor-to-internal-Ram Bus?
 I'm asking for this specific bus, not for some card you could put in!
 (like small vme). The information that's given here does not exactly 
 state this. And i can't believe that they really use an 16bit Ram-Bus
 in the Falcon..

	greetings

		thomas
From: ekrimen@wet.UUCP (Ed Krimen)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Using an IBM keyboard with an Atari ST
Date: 18 Nov 92 19:47:24 GMT
Organization: Wetware Diversions, San Francisco

In article <1992Nov17.153244.11952@newshost.lanl.gov> hutch@bellman.lanl.gov writes:
>The D.E.K.A. keyboard adapter kit has received some pretty good reviews of
>late (most recently in Current Notes, Nov 92, pg 75).  Adopting a MSTE
>keyboard would be the easiest, but if you must go with a PC unit, the D.E.K.A.
>thingie offers a good solution, it seems.

I don't think Omnimon Peripherals, its developer, is in business any more.
I'm sure you could still find some around, though.




-- 
   |||    Ed Krimen
   |||    ekrimen@wet.uucp
  / | \   E.KRIMEN (GEnie)
Newsgroups: comp.sys.atari.st.tech
From: raist@rmece02.upr.clu.edu (Ricardo Hernandez)
Subject: Re: this bus thing....
Organization: UPR-Mayaguez--ASEL Lab
Date: Wed, 18 Nov 1992 02:33:25 GMT

In article <BxvMrI.Eu@rahul.net>, wilsont@rahul.net (Timothy Wilson) writes:
|> First of all, How does a bus work?
|> 
|> second, 16 bits on a memory 'bus' would seem  (to me) that it could
|> only adress 64k. but it can adress 16megs.. or 24bits. 
  
   Nope, that would be the "address bus", not the "data bus"

|> would the chip send 2 bytes out in two cycles to complete an adress?
|> thats screwy.

    Somethings among those lines...

|> 
|> You can add TT ram to the falcon (32 bit ram) (or so says AtariUser)

   I understand that the TT also has a 16-bit data bus... someone stated
that a while ago... I am not sure about that, but since the Falcon in
some benchmarks (posted here somewhere) was about 50% as fast as the TT,
sounds logical to me...

|> third: Atari docs state full 32bits, it would be crime to lie about something
|> like that.
|> (of course, big corps can get away with that stuff.)

   Yep.  I remember when Apple said that their Mac used a 32-bit CPU
(68000).

|> 
|> could it be that the PDS slot could be confused with another bus?
|> the pds is 16/24 68000 compatible. (according to my mags)
|> its definately not 32bits
|> and, its something dave small would be 'into' since he's mr. mac emulation
|> (the primary purpose of the PDS slot)

   Could be...

|> could a 16bit adress bus be 4-5x faster than an ST? 

   Could be...
    
|> what was the ST bus like?
|> was it 16? 24?

   The data bus I guess would be 16-bits.  68000 data bus is 16-bits.

|> why would atari have a dsp/videl and other 'cool' stuff in the falcon, but
|> then intentionally screw the cpu?
|> i would figure its not any cheaper to have 16bit busses...
|> 
|> just my observations.
|> 
   Well, it actually reduces cost and makes the machine easier to implement.
Still, the 68030 has some benefits (MMU, internal cache), although I agree
that looks a little crippled in the Falcon (like on the Mac LC-II).

   Some notes:
   
   Adress bus: where adresses are specified to access memory locations.
   This means how much memory can you access without bank switching.
   For example, a 6502 has a 16 bit address bus meaning it can access
   64k.  A 68000 has 24-bits so it can access 16 megs.

   Data bus:  where instructions/data are read/written from/to memory
   locations.

|> 
|> -- 
|> Timothy Wilson <wilsont@rahul.net>

- Raist
From: bull@vaxc.cc.monash.edu.au
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Surface mounted 68030?
Date: 23 Nov 92 16:43:25 +1100
Organization: Computer Centre, Monash University, Australia

wmagro@uiuc.edu (William Magro) writes:
> I've read here that the 68030 in the Falcon is surface mounted.  Does
> anyone know of a good reason for that?  Wouldn't it be reasonably cheap
> and forward thinking to put it in a socket?

        Not really. When you use surface mount components, you cut down
on the number of individual components required to assemble the Falcon
and the number of seperate assembly operations. This makes the process
of making Falcons (or any other electronic equipment) faster and cheaper.
Surface mount also tends to be more reliable (the drawback is that when
a surface mount component is faulty, it's more expensive to repair or
replace it). Fewer warrantee repairs mean more satisfied customers and
lower operating costs for Atari.

        I can see that a socketed 030 would let you add Page Mode 32 bit
ram by plugging a ram board into the 030 socket and the 030 on top of the
ram board, but Atari seem to have other priorities.


           Bull@vaxc.cc.monash.edu.au  OR  bull@monu1.cc.monash.oz
                    DOD# 251  '84 VF 750   Closet Ducatisto
             Disclaimer. If you love your llama, let it lambada.
Newsgroups: comp.sys.atari.st.tech
From: hyc@hanauma.jpl.nasa.gov (Howard Chu)
Subject: Re: Does Gulam use TERMCAP?
Summary: No, it doesn't.
Organization: SAR Systems Development & Processing, JPL
Date: Sun, 22 Nov 1992 08:40:05 GMT

In article <1992Nov21.082438.21290@r-node.gts.org> mike@r-node.gts.org (Mike Stramba) writes:
>I use Gulam all the time, but only recently have started playing with the
>terminal emulator. I see in the doc file, there is mention of a termcap emtry,
>with which the author stated 'we have used this with `vi and `emacs.

That little note describes a termcap entry that you can use on a Unix box to
drive the Gulam screen, which is just the standard Atari screen control
characters. Most folks call this setup "st52" because it is a superset of
the VT52 controls.
>
>If I set the TERMCAP variable to TERMCAP = "d:\termcap", with the file
>d:\termcap containg the term def, will Gulam actually use it? I tried it, and
>connected to a dos-ansi system. It wasn't working, .... should it?

Nope. Gulam knows nothing about termcap. Quite a pity. At some point I'm
definitely going to have to recompile the thing; I use it too much to let
it go like this...
-- 
  -- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA

All true wisdom is conveyed in one-line witticisms.
Newsgroups: comp.sys.atari.st.tech
From: raist@rmece02.upr.clu.edu (Ricardo Hernandez)
Subject: Re: 16-bit RAM Access on Falcon ?
Organization: UPR-Mayaguez--ASEL Lab
Date: Wed, 18 Nov 1992 02:10:59 GMT

In article <q0JDuB2w165w@comtch.spk.wa.us>, mhughes@comtch.spk.wa.us (Mark Hughes) writes:
|> raist@rmece02.upr.clu.edu (Ricardo Hernandez) writes:
|> >    I suggest that you read signatures before replying.... the guy above
|> > seems to work for an entertainment software company and I think that
|> > he knows better.
|> > - Raist
|> >   BLAME ATARI, they deserve it.
|> 
|>   Bullpuckey.  He's an Amigan.  He's not CAPABLE of knowing better.  For 
|> that matter, you aren't either.  Why not take your silly flames back to 
|> advocacy, where you can be with your fellow fools?

   OK, I admit it, I am an AMIGAN.  OK? OK...

 But I don't think I am making silly flames... Why did I say Blame ATARI?
'cause the other guy said something about not doing that, and I strongly
believe that ATARI has to be blamed for a lot of mistakes at this point
in time (Falcon delay?, Tramiel close-minded thinking?).

  And how could I not resist answering back to something that is false?
Sorry, I couldn't help it.  BTW, below is my full signature now that
I have been 'discovered' :-)  I still have AND LIKE my ATARI 130XE...

|>  
|>  - Mark Hughes (Caves of Steel 509-624-2078)  mhughes@comtch.spk.wa.us

-- 
--------------------------------------------------------------
  Raist   // Amiga 500, 38Mhz Special MegaMidget Racer
        \X/  Avid user of AmigaVision, sending mail from Mayaguez, Puerto Rico 
---------
           "If the PC or Mac continues to be the standard,
            the SkyNet will never be built." - OUCH! were not my words!

   Oh well, for the last time, my full signature... I try to avoid it
on "foreign groups."
From: bull@vaxc.cc.monash.edu.au
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Falcon BUS..
Date: 21 Nov 92 18:21:23 +1100
Organization: Computer Centre, Monash University, Australia

paetau@mits.mdata.fi (Rasmus Paetau) writes:
> jornmoe@fredrik.atari.no writes:
>
> [Lots deleted]
>
>>HOWEWER, when requiering more than 2 simultainious channels, you will have to
>>add external AD/DA converters to the DSP's external port. Only then you
>>HAVE to use the DSP for direct to/from disk recording/playback!
>
> Do you mean to say that the Falcon really only has 2 channels? What's
> all the talk about 8-channels then? Even the STe has 4 channels if I
> have understood correctly, at least my STe plays soundtracker modules
> with 4 channels.

        One of the people in the same dept as I work in used to be a
programmer for Fairlight (an Australian company who make high end
music equipment). He said the DSP (MC56001?) can support 8 audio channels
(but I think this is 8 virtual channels which are added to form a stereo
pair). I didn't discuss the matter in depth (so sue me :-).

           Bull@vaxc.cc.monash.edu.au  OR  bull@monu1.cc.monash.oz
                    DOD# 251  '84 VF 750   Closet Ducatisto
             Disclaimer. If you love your llama, let it lambada.
Newsgroups: comp.sys.atari.st.tech
From: hyc@hanauma.jpl.nasa.gov (Howard Chu)
Subject: Re: Falcon BUS... DSP
Keywords: SoUnD
Organization: SAR Systems Development & Processing, JPL
Date: Thu, 19 Nov 1992 04:15:28 GMT

In article <2681@ulysse.enst.fr> elendir@inf.enst.fr writes:
>Warwick Allison writes
>] Also, with the DSP running at 32MHz, it has time for quite a few
>] instructions for fiddling with those values too, besides adding the
>] sounds together.  Of course, when processing 90 voices at once, you'd
>] be pushing it pretty hard :-) 
>
> A 32 MHz DSP has a 16 MHz instruction clock rate. A 1 Mbyte/sec throughput  
>corresponds to 300 KDSPwords/sec, or one interrupt every 3 us. You have time  
>to execute 48 instructions then between each interrupt. Enough to do some  
>pretty effects : Surround, Echo, Reverb, Basic IIR filters and much more.
>
> If you want a demo of the sound capabilities of the DSP, watch out for the  
>Audio Fun Machine demo at the Comdex (Personnal pub). 

I just got home from Comdex. Yeah, the AFM is a nice little toy. (All kinds
of sound effects in realtime.)

As for sound channels, I think Warwick has it right on the money. (Although
trying to implement an actual orchestra, and then only going to 11khz sampling
is going to put a real damper on your instruments, eh? }-) My company is
currently showing a single-line voice-mail system on the Falcon (most of the
group is still in Vegas right now) but it would be trivial to bump it up to
6 or 12 phone-lines per sound-track, giving a maximum capacity of handling 96
phone lines simultaneously. (I suppose we would have to be nice and leave
at least two channels free for system audio, though, unless the machine was
used as a dedicated automated response system...)
-- 
  -- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA

All true wisdom is conveyed in one-line witticisms.
From: warwick@cs.uq.oz.au (Warwick Allison)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Falcon BUS..
Date: 16 Nov 92 23:24:04 GMT
Reply-To: warwick@cs.uq.oz.au

paetau@mits.mdata.fi (Rasmus Paetau) writes:
>jornmoe@fredrik.atari.no writes:

>>HOWEWER, when requiering more than 2 simultainious channels, you will have to
>>add external AD/DA converters to the DSP's external port. Only then you
>>HAVE to use the DSP for direct to/from disk recording/playback!

>Do you mean to say that the Falcon really only has 2 channels? What's
>all the talk about 8-channels then? Even the STe has 4 channels if I
>have understood correctly, at least my STe plays soundtracker modules
>with 4 channels.

Slight misunderstanding here.

The Falcon only has two PHYSICAL channels - ie. normal stereo, just like the STe.

As far as "voices" go (ie. internal channels), I don't see why there would be
any limitation.  Since the DSP can handle 1Mbyte/s of incoming data, you
can have as many channels as you want - the more channels, the lower the
frequency.  For example, just using the "1Mbyte/s" value, you should be able
to process 20 16-bit channels, each at 25kHz (20 * 2bytes * 0.025M/s = 1Mbyte/s).
Or, about 8 16-bit channels, each at 62.5kHz, which is around the published
limit.

I guess you could have 90 little 8-bit Apple Mac (11kHz) voices too, if you
wanted to.

How many instruments in an Orchestra?  :-)

Also, with the DSP running at 32MHz, it has time for quite a few
instructions for fiddling with those values too, besides adding the
sounds together.  Of course, when processing 90 voices at once, you'd
be pushing it pretty hard :-) 

NOTE:  This is all quite theoretical, based solely on the FACT that the DSP
can access main memory at 1Mbyte/s, which it can (the hard-drive controller
accesses it at something like 3Mbyte/s, so it's not a major feat).  The
actual implementation would probably operate by transfering sound data in
chunks from each of the currently playing sounds, storing them in the DSP's
memory as a buffer, since reading 20 words from different parts of memory
isn't very efficient :-).

--
Warwick
--
  _-_|\      warwick@cs.uq.oz.au            /Disclaimer:
 /     * <-- Computer Science Department,  /  
 \_.-._/     University of Queensland,    /   C references are NULL && void*
      v      Brisbane, Australia.        /