HDTenEightyP/NetNews huggingface dataset:
From: aeg03@rrz.uni-koeln.de (Jan T. Kim)
Subject: GFA and FPU support (was: Some old questions)
Reply-To: kim@vax.mpiz-koeln.mpg.dbp.de
Organization: Regional Computing Center, University of Cologne, F. R. Germany
Date: Mon, 09 Nov 92 20:54:24 GMT

In <af49f08f@Kralizec.fido.zeta.org.au> michael.smith@f842.n800.z3.fido.zeta.org.au (michael smith) writes:

>Original to: fsctc@lerc03.lerc.nasa.gov
>In a message of <27 Oct 92 22:37:01>, fsctc@lerc03.lerc.nasa.gov (3:713/602)
>writes:

> f> 4.  Is there a version of GFA BASIC that supports the math coprocessor
> f> on an ST (as a peripheral device)?  Is there one that supports the math
> f> coprocessor on the TT?  Will this run under the TT RAM?

>At this point, no.

I don't think that's correct. When the copy of GFA basic 3.60  TT
arrived here, I did the following quick test:

t%=TIMER
FOR i&=1 TO 1000
  l=l+SIN(RAD(i&))*COS(RAD(i&))
NEXT i&
t%=TIMER-t%
PRINT "ohne ~TT?: ";t%/200;" sec.",l
~TT?
CLR l
t%=TIMER
FOR i&=1 TO 1000
  l=l+SIN(RAD(i&))*COS(RAD(i&))
NEXT i&
t%=TIMER-t%
PRINT "mit ~TT?:  ";t%/200;" sec.",l

The loop takes .825 seconds without and .180  seconds  with  ~TT,
showing that there definitely is a very significant difference in
speed between the  TT  specific  rountines  and  those  that  are
designed  to run on all 680x0 Ataris. I haven't analyzed the code
and verified if the speedup is due to FPU usage, though.
For those not familiar wiht GFA: TT is a  boolean  function  that
returns  TRUE  if the program runs on a TT. Programs compiled and
linked carry two versions of some routines, one that runs on  all
Ataris  and  one  that  is  optimized for the TT. Originally, the
pointers to those routines are set to use the all-Atari versions.
If  the  TT  function  is  called  and  a  TT is detected, the TT
function changes those pointers to use the TT optimized versions.
At the CeBIT 1992, they demonstrated this at  the  GFA stand, and
claimed the speedup was in large part due to FPU usage.

>Richter have recently acquired the rights to GFA basic
>(ST only) from GFA themselves, and are undertaking a complete rewrite, with
>the intention of completely legalising the package.

>They may add this support - however I have no information either way.

According to what Richter told me on the phone recently, the  GFA
version  developed  by  them  will  run  and  be supported on all
Ataris, including the Falcon, and it  will  run  under  MultiTOS.
This is also what Richter announced at the Atari Messe.
Oh yes, and the support will not be continued to be done  in  the
clumsy way described above, they assured me at the Messe. So save
your sneering remarks :-)

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


Newsgroups: comp.sys.atari.st.tech
From: aeg03@rrz.uni-koeln.de (Jan T. Kim)
Subject: Re: Ethernet for the Atari ST ?
Reply-To: kim@vax.mpiz-koeln.mpg.dbp.de
Organization: Regional Computing Center, University of Cologne, F. R. Germany
Date: Tue, 10 Nov 92 18:19:00 GMT

In <BxI0Ft.MHD@dcs.ed.ac.uk> scgk@dcs.ed.ac.uk (Simon Kinahan) writes:


>  I have been wondering recently whether there is an Ethernet card or suchlike
>available for the ST.
>  I have been discussing networking with freinds recently and I assumed there
>would be come kind of ethernet interface available but I have checked all the
>magazines and I cannot find one.
>  This strikes me as odd especially as ethernet intefaces are available for
>everything else under the sun.
>  Is there is any reason why the ST should be an exception.

No, absolutely not. There are at least  three  ethernet  adapters
for the Atari ST/STe/TT computers, namely:

