HDTenEightyP/NetNews huggingface dataset:
From: pyr579@oz.plymouth.edu (Technoid)
Subject: C programs in GEM
Reply-To: pyr579@oz.plymouth.edu (Technoid)
Organization: Plymouth State College - Plymouth, N.H.
Date: Thu, 12 Nov 92 02:42:58 GMT

Hello,

	I sent a message about 1 week ago relating to alert boxes and
programs to create them, and the fact that Neodesk and even the regular
GEM desktop boots out, runs this program that displays an alert box and
then reloads the desktop. What I want is to be able to put that alert
box up with the desktop dropping out. It must be POSSIBLE! One person
responded ( and I thank them ) but suggested I write an accessory
instead. I'll do that if that is what it takes, but I have no books
nor any way of getting any GOOD ST books that I can see. I have a Toad
Computers catalog, but they do not seem to have any books listed that
sound like what I'm looking for. What I really need is some guidance,
how do I write an accessory? I can program in C and C++, very well in
fact, but if you don't know the commands that exist it is difficult at
the very least. I'd also like info on line-a commands for direct screen
access ( this is what the manual says Neodesk uses. ) Surely someone
out there knows some information and has time to help a fellow ST owner,
I have some ideas for programs that I have never seen on the ST and want
to implement them, which could be beneficial to all ST owners, but I
need someone to help me a little with the commands first. Or at least
give me the publisher or whatever to get a good GEM book, should include
AES, VDI, and line-a routines.

Thanks, please E-mail

	Stephan

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
  pyr579@oz.plymouth.edu      Stephan R. Cleaves      Salamanders Are Slick...
  	       Newts Are Neato-van...    Chameleons Are Cool...
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
From: anneklin@acs.bu.edu (Patricia Anne)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Raster Copy [for window scrolling]
Keywords: raster-copy, window, scroll, fast
Date: 11 Nov 92 23:32:47 GMT
Organization: Boston University, Boston, MA, USA

In article <1992Nov11.133728.115954@rrz.uni-koeln.de> kim@vax.mpiz-koeln.mpg.dbp.de writes:
>In <H.KtV1EXXhvs6@elfhaven.ersys.edmonton.ab.ca> mforget@elfhaven.ersys.edmonton.ab.ca (Michel Forget) writes:
>
>It seems to me that you should use the VDI(109)  function,  which
>seems  to  be called vro_cpyfm() in standard C libraries. I don't
>know though,  whether  this  function  will  work  properly  with
>overlapping  rasters,  that  is,  whether you'll have to copy the
>raster to some buffer first and then copy it from the  buffer  to
>its  destination, or you can copy blocks directly from source tor
>destionation.


vro_cpyfm() works, and it deals properly with overlapping rasters,
so you don't have to use a buffer--wouldn't want to, as it consumes
a huge amount of time.  Thank heavens I checked and ditched the
buffer...

There's a package on atari.archive, that's been languishing in the
atari/New directory for some unknown time called wx_lib10.zoo.  It's 
a window'd output library for C, and it emulates printf() and puts()
with scrolling and all.  Pretty soon I'm thinking of giving it VT100
capability.

Oh, yeah, I never saw any need for word-alignment--I can scroll text
fast enough without it that it's unreadable.

Later,
From: scgk@dcs.ed.ac.uk (Simon Kinahan)
Newsgroups: comp.sys.atari.st.tech
Subject: Ethernet for the Atari ST ?
Date: 10 Nov 92 11:40:40 GMT
Organization: Department of Computer Science, University of Edinburgh


  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.

  Simon.
From: mpark@stein.u.washington.edu (Michael Park)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Extended characters with printf()
Date: 8 Nov 92 21:16:54 GMT
Article-I.D.: u.1992Nov8.211654.22528
Organization: University of Washington, Seattle

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

Bconout( 5, ch ) displays the 'non-printable' characters.


--m
Newsgroups: comp.sys.atari.st.tech
From: annius@nanna.research.ptt.nl (Annius Groenink)
Subject: Re: Raster Copy [for window scrolling]
Reply-To: A.V.Groenink@research.ptt.nl
Organization: PTT Research
Date: Fri, 13 Nov 1992 09:39:40 GMT

