HDTenEightyP/NetNews huggingface dataset:
From: kjohnson@castor.cs.uga.edu (Kristopher Johnson)
Newsgroups: comp.sys.atari.st
Subject: Re: Atari Conference at GEnie 9/9
Date: 9 Sep 92 06:47:29 GMT
Distribution: na
Organization: University of Georgia, Athens

Good news!!!  According to Bill Rehbock at the CIS conference, 
the Falcon030 has passed FCC Class B specifications and they
are only waiting for the paperwork certification.  And people
thought it would take a few months just for THIS to happen. <grin>
Newsgroups: comp.sys.atari.st
From: cummins@a.cs.okstate.edu (CUMMINS JOHN WILLI)
Subject: Re: Is Falcon worth buying?
Organization: Oklahoma State University, Computer Science, Stillwater
Date: Sun, 13 Sep 92 06:37:13 GMT

In article <1992Sep12.094141.18101@sci.kun.nl> leonp@cs.kun.nl (Leon Pillich) writes:
>- Buying a falcon with 4 meg and a 65 meg hd and a vga monitor.
>  This looks great. With MultiTos it certainly offers what I'm looking for and
>  a lot of nice extras and its not to expensive. Memory can still be
>  expanded and I already have lots of software (partially self-made) that 
>  can be used on the falcon. However: it cannot and will never run
>  unix (at least not for free) with X-Windows/OpenLook and I am not
>  very confident in Atari at the moment. They might just make it, because]
>  the falcon is a winning machine and a great MULTI-MEDIA machine, but
>  they have to invest in advertisement and software for it.
>

Have you fooled with MiNT/gcc/tcsh etc?
This is about as close to unix as I've ever been.  Cost's less than ASV too!

Seriously,
jc
Newsgroups: comp.sys.atari.st
From: wwc@vsnhda.cern.ch (Wolfgang Wander)
Subject: Re: Communication programs
Organization: European Organization for Nuclear Research, Geneva
Date: Fri, 11 Sep 1992 08:25:42 GMT

> > CoNnect is completely based on GEM and supports many MiNT/MTOS features.
> >
> >   Wolfgang Wander (the author)
> >
> 
> Where can this program be FTP'ed from?  It sounds like it might be a
> pretty good term program.  Right now I use Interlink, because it has an
> external file that you can load and it gives it full ANSI compatibilities
> which I find necessary much of the time.

On atari.archive.umich.edu /atari/telecomm or
   ftp.uni-kl.de /pup/atari/telecom

   Wolfgang


Newsgroups: comp.sys.atari.st
From: grante@aquarius.rosemount.com (Grant Edwards)
Subject: Re: sampling and human hearing range (was Re: (none))
Reply-To: grante@aquarius.rosemount.com (Grant Edwards)
Organization: Rosemount, Inc.
Date: Mon, 14 Sep 1992 03:04:59 GMT

egates@triton.unm.edu (EL GATES) writes:
: 
: BTW, the reason that CDs  only sample at 44.1 kHz is that when they 
: first came out that was about the best they could do and then couldn't
: up the sampling rate since so many people had already bought CD players
: for the 44.1kHz sampling rate.  It also turns out (I believe) that a
: sampling rate higher than 48 kHz doesn't really get you anything as far 
: as better quality reproduction, (again see Nyquist Theorem) and does 
: get more expensive to make good AD converters.
: 

I thought that they reduced the sampling rate from 48KHz to 44.1 KHz
so that the 9th symphony would fit on a single disk.  Can't let that
legend die, can we?

--
Grant Edwards                                 |Yow!  Now, I think it would
Rosemount Inc.                                |be GOOD to buy FIVE or SIX
                                              |STUDEBAKERS and CRUISE for
grante@aquarius.rosemount.com                 |ARTIFICIAL FLAVORING!!
From: ucacmsu@ucl.ac.uk (Mr Stephen R Usher)
Newsgroups: comp.sys.atari.st
Subject: Re: More TT030 help...
Date: 7 Sep 92 10:24:16 GMT
Organization: Bloomsbury Computing Consortium, London