PamsNet: This ethernet based Atari network allows you to  network
up  to  127  Atari  computers.  There  are  three versions of the
adapters, one for ACSI, one for the Mega Slot and one for the VME
slot.  PamsNet  uses a special network protocol, but TCP/IP and a
gateway to Novell are available. An unique feature of PamsNet  is
the  availability  of  a server for a VAX under VMS, which allows
transparent access to the VMS filesystem over the network.
BioData: Another ethernet based Atari network. I  don't  know  if
there  are other adapters than those for ACSI for BioData. TCP/IP
is available, and since BioData is also available  for  DOS  PCs,
they can be integrated without any problem.
Riebl Card plus: I mostly know about this one from  the  net.  It
seems that the network software associated with the Riebl card is
slow and flaky, but it seems to be the  only  ethernet  card  for
Ataris  for which technical documentation is publicly accessible.
A group at the TU Wien has developed a  TCP/IP  package  for  the
Riebl card.
It seems that a main difference between ethernet boards  for  the
Ataris  and  boards  for  PCs is that the Atari boards tend to be
available only as a package with  hard-  and  software,  and  the
technical  information  is  not  available  to everyone. At least
PamsNet requires you to sign a  non-disclosure  agreement  before
they  give  you  programming  manuals  and  such,  as  far  as  I
understand things.

I hope you can use this info. We have PamsNet here, feel free  to
mail  or  to post if you're interested in additional information.
Of course, I'd love to get into contact with other PamsNet users.

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  >=-----*
Newsgroups: comp.sys.atari.st.tech
Subject: Resource Constrution Program that generates C source
From: erkamp@JANUS.ARC.AB.CA (Bob Erkamp)
Date: 10 Nov 92 12:13:48 MDT
Reply-To: erkamp@JANUS.ARC.AB.CA
Organization: Alberta Research Council

I am looking for a program to generate resource files as well as the equivalent 
C source code. I would prefer PD but will take recommendations for commercial
products as well. Any help would be appreciated.

Bob
From: andrew@minster.york.ac.uk
Newsgroups: comp.sys.atari.st.tech
Subject: Co-operating processors on the Falcon
Date: 12 Nov 92 13:16:20 GMT
Organization: Department of Computer Science, University of York, England

If the Falcon is multitasking how will the operating system
ensure that memory access by the DSP are safe?  Will programs running in the
DSP get swapped in and out or is it used like a 'dumb' peripheral which 
processes have to contend for?  I wonder how machines like the NeXT do it?

Will this also mean that two assemblers are needed too?  One which
programs for the 68030 CPU are written/compiled and one which is used for
the 56001 DSP.  Writing programs for the Falcon will be complicated.  First
I'd write a program in C for the CPU and then one for the DSP(?) and somehow
link the two so that the DSP program is downloaded into the DSP where it is
initiated by the main program?

I'm sorry if this all sounds a little naive but I've never explored co-
processor systems but when I get my Falcon I'll have to.

-Andrew.

P.S.
Will it be possible to perform JPEG conversions on the Falcon using the DSP
so that they are 'super' fast?  The conversion programm will obviously have
to read and write from main memory which is where my question about security
on memory access comes in for multiprocessing systems.

---------------

 Andrew Hague - Researching Computer Aided Learning & On-Line Lectures.
 Department of Computer Science.
 University of York,			"To get that all over tan stand
 YORK.					 still at the north pole during
 Y01 5DD				 the summer." A. Hague 6-Nov-92
 Tel: (+44/0)904 432762

 E-MAIL: andrew@minster.york.ac.uk
From: sheppard_r@kosmos.wcc.govt.nz
Newsgroups: comp.sys.atari.st.tech
Subject: Re: HD help please
Date: 7 Nov 1992 09:32:47 GMT
Organization: Wellington City Council (Public Access), Wgtn, Nz
Reply-To: sheppard_r@kosmos.wcc.govt.nz
NNTP-Posting-Host: kosmos.wcc.govt.nz

In article <1992Nov5.113359@sees.bangor.ac.uk>, ms9211@sees.bangor.ac.uk (Mr Colin Simons) writes:
>
>Hi,
>
>I have a Miniscribe HD with an Omti controller, that is proven to
>work on an ST but refuses to play ball with my STE.
>
>Colin. ms9211@sees.bangor.ac.uk