U.Kuehn <KUHNU@DMSWWU1A.UNI-MUENSTER.DE> writes:

>To scroll up a window, one _must_ go along the rectangle list (the window
>might not be on top) and scroll up the contents of every rectangle.
 ^^^^^^^^^^^^^^^^^^^
 of course, when running a single tasking AES, this is not a problem.  I think
 with MultiTOS lots of programs of the highest standards will have problems
 with scrolling.

>If the region is high enough, use vr_cpyfm() to copy the lower part of the
>region to the upper and the redraw the lower part, as the new things
>could have lain under another window.
>An alignment to a 16 bit boundary is used to speed things a bit up, especially
>text  output, as the pixel to write dont have to be shifted around so much.
>To align a window,make sure that it x-coordinate of the _inner_ left edge
>is divisible through 16, and the do a wind_calc() to calculate the outer
>bounds of the window, then make it open there or move it there or what so ever.

Rounding on an 8 bit boundary BTW is sufficient.  Apart from the wind_calc you
should have a small edge of white space before you start v_gtexting.  It's very
ugly if you stick the letters to the left edge of the window.

-- 
Annius Groenink  --  Universiteit Utrecht  --  PTT Research Leidschendam
annius@research.ptt.nl/avgroeni@cs.ruu.nl       Maths/Comp.Sc./TOS/Music
From: snoret@egon.unx.sas.com (Rick Tatem)
Newsgroups: comp.sys.atari.st.tech
Subject: Installation of TOS 1.4 (6 chip set)
Summary: what order?
Keywords: TOS 1.4, 1040STf, help
Date: 10 Nov 92 18:36:07 GMT
Followup-To: comp.sys.atari.st.tech
Organization: SAS Institute Inc.

I just got my TOS 1.4 6 chip set from Toad Computers, but they didn't
include any instructions!  So, now I've got my ST 'naked to the world'
and am afraid to just start pluggin in these chips without knowing what
order to put them in.  Here is the layout of the TOS sockets:


	--------------		--------------
	|	     |		|	     |
	|	     |		|	     |
	--------------		--------------
		U4			U7
	--------------		--------------
	|	     |		|	     |
	|	     |		|	     |
	--------------		--------------
		U3			U6
	--------------		--------------
	|	     |		|	     |
	|	     |		|	     |
	--------------		--------------
		U2			U5
	||		||
	\/		\/
   to MIDI ports    to Cartridge Port

Now, the question is... In which socket does each TOS 1.4 chip go???
The set I have has two sets of three chips.  Set 1 - L0, L1, and L2.
Set 2 - H0, H1, H2.  Will someone please tell me the order to put them
in.  I got 'trigger happy' and have already pulled my old TOS 1.0 chips
out, but have successfully put them back in. (i.e. it boots and works ;)

I searched through all my FAQ and saved news articles, and I even 
downloaded the TOS 1.4 Discussion files from GEnie, but nothing had
the installation instructions.  HELP!!!

Thanks alot in advance,

Rick
--
----
Richard E. Tatem		Asst. Systems Programmer
snoret@unx.sas.com		UNIX Systems Support
(919) 677-8000 x4719		SAS Institute Inc.
Newsgroups: comp.sys.atari.st.tech
From: cmmiller@iastate.edu (Chad M Miller)
Subject: Help with downloading files from umich
Organization: Iowa State University, Ames, IA
Date: Fri, 13 Nov 1992 08:17:16 GMT

