HDTenEightyP/NetNews huggingface dataset:
From: solorzan@fwi.uva.nl (Valik Solorzano (I88))
Subject: MY AMIGA GURUS,HELP!!!!!!!
Keywords: guru
Organization: FWI, University of Amsterdam
Date: Thu, 17 Dec 1992 16:07:09 GMT

Sometimes my Amiga gurus with this error message:
80000003.another number could someone tell me what for error this is I try
to find it out, but without success, HELP ME

My system:

Amiga 2000+52MB Evolution 2.2+2MB Megamix III+1MB Chip+1085S Monitor
I did put the new 2.04 ROM 
Newsgroups: comp.sys.amiga.programmer
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: WShell: Hangning forbid!
Date: 14 Dec 92 03:50:56 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

jdickson@jato.jpl.nasa.gov (Jeff Dickson) writes:
>In article <1992Dec12.143541.21468@sth.frontec.se> bjst@sth.frontec.se (Bjorn Stenberg) writes:
>>A while ago there was some talk about process syncronization when
>>multithreading, and Randell Jesup suggested doing:

>>   Forbid();
>>   Signal(parent,sig);     // tell parent we exited
>>}
>>to make sure the child has exited before any other process gets a time slice.
>>Well, I do this in a child of mine, but after the parent exits WShell
>>complains with the message:
>>
>>***Hanging forbid!

>My guess is that you are mistakenly letting the forbid hang in the parent pro-
>cess. When the shell runs a program, the same process is used. This explains
>how Wshell could possibly know. Child processes are their own entities (task/
>process). Wshell or any shell for that matter is totally oblivious of such.

	I think Jeff is correct here.  Are you certain you're running the 
child process as an actual separate process?  I.e. CreateNewProc() or
CreateProc()?  Note that RunCommand runs the child on _your_ process.  Also
note that if you're starting it as another program with System(), then you
might get such a message - however, since the program would be loaded by
the new shell System() starts, there's no need for the Forbid().

	If you are running it as another process, then the bug must be
elsewhere.

-- 
To be or not to be = 0xff
-
Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Searching for DOS documentation
Date: 11 Dec 92 22:26:24 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

jdickson@jato.jpl.nasa.gov (Jeff Dickson) writes:
>>>>My question is WHY is the dos stuff documented separately?  
>>>	Ancient history dealing with contracts signed back before the Amiga
>>>was introduced...

>>Every time I try to use that book I get mad.  I read manuals all day
>>long and that's one of the worst.

>	The real problem here is that the filesystem was handed over to
>Commodore on a silver platter when they purchased the Amiga from Amiga Corp
>back in 1985.

	No.

> Plus, I don't believe the documentation was all that good either.

	True, it was a bunch of terse, confusing comments I think written
by Tim King about Tripos.  The original Bantam manual was just a copy of
this developer documentation in one manual.

>the market. Boy, was I disapppointed. Commodore ought to be more up on the
>curve nowadays (7 years later), but if they are the current release of the 
>AmigaDOS manual certainly doesn't reflect it.

	Unlike the RKMs, commodore does not have complete control of the Dos
manual, I think.

-- 
To be or not to be = 0xff
-
Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.
Newsgroups: comp.sys.amiga.programmer
From: shulick@navajo.ucs.indiana.edu (Sam Hulick)
Subject: Does opening libraries require a fixed varname?
Originator: shulick@navajo
Reply-To: shulick@navajo.ucs.indiana.edu
Organization: Vallen Software
Date: Thu, 17 Dec 1992 00:16:47 GMT


If I wanted, for instance, to open intuition.library, does the line
*HAVE* to be:

IntuitionBase = OpenLibr.......

Can it be something like "IBase = OpenLibrary(.." or "blech = Open..."
In other words, does it matter what you call the variable?
GadToolsBase, ExecBase, GfxBase, etc.

-- 
    // Amiga 3000   ___ \ Sam Hulick: shulick@indiana.edu (NeXTmail OK!)
   // 68030 25 MHz /__/\ \ My opinions wear combat boots.  Or whatever.
\\// OS 2.04       \__\/ / "Walk!  Not bloody likely.  I am going in a
 \/                     / taxi."  --George Bernard Shaw
Newsgroups: comp.sys.amiga.programmer
From: quandt@mcs213b.cs.umr.edu (Brian Quandt)
Subject: task communication and forbid()
Date: Fri, 18 Dec 1992 05:51:55 GMT
Organization: University of Missouri - Rolla

I have a question on how to communicate from a subtask to the parent.
The main problem is that I need to call forbid so that I can
ensure that I get timely response during the while loop.  Is it
legit to use globals?  Is there any special way that these
globals need to be declared (memory model) ?  I know that task
communication via globals and assumed constant memory addresses
is ugly but it seems to be the correct way on the amiga.  Is it?
Is there a better way? 
 
 {
 CreateTask( some task that reads keyboard input and sets globalKILL
 		appropriatly )
 
 forbid();
 
 while(!globalKILL)
	{
        
 	}
 
 permit();
 }
From: ry53@rz.uni-karlsruhe.de (Angela Schmidt)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Getting a valid FileSysStartupMsg pointers.
Date: 14 Dec 1992 16:59:22 GMT
Organization: Nessyhoehle@I501.NessyNet.de
Distribution: world
Reply-To: Angela@rz.uni-karlsruhe.de
NNTP-Posting-Host: tp70.rz.uni-karlsruhe.de

In article <37848@cbmvax.commodore.com>, jesup@cbmvax.commodore.com (Randell Jesup) writes:
> chris@alchemy.tn.cornell.edu writes:
> >However, apparently dol_StartUp does NOT always point to a valid
> >FileSystemStartupMsg (hereafter abbreviated FSSM) even though IsFileSystem()
> >returns true.  I have particularly found this to be the case on devices
> >which are not physical disks such as RAM disks or remotely mounted
> >network devices.

Here is a part of <dos/dosextens.h>. Please have a look at the commented
line. Doesn't this say, that there has to be a fssm in dol_Startup?
Or are there disks which are no real disks...?

| struct DosList {
|     [...]
|     union {
|         struct {
|         [...]
|         ULONG   dol_Startup;    /* startup msg: FileSysStartupMsg for disks */
|	  [...]
|	  } dol_handler;
|         [...]
|     } dol_misc;
|     [...]
|     };

> 	This is an ugly area.  Unfortunately, early in the Amiga days (or
> perhaps back in tripos), someone though strings would be neat to hold
> parameters for handler startups.

Grmpf. Programs like DiskCopy _need_ a fssm in dol_startup - otherwise
they cannot work correctely. Why do programmers make their handler 
doing bad things with dol_startup? To annoy the user by causing his
machine to crash or hang up?

> 	A heuristic approach: first, filter out values <64 (64*4 = the size of
> the 680x0 vector table, no pointer can be here).  Next, see if TypeOfMem
> on startup<<2 says it's real memory.  Next, see if the various FSSM pointers
> (or BPTRs) point to real memory (TypeOfMem again).  That should catch almost
> all cases.  (UGLY!!!!).

TypeOfMem() will return 0 if the pointer points to the ROM or to
RAM which holds the remapped ROM. Since e.g. fssm_Device and
fssm_Environ may and _do_ point into ROM area, you do have to
check this. But how shall I do this? Testing for an absolute
adress like 0x00F80000 will fail on softkicked machines.

And what will happen if fssm_Device or fssm_Environ point into
the expansion space...?


     V v
  @/@@=\   Salut,
    00 &=-      Angela 