You don't say what host adapter you are using, also what type of DMA chip
that was fitted, is it the 1991 version..

Early SUPRA host adapters will not work on a STE....



Roger.............          sheppard_r@kosmos.wcc.govt.nz

Newsgroups: comp.sys.atari.st.tech
From: hutch@bellman.lanl.gov (John Hutchinson)
Subject: Re: Checking if the printer is ready for input.
Reply-To: hutch@bellman.lanl.gov
Organization: Los Alamos National Laboratory
Date: Mon, 9 Nov 1992 18:36:08 GMT

In article 1uewTB2w165w@sys6626.bison.mb.ca, marco@sys6626.bison.mb.ca (John Perry) writes:
>How can I check to see if the printer is ready for input? I tried using 
>Bcostat(), but it returns -1 (which is supposed to mean I can send the 
>printer data) even when the printer was turned off!

John, I seem to remember having the same trouble on occasion with Bcostat() and I
believe I avoided that with Cprnos() which is GEMDOS(17) that checks the status
of the parallel port.  You might give that a try.

---

___________________________ John "HUTCH" Hutchinson _________________________
_________________ Fair Dinkum Technologies     Member - IAAD  _______________
________________ "No worries, mate... it's from Fair Dinkum!" _______________
____________ email: hutch@bellman.lanl.gov   GEnie: FAIR-DINKUM _____________


Newsgroups: comp.sys.atari.st.tech
From: bgilbert@cs.washington.edu (Ben Gilbert)
Subject: Re: Falcon BUS..
Organization: Computer Science & Engineering, U. of Washington, Seattle
Date: Sat, 14 Nov 92 02:44:58 GMT

In article <1992Nov13.225216.5984@prime.mdata.fi> paetau@mits.mdata.fi (Rasmus Paetau) writes:
>
>Is the 68030 going to have to handle the screen-displaying all by
>itself? I heard there would be some kind of graphics processor named
>VIDEL, do you know anything about it? How about the Blitter then? Does
>anybody know if the blitter can function simultaneously with the main
>processor, or does the processor have to halt while the blitter is
>working?
>

Why does everyone keep asking if the CPU has to halt whenever some sort
of coprocessor is operating (DMA, VIDEL, BLiTTER, whatever)?  The whole
point of even having a coprocessor is to let the CPU churn away at other
stuff while the coprocessors grab the data and deal with it, all by
themselves.  What would be the point of having a blitter if the CPU had
to halt and wait for it to finish?  You might as well have the CPU
perform the blitting operations then (and yes, before someone complains,
the blitter does do more stuff than the CPU could alone, and probably
more efficiently too).

In conclusion, the CPU does not HALT for anything -- you may run into
some bus contention when DMA or similar operations are taking place,
but that won't generally affect the CPU much.  The whole idea of all
the COprocessors is that they can run in tandem with the CPU and
take the burden away from the CPU on tasks such as transferring, say,
10 MB from the hard drive.  Such tasks are trivial to implement so it's
stupid to waste precious CPU time doing them.

Sorry if this seems a bit out of hand, but think about it : why do
coprocessors exist on the Falcon and what do they accomplish?  It's
really a simple matter.  :-)

>
>--
>-----------------------------------------------------------------------
>| Rasmus Paetau (paetau@mits.mdata.fi) | Waiting for the Atari Falcon |
>-----------------------------------------------------------------------
>

-- 
Ben Gilbert				e-mail : bgilbert@cs.washington.edu
Department of Computer Science
University of Washington
From: mbaffoni@skat.usc.edu (Michael Baffoni)
Newsgroups: comp.sys.atari.st.tech
Subject: MiNT, TCSH, CoNnect, Warp9...what they have in common?
Date: 5 Nov 1992 23:51:18 -0800
Organization: University of Southern California, Los Angeles, CA
Distribution: world
NNTP-Posting-Host: skat.usc.edu

 
	My journey in search of a system with MiNT, TCSH, Warp9, and CoNnect
