HDTenEightyP/NetNews huggingface dataset:
From: walker@twix.unx.sas.com (Doug Walker)
Subject: Re: Lattice 5.10 upgrade
Originator: walker@twix.unx.sas.com
Date: Mon, 23 Nov 1992 21:46:21 GMT
Organization: SAS Institute Inc.
Keywords: upgrade


In article <sims.722527621@sauron.msfc.nasa.gov>, sims@sauron.msfc.nasa.gov (Herb Sims) writes:
|> I have a favor to ask of some-one concering SAS C V5.10(x) upgrade.  Somehow
|> SAS did not send me the upgrade from 5.04 to 5.10 is there someone out the
|> there who would be kind enough to send me the upgrade disk?  If it cost money
|> to get the upgrade from 5.04 to 5.10(x) then I am sorry and please put this
|> note in the :dev/null bin.  Before anyone tells me to call SAS I already have
|> and they do not have any more 5.10(x) upgrades since the 6.00 has come
|> out.

5.10 was a paid upgrade ($40) from version 5.05.  5.05 is available
from technical support free of charge to registered owners of 5.04.

You should consider getting 6.0, though, it really is worth it.

-- 
  *****
=*|_o_o|\\=====Doug Walker, Software Distiller====== BBS: (919)460-7430 =
 *|. o.| ||                                          1200/2400/9600 Dual
  | o  |//     For all you do, this bug's for you!
  ====== 
usenet: walker@unx.sas.com                            bix: djwalker 
Any opinions expressed are mine, not those of SAS Institute, Inc.

Newsgroups: comp.sys.amiga.programmer
From: breese@monet.imada.ou.dk (Bjoern Reese)
Subject: Re: New hardware reference guide?
Organization: Dept. of Math. & Computer Science, Odense University, Denmark
Date: Thu, 19 Nov 1992 14:05:44 GMT

In article <1992Nov18.134641.58767@qut.edu.au> podesta@qut.edu.au writes:
> In article <OAHVENLA.92Nov17002933@lk-hp-4.hut.fi>, oahvenla@snakemail.hut.fi  
(Osma Ahvenlampi) writes:
> >                          C= won't release the Hardware information, because
> > that would mean saying that it's OK to directly access hardware, when it's
> 
> I don't get it. What's the big deal????
> Why don't Commodore just release it and say something like:
> 
> "BANGING THE HARDWARE IS NOT UPWARDLY COMPATIBLE"
> 
> Then all of us who don't give a damn about upward compatibility
> (ie. in demos and some games) can write our demos and have fun, and
> those who want to write software that will last forever can go through
> the OS.

That is EXACTLY how I feel too. The demo won't run on a new chipset, but
so what? I don't care. There's no, or little, money in doing demos. We're
doing demos for the fun of it.

You people with the big machines actually have an option: Don't watch
demos!!! If you're so afraid that demos will crash your machine or
that it may harm your hardware, don't watch demos! If C= doesn't
release the hardware specs, I can ensure you that it doesn't mean
that democoders will start producing OS-demos; more likely they will
leave the Amiga world.

Why can't you let us write our demos and have the fun what we want?

> I mean the OS is GREAT. I love it. It's one of the reasons that Amiga rules..
> but its a development environment, not a demo or game environment.

I agree again. The OS is GREAT, and I can understand that the software
engineers at C= aren't feeling too happy about people like me, when I
stuff the OS, which they have been working hard at for several years. But
I think that every programmer should be given to freedom to do as he/she
likes, based on guidelines from C=. If we don't care about upwards
compatibility, it's our problem (we probably never intended these
programs to run on a future machine; we made them to show what the
current machine can do, and remember: we never got any money for our
efforts!!)

--

Bjoern Reese                   |     Email: breese@imada.ou.dk
Odense University, Denmark     |     Voice: +45 65 932 182 (private)
From: stern+@pitt.edu (Eric G Stern)
Newsgroups: comp.sys.amiga.programmer
Subject: snapshot and SASC 6.0
Date: 23 Nov 92 13:45:33 GMT
Organization: University of Pittsburgh
Originator: stern@unixd1.cis.pitt.edu

Hi,

    Has anyone come up with a strategy for being able to take
snapshots of programs that GURU with the catch.o startup module of
SASC 6.0 without clobbering their hard disk?  I thought I'd be able to
do that be running the program from the removable RAM disk and then
copying the file to the hard disk, but I still ended up clobbering the
hard disk.  What is the mechanism that causes this?  Would locking the
hard disk with the DOS command LOCK prevent hard disk damage?  How
about working from floppies?  Any insights would be useful.

				Thanks,
				Eric Stern
Newsgroups: comp.sys.amiga.programmer
From: sims@sauron.msfc.nasa.gov (Herb Sims)
Subject: Serial question
Keywords: Serial
Organization: NASA/MSFC
Date: 23 Nov 92 13:59:34 GMT

I have a wuestion concerning the serial.device:  I am working on a serial
interface for a modem and I am having the following problem.

When I send one or many character(s) to the serial device in question ( a ham
radio Packet TNC) I use a DoIO CMD_WRITE request.  The problem/question is this
I though that when you do a DoIO command a message is NOT sent to the associated
message port.  Is this correct?  The problem is the Packet TNC is acting like 
a Full duplex device and I can't seem to make tit work in the half-duplex
mode.

Any suggestions?

Thanks in advance

Herb



--------------------------------------------------------------------------------
W. Herb Sims                                        sims@sauron.msfc.nasa.gov or
KU0C                                                sims@avdms8.msfc.nasa.gov
MSFC/NASA/EB33				
Huntsville, AL 35812				    PP-ASEL-IA

           _#      **MMp     g#00   `N##0"     _agN#0P0N#            _#L
          g##       jN##    j##F     J##     _dN0"      "           g##L
        _#]##      _0 ##L  jN##F     ###    g#0"                  _03##L
       gE_j##      #  0## jF ##F    j##F   j##     ______        gE_j##L
     _0"""N##     d"  J##L0  ##F    0##    0##     "9##F"      _0"""5##L
   _gF    ]##    jF    ##0   ##F    ##F    `##k     d##      _gF    j##L
 _g#_    _j##L__g#__   ]N  _j##L_ _d##L_    `#Nh___g#N'    _g#_    _j##L_
`""""    """""'""""'    "  """""" """"""       """""""    `""""    """"""
--------------------------------------------------------------------------------
From: robinson@elux3.cs.umass.edu (RICHARD ROBINSON)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: A couple of questions
Date: 18 Nov 92 16:35:51 GMT
Reply-To: robinson@elux3.cs.umass.edu (RICHARD ROBINSON)
Organization: The Realm of Dread

In article <1992Nov16.222301.21722@jato.jpl.nasa.gov> jdickson@jato.jpl.nasa.gov (Jeff Dickson) writes:
>In article <56246@dime.cs.umass.edu> robinson@elux2.cs.umass.edu (RICHARD ROBINSON) writes:
>>
>>In article <1992Nov13.063457.22216@ucc.su.OZ.AU> willw@extro.ucc.su.OZ.AU (William Waring) writes:
>>
>>Anyway, ACTION_READ, not ACTION_SCREEN_MODE... I am doing asynchronous
>>reads by sending a ACTION_READ packet. Read(filehandle,buffer,x) would freeze
>>me up. It has nothing to do with the mode of the console.
>
>Oh, yes it does! If the console is not operating under RAW mode, then reads
>will block until the number of chacters to read (in this case 'x') has been
>read. 

Reads will block regardless of mode!!! In RAW mode, reads will block until
x characters have been read. Otherwise, a newline will terminate the read.
That is why I am sending a packet - no blocking. I just wait on a message
port (along with all my other ports). It has nothing to do with whether I
am waiting for 1 character under RAW mode (what I am doing), or waiting for
a newline-terminated line under CON mode. The point is that the user is no
longer in a position to type anything, the packet is still out, and need
it killed.

>
>>I send a READ,
>>and when it returns, stuff the character into a pipe. When I am ready
>>to exit, there is one outstanding read. I need to be able to kill it.
>
>Another way would be to generate the number of characters needed to satisfy
>the read request when your program wanted to exit. This could be done by
>using the IND_WRITEEVENT command of the Input device. This precludes that
>your program's window would be the one currently receiving input when the
>program decided to exit. 

Sorry, the program's is a little more complex. I have outstanding reads on
pipes, console windows, and AUX:. I need a generic way to kill that darn
packet.

--
Dread				      (Richard Robinson, Univ of Mass, Amherst)
dread@titan.ucc.umass.edu	      "There is no right, there is only power!"
robinson@elux3.cs.umass.edu		     "Kill them, kill them all!"
Newsgroups: comp.sys.amiga.programmer
Subject: Gadget problems !!  NEED HELP !!!!!
From: landall_v@kosmos.wcc.govt.nz
Date: 20 Nov 92 12:34:51 NZST
Organization: Welligton City Council, Public Access.
NNTP-Posting-Host: kosmos.wcc.govt.nz


Hi


I need some help with this small gadget problem that I can't seem to figure
out.

I have three gadgets like this :

	+-+
	| |
	+-+

	+-+
	| |
	+-+

	+-+
	| |
	+-+

What I want to do is this :   When, say gadget one, is selected I now want to
select gadget two. I select it, now I want gadget one to go off and gadget two
to come on.

It's a bit like a toggle only that gadget one toggles gadgets two and three
off, etc.

Can some one help me with this ??  I program in 'C'.

THANKS in advance
From: breese@monet.imada.ou.dk (Bjoern Reese)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware Manual)
Date: 22 Nov 92 15:25:20 GMT
Organization: Dept. of Math. & Computer Science, Odense University, Denmark

In article <37190@cbmvax.commodore.com> bj@cbmvax.commodore.com (Brian Jackson  
- Amiga Networking) writes:
> Hey. Commodore makes the chips, Commodore makes the machines,
> Commodore writes the docs, Commodore pays the engineers and Commodore
> decides what does and does not get released to the public. 

Hail almighty Commodore! (Do you support dictatorship too?)
Just remember that Commodore is absolutely NOTHING without the public.

> We did it your way up til now and it created FAR more problems for
> engineering, users and developers than it was worth.  So, this time,

So the first (and completely incomprehensive) version of the hardware
reference guide was you way of supporting "our way" ? Thanks for nothing.
Well, pick up an issue of this book, which was the only material from C=
that we had back then, and you'll find that C= also is guilty of this
problem.

> we're doing it differently.  If, in your view, that "SUCKS!" then so
> be it.  The fact is that "demo coders", while creating 'neato' things
> to look at, do little or nothing for sales and they create an entire
> generation of Amiga programmers that have failed to learn how to do it

Most people I know bought their Amiga because a) the games, b) the
demos, and c) the possibility of learning how to create one (game/demo)  
themselves. It is my strong belief that Amiga only survived the initial
sale problems (I remember that sales were low i US, and that only the
sales in Europe - especially in Germany - rescued the Amiga) because
of kids buying a programmable game machine. If you wanted applications
back then, you bought a PC or a MAC. Now, has that "little or nothing"
to do with the sales?

BTW, do you actually KNOW any demo coders personally?

> right. The result is application software (you know, the stuff that
> people pay MONEY for and expect to work on new machines) that is chock

How much MONEY do you pay for demos? If it's anything above the prize of
a disk, you've been fooled.

> full of silly, pointless coding errors and, often, _slower_ code than 
> if it had been coded properly from the start.

Most applications are written in C, or another highlevel language, not
in assembly language, like almost all demos. I doubt that the problems
above erupt from the demo scene the way you want us to believe. I think
many people have their first programming experiences on the Amiga, and
beginners _do_ make mistakes, whether they do demos or applications.
Just don't blame demo coders for _all_ the mistakes done by application
programmers.

Which leads me to another question. What is worst: a demo coder with
docs on how to bang the hardware properly, or a demo coder without
these docs?

--

Bjoern Reese                   |     Email: breese@imada.ou.dk
Odense University, Denmark     |     Voice: +45 65 932 182 (private)
Newsgroups: comp.sys.amiga.programmer
From: seifert@gn.ecn.purdue.edu (Michael S. Seifert)
Subject:  FORTRAN/020 ON THE AMIGA
Organization: Purdue University Engineering Computer Network
Date: Sun, 15 Nov 92 21:58:29 GMT


Does anyone use Absoft's FORTRAN compiler (020 version).  Im thinking about
buying it, but I wanted to hear a few comments before I spent so much...

thanks, mike
From: heinz@edohwg.adsp.sub.org (Heinz Wrobel)
Newsgroups: comp.sys.amiga.programmer
Subject: Re:   SAS/C 6.00 problems
Date: 14 Nov 92 13:28:37 GMT
Organization: Edotronik GmbH

In article <Bxnq6A.44p@unx.sas.com> walker@twix.unx.sas.com (Doug Walker) writes:
>|> I'd rather have a command to get the error _column_ :-)
>|>
>|> Heinz Wrobel, Edotronik GmbH (ECG018)
>
>Me, too - unfortunately, that information is lost by the time the
>message is printed because preprocessor macro expansions have messed
>it up.  I'll have to write new code to get it to work.

But the compiler can show the line with the error highlighted. Couldn't
this line including the ANSI sequence be available to SCMSG?

With 5.10B I peeked how LSE got the error information from the compiler and
wrote a LSE2DME for myself that passed the line to a REXX script. There I
could parse the line for the ESC of the highlight sequence. This gave me a
useable column. Now I miss that "feature" :-(

>=*|_o_o|\\=====Doug Walker, Software Distiller====== BBS: (919)460-7430 =

--
Heinz Wrobel, Edotronik GmbH (ECG018)
FAX +49 89 850 51 25 / TEL +49 89 850 25 20 (HOME!&VOICE, sometimes...)
From: paulk@terapin.com (Paul Kienitz)
Newsgroups: comp.sys.amiga.programmer
Subject: GRIPE! about refreshing string gadgets
Date: 17 Nov 92 23:29:11 PST
Organization: BBS

This is a gripe about the refreshing of string gadgets.

In my current project, I have lots of string gadgets, and sometimes
they need to be enabled and disabled in response to other input, and
sometimes they need to have their text contents altered, and sometimes
both at once.  I've noticed that all versions of Intuition do a LOUSY
JOB of refreshing string gadgets in different states, when the string
is shorter than the gadget and I'm also using the 2.x feature of
having different colors for active and inactive string gadgets.
Furthermore, different versions mess up in different ways.

In the effort to create a function which would correctly refresh a
string gadget after changing its text and possibly its enabled state,
here's what I ended up needing to do:

 - Pad the current string in the gadget with spaces so as to
    completely fill the visible space with text.  Under 2.x, pad it
    so the terminating nul char falls just after the end of the
    visible space, under 1.x pad it so the nul is just inside the end
    or else it will refresh one character space OUTSIDE the
    boundaries of the gadget.

 - RefreshGList the gadget

 - Restore the original length of the string in the buffer
 
 - Unless the gadget is currently disabled (maybe this should be done
    anyway, come to think of it), RefreshGList the gadget a second
    time with the window rastport's write mask temporarily set to
    zero.  This lets Intuition know the current string length,
    without doing any actual rendering.

Here is a sketch of my refreshing function ... this one assumes that
the font is always of 8 pixel width, and assumes that the gadget is
currently in the window's gadget list ... of course, in my actual
program this is more complicated:


extern struct Library *SysBase;

void PaintStringGad(struct Gadget *gg, struct Window *ww)
{
    struct StringInfo *si = (APTR) gg->SpecialInfo;
    short wid = (gg->Width >> 3) + (SysBase->lib_Version >= 36);
    short l = strlen(si->Buffer), i;

    si->DispPos = 0;
    si->BufferPos = 0;
    for (i = l; i < wid; i++)
        si->Buffer[i] = ' ';
    if (wid >= l)
        si->Buffer[wid] = 0;
    RefreshGList(gg, ww, NULL, 1);
    si->Buffer[l] = 0;
    if (!(gg->Flags & GFLG_DISABLED)) {
        SetWrMsk(ww->RPort, 0);
        RefreshGList(gg, ww, NULL, 1);
        SetWrMsk(ww->RPort, 0xFF);
    }
    if (gg->Flags & GFLG_DISABLED)      /* this part is optional */
        si->BufferPos = 0;
    else
        si->BufferPos = l;
}
From: wittb@nextnet.csus.edu (brian witt)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: How to program multi-threaded programs on Amiga ?
Date: 21 Nov 92 06:30:15 GMT
Article-I.D.: csus.1992Nov21.063015.20289
Organization: California State University Sacramento

In article <83755@ut-emx.uucp> amigamat@ccwf.cc.utexas.edu (Mark Thomas) writes:
>In article <1992Nov12.195317.19859@csus.edu> wittb@nextnet.csus.edu (brian witt) writes:
>>	At exit time, send the low priorty process a kill message.
>>	Then loop with a sleep() call until some global varaible is
>>	set to indicate OK to die.
>
>Why not just have the sub-process reply back to you when it is okay
>to quit?
>I like for the OS to handle telling me a change in state.

Picture a higher priority task in a busy loop waiting for a variable
(some flag) to change.  This higher priority task is not calling any
OS functions.  Amiga Exec (1.3) does not lower the priority of a
compute-bound process. (The scheduler is a soft-realtime system.) 

The flag variable can only be changed by lower priority process that
is being starved out of CPU time.  The variable can't be set since
the lower priority process never executes...  :-(

In SimCity, the Simulator is run at a lower priority.  When the user
wants to quit I set a "better finish up" variable.  The user interface
portion enters a loop of:
	while( ! sim_has_exited ) Sleep(40L);

This gives the simulator a chance to actually get to a check.  Then
it Forbid()s, sets the variable and exits.  I could have used a RemTask()
since the simulator owns no resources, but while debugging, it was
printf() (eg, ADOS Write()s) to a debug window...

>>   Brian Witt   Sac State Computer Science]   "Waldo, the pariot, is dead"
>         Mark A. Thomas          / (amigamat@ccwf.cc.utexas.edu)

--- brian

-- 
============================================================================= !
   Brian Witt   Sac State Computer Science]   "Waldo, the pariot, is dead"
   Internet:  wittb@cube01.ccs.csus.edu               -- Agent Cooper
                #define  POSIX_ME_HARDER     1       <-- GNU
From: amipb@amipb.gna.org (Philippe Berard)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Blitter vs 680x0
Date: 22 Nov 92 12:51:39 GMT
Organization: IWANIMA
X-NewsSoftware: GRn 1.16e (7/4/92) by Mike Schwartz & Michael B. Smith

In article <1698@igd.fhg.de> wirth@jocki.NoSubdomain.NoDomain (Hanno Wirth) writes:
>
> |> good for speedy graphics, but what with the 68030 and 68040 picking up real
> |> speed, how much long is it going to be, before using the blitter is slower
> |> than using the CPU?
> 
> I don't know exactly about the A4000, but in the A3000 the CPU is faster than
> the blitter. That's the reason a program named 'CPUBlit' exists. Even on my
> A2000 with it's 16 bit data path, the A2630 + CPUBlit is a little bit faster
> than the Blitter.

    You also need CpuBlit on the 4000 with an 7/8 bitplanes screen, because
    you'll see that flicking bitplane scroll in the shell if you don't use
    it.

    Sincerely,
                                   -- Philippe

/----------------------------------------------------------------------------\
|  Philippe Berard  (French Amiga User)       | UseNet : amipb@amipb.gna.org |
|  "They hold a cup of wisdom,                | FidoNet: 2:320/104.8         |
|   But there is nothing within" (Kate Bush). |AmigaNet: 39:180/1.8          |
\----------------------------------------------------------------------------/
From: jpotter@sirius.ucs.adelaide.edu.au (Jonathan Potter)
Newsgroups: comp.sys.amiga.programmer
Subject: Are there bugs in 1.3 AreaEllipse() ?
Date: 22 Nov 1992 14:35:46 GMT
Organization: Information Technology Division, The University of Adelaide, AUSTRALIA
NNTP-Posting-Host: sirius.itd.adelaide.edu.au

Subject basically says it all, are there any known bugs or other problems
in the 1.3 and earlier AreaEllipse() routine ?

Jon
-- 
| Jonathan Potter |                              | A                       |
| P.O. Box 289    | jpotter@itd.adelaide.edu.au  |   Suffusion             |
| Goodwood, SA    | FidoNet : 3:680/829          |               Of        |
| Australia  5034 |                              |                  Yellow |
Newsgroups: comp.sys.amiga.programmer
From: wlanders@nexus.yorku.ca (W L Anderson)
Subject: Re: physical memory protection with MMU
Summary: how about this?
Organization: York University, CS Dept. Toronto
Date: Sat, 21 Nov 1992 18:34:08 GMT

I've been following this thread for a while now,  and  I  have  a
question.

Since in a protected memory environment, you are going to have to
keep  track of what memory is allocated by which process, and the
problem seems to be with memory that is being  used  to  pass  to
other tasks is not always allocated as MEMF_PUBLIC, why not put a
hook into the EXEC message passing code so that when  a  task  is
about  to  pass  a message, you check to see if it's MEMF_PUBLIC.
If it isn't, make it MEMF_PUBLIC.

Is there a drawback to this that I don't see?  At least new  pro-
grams  that are written correctly could start taking advantage of
memory protection, and old programs would  at  least  have  their
code protected from errant processes.

Tom Hayko
wlanders@nexus.yorku.ca
Newsgroups: comp.sys.amiga.programmer
From: phsbs@marlin.jcu.edu.au (Simon Spagnol)
Subject: GCC 2.2.2 and math functions
Keywords: gcc 2.2.2, unix math library
Organization: James Cook University
Date: Mon, 23 Nov 92 01:52:58 GMT


Hello Netters,
	I am using gcc 2.2.2 to port some unix 
prgm to amiga, and ran into a slight problem.
I can't seem to find some math functions like

	y0, y1, yn, j0, j1, jn, lgamma,
	erf, erfc

in libm.a (or any .a file I have for that matter).
I assume the simple answer is there not there. 

So would anyone out there know where I can ftp a 
pd copy of some src  containing the afore mentioned 
functions. Actually complete libm.a functionality 
would be a bonus. 

To Mr Markus Wild, is there a possibility that
this will be fixed/included in newer releases of
gcc's libm.a?

	Any information appreciated,
	Simon.

+---------------------------------------------------------------------+
 Simon Spagnol - mild mannered physicist, power crazed computer user 
 email: phsbs@manta.jcu.edu.au                                      
 mail:  Physics Department                                                  
        James Cook University,
        Townsville, QLD, 4811,
        AUSTRALIA                                                  
+---------------------------------------------------------------------+