I noticed (while FTP'ing) to mac.archive.umich.edu that they have a
large selection of games for Atari.  Most of these games had endings
with ".lzh", ".zoo" or ".tos".  Does one need some sort of compression
programs for these files?  If so what and where can I get it?

Also, as I understand it, Atari has their own system.  If I download
these files, and the person in Germany has the correct decompression
programs, is it possible at all for her to read the disk on which I
send it?  

I can download directly onto Mac or DOS formatted floppies.
I presume I download the files as binary data.   

Is there really anything I can do without having access to an Atari? 

Any help would be greatly appreciated.  Please respond via e-mail
since I don't read this newsgroup regularly. 

Thanks a lot in advance!

Chad  "cmmiller@iastate.edu"
From: alf@skid.north.de (Alf Hoheisel)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Does Gulam screw up environmental variables?
Date: 4 Nov 92 20:11:24 GMT
Article-I.D.: skid.a1003302

In <1d27jnINNmnf@usenet.INS.CWRU.Edu> bq035@cleveland.Freenet.Edu (Brian Jepson) writes:


>==========cut here=================
>set path c:\bin,c:\,C:\utils\arc,c:\utils\disk,d:\sozobon\bin,e:\bin
>setenv TMP G:\
>setenv INCLUDE  D:\SOZOBON\INCLUDE\
>setenv LIB  D:\SOZOBON\LIB\
>setenv BUFSIZE 4096
>==========cut here==================

>Hope this helps... I think the solution is in using 'set' for the path...

Gulam didn't use environmentvariables. All environmentvariables you set
with `setenv' will only be given to the processes started from inside of
gulam. If you wants to set variables which gulam should use you have to
set them with `set' and write them lower case. There are several shell
variables you can set for gulam. I didn't have a list of the shell variables
which gulam understands by hand. Look into the manual.

Hope that helps,
			Alf
-- 
Alf Hoheisel, Potsdamer Str. 14, D-2940 Wilhelmshaven, Phone: +49 4421 52635
<university> alf@zfn.uni-bremen.de | alf@informatik.uni-bremen.de
<home>       alf@skid.north.de
Newsgroups: comp.sys.atari.st.tech
From: paetau@mits.mdata.fi (Rasmus Paetau)
Subject: Re: 16-bit RAM Access on Falcon ?
Organization: Microdata Oy, Helsinki, Finland
Distribution: eunet
Date: Thu, 5 Nov 1992 21:31:00 GMT

In article <1992Nov1.183817.15596@rhrk.uni-kl.de> peter@rhrk.uni-kl.de (Gunter Bitz) writes:
>anderss@colargol (Anders Skar) writes:
>
>>  Is it true that the Falcon030 only has 16 bit RAM Access ?
>
>Ok. My answer is simply :  YES !
>To be more precise the 68030 has only 16 bit access while the video hardware
>has full 32 bit access.
>Before you start flaming now: Has anyone of you ever tested this ?
>I have !
>
>cu
> Gunter

Excuse me, but where did you get that from? Sam Tramiel stated in the
GEnie conference a long time ago that it has a 32-bit bus. Also,
somebody tested Falcon with QIndex and got 471% for the CPU memory
test, compared to a normal ST. I don't see how this could be possible
with a 16-bit bus. So please tell me (us) where this information came
from?


--
-----------------------------------------------------------------------
| Rasmus Paetau (paetau@mits.mdata.fi) | Waiting for the Atari Falcon |
-----------------------------------------------------------------------
From: cs90ijr@brunel.ac.uk (Ian J Ray)
Newsgroups: comp.sys.atari.st.tech
Subject: CPX v1.00 Bug?
Date: 12 Nov 92 10:16:21 GMT
Organization: Brunel University, Uxbridge, UK
X-Newsreader: TIN [version 1.1 PL6]

I have just started to write a simple CPX, using CPX v1.00. It appears that
there is a bug in the XControl redraw code. I did the following:

  . open XControl from 'Desk'
  . move window to the left/right a bit
  . get 'Desk' About... dialog box up
  . click [ok]

Now, *sometimes* XControl misses a _single_ pixel line along the left edge
of the redraw area.

i.e.
                    +---------------+
           +--------|       |       |
	   |===Contr|      / \      |
	   |        |               |
	   |        |   Atari....   |
	   |        |               |
	   +--------|               |
		    |    [ OK ]     |
		    +---------------+

           +--------|----------+
	   |===Contr|l Panel===|
	   |        |          |
	   |        |          |
	   |        |          |
	   +--------|----------+

                    ^single pixel line left.

This problem seems to depend on the 'alignment' of the XControl window
on the desktop. Has anyone else had this problem? What is the latest
version of XControl?

.Ian.
cs90ijr@brunel.ac.uk
From: glens@natinst.com (Glen Sescila)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: 16-bit RAM Access on Falcon ?
Date: 9 Nov 1992 10:09:20 -0600
Organization: National Instruments, Austin, TX
Distribution: eunet
NNTP-Posting-Host: falcon.natinst.com

In article <1992Nov8.132805.1903@rhrk.uni-kl.de> peter@rhrk.uni-kl.de (Gunter Bitz) writes:

>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
>
>The result was that filling the same amount of memory with longwords is a bit
>faster than filling with words, but not twice as fast as it should be on a
>r e a l   32 bit machine. I'm sorry about that

	Are you sure your data started on a longword boundry?  If it wasn't,
that would explain why it was not twice as fast.

-----------------------------------------------------------------------------
"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
-----------------------------------------------------------------------------
From: ee90jde@brunel.ac.uk (Jonathan D Evans)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Falcon and Hard Drives
Date: 11 Nov 92 12:46:56 GMT
Organization: Brunel University, Uxbridge, UK
X-Newsreader: TIN [version 1.1 PL6]

Samples do take a lot of memory/disk space but due to the DSP
having various in built tables, i.e. A-Law and U-Law, it is
capable of being able to compact samples by up to 4:1 and
acording to the comp.compression network should be able to
compress screen data by up to 26:1.
From: mjl-b@minster.york.ac.uk
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Falcon BUS..
Date: 13 Nov 92 10:54:45 GMT
Reply-To: mjl-b@minster.york.ac.uk (Mathew Lodge)
Organization: Department of Computer Science, University of York, England

In article <H.CERjFbwM9dE@fredrik.atari.no> jornmoe@fredrik.atari.no writes:
>In <1992Nov11.203921.11068@rmece49.upr.clu.edu>, Ricardo Hernandez writes:
>[stuff deleted]
>>  So the Falcon can't do any processing when a DMA is taking place?
>
>The 68030 has a cache, so it might do some processing while DMA occures on the
>bus!

The 68030 can't _access the bus_ while DMA is taking place, but it can
continue to do anything else until it requires bus access. 

There's also a problem with caches and DMA. Because a cache may contain
data that has yet to be written to memory, it must be flushed before DMA can
take place. This prevents the DMA operation picking up any "old" data held
in main memory. Hence the processor caches are usually flushed before any
DMA operation.

> / Joern F. Moe /  All above is my own personal opinion! \
>/ Oslo, Norway /  Any lack of opinion above is also mine! \

Mat

| Mathew Lodge                      | "I don't care how many times they go    |
| mjl-b@minster.york.ac.uk          |  up-tiddly-up-up. They're still gits."  |
| Langwith College, Uni of York, UK |  -- Blackadder Goes Forth               |
From: eker@loria.crin.fr (Steven Eker)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Cross Compiling Sozobon 2.0
Keywords: hash function
Date: 5 Nov 92 17:07:43 GMT
Organization: CRIN (CNRS) Nancy - INRIA Lorraine

In article <1992Nov3.140438.19093@news.lrz-muenchen.de>, HUSFELD@usmv01.usm.uni-muenchen.de (Husfeld, Dirk) writes:
|> In <1992Nov2.133525.7992@sol.ctr.columbia.edu> richard@op.ph.ic.ac.uk writes:

[discussion of what hashing is supposed to be deleted]

|> > 
|> > hash(s)
|> > unsigned char *s;
|> > {
|> >         unsigned char c;
|> >         register i, n = 0;
|> > 
|> >         for (i=1; i<5; i++) {
|> >                 c = s[i];
|> >                 if (!c)
|> >                         break;
|> >                 n = (n<<1)|c;
|> >         }
|> >         return n & (NHASH-1);       /* NHASH is the max value */
|> > }
|> > 
|> > 
|> > I've spotted that this routine only uses the 1st to fifth letters of

Actually 1st -> 4th letters.
 
|> > the name (skipping the first underscore), and that this is the same
|> > for both __initial_stack and __init_signal, but increasing the number
|> > doesn't help - in fact the routine only seems to return hash values
|> > of 46,61,62,63 whatever is passed through to it when it uses seven
|> > characters.

This is a truly _awful_ hash function; simply ORing and shifting is
going to produce a heavy bias towards hash values with lots of ones -
especially in the more significant bits:
46=%101110, 61=%111101, 62=%111110, 63=%111111
(one can guess that NHASH=64)

Replace the OR (|) with addition (+) or exclusive-OR (^) for some improvement.

|> >
|> One might argue over the sensibility of a hash function that only looks
|> at the first characters of a name.  It is often a bad approach because
|> some programmers enumerate their variables (like file1, file2,...;
|> not recommended), others use a verb-object template for their function
|> names (get_this(), get_that(), get_next()...).  Nevertheless, a bad hash
|> function only slows down the calling code because it has to do more work
|> to solve the name clash.

Agreed. I believe the Sozobug loader only deals the first 8 characters
of a name so I'd hash on 1 thu 7 (starting at zero!);
i.e. replace the 5 with an 8 in the above code.

Steven
From: d91-jsn@ludd.luth.se (Joachim Str|mbergson)
Newsgroups: comp.sys.atari.st.tech
Subject: pds slot specs wanted
Date: 5 Nov 92 14:17:14 GMT
Organization: Lule} Tekniska H|gskolas Datorf|rening - Ludd

I have heard so much junk about the pds slot so I would like
to REALLY know more about it. Is it a crippled slave slot or a real
32 bit ninja bus? This info don't exsist in the FAQ file but I think
that it really should be in it.


Yours


Joachim Str|mbergson
Newsgroups: comp.sys.atari.st.tech
From: kremser@rbg.informatik.th-darmstadt.de (steffen kremser)
Subject: Falcon  BUS-width/ RAM-size
Date: Thu, 12 Nov 1992 15:27:17 GMT
Organization: TU Darmstadt

IMHO, the Falcon's '030 has 32 Bit memory access,
(with a 24-bit adress-bus)
This would explain the three standard RAM sizes :
 
 Width x Chipsize = Total RAM
   32  x 256-Kbit =  1 MB 
   32  x  1-Mbit  =  4 MB 
   32  x  4-Mbit  = 16 MB (max for 24 Adress lines)

BTW : *EXPANSION SLOT* and VIDEO (SHIFTER,BLITTER) 
      have 16-Bit access only !

-- 
Steffen +------------------------+-------------------------------------+
 ////   | kremser@igd.fhg.de     | Rorschach: None of You understand!  |
 c-OO   | kremser@rbg.informatik | I'm not locked up in here with YOU. |
 | -~   | .th-darmstadt.de       | YOU're locked up in here with *ME*. |