working very happily together has been a long one with both ups and downs,
and strange sights indeed!  Let me exemplify:

	When I load _just_ MiNT and TOSwin(1.1), I am completely, utterly
unable to run another GEM program - PID errors and such.

	If I load _just_ MiNT and TOSwin and have something "INIT="ed,
it says "leaving MiNT" just before it drops me into the desktop, nothing
running, and every .acc except TOSwin is loaded.  I can't run .prgs.

	If I load Warp9 (as well as all the rest of my junk), MiNT, TOSwin,
Warp9.acc, then everything has the new font, but I still can't run any
.prgs. Warp9.acc is accessible, no bombs.

	If I load Warp9 (as well as all the rest of my junk), MiNT, TOSwin,
Warp9.acc and have ConNect set to autorun (from the inst app of GEM), it runs 
at bootup, just like it should, Warp9 is active, MiNT and TOSwin are active,
and I have no problems whatsoever accessing the Warp9.acc.  In fact I can
quit CoNnect, it puts me at the desktop, I can run most of my .prgs (including
the old, original First Word!) and both Warp9 and TOSwin accs are accessible.
No bombs.  This would be idyllic....EXCEPT EVERY ONCE IN A WHILE IT SEMI-LOCKS
UP!
	This lockup behavior occurs whether I have just MiNT and TOSwin or
whether I have Warp9 and the kitchen sink thrown in (but never when MiNT isn't
loaded).  What happens is whatever was happening stops.  Sometimes I can
use the mouse (it moves as per normal) but it can't _do_ anything.  Menus
aren't selected, window boxes can't be pressed/highlighted.  Keyboard at this
time _definately_ does not work.  The only way I have found to stop the lock
is to warm boot.  Has anyone _ever_ had MiNT lock up like this?  Is this not
a real Lockup, but rather is some process that is stealing all the CPU cycles
except what is used for the mouse handler?  Remember, this is with _or_ without
warp9 so that shouldn't have anything to do with it.  Oh, if it makes any
difference, when I _do_ have Warp9 and everything else loaded, the lockup
occurs more often - I can do it every time, by dialing in from Connect.  As
soon as the modems connect with each other, it locks up.

	If _anyone_ can help me with this, I would _greatly_ appreciate it.

	Thanks in advance,

	MikeB
Date: Fri, 13 Nov 92 02:52:40 +0100
From: Benedikt_Heinen@firemark.fido.de (Benedikt Heinen)
Subject: Re: Resource Constrution Program that generates C source
Newsgroups: comp.sys.atari.st.tech
X-Comment-To: (Erkamp)
Organization: Firemark.BBS - 1st Atari ST Node Aachen 

 e> I am looking for a program to generate resource files as well as the
 e> equivalent C source code. I would prefer PD but will take recommendations
 e> for commercial products as well. Any help would be appreciated.
Perhabs try ORCS... (Shareware - fee 50,-DM  ~30). I think there is a copy of 
ORCS on atari.archive

bye,

    Benedikt
From: jornmoe@fredrik.atari.no (Joern Moe)
Newsgroups: comp.sys.atari.st.tech
Organization: Atari Corp. Scand. AB (Norway)
Subject: Re: Falcon BUS..
Reply-To: jornmoe@fredrik.atari.no
X-Software: HERMES GUS 1.03 Rev. Apr 14 1992
Date: Mon, 09 Nov 1992 18:43:04 MET