oOoO_/` \\_
    \ /&\   Angela Schmidt cand. inf. (Nessy@IRC) | Amiga //
  |>O<|         EMail: Angela@rz.uni-karlsruhe.de | 1000 // 
   / \_/\/\/v,  Weekend: +49 731 712316 (9am-9pm) |  \\ // since 
  /___________\ Weekdays: 721 6904263 (10am-11pm) |   \X/ 1986 
Newsgroups: comp.sys.amiga.programmer
From: walker@twix.unx.sas.com (Doug Walker)
Subject: Re: Rewrite of PRINTF function, How do you do multi Args an
Originator: walker@twix.unx.sas.com
Date: Fri, 11 Dec 1992 19:29:10 GMT
Organization: SAS Institute Inc.


In article <70868@cup.portal.com>, jimdawson@cup.portal.com (Jim R Dawson) writes:
|> Could someone give me an example of how to use RawDoFmt() in C? I haven't
|> been able to figure out how to call this function and I cannot find an
|> example anywhere (except in asm).

|> |Jim Dawson - Author of AmiQWK .QWK mail reader | jimdawson@cup.portal.com|

Sure, here's a sprintf() implementation.  You can easily modify it
to work as a printf() instead.  Keep in mind that you MUST use %ld
to print a "long" or "int" value even if you are not using short
integers.

This should work on any ANSI-compliant compiler.

Note that the callback function below is really a string constant
which contains the code, written in hex, to implement the RawDoFmt
callback routine.  Using SAS/C, you can use the STRINGMERGE option
and this string constant will even be placed into the code section!

/*---------cut here---------------*/

#include <stdarg.h>
#include <clib/exec_protos.h>
#include <pragmas/exec_pragmas.h>

int rawsprintf(char *buffer, char *ctl, ...)
{
   va_list args;

   va_start(args, ctl);

   /*********************************************************/
   /* NOTE: The string below is actually CODE that copies a */
   /*       value from D0 to A3 and increments A3:          */
   /*                                                       */
   /*          move.b d0,(a3)+                              */
   /*          rts                                          */
   /*                                                       */
   /*       It is essentially the callback routine needed   */
   /*       by RawDoFmt.                                    */
   /*********************************************************/

   RawDoFmt(ctl, args, (void (*))"\x16\xc0\x4e\x75", buffer);

   va_end(args);

   return((int)strlen(buffer));
}

/*---------cut here---------------*/
-- 
  *****
=*|_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.
From: jamiller@kuhub.cc.ukans.edu
Newsgroups: comp.sys.amiga.programmer
Subject: Access to BIX developer sections or Developer's Mailing list??
Date: 19 Dec 92 14:52:07 CST
Organization: University of Kansas Academic Computing Services

Is there anyway to access the BIX developers sections via the
internet?  A guest login of sorts or something?  If not I wonder how
many people would be interested in a mailing list for certified
developers?  There's probably someone developer numbers could be
checked with C=, or ideally maybe someone at C= would like to run one?
Just a thought...
-- 
jamiller@kuhub.cc.ukans.edu
James Miller

_chicchai .sig no ho ga ichiban iin janai ka..._
             Enlightenment Happens?
Xref: sparky comp.sys.amiga.programmer:17560 comp.sys.amiga.hardware:21805
From: ahansfor@bigwpi.wpi.edu (Andrew L. Hansford)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
Subject: Re: CISC and RISC
Date: 19 Dec 92 03:05:42
Organization: Worcester Polytechnic Institute, Worcester, MA 01609-2280
Distribution: world
	<AHANSFOR.92Dec17115522@bigwpi.wpi.edu> <1gsorsINN327@crcnis1.unl.edu>
NNTP-Posting-Host: bigwpi.wpi.edu
In-reply-to: tbills@cse.unl.edu's message of 18 Dec 1992 14:57:00 GMT

>>>>> On 18 Dec 1992 14:57:00 GMT, tbills@cse.unl.edu (Trent Bills) said:

tbills> In article <AHANSFOR.92Dec17115522@bigwpi.wpi.edu>, ahansfor@bigwpi.wpi.edu (Andrew L. Hansford) writes:

tbills> |> True. But like exception handling, more support for this seems to go
tbills> |> into CISC machines.  As for multiple processors, you still incur the
tbills> |> same cost for a context switch.  Now you have more processors
tbills> |> switching.  Esp with microkernel architectures that instead of one
tbills> |> switch to the kernel and back to the calling function (2 switches),
tbills> |> you get a context switch to the kernel,  a message is copied or
tbills> |> remapped, a context switch to a user lever server, and then the server
tbills> |> enters the kernel to pass a message back to the calling proces.  Now
tbills> |> we have twice and many context switches.  

tbills> The idea behind having multiple processors is that you only have a few
tbills> active processes at any one time and that each processor can be more
tbills> or less dedicated to that process.

How many processors do you plan to have running?  How many processes
do you intend to have running?  I bet that at most any time
#processes > #processors. 


tbills> The cost of a context switch in a RISC machine isn't usually that much
tbills> more that a CISC machine.  The only real difference is that the CISC
tbills> machine only has to execute one or two instructions to perform the
tbills> context switch whereas the RISC machine will have to execute much more.
tbills> However, every instruction in the RISC machine will only take one clock
tbills> cycle whereas the instructions for a task switch in a CISC machine
tbills> will take a rather large number of clock cycles.  Every access to memory
tbills> will take at least one clock cycle regardless of the type of processor.
tbills> The result is larger code on the RISC machine, but roughly identical
tbills> performance for both.

Yes.  The time that each takes is roughly the same.  The RISC chips
come out slightly faster.  Still, the more registers the longer a
context switch.  And RISC machines, having the virtue of being of new
design, have larger register files.  The effect is that application
performance has seen a greater increase in performance than the OS.
Note that the OS functions on RISC still run faster than on CISC but
not by as large of margin.


-- Andrew Hansford
   ahansfor@wpi.wpi.edu
 
Newsgroups: comp.sys.amiga.programmer
From: kopnicky@great-gray.owlnet.rice.edu (Lyle Warren Kopnicky)
Subject: Re: Appropriate Shell For GNU Emacs?
Organization: Rice University, Houston, Texas
Date: Sat, 12 Dec 1992 23:36:53 GMT


The two big problems with shells in GNU Emacs are, to me, that (1) the
ANSI codes come out funny, and (2) when using "M-x shell", it inherits
my path (which is in my User-Startup) but not my aliases (which are in
my shell-startup), but when using "M-x compile" it doesn't even
inherit my path, so running a script like "gcc" or "lc -L" is useless,
because when they launch their own commands, the system can't find
them.  Anybody have any solutions to these?

--
+----------------------------Ren & Stimpy--------------------------------+
| "Psst. Hey Guido. It's all so clear to me now. I'm the keeper of the   |
| cheese. And you're the lemon merchant. Get it? And he knows it. That's |
| why he's gonna kill us. So we gotta beat it. Yeah. Before he lets      |
| loose the marmosets on us! Don't worry, little missy! I'll save you!"  |
+--------------- Quantum Seep -- kopnicky@owlnet.rice.edu ---------------+
From: ludde@milou.nada.kth.se (Erik Lundevall)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Hardware Reference Manual
Date: 11 Dec 92 17:28:04 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

In <1992Dec11.144552.1339@imada.ou.dk> breese@monet.imada.ou.dk (Bjoern Reese) writes:

>I got a copy of HRM (4th reprint, 1987) and it says absolutely NOTHING
>about "the right way", nothing about upwards compatibility. It even
>uses absolute adressing in its examples (like MOVE #$21000,bpl1pt.)
>It urges people to use the hardware directly! The only limitation it

The Hardware Reference Manual is just what the name implies, a reference
book for the hardware and how it works. Not a book teaching how to program
by hardware banging on the Amiga. That is quite a different thing.
There is no information about how to say compatible with the system, because 
that is supposed to be covered by other RKMs. 

Some people was picturing the Amiga as a "super-C64" and they 
thought the HRM was the closest equivalent to "Mapping the 64" or similar
books. That does not mean they were right.


>You simply can't blame the hardware bangers without blaming C=.
>Whether C= have matured or not, the harm was done, and they
>contributed to this situation, IMHO.

Possibly, because they thought that those who read the books would have 
some knowledge about OSes and interpret the given information in a proper
way. 
Most people with backgrounds from the C64 isn't in that category, but they
did like the Amiga and applied the knowledge they had on the new environment.


>--

>Bjoern Reese                   |     Email: breese@imada.ou.dk
>Odense University, Denmark     |     Voice: +45 65 932 182 (private)
-- 
-Erik Lundevall             ludde@nada.kth.se           
                            ludde@adder.adsp.sub.org    
Your fault. Core dumped.
Newsgroups: comp.sys.amiga.programmer
From: ruffalom@cs.uwp.edu (Mike Ruffalo)
Subject: FIle name truncations
Organization: University of Wisconsin - Parkside
X-Newsreader: TIN [version 1.1 PL8]
Date: Thu, 17 Dec 1992 01:26:16 GMT


	Does anyone know if there are any conventions on how one should go
about renaming AmigaDOS files (that have longer file names) to MSDOS'able
file names.
	The implimentation for this is going to be a mass file uploader
for a BBS program and it would be nice to stick to something firendly.
	Thanks.

-- 
///////////////////////////////////////////////////////////////////////////
			PANIC NOW AVOID THE RUSH!
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
From: bjst@sth.frontec.se (Bjorn Stenberg)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: SAS6.1 users: please read
Date: 12 Dec 92 00:35:20 GMT
Organization: IDK/Frontec - System Design Group

root@bcstarc.stgt.sub.org (Frank Pecher) writes:
> |>     And  I'd  expect  the  compiler to  give  an  unsigned/signed  conflict
> |> warning.  I  tried to get something like that after compiling your  example
> |> with STRICT and ANSI options but got no warning.

walker@twix.unx.sas.com (Doug Walker) writes:
> I believe you would find that this warning would come out a lot more
> than you think.  I don't think it would be particularly useful due to
> this.

I agree. An option to activate the warning would be nice, though.
Like a PICKY mode for use when STRICT isn't enough. :-)

	-- Bjorn


---------------------------------------------------------------------------
Bjorn Stenberg, Stockholm, Sweden                       bjst@sth.frontec.se
---------------------------------------------------------------------------
Organization: Carnegie Mellon, Pittsburgh, PA
Newsgroups: comp.sys.amiga.programmer
Date: Thu, 17 Dec 1992 18:45:19 -0500 
From: Michael Witbrock <mjw+@cs.cmu.edu>
Subject: Re: Emacs and SAS/C

Excerpts from netnews.comp.sys.amiga.programmer: 15-Dec-92 Emacs and
SAS/C Lyle Warren Kopnicky@gre (811)

> I have just recently purchased SAS/C 6.0 and I know it allows you to
> use whatever editor you wish.  This can be accomplished by changing a
> tooltype or something.  But don't you also have to change the
> appropriate ARexx scripts for use with the message browser?  I'm using
> gnuemacs.  If anyone had the appropriate scripts, it would be very
> helpful.  Thanks.

> --
> +----------------------------Ren & Stimpy--------------------------------+
> | "Psst. Hey Guido. It's all so clear to me now. I'm the keeper of the   |
> | cheese. And you're the lemon merchant. Get it? And he knows it. That's |
> | why he's gonna kill us. So we gotta beat it. Yeah. Before he lets      |
> | loose the marmosets on us! Don't worry, little missy! I'll save you!"  |
> +--------------- Quantum Seep -- kopnicky@owlnet.rice.edu ---------------+

You don't need scripts, just editor commands, which in gnuemacs are
emacs-lisp function calls
something like  
(find-file "%f")
(goto-line %l)
etc in the appropriate places (there is a menu in the message browser
that lets you fix them, but prior to v6.1, it would forget them again,
so upgrade with the patch first).
sorry this is a bit sketchy, I'm not at home near my amiga

p.s. if anyone has written a really spiffy compile mode for gnuemacs and
sas c, I'm sure lots of people woule like to see it.
michael
From: misar@rbg.informatik.th-darmstadt.de (walter misar)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Position independant code ?
Date: 11 Dec 92 18:45:21 GMT
Organization: TU Darmstadt

In article <Bz27o7.955@usenet.ucs.indiana.edu>, ejames@venus.iucf.indiana.edu (ERIC JAMES) writes:
>   The assembly output of the compiler I use looks like position dependant code
> to me, here is an example.
> 
>       move.b   #4,_variable
> 
>   Where _variable will be defined as a data storage area latter.  The output
> is then assembled using a68k and linked with blink.  Do either of these change
> the code into position independant code?  I am under the impression that all
> programs that work under the operating system MUST be position independant.
> The only other solution I can come up with is that the system might decide where
> in memory the program is to be loaded, and durring loading it fills in the
> actual memory locations, but I'm not sure.  Any help would be appreciated

Yes, the code is position dependant.
Programs working under the operating system needn't to be position
independant because whenever a program is loaded into memory, all position
dependant references to variables get corrected (There are some hunks, which
names I can't remember right now, where all position dependant adressings are
stored).
Yep, youre assumption is correct. 

-- 
Walter Misar
misar@rbhp56.rbg.informatik.th-darmstadt.de
From: rock@lakes.trenton.sc.us (Rockerboy)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware
Date: Wed, 16 Dec 92 14:41:50 EST
Reply-To: rock@lakes.trenton.sc.us (Rockerboy)
Organization: Lakes Public Access

jxp@dcs.ed.ac.uk (Joe Potter) writes:

> 	Remember, I can't use OS compliant software in the base machine case -
> it would be too slow, because I can't guarantee the presence of WB2.1 or bett
> I'd have to have *very* intricate code that figured out what calls were
> floating around that I could still use, all-or-nothing library coding seems t
> still be quite popular.  I suspect the answer to my quandary is the second
> option above, but this does lengthen development time and cost, and can raise
> production cost, especially in the manual ("If you're the proud owner of a
> machine with the AGA graphics hardware, you can select >KAPOW< from the title
> screen and run OS compliant! ...")

I agree with this completely.  I have never once suggested that people 
not use the OS when they can.  I simply think that the alternative should 
be available if a programmer feels the need to use it.  If it really is 
possible to make very good OS games, then the market will demand that OS 
games be released.

> 	I might also take this point to slap a few OS enthusiasts' wrists for
> doggedly attacking the demo-coders whilst also saying that the demo scene
> doesn't affect Amiga sales.  You can't have your cake and eat it!  If they
> don't matter, why should they comply?
> 
> 							Joe.
> 
> "How many times must the cannon balls fly?"

It would be nice if said OS enthusiasts spent more time on their own work 
and less time complaining about how other programmers choose to play.
Xref: sparky comp.sys.amiga.programmer:17551 comp.sys.amiga.misc:18784