In article <H.jMKlAl4NqCU@fredrik.atari.no> jornmoe@fredrik.atari.no writes:
>In <1992Sep4.042609.12758@u.washington.edu>, Daniel Aylward writes:
>>I just bought an 8 meg TT.  I have a hundred zillion questions, but I'll
>>start off with 2...
>>
>>1)  How do you use the Fast RAM?  All memory tests show I only have 4,
>>which I can understand, but when I run Calamus and load all my 130 fonts
>>it says I'm out of memory (I know that's only 4 megs because I could load
>>most of my fonts on my 4 meg Mega STe).  Do I have to set a bit on the
>>programs I want to make use of Fast RAM?  How do I do that?
>
>Calamus can not use TT-ram.

Oh yes it can! If you change the header Calamus will complain at startup (it
believes it's been infected by a virus) but will work fine from then on.
(The copy I have is a seconds hand copy of version 1.09(UK))).

>BUT, things like AHDI (harddiskdriver), 
>CACHExxx.PRG, FOLDERxxx.PRG and other applications in the AUTO folder
>can be loaded to TT-RAM, giving you more free ST ram. Also accessories
>may be loaded into TT-RAM.

Putting CACHExxx.PRG in TT ram can slow it down, especially for ACSI drives.

>To get a program (or ACC) to load into TT-RAM you either use one off the
>many utilities specially made for this, or you use a fileeditor

Best not set the fastload bit for ACCs, it can cause problems.

>The first 
>aproach is the easiest. There is a CPX module around (FILEINFO.CPX I think 
>it's caled), and there is a ACC around (SETFLAG.ACC). The second approach
>is a litle more complicated:
>It is byte no. 26 (counting first byte as 1) that holds the program flags.
>Note that most file-editors count the first byte as 0.
>Bit 0 is the fastload flag
>Bit 1 is the 'malloc' flag (malloc from     ST (unset) or TT (set) ram.)
>Bit 2 is the 'load'   flag (Load program to ------------ " ------------)
>
>You have to try out the different combinations to decide wheter a program can
>use the TT-ram. Surprisingly many programs does run well in TT-ram (but not
>Calmus).

Oh yes it does, see earlier.

>Newer profesional programs (like Calamus SL, Cranach etc.) use both kind of 
>ram. I've seen Cranach report over 256Mb (Yeah 256MEGABYTE) free on a TT!!!
>
>>2)  Screen trouble(?).  My TT Medium res screen is supposed to be 640X400
>>16 colors, right?  
>No wrong, it is actually 640x480 16 colors! 
>
>>Dan Aylward
>>dud@u.washington.edu
>>
>
>-- 
>  _______________________________________________________
> / Joern F. Moe /  All above is my own personal opinion! \
>/ Oslo, Norway /  Any lack of opinion above is also mine! \
>-----------------------------------------------------------


Steve
--
Addresses:-
JANET:-		ucacmsu@uk.ac.ucl or	steve@uk.ac.ox.earth (preferable)
Internet:-	ucacmsu@ucl.ac.uk or	steve@earth.ox.ac.uk (preferable)
Newsgroups: comp.sys.atari.st.tech
From: cs311113@umbc5.umbc.edu (cs311113)
Subject: Magnification
Organization: Univ. of MD, Baltimore County
Date: Thu, 10 Sep 1992 13:05:39 GMT

Morning..  I was just wondering, in some demos and other programs, they have 
very fast image or graphic manipulation.  For example, magnification.  What
sort of algorythim would you use for realtime zooming in on a block of the 
screen?  Thanks..
From: warwick@cs.uq.oz.au (Warwick Allison)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: "fast" sprites in C
Date: 16 Sep 92 02:22:51 GMT
Reply-To: warwick@cs.uq.oz.au

George Reimer@electro.el (1238) writes:

> How do the VDI calls compare? ( specfically the 
> raster operations ? ) Are they usefull only for 
> prototyping or can one implement a reasonable animation?

> If these calls are poor performers, is there assembly source
> code avaiable to replace them?


Over the past 6 months, I have been developing "AMS", the Atari Machine
Specific library.  It is for G++ program development, primarily focussed
on games (since non-real-time applications should generally avoid
machine specific coding).

For a simple example of what it makes possible, take a look at the
COMBAT game, now in the /atari/games directory (and /atari/newitems),
under the name "combat.zoo".  No source is provided as yet, but it will
all be free.  If you have G++ set up, and would like to use AMS, mail
me, and I'll make it available.  Combat is the first full game I've
made with AMS, although I did port GNUChess to a graphical interface
with an older version of AMS (just to try out the library - I'm not
into chess these days), which is also in the games directory.

I don't really intend to support "COMBAT", but I'll add the "Tank Pong"
feature...  Great Scott - how could I forget!


--
Warwick
--
  _-_|\      warwick@cs.uq.oz.au            /Disclaimer:
 /     * <-- Computer Science Department,  /  
 \_.-._/     University of Queensland,    /   C references are NULL && void*
      v      Brisbane, Australia.        /  
Newsgroups: comp.sys.atari.st.tech
From: avgroeni@cs.ruu.nl (Annius Groenink)
Subject: Official Keycode Guidelines of Atari
Date: Mon, 14 Sep 1992 14:20:48 GMT
Organization: Utrecht University, Dept. of Computer Science



I suppose you've all heard it: Atari has official key code guidelines.
Of course, we couldn't expect them to come up with REASONABLE propositions:

	code	operation	objection

	^O	Open		OK
	^N	New file	All right
	^Q	Quit		Of course
	^F	Find		Sure
	^G	Find Next	Fine
	^H	Replace		??? Never heard of this. I thought it was

					^R	Replace
					^T	Replace Next

				OK. What I did in my text editor is this: you use search all which
				marks all the targets that are found. (Multiple selections are NOT
				easy to implement...) Then you use ^H which replaces a multiple
				text buffer (filled in by the search routine with either one replacement,
				or in case of regexp s&r, a different replacement for each item found)
				with the selected fragments that were found.

	^W	Close Window	Well God D******* why this? I thought ^W was cycle windows
				and (maybe only in Germany, but after all that is the leading ST territory)
				^U was close window. OK, I implemented ^U for close window as well as
				^W, and put cycle windows on Alt-Q. (With all possible dangers of someone
				accidentally using Control-Q :)

This is all as far as I remember. They could have specified more, though,
to my taste. Does anybody have any suggestions/comments to what I've written?
Shouln't we **.tech readers make a more extensive list with more elaborate
comments like I've done here, and then distribute it widely (somewhat like the
picture format document that went round the world some years ago)?