In <mpnolan.720881057@unix1.tcd.ie>, Mark Patrick Nolan writes:
>I believe that Atari have at last got their act together...
>
>Q: As the Falcon has (from what I've heard) one bus (32),
>how will the custom chips (DSP,DMA Sound,Blitter,H-Scrolling,..)
>interact, and will the system lose preformance as a result?
>
>Surely the DSP has it's own bus, as it does have 56k of it's own 
>memory!?
>
>You can always tell how good a machine is by observing how 
>defencive amiga owners get...and believe me, I've never seen
>them so bad...!
>
>Please dont spare me on the technical info., I'd love to hear it
>(I'm sure I could understand it - I study Comp. Sci.)
>

There's a lot of confusion going on here. So let me clarify some topics:

The DSP has its own 24Bit databus for local memory. On the Falcon, the DSP has
32 K-Words of 0 waitstate S-RAM. One word is 24 bit (i.e. 3 byte) giving 
96KByte local memory.

The DSP does communicate with the rest of the world (including 68K bus) 
through serial interfaces. The serialinterface to the 68K bus is a full
duplex ~1Mbit/s interface, as is the communication with the external
dsp port (wich howewer is multiplexed into 8 slower channels).
Just a comment to this: As long as the data rate the DSP uses to 'fetch' data
from the 'real world' (external port) is the same (or less than) the datarate
between the DSP<->CPU/memmory, there is realy no reason to complain!

The 'prosessor direct slot' (PDS) intended for hardware PC emulators and
the like, is a 68000 buss (16D/24A) with som extra controlsignals (interupt 
and buss artbitration).

I do not know if the CPU<->memory databus is 16 bit or 32 bit. But given the
benchmarks that rates the falcon to >450% i would guess it is 32Bit wide!
Surely the addressbus is 24 bit!

The builtin 16bit sound subsystem does not use the DSP. It CAN use it but it 
doesn't have to. Direct to disk recording and playback can (and will) be done 
with only the CODEC and the SDMA involved!
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!

-- 
  _______________________________________________________
 / Joern F. Moe /  All above is my own personal opinion! \
/ Oslo, Norway /  Any lack of opinion above is also mine! \
-----------------------------------------------------------
From: slansk@ee.ualberta.ca (Richard Slansky)
Newsgroups: comp.sys.atari.st.tech
Subject: Accelerator Boards
Summary: Any recommendations?
Keywords: Upgrade Accelerator math coprocessor
Date: 10 Nov 92 05:35:22 GMT
Organization: University Of Alberta, Edmonton Canada


Can someone recommend an accelerator board which allows for the 
installation of a math-coprocessor. Also of interest is one
which has capacity for additional memory. Do-it-yourself 
projects are also of interest provided I don't have to
produce my own Printed Circuit Board. It is for a an 520 STfm
which has already been upped to 1Meg on the motherboard.
What have people used that is good and what is bad. I also 
do not have unlimited money to spend (who does?).


					Rick Slansky
					slansk@bode.ee.ualberta.ca
					University of Alberta
Newsgroups: comp.sys.atari.st.tech
From: micro@imada.ou.dk (Klaus Pedersen)
Subject: Re: 16-bit RAM Access on Falcon ?
Organization: Dept. of Math. & Computer Science, Odense University, Denmark
Distribution: eunet
Date: Tue, 10 Nov 1992 18:05:20 GMT

peter@rhrk.uni-kl.de (Gunter Bitz) writes:

>>>
>>>>  Is it true that the Falcon030 only has 16 bit RAM Access ?

>I don't know what Qindex does, but I testet the following:
>A short loop (which fits completely in the processor cache) like that:

>ll:
>	move.w	d0,(a0)+
>	dbf	d7,ll
>and another like
>ll:
>	move.l	d0,(a0)+
>	dbf	d7,ll

Try with :

        move.l  #data+3,D0
        and.b   #~3,D0
        move.l  D0,A0
ll:     move.l  d0,(a0)+
        dbra    d7,ll
data:


Is it faster when it reads from the memory rather than writing to it?


-Klaus
From: leo@dcs.warwick.ac.uk (Leo Hendry)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Extended characters with printf()
Date: 9 Nov 92 11:20:03 GMT
Organization: Department of Computer Science, Warwick University, England

In article <hjv.721232850@groucho.phil.ruu.nl> hjv@phil.ruu.nl (Hendrik Jan Veenstra) writes:
>marco@sys6626.bison.mb.ca (John Perry) writes:
>
>>Does anyone know how to use the extended character set with printf()? For
>>example, how would I go about printing the "arrow" symbol?
>
>As far as I know this is not possible. The control-chars (<32 ?) and the 'high'
>ascii chars (>127 ?) are just 'non-printable characters'.
>If I'm mistaken (which I surely hope :), let someone please correct me.

Use Bconout(5,chr) to print a non-printable character (5 is the raw conout
device).  To do this from printf write the following:

#include <osbind.h>

#define BUF_SZ  something big

int printf(void *wibble)
 {
 char   buffer[BUF_SZ], *ptr;
 int    len=sprintf(buffer, wibble);
 for (ptr=buffer; *ptr; Bconout(5, *ptr++));
 return len;
 }

Obviously this could be improved, but gives you the general idea (remember \n
won't work!)

Hope this helps

- Leo

>
>--
>Hendrik Jan Veenstra    hjv@phil.ruu.nl  *  How can I save my dreams
>Dept. of Philosophy                      *  in the nightmare, in the flood
>University of Utrecht                    *  But I try.
>The Netherlands                          *
Newsgroups: comp.sys.atari.st.tech
From: annius@loki.research.ptt.nl (Annius Groenink)
Subject: Re: MiNT and *.XFS files
Reply-To: A.V.Groenink@research.ptt.nl
Organization: PTT Research
Date: Wed, 11 Nov 1992 16:29:03 GMT

grier@bnr.ca (Brian Grier) writes:

>Basically what ".XFS" modules are available in the public domain?
>Also what is the basic template for creating a ".XFS" file?

The 'alias drive U as drive O' is the only one I've seen so far.

-- 
Annius Groenink  --  Universiteit Utrecht  --  PTT Research Leidschendam
annius@research.ptt.nl/avgroeni@cs.ruu.nl       Maths/Comp.Sc./TOS/Music       
Newsgroups: comp.sys.atari.st.tech
From: CASTAN@bonnie.physik.uni-stuttgart.de ()
Subject: Re: Falcon BUS..
Organization: Physics Dept, University of Stuttgart, FRG
Date: Fri, 6 Nov 1992 09:39:05 GMT
X-News-Reader: VMS NEWS 1.24

In <mpnolan.720881057@unix1.tcd.ie> mpnolan@unix1.tcd.ie writes:

> I believe that Atari have at last got their act together...
> 
> Q: As the Falcon has (from what I've heard) one bus (32),
> how will the custom chips (DSP,DMA Sound,Blitter,H-Scrolling,..)
Blitter is new with 16 MHz

> interact, and will the system lose preformance as a result?
There are 4 independent parts that can be connected together
(free programmable): 68030, 56001, CODEC (=AD/DA/sum), ?

> 
> Surely the DSP has it's own bus, as it does have 56k of it's own 
> memory!?
32k words of fast (32 MHz) SRAM (3 bytes/word). Own bus.

> 
> 						Thanks,  Mark Nolan
> 

Gerd



##############################################################################
internet: CASTAN@bonnie.physik.uni-stuttgart.de
##############################################################################
Real Name:          # Einem Land, dessen Sprache das Wort "Kultur - Beutel"
Gerd Castan         # hervorgebracht hat, ist nicht zu trauen.
Hoehbergstr. 16     #                 (Luisa Francia)
D-7000 Stuttgart 60 #

Newsgroups: comp.sys.atari.st.tech
From: leo@dcs.warwick.ac.uk (Leo Hendry)
Subject: Re: Falcon BUS..
Organization: Department of Computer Science, Warwick University, England
Date: Thu, 5 Nov 1992 11:49:27 GMT

I asked questions similar to these a month or two ago, but nobody answered.
Perhaps somebody knows the answers now.

1) What is the speed of the Falcon's memory (Somebody said it had 0 wait
states which seems to imply 16MHz, but they may have been wrong)
2) How does the DSP access the main memory (Somebody said it is not connected
to the data bus, in which case I suppose it must be some kind of serial link)
3) Does the TOS V4 use the DSP to speed up things (for that matter does it
make intellegent use of the Blitter?)
4) Is the data bus between the memory and the 68030 16 or 32 bits wide (There
seems to be an argument going on about this).
5) Why does the benchmarks that I have seen posted here only indicate an
approx 3x speed increase and real-world tests (excluding any disk access)
only twice as fast?  If the data bus is twice as wide, the memory twice as
fast, the processor at least twice as efficent and running at twice the clock
speed it should be more like 10 times the speed.

Thanks,
Leo