Kremser +------------------------+-------------------------------------+
Newsgroups: comp.sys.atari.st.tech
From: peter@rhrk.uni-kl.de (Gunter Bitz)
Subject: Re: 16-bit RAM Access on Falcon ?
Organization: University of Kaiserslautern, Germany
Distribution: eunet
Date: Sun, 8 Nov 1992 13:28:05 GMT

>>
>>>  Is it true that the Falcon030 only has 16 bit RAM Access ?
>>
>>Ok. My answer is simply :  YES !

>Excuse me, but where did you get that from? Sam Tramiel stated in the
>GEnie conference a long time ago that it has a 32-bit bus. Also,
>somebody tested Falcon with QIndex and got 471% for the CPU memory
>test, compared to a normal ST. I don't see how this could be possible
>with a 16-bit bus. So please tell me (us) where this information came
>from?

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

The result was that filling the same amount of memory with longwords is a bit
faster than filling with words, but not twice as fast as it should be on a
r e a l   32 bit machine. I'm sorry about that
I also know that Atari states that the Falcon is a real 32 bit computer.
I also asked a few people at the Duesseldorf Atari Messe and they told me the 
same stuff. My opinion is that Atari tries the same way as Apple with their
'small' Macintosh.
Anyway most of the 'Users' don't recognize a difference between 
a 16 or 32 bit bus.

Perhaps somebody might try the same as I did and report to this group !

But anyway even with this small bus the Falcon is a interesting computer
and I personally will buy one anyway !

cu 
  Gunter
From: warwick@cs.uq.oz.au (Warwick Allison)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Alert Boxes in C
Date: 12 Nov 92 01:22:43 GMT
Reply-To: warwick@cs.uq.oz.au

pyr579@oz.plymouth.edu (Technoid) writes:

>I run Neodesk and when I use
>this program, Neodesk unloads, the alert box pops up on its own blank
>screen, I click the button, and the Neodesk reloads. This is not what I
>want,

I'm not sure about NeoDesk, but what you want is supported by the Gemini
desk replacement - from the "Install Application" menu, I'd assume.  It's
definately possible - I did it once.


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