-- 
________________________________________________________
    Annius Groenink|undergraduate student
Laan van Borgele 24|maths/computer science at the
   7415 DJ Deventer|University of Utrecht, Holland.
Newsgroups: comp.sys.atari.st.tech
From: apelled@cix.compulink.co.uk (Adam Pelled)
Subject: Re: problems w/ 2 SCSI drives on ST
Reply-To: apelled@cix.compulink.co.uk
Date: Wed, 9 Sep 1992 22:12:00 +0000


In article <1992Sep8.182604.23328@a.cs.okstate.edu>, cummins@a.cs.okstate.edu (CUMMINS JOHN WILLI) writes:
>>   I need to reformat the ST 296N on a low level, since it stems from a 
>>PC, where it was formatted with interleave 2.
>>
>
>a) the Seagate ROMS (296N anyway) have a problem...  You must set all drives
>in a system to an EVEN id to prevent problems, I've combined 296n(s) using IDs
>of 0,2 and 2,4 with no problems.  I got "the cure" via Tech. Info. at ICD.
>
>b) the Seagate 296n drives I use are MUCH faster at 2:1 interleave.  I'd
>reccomend you leave the interleave at 2:1 for now.  If you want to test 1:1,
>be prepared to change it back!  Again... this is a ROM problem, but I know of
>an update (by Seagate) to fix this.  Don't see any socketed ROMs on my 296n
>though... so I live w/o the fix.

    i didn't know about the EVEN bit. i do know that the 296N can't be
formatted to 1:1, but that is only from trying. i didn't know why. i have
a quantum 105 on ID 0 with 1:1, and the 296 (also dying) on ID 1 (i.e odd).
There doesn't seem to be any problems (apart from the usual sense $11 errors
that i am getting occasionaly anyway, regardless of any setup).
    i would appreciate if you could pass me some info on the ROM fix. i'd
like to try it, seeing as it's on its last legs anyway.

    Adam
From: "david snowdon" <david.snowdon@canrem.com>
Newsgroups: comp.sys.atari.st.tech
Subject: c help
Date: 6 Sep 92 16:50:34 EST
Reply-To: "david snowdon" <david.snowdon@canrem.com>
Distribution: comp
Organization: Canada Remote Systems

   I'm am unable to compile the Motorola 6809 cross-assembler using
the H&S Sozobon C compiler due to two errors:

           error in as.h (124): pointer type not allowed
           error in ffwd.c (10): pointer type not allowed
           2 errors

   The code for as.h (lines 123 and 124) is:

FILE    *Objfil =0;             /* object file's file descriptor*/
char    Obj_name[] = {"             "};

   And the code for ffwd.c (lines 9 and 10) is:

int     Forward =0;             /* temp file's file descriptor  */
char    Fwd_name[] = { "Fwd_refs" } ;

   I'm just starting learn how to program in C and could use any
suggestions that you might have.

      David
--
Canada Remote Systems  - Toronto, Ontario/Detroit, MI
World's Largest PCBOARD System - 416-629-7000/629-7044
From: dud@hardy.u.washington.edu (Daniel Aylward)
Newsgroups: comp.sys.atari.st.tech
Subject: Even MORE TT030 help
Date: 11 Sep 92 05:33:36 GMT
Article-I.D.: u.1992Sep11.053336.20699
Organization: University of Washington

Ok, I took apart my TT for the first time.  I now have a few more
questions...  How do I know what RAM is what?  Right now I can only access
the 4 megs of ST RAM.  There are 4 megs of RAM on the motherboard, and
also 4 megs on a daughter board directly under the HD.  There is an empty
socket that I've been told is for fast ram in front of the power supply.  
Since there are 8 megs in the machine, and only 4 seem to be accessable,
I'd assume something is wrong.  Should I unplug the board under the HD &
plug it in in front of the HD?  I don't think it'll fit in that small
space.  Are there DIP switch settings that make the TT RAM accessable?
Thanks for any help or suggestions in advance....

Dan Aylward
dud@u.washington.edu
Newsgroups: comp.sys.atari.st.tech
From: wilsont@holonet.net (Timothy Wilson)
Subject: digitized sound, how to?
Organization: HoloNet (BBS: 510-704-1058)
Date: Tue, 8 Sep 1992 05:07:14 GMT

Hi again. ok you tech guys...
how do i get sound samples out of my ST?
is optimized C fast enough to handle this job?


I've looked in my TOS book, but only the PSG s there, and it doesn't seem to
have a way to control the speaker directly.
I also looked at noisetra.s, (68k code for noisetracker), but it seems not
a single standard call is used (therefore i couldn't reference it)

Thanks for helping me with the screen memory... i found Setscreen...just what
i needed!

books, code, ftp site would be helpful!

Newsgroups: comp.sys.atari.st.tech
From: kslate@MtHolyoke.edu (Kevin D. Slate)
Subject: ANSI C
Organization: Mount Holyoke College
X-Newsreader: Tin 1.1 PL5
Date: Sun, 13 Sep 1992 02:10:11 GMT


Newsgroups: comp.sys.atari.st.tech
From: 7103_2622@uwovax.uwo.ca (Eric Smith)
Subject: Re: How do I replace an existing GemDos routine or add a new one?
Organization: University of Western Ont, London
Date: Mon, 7 Sep 1992 18:29:56 GMT

In article <B76NqB1w165w@ersys.edmonton.ab.ca>, mforget@ersys.edmonton.ab.ca (Michel Forget) writes:
> The reason I am asking about this is I am thinking about writing an ANSI
> emulator, and I would like to see if it is feasible to write it in the form of
> a TSR that any program could use simply by calling the appropriate routines.
> 

That's certainly feasible, but there are better ways to do it than replacing
(or adding new) GEMDOS calls, I think. I would set up a cookie in the cookie
jar, say with the name 'ANSI' and with a pointer to a function table as
its value. Programs which want to use the ANSI functions would look up the
cookie, get the table of functions from the cookie, and then jump through
the table to the appropriate functions.

(I think this is better than trying to add/replace GEMDOS calls because it
doesn't add any overhead on the trap #1 vector.)

Under MiNT (and probably under MultiTOS) you could write your ANSI emulator
as a device driver, and have it install a device like U:\DEV\ANSI; programs
could then open this device and use it just like any other. It probably
wouldn't be too hard to make your program work either as a device driver
(if MiNT is active) or as a 'cookie-driven' TSR; just make the functions
in the cookie's function tables the same as the functions needed for a MiNT
device.
--
Eric R. Smith                     email:
Dept. of Mathematics            eric.smith@uwo.ca
University of Western Ontario

Newsgroups: comp.sys.atari.st.tech
From: lahtinen@gideon.fmi.fi (Kimmo Lahtinen)
Subject: Re: problems w/ 2 SCSI drives on ST
Keywords: SCSI, GE-Soft, ST157N, ST296N, SCSI-Tools
Organization: Finnish Academic and Research Network Project - FUNET
Date: 10 Sep 92 11:33:43 GMT

boblu@tekgen.bv.tek.com (Robert Luneski) writes:

>In article <H._49DdC_yXeQ@wpcst1.phys-chemie.uni-wuerzburg.dbp.de> kruel@wpcst1.phys-chemie.uni-wuerzburg.dbp.de (Thomas-Martin Kruel) writes:
>>Dear netters,
>>
>>  Is it absolutely necessary to remove the resistor packs ? If so, 
>>which drive ? The physically last or the logically last one (which is 
>>different in that case) ?
>>

>Yes, it is absolutely necessary that you remove the terminating resistor 
>packs on all but the last physical drive in the SCSI chain.  

Actually this is not quite true. In most cases there is no need to
remove terminators, only if you have two similar drives. That
requirement was from the days of SASI. Sometimes removing terminators
may even course problems.

I have two drives in my Unix PC here at work and in Mega ST at home
and both have terminator resistors there and no problems.
--
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Kimmo Lahtinen                      E-Mail : lahtinen@gideon.fmi.fi       
Finnish Meteorological Institute    Phone  : +358 0 758 1322
Possessed by a Spirit               G3 Fax : +358 0 758 1396
Newsgroups: comp.sys.atari.st.tech
From: q92269@pbhrzx.uni-paderborn.de (Daniel 'danny' Roedding)
Subject: Re: The ST parallel (printer) port
Organization: Uni-GH Paderborn
Date: Tue, 15 Sep 1992 14:30:11 GMT

sakaria@vipunen.hut.fi (Sakari Aaltonen) writes:

>A safer way perhaps would be to bypass the BIOS function and divide the
>PSG port into two: x inputs and 8-x outputs. For that, you would have
>to know how to program the PSG - I don't...

It isn't possible to split the 8-bit-wide port into an input and an output
section. You can only change the data direction for the entire port.

Daniell
--
Daniel Roedding    "From: MAILER-DAEMON@cpac.washington.edu
Detmolder Str. 19   Subject: Returned Mail: Deferred: Not a typewriter"
D-4790 Paderborn                      E-Mail: q92269@pbhrzx.uni-paderborn.de
+49 5251 541965    "/: cannot stat ."         danny@fiction.ms.sub.org
Newsgroups: comp.sys.atari.st.tech
From: zxmkr08@mailserv.zdv.uni-tuebingen.de (Cornelius Krasel)
Subject: Re: Turbo assembler (turboass.prg) question
Organization: Comp. Center (ZDV) U of Tuebingen, FRG
Date: Fri, 11 Sep 1992 12:54:32 GMT

In <1992Sep11.011628.11774@news.csuohio.edu> max@neumann.cba.csuohio.edu (Max Polk) writes:

>The atari.archive.umich.edu program called "turboass.prg" is a nice
>assembler for the ST -- but written in German.  After figuring out
>how much of it worked by trial and error and making educated guesses
>about German words, I still need to know one important thing:

>   How can I create linkable *.o files that work with C-language
>   *.o files?

This depends supposedly on the link format which your linker wants.
Basically, there are (at least) two formats: one proposed by
the company which wrote GEM (I just forgot the name), the other
proposed by GST. As far as I know the Turboass can produce both
formats. The first format is provided by the "SMALLDRI" button,
the other format ??? (I didn't use it yet).

Hope that helps, Cornelius.

--
/* Cornelius Krasel, Department of Physiological Chemistry, U Tuebingen    */ 
/* email: krasel@mailserv.zdv.uni-tuebingen.de (Internet)                  */
/*        krasel@chemie.uni-tuebingen.dbp.de (WIN/X400)                    */
/* "People are DNA's way of making more DNA." (anonymous)                  */
From: sm86+@andrew.cmu.edu (Stefan Monnier)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: The ST parallel (printer) port
Date: 12 Sep 92 22:32:01 GMT
Organization: Junior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.sys.atari.st.tech: 12-Sep-92 The ST parallel
(printer) port michael g moncur@world.s (636)

> send and receive data through the parallel port.  Can anyone confirm that
> the parallel port can be used as input?  Someone once told me that the 
> PC's parallel port can do both input and output (which I know is true) but
> the ST can't...  And Abacus has been known to stretch the truth
> occasionally.  thoughts?

>   (I'm building an EPROM programmer that will be controlled by an ST
> via the parallel port, and a "read" option would be nice...)
>  
>   Also, what would I use to read the printer port?  An example in C would
> be greatly appreciated.
>  
>   Michael Moncur 
>   mgm@world.std.com (preferred) 
>   sysop@only_bbs.via.mind.org (alternate)


The parallel port is controlled by the Yamaha 'sound processor'
(well, only the data pins). And this YSP permits use in both
directions. I believe that on normal STs, the port isn't buffered
so that you can use it as input !

But you haven't much BIOS support: you have to write in YSP's 
registers (there may be an XBIOS call for that) directly !
(doc on YSP registers shouldn't hard to find in atari books)

Anyway, you also can get data input through the only input
pin of the atari-parallel-port: busy (I think almost all
EPROMMERS that a conected through centronics use this
'trick')

	Stefan Monnier

 

-----------------------------------------------------
-- On the average, people seem to be acting normal --
-----------------------------------------------------
Newsgroups: comp.sys.atari.st.tech
From: kslate@MtHolyoke.edu (Kevin D. Slate)
Subject: Re: ANSI C
Organization: Mount Holyoke College
X-Newsreader: Tin 1.1 PL5
Date: Mon, 14 Sep 1992 19:50:32 GMT


This should have read: I'm wondering if there is a true ANSI C for the
St...ie Mark Williams C. If any one knows please let me know.


Newsgroups: comp.sys.atari.st.tech
From: pbh@jake.cc.wayne.edu (Patrick Haggood)
Subject: Hardware support for m/t on Falcon?
Originator: pbh@jake
Organization: Wayne State University, Detroit
Date: Tue, 15 Sep 1992 11:20:35 GMT

I've been watching the posts about the Falcon's specs and MultiTos, the
multitasking OS and I don't recall seeing any info about this.  So I
ask, does the '030 have hardware memory protection built in, or is 
there a chip on the Falcon mb for it, or is there no protection 
for processes?  I've heard talk about ports of BSD to the falcon and
was wondering useful this might be if that protection isn't built in to
the machine.
 
-- 
"Again, the kingdom of heaven is like unto a net," | DoD #1966	
	Matthew 13:47                              | 81 Honda CB400T Hawk
From: Ulf_Moeller@hh2.maus.de (Ulf Moeller)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: atari emacs and ^M
Date: 4 Sep 92 21:45:00 GMT
Article-I.D.: HH2.A12220
Organization: MausNet
X-Gateway: MausGate/News 1.11

kinzel@ibr.cs.tu-bs.de wrote:

>I just managed to pass the dungle installing emacs under MiNT (and
>after a short period of happiness), I feel it's nasty that atari-emacs
>can't handle '^M' EOL charakters by default. This editor isn't vewry
>useful, when can't handle EOL's (or when it should be too difficult to
>handle 'em). So I think there must be someone who wondered about this
>problem like me, or has just solved it!

It shouldn't really be a problem to write an elisp program that removes
^M characters when loading a file, and adds them at the end each line
when saving.
Newsgroups: comp.sys.atari.st.tech