HDTenEightyP/NetNews huggingface dataset:
From: aforrest@cs.strath.ac.uk (Andrew R Forrest CS92)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Why bother registering?
Date: 14 Dec 92 12:17:12 GMT
Followup-To: Why bother registering?
Organization: Comp. Sci. Dept., Strathclyde Univ., Glasgow, Scotland.

In article <11263@baird.cs.strath.ac.uk>, I, aforrest@cs.strath.ac.uk wrote:
>
>Does anyone know what (programming) documentation you get after
>registering in the UK as an official Amiga "Registered Developer"? Do you
>get all the reference manuals, or updates or what?
>
>Also does anyone from CBM know when the 3.0 stuff is going to be released
>to the public?
>

Thanks to everybody who replied - here follows the various bits and bobs
I was sent (in chronological order).


Andy Colebourne <andy@comp.lancs.ac.uk>:


 "It is well worth becoming a [registered] developer if you want to
 program the Amiga.  I have been a registered one for 2 years now.  If you
 join at the start of next year then you will only pay 1/2 price (about 40
 quid).

 "You get loads of documentation - I have just recieved a large amount all
 about 3.0.  You also get ROM-files that enable you to run 2.0/3.0 on a 500
 etc.  The autodocs are man-pages on disk and are extremely useful.

 The hardware discounts are good to - I bought a 1200 for 300 quid well
 before it was officially released."


From Bill Bennet <warda@vax.ox.ac.uk>:


 "...buying the _Native_ Developer's Kit for 25 quid gets you four disks,
 containing includes, headers, FD files, autodocs, debugging/development
 tools, example source code for 2.0, debugging/development advice docs, and
 the CATS AmigaMail docs.  The example source and the CATS notes are
 available from Fish disks, but the rest is copyright.  This also obviates
 having to buy the "Includes and Autodocs" manual, since all the info is
 provided on-disk.  It's a good deal, basically."


Also thanks to Steve McKinty <smckinty@france.sun.com>:


 "If you write to Commodore UK they'll send you all the info. Write to:

 Sharon Rodrigo
 Developer Support
 Commodore Business Machines (UK) Ltd.
 Commodore House
 The Switchback
 Gardner Road
 Maidenhead
 Berks
 SL6 7XA"


Anybody want to make this into a FAQ?

>Thanks.

-Andrew
-- 
|     \=====\  | Andrew Forrest               -  2nd Year Computing Science   |
|    /\\       | University of Strathclyde    -  aforrest@cs.strath.ac.uk     |
|   /==\\==(   |--------------------------------------------------------------|
| _(    )\     |            Signature removed due to lack of wit.             |
From: jaxh@dcs.ed.ac.uk (Jon Hanson)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: fread() in C
Date: 14 Dec 92 17:24:29 GMT
Organization: Department of Computer Science, University of Edinburgh

In article <Ixw6s*Su2@spirits.ka.sub.org>, rob@spirits.ka.sub.org (Roland Bless) writes:
> In article <BysKr2.3vu@dcs.ed.ac.uk>, Jon Hanson writes:
> 
> > I'm using fread() to read a large portion of a file into memory, using something like,
> >
> >       buffer = (struct [...] *) AllocMem(bufflen,MEMF_PUBLIC|...);
> >       if (buffer) fread(&buffer,1,bufflen,fileptr);
> > where bufflen is the portion lenght in bytes.
> 
> You should better use fread(&buffer,bufflen,1,fileptr); which means
> to read bufflen bytes in 1 block instead of reading bufflen*1-byte blocks.
> 
> With ANSI-C <bufflen> is type size_t which is library dependent. This could
> be "int" or "long int". If you link with 16-bit int's, so size_t is 16-bit,
> you might run into problems with buffer sizes >64kB.
> 
> > crashes. Is there some problem with using fread() with large'ish read lengths ?
> 
> You should be aware what size the number arguments have.
> 
> Regards,
>  Roland

To all the people who said that i should have put fread(buffer,..) not &buffer, this
was actually a typo - I was using 'buffer`. The above seems like a possible solution.

Thanks for the help anyway.

   .
   |on Hanson
 `-' jaxh@dcs.ed.ac.uk
Xref: sparky comp.sys.amiga.programmer:17444 comp.sys.amiga.hardware:21653
From: saunders@cs.arizona.edu (Richard T. Saunders)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
Subject: Re: CISC and RISC
Date: 16 Dec 92 20:32:02 GMT
Followup-To: comp.sys.amiga.programmer
Organization: U of Arizona CS Dept, Tucson

In article <BzByvD.FA9@news.cs.andrews.edu> adap@edmund.cs.andrews.edu (Edsel Adap) writes:
>In article <Bz8FD1.Dxt@ns1.nodak.edu> dewald@plains.NoDak.edu (Eric Dewald) writes:
>>Why should computer makers go from CISC to RISC?
>>

Talk about a loaded question! ;v)

>
>RISC - Reduced Instruction Set Computer
>CISC - Complex Instruction Set Computer
>

[Many useful and good points deleted for bandwidth reasons]

I would like to add my 2 cents to this. 

The RISC direction is, in some sense, a reaction to machines that
were _TOO_ CISC, such as the VAX.  When there were so many ways
to accomplish one task, it was difficult to "optimize" hardware
because it wasn't quite clear what the ramifications were.

So, "Simplify, simplify, simplify".  Try to discover only the
MINIMAL needs of the hardware, then hardware optimization (just as pre-fetching
instructions, data forwarding, etc) would be much simpler.  And, more
importantly, the ISSUES involved in hardware optimization would
be better understoood. 

This technology could then be applied to CISC chips in the future.
That is, until they discover "new and better ideas" they want
to incorporate into their chips.  Then they'll "simplify, simplify,
simplify" again for a better understanding.

In other words:
   
    REPEAT

      Simplify until you understand as well as possible
      
      Incorporate simple ideas into more useful "packages"---These
      packages will certainally be more complex in order to be useful

    UNTIL (pi=3)

I predict we'll see the RISC vs. CISC war again in about, oh, 10
years in a slightly different form.



saunders@caslon.cs.arizona.edu | "This is NOT Mel Torme!" - Top Secret
From: slmt9@cc.usu.edu (Joshua Dinerstein)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: MPEG on the Amiga
Date: 11 Dec 92 19:11:41 MDT
Organization: Utah State University

In article <71494@cup.portal.com>, Tony-Preston@cup.portal.com (ANTHONY FRANCIS PRESTON) writes:
> Is there an MPEG viewer that will run on an ECS machine?  

	Read the docs! :)

	I usually don't but I did in this case and it says right in the docs
that 3.0 is required but AGA is not. Just use the option flag "-amiga window"
and it will open a window on your workbench screen to whatever depth that is
at.

	Anyone wana recode this thing so that it does not use AGA at all?

	Joshua
	SLMT9@cc.usu.edu
-- 
**************************************************************
*                     *                                      *
*  Joshua Dinerstein  *  Nothing matters and what if it did? *
*  SLMT9@cc.usu.edu   *            - Who Knows!!!            *
*                     *              Anyone?? Anyone??       *
**************************************************************

If it's a raincoat why does it have to be dry cleaned?
        - Some Guy on some comody show
From: walker@twix.unx.sas.com (Doug Walker)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: SAS 6.1 and IDIR problems
Date: 16 Dec 92 13:59:47 GMT
Distribution: inet
Organization: SAS Institute Inc.
Originator: walker@twix.unx.sas.com


In article <JRAJA.92Dec15231111@vipunen.hut.fi>, jraja@vipunen.hut.fi (Jarno Tapio Rajahalme) writes:
|> What about adding _new_ include files to gst automagically? This would
|> ease up thing in the start phase of developing new code. You could
|> start with an empty gst which would then grow up with no changes to sc
|> options.

|> | Address: Jarno Rajahalme            | EMail:                              |

This would indeed be a nice feature, but there are some extremely
difficult technical problems in adding to an existing GST.  Most of
them have to do with incomplete structure tags (in fact, most of
the technical problems we did have had to do with incomplete
structure tags.)  If header file A uses a structure tag but never
defines it, then we have an incomplete definition in the GST; if
later you add header file B that does define it, we have to 
backpatch all references, but ONLY if the .c file includes both
header file A and header file B, and use the incomplete definition
otherwise.

Also, it is possible that the new file contains #defines or structure
definitions that actually CONFLICT with the information already in
the GST.  In this case, I have to make sure that the .c file being
included doesn't include both .h files, because this would never
work without GSTs.  This implies that I have to be able to tell which
symbols will affect the other .h file, which, given C's preprocessor,
is a near-impossible task.

With the current setup, what's in the GST is basically determined by
the state of the symbol table after one compile; this state is
guaranteed to be consistent, or an error would have been generated
during the GST's creation.  It is much, much more difficult to "guess"
at what errors WOULD have been produced when adding a new file and
produce them without actually reading the old file!

In the current GST implementation, there are the beginnings of a
technique to handle this.  We couldn't explore it fully in the time
available for 6.0, but hopefully someday we will be able to.

-- 
  *****
=*|_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: heinz@edohwg.adsp.sub.org (Heinz Wrobel)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Enforcer hits at 0000000
Date: 10 Dec 92 19:28:42 GMT
Organization: Edotronik GmbH

In article <1g56slINN1p2a@rs1.rrz.Uni-Koeln.DE> ad010@rrz.uni-koeln.de (Wilhelm Stiefelhagen) writes:
>Hello Guys,
>
>Last week I tested my Amiga-Programms with Enforcer. I got a lot of
>Enfercer hits of programs reading at adress 00000000. Some of the
>programs are candidates for crashes, some are not.
>Is this enforcer hit so common, and what is the reason?

You probably use pointer variables without checking for a NULL pointer
beforehand. This is often not deadly but _REALLY_ ugly and should be fixed.
Never ever use a pointer without checking it. This is _especially_
important with return values of system functions like AllocMem() or
OpenWindow(). Of course it apllies to everything else, too. If you don't
check the value you don't know what actually happened.

>Willi

--
Heinz Wrobel, Edotronik GmbH (ECG018)
FAX +49 89 850 51 25 / TEL +49 89 850 25 20 (HOME!&VOICE, sometimes...)
From: bloc1469@ee.ee.uwm.edu (Gregory R. Block)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: SAS6.1 users: please read
Date: 12 Dec 1992 03:14:08 GMT
Organization: Electrical Engineering Dept. University of Wisconsin - Milwaukee
NNTP-Posting-Host: 129.89.2.33

In article <1992Dec12.003520.16086@sth.frontec.se> bjst@sth.frontec.se (Bjorn Stenberg) writes:
>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. :-)

I also agree.  I see this as a subset of the typecasting conflict, so
I also think it should exist.

And after all, shouldn't "particularly useful" apply to us, the user?
;)  I don't think it's too much to ask.

Greg

--
(: (: (: (: Have you overdosed on smileys today?  Why NOT!?! :) :) :) :)
(:   "AAAAAAAAAAAAAAARRRRRRRRRRRRGGGGGGGGGGGGGGHHHHHHHHHHHHH!!!!!!!"  :)
(:		-Bobby Blazebleeder, BLAZEMONGER INC.		      :)
(: (: (: (: (: (: (: (: (: (: (: (: () :) :) :) Wubba, the Dark Angel :)
Newsgroups: comp.sys.amiga.programmer
From: perod@ifi.uio.no (Per Christian \deg}rd)
Subject: Re: Help a 1.3 programmer get started on 2.0
Organization: Dept. of Informatics, University of Oslo, Norway
Date: Tue, 15 Dec 1992 17:32:59 GMT
Originator: perod@yrsa.ifi.uio.no


In article <BzB6Ds.K6n@usenet.ucs.indiana.edu>, shulick@navajo.ucs.indiana.edu (Sam Hulick) writes:
> 
> I'm still writing apps that work on OS 1.3. :)  I don't know where to
> start learning OS 2.0 specific code.  For instance, how does one make
> the gadgets w/ key shortcuts?  I see them all the time.. i.e. a gadget
> 'Help' with the 'H' underlined.  And how do you make cycling gadgets?
> etc. etc.  I need a book that explains what functions to use, how to do
> it, etc.  I have the 'Includes And Autodocs' with all the functions..
> but I have no clue which functions to use to make these things.  Any
> help would be great.. thanks.

You don't really need more that 'Includes and Autodocs' if don't mind a lot
of looking-up. Looking in the .h and .i files explains almost
everything. However, buying 'Libraries' will probably help a lot.
Getting underlined characters isn't hard at all. Just place a '_' before the
character you want underlined, and hey presto! An underlined character.
Example:	dc.b '_Help',0    will work in your example.

There are flags for positioning the text too, but look in the gadtools files for
all the info. In order to enable tab-cycling, you just have to set a flag to
indicate that you want cycling. As far as I can remember this does only work on
2.04 and upwards.

Good luck!

Per Chr. Odegard (perod@ifi.uio.no)
From: podesta@qut.edu.au (Department of Computing Science, QUT)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Attn Commodore: You are making a B.
Date: 18 Dec 92 12:46:49 EST
Organization: Queensland University of Technology

In article <paulk.2r1u@terapin.com>, paulk@terapin.com (Paul Kienitz) writes:
> About the only "contraint" I can think of that you have by going
> through the system is that copperlists can't be as fancy.
>  
Considering that copperlists are, arguably, the most powerful hardware
resource that you have for demos, this is a pretty major constraint.
It is essential in games and demos to be able to instantly change some
pointer or color in a copper list without having to recreate the entire
copperlist.

Note that I'm not arguing that OS 3.0 is restrictive coz I haven't used it
with copperlists yet...I'm just saying that if it is, it's a major limitation.

James.
Newsgroups: comp.sys.amiga.programmer
From: chris@132.236.236.32 (Christopher A. Wolf)
Subject: Re: Getting a valid FileSysStartupMsg pointers.
Content-Type: text/plain; charset=iso-8859-1
Nntp-Posting-User: tc13@cornell.edu
Reply-To: chris@alchemy.tn.cornell.edu
Content-Transfer-Encoding: 8bit
Organization: none
X-Newssoftware: GRn-beta 1.16g (13.12.92) by Michael B. Smith & Mike Schwartz
Mime-Version: 1.0
Date: Fri, 18 Dec 1992 23:23:20 GMT

In article <1992Dec15.110215.18810@odin.diku.dk> bombadil@diku.dk (Kristian Nielsen) writes:
> ry53@rz.uni-karlsruhe.de (Angela Schmidt) writes:
>
> >In article <37848@cbmvax.commodore.com>, jesup@cbmvax.commodore.com (Randell Jesup) writes:
>
> >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...?
>
> Yes. For example the RAM: disk, or XFH:, or some network file systems
> apparently (?).

The network file-system I have heard about which does this is a custom
designed job on one of my beta-tester's machines.  I haven't seen it
myself but apparently it is actually a handler which expects a BSTR
much like your XFH-Handler does.

> Anyway, I'd be VERY interested in any opinions on the best way to solve
> this problem (ie. how to pass information to a file system handler that
> cannot provide a valid FSSM). My current approach is to overwrite the
> 'Startup' field in the device node with NULL (!), which is a terrible
> hack IMHO.
>
> 	- Kristian.

Actually I like this idea a lot and wish that everyone who needed to
pass something other than a FSSM would use it.  Its trivial to filter
out a NULL pointer but apparently impossible to 100% reliably filter
out non-FSSM pointers.  At least for my application finding a NULL here
would not cause any problems.

--
------------------------------------------------------------------------------
Christopher A. Wolf   mail: chris@alchemy.tn.cornell.edu   IRC: cwolf (#amiga)

The rec.arts.sf.starwars Frequently Asked Question List is available via anon.
FTP from the Star Wars archive site at wpi.wpi.edu. "May the FAQ be with you!"
------------------------------------------------------------------------------
Xref: sparky comp.sys.amiga.programmer:17483 comp.sys.amiga.hardware:21717
From: ahansfor@bigwpi.wpi.edu (Andrew L. Hansford)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
Subject: Re: CISC and RISC
Date: 17 Dec 92 11:55:22
Organization: Worcester Polytechnic Institute, Worcester, MA 01609-2280
Distribution: world
	<AHANSFOR.92Dec17000706@bigwpi.wpi.edu> <1gq3mlINNstt@crcnis1.unl.edu>
NNTP-Posting-Host: bigwpi.wpi.edu
In-reply-to: tbills@cse.unl.edu's message of 17 Dec 1992 14:43:33 GMT

>>>>> On 17 Dec 1992 14:43:33 GMT, tbills@cse.unl.edu (Trent Bills) said:

   In article <AHANSFOR.92Dec17000706@bigwpi.wpi.edu>,
|> 5) saving and restoring state on a page fault - Restarting an 
|> instruction and restoring the pipeline to its previous state (or near 
|> to it) can be very time consuming. (Of course CISC machines with a
|> pipeline have the same problem) |>

tbills> As far as I know, all of the current popular CISC chips ARE
tbills> pipelined at least to some degree.

tbills> The extreme cost of task switching is part of the motivation
tbills> for putting multiple processors in one machine.  Most (all?)
tbills> workstation makers have some kind of multiprocessor machine.

tbills> |> -- Andrew Hansford |> ahansfor@wpi.wpi.edu

tbills> - Trent Bills

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

-- Andrew Hansford
   ahansfor@wpi.wpi.edu












Newsgroups: comp.sys.amiga.programmer
From: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: MPEG on the Amiga
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Sat, 12 Dec 1992 20:52:16 GMT

In <1ga0g2INN6a0@uni-paderborn.de> tron@uni-paderborn.de (Matthias Scheler) writes:
>There's a Amiga MPEG Player on amiga.physik.unih.ch. I couldn't test it yet,
>because the SS10 corrupted my MS-DOS transfer disk.

Seems to work fine. I'm adding EHB screen support for those that do not
run Workbench 3.0 on AGA machines.

Regards,
-- 
Michael van Elst
UUCP:     universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
Internet: p554mve@mpirbn.mpifr-bonn.mpg.de
                                "A potential Snark may lurk in every tree."
From: paulk@terapin.com (Paul Kienitz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Hardware Reference Manual
Date: 12 Dec 92 10:42:29 PST
Organization: BBS

> As amigadisplays are based on bitplanes and VGA/SVGA cards is based
> on 1Byte==1Pixel technique, I would say it is impossible to get the > same
kind of texturemapping on an amiga as it of an SVGA display.
> I.E. I belive it cannot be done, whoever writes the amiga-port.
 
That's true if we try to do it by writing ONE pixel at a time to the
bitplane display.  But who says we have to set each pixel separately?
Figure out the colors of groups of 32 pixels, flip the bits "sideways",
and write whole longwords to the bitplane memory.  The overhead of
WritePixel with bitplanes doesn't have to enter the picture at all.
There's no reason texture mapped stuff can't be done with bitplanes.
From: c1a192@rick.cs.ubc.ca (Oliver Erik Seiler)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Sorry, can't learn from includes alone
Date: 15 Dec 1992 20:58:04 -0800
Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
NNTP-Posting-Host: bowen.rick.cs.ubc.ca

Well, you might want to pick up the Amiga ROM Kernal Manual 3rd Edition: Libraries.
This tells you everything you need to know to properly program the Amiga. The other
books in the series are also useful:
 Devices
 Includes&Autodocs
 User Interface Style Guide

-Oliver

-- 
\  Oliver Seiler  /\  \    /  /      _                              |||||
 \               /  \  \  /  /      /o\__   <--- My dream car...    (o o)
  \             /    \  \/  /_______-O--O'_____                      \^
   \_Insomniak_/      \_c1a192@rick.cs.ubc.ca_/                     _| |_
From: S.N.Owen@newcastle.ac.uk (Si Owen)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: File name truncations
Date: 18 Dec 92 11:29:45 GMT
Organization: Computing Laboratory, U of Newcastle upon Tyne, UK NE1 7RU.


In article <1992Dec17.012616.27248@cs.uwp.edu>, ruffalom@cs.uwp.edu (Mike Ruffalo) writes:
>
>	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!
>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

 Have a look in the source for MSH - it has to do just what you need. Even if
 you can't use the code in there, you'll learn enough to write your own.

 Si
______________________________________________________________________________
       __
 A500 ///    Simon Owen                        + Intelligence isn't to make no
 __  ///     S.N.Owen@newcastle.ac.uk          + mistakes,  but to see  how to
 \\\///                                        + make them good.
  \XX/       University of Newcastle-upon-Tyne +           
------------------------------------------------------------------------------
Newsgroups: comp.sys.amiga.programmer
From: cschneid@amiga.physik.unizh.ch (Christian Schneider)
Subject: Re: App(Icon|Window) and Style Guide.
Organization: ICU - University of Zurich, Dept. of Computer Science
X-Newsreader: TIN [version 1.1 PL8]
Date: Wed, 16 Dec 1992 11:34:35 GMT

Erik Funkenbusch (chucks@pnet51.orb.mn.org) wrote:
: heinz@edohwg.adsp.sub.org (Heinz Wrobel) writes:
: >In article <8765@orbit.cts.com> chucks@pnet51.orb.mn.org (Erik Funkenbusch) writes:
: >>Why doesn't the style guide define visual feedback for Appicons and
: >>Appwindows?  How do you know they are there?  How do you distinguish them from
: >>normal windows and normal icons?

Following AUISG, AppWindows 'should' provide a drop box like IconEdit.
AppIcons... hmm... perhaps up to the icon designer to ensure his AppIcon
is not mistaken for a normal icon..

- Chris

-- 
Chris Schneider - cschneid@amiga.physik.unizh.ch BIX: hschneider IRC: cschneid
It's impossible to enjoy idling thoroughly unless one has plenty of work to do
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware