HDTenEightyP/NetNews huggingface dataset:
From: jbickers@templar.actrix.gen.nz (John Bickers)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware Manual)
Date: 20 Dec 92 03:22:50 PST
Organization: TAP

Quoted from <paulk.2r1u@terapin.com> by paulk@terapin.com (Paul Kienitz):

> overhead of Draw(), but who actually wants to sit through vektor
> demos anyway??  They're BORING.

    IYHO.

> About the only "contraint" I can think of that you have by going
> through the system is that copperlists can't be as fancy.

    You have all sorts of possible interference with the resources you
    need to use. There may not be enough CHIP RAM, or the audio.device
    may be in use, or controlling the display registers and also
    trying to use the OS for double-buffering may be out of the
    question, or the timing for changing bitmap pointers within each
    scanline may be thrown off, etc.

    You may also want to try and make it harder for people to rip your
    graphics or music.

    This whole thing about trying to make demo coders use the OS is
    akin to trying to make all painters use crayons, IMHO.
--
*** John Bickers, TAP.                   jbickers@templar.actrix.gen.nz ***
***    "Radioactivity - It's in the air, for you and me" - Kraftwerk    ***
From: bloc1469@ee.ee.uwm.edu (Gregory R Block)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: MPEG on the Amiga
Date: 21 Dec 1992 05:05:49 GMT
Organization: Electrical Engineering Dept. University of Wisconsin - Milwaukee
Distribution: world
NNTP-Posting-Host: 129.89.2.33

In article <1gsegrINNsj7@uni-paderborn.de> tron@uni-paderborn.de (Matthias Scheler) writes:
>I think a MPEG-to-ANIM5-converter with HAM(8) support would be the much better choice.
>You could archive anims as small MPEG files and convert them to larger ANIM5 files,
>beforcer viewing.

Umm, maybe 6 months before viewing...  MPEG is just too slow, let's be
honest with ourselves...

Greg

--
(: (: (: (: Have you overdosed on smileys today?  Why NOT!?! :) :) :) :)
(:   "Commodore has never proven to me, to my satisfaction, that      :)
(:    Marc Barrett is still alive."			       -Wubba :)
(: (: (: (: (: (: (: (: (: (: (: (: () :) :) :) Wubba, the Dark Angel :)
Newsgroups: comp.sys.amiga.programmer
From: ejames@venus.iucf.indiana.edu (ERIC JAMES)
Subject: Re: Pascal
News-Software: VAX/VMS VNEWS 1.3-4   
Reply-To: ejames@venus.iucf.indiana.edu
Organization: nothing
Distribution: comp
Date: Fri, 18 Dec 1992 16:04:10 GMT

In article <634@thunder.LakeheadU.Ca>, tlbechar@thunder.LakeheadU.Ca (Timothy Lee Bechard) writes...
>any information you can give me...
> 
>	Thanx You.
> 
> 
  PCQ pascal is located around fishdisk 500, with an update located on fish disk
511.
.
From: jamie@cdevil.unx.sas.com (James Cooper)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Need 2.04 includes..
Date: 17 Dec 92 15:08:50 GMT
Distribution: comp
Organization: SAS Institute Inc.
Originator: jamie@cdevil.unx.sas.com


In article <MJL.92Dec16034735@dino.ph.utexas.edu>, mjl@dino.ph.utexas.edu (Maurice J. LeBrun) writes:
>
>Sorry if this has come up before.  I am trying to call some 2.04 libraries
>(asl and gadtools) and apparently the header files that came with SAS/C 5.10
>are missing some important elements of 2.04.  So, short of upgrading to SAS
>6.x (that's $100 I don't have right now), is there any recourse?  Thanks in
>advance,

The latest available includes at the time the 5.10 master disks were created
were the 2.02 includes, not 2.04.

The best way to make sure of having the latest version of the Commodore include
files is to get them directly from Commodore:

        Commodore Business Machine, Inc.
        Department C
        1200 Wilson Drive
        West Chester, PA  19380

Ask for part # NATDEV20, they want $20 + $3 S&H.

If all else fails, send me EMail with your serial number, and I'll see what I
can do...

-- 
---------------
Jim Cooper
(jamie@unx.sas.com)                             bix: jcooper

Any opinions expressed herein are mine (Mine, all mine!  Ha, ha, ha!),
and not necessarily those of my employer.
Newsgroups: comp.sys.amiga.programmer
From: pelbe01@mailserv.zdv.uni-tuebingen.de (Martin Brenner)
Subject: Re: Hardware hacking....
Organization: Comp. Center (ZDV) U of Tuebingen, FRG
Distribution: inet
Date: Fri, 18 Dec 1992 13:12:48 GMT

In <S37732V.92Dec11174750@lk-hp-7.hut.fi> s37732v@snakemail.hut.fi (Markus Juhani Aalto) writes:

>Some hardware hackers here said that it's at least 50% slower to use OS
>than go directly to the HW. I don't believe this, but lets just pretend 
>this is the case. Then now that A1200 is from 2 to 5 times faster than
>old A500, that 50% is recovered. And your code should be even faster with 
>A1200 through OS than with A500 directly through Hardware.

>And because you can't use AGA with lower
>than 68020, then there is enough power to code with OS. But it requires
>KS3.0.

Wrong. You might want to use higher resolutions and more bitplanes.
Thats what AGA is for. But OS 3.0 has features that make using the
OS faster.

Not supporting hardware banging...
-Martin
--
Martin Brenner, Institut f. Theoretische Astrophysik, Universitaet Tuebingen
brenner@tat.physik.uni-tuebingen.de    <Deepthought the Nightfall Sourcerer>
DISCLAIMER: I take no responsibility whatsoever for any damage done to your
            monitor or mind resulting from your reading this article.
Xref: sparky comp.sys.amiga.programmer:17366 comp.sys.amiga.hardware:21511
From: TomK@cup.portal.com (Tom R Krotchko)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware
Date: Mon, 14 Dec 92 18:57:22 PST
Organization: The Portal System (TM)
  <70436@cup.portal.com> <amipb.04wr@amipb.gna.org>
  <Bz9qq6.5L6@dcs.ed.ac.uk>

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

That's a good point, except that too many games appear to coded by the same
people who coded the demos. And with predictable results.

TomK@cup.portal.com
Tom Krotchko
From: wild@nessie.cs.id.ethz.ch (Markus Wild)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Help with GCC and G++
Date: 20 Dec 92 18:18:07 GMT
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH

In article <1992Dec19.152246.6286@desire.wright.edu> fheitkamp@desire.wright.edu writes:
>In article <1992Dec18.131626.834@fwi.uva.nl>, solorzan@fwi.uva.nl (Valik Solorzano (I88)) writes:
>> Hai everyone,
>> I'm having problems trying to compile a C++ program with gcc on my Amiga.
>> Every time I try I get a lot of errors, and the same program I did compile
>> on a Sun Workstation with gcc any I din't get any errors.
>> 
>> Is this because I'm not using the C++ version of gcc or what. Because when
>> I try to use g++ on my Amiga I get the message 'g++ not executable'.
>> 
>> Could someone tell me what i'm doing wrong.
>> I use the gcc port for the Amiga, version 2.2.2.
>
>	You need to make sure your program has a .cc extension otherwise
>	gcc thinks it's a C program instead of C++.  I have gotton a C++
>	program to compile using the above suggestion and the following
>	command line: gcc [filename].cc -lg++ -o [filename]
>
>	I'm still getting an Error message:  undefined symbol
>	___new_handler referenced from text segment.

(gpp is an AREXX script, g++ is a /bin/sh script, for those that want a
g++ frontend).

The __new_handler bug is a known bug of the initial distribution. It has
been fixed in fix1. Please get fix1, fix2 and fix3, and save yourself a lot
of problems. Note: please set your STACK high enough while applying fix1,
the later fixes set the stack themselves, I didn't know about the stack
hunger of ar/ranlib when releasing fix1.

-Markus
-- 
Markus M. Wild    -  wild@nessie.cs.id.ethz.ch  |  wild@amiga.physik.unizh.ch 
Vital papers will demonstrate their vitality by spontaneously moving
from where you left them to where you can't find them.
From: peterk@cbmger.de.so.commodore.com (Dr Peter Kittel Germany)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware Manual)
Date: 9 Dec 92 09:27:23 GMT
Reply-To: peterk@cbmger.de.so.commodore.com (Dr Peter Kittel Germany)
Organization: Commodore Germany

In article <qDDgVB4w165w@lakes.trenton.sc.us> rock@lakes.trenton.sc.us (Rockerboy) writes:
>
>I have yet to see hardware hackers try to prevent people from using the 
>OS.  The OS people are _constantly_ trying to prevent the hackers from 
>hitting the hardware, though.  

You're completely wrong, I read here the exact opposite: HW coders saying
that *everything* in the OS is slow and bad, and Chris Green and other
OS advocates who say in every second sentence that there indeed *exist*
*legal* ways to access the HW directly! Yes, it's possible and legal!
E.g. you can do everything with the Blitter, *IF* you use that OwnBlitter()
protocol.

>After all, you have a situation of demos which only 
>work on certain machines vs. no demos at all.  

Yes, this is the bad situation. BUT: This is already so since a lot of
years, long before AA, in years where all programmers *had* a HRM!
But obviously those people can't read such manuals correctly, *many*
of the demos crash on different Amigas, because those dare to have
more memory/floppies/ECS/etc. etc.

So my conclusion is: The coder scene has proven that they also can't
write portable programs when they *have* the information. Why then
give them any???

-- 
Best regards, Dr. Peter Kittel  // E-Mail to \\  Only my personal opinions...
Commodore Frankfurt, Germany  \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
Wer's nicht kann, soll's bleiben klopfen oder Steine lassen!
From: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Hardware Reference Manual
Date: 12 Dec 92 19:39:51 GMT
Organization: Max-Planck-Institut f"ur Radioastronomie

In <6416@pdxgate.UUCP> idr@rigel.cs.pdx.edu (Ian D Romanick) writes:
>that bangs the hardware.  NO MATTER WHAT!  The difference is that with a
>manual people will know the right way to do it!  The idea behind having a
>manual is to prevent the complaints of, "Hey, this (what ever) doesn't work
>on my machine!"  You'll notice that a lot of the stuff that really breaks is
>older stuff.  Old demos (for example) tend to break if you run them off the
>wrong drive. :^) This is because nobody knew what was right and what was
>wrong, and they didn't care.  Now, we do care!  But we need the other half
>of the set!

Well, someone else commented that before and I can only repeat. The existence
of the hardware manual hasn't helped at all, why should a new one do the
trick ?

Some of todays demos may run on an A3000 but just because the demo coder
had access to an A3000 and not because he had the manual.

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: rob@spirits.ka.sub.org (Roland Bless)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Enforcer hits at 0000000
Date: Sat, 12 Dec 1992 09:58:34 GMT
Organization: Blessed Software Products, private, Karlsruhe (FRG)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 8bit
X-Newsreader: Arn V1.00 pre

In article <1g56slINN1p2a@rs1.rrz.Uni-Koeln.DE>, Wilhelm Stiefelhagen writes:

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

The reason is that you/the programmer forgot to check for NULL-pointers.
Something like:

char *text= NULL;
/* text isn't changed */
printf("gaga %s",text);

should be better (if text can contain the value NULL):
char *text= NULL;

if (text) printf("gaga %s",text);

> (The docs of Enforcer said just "lowest page", but I get everytime
> time  (ok, nearly everytime) hits at the absolut lowest adress. So I am a
> little bit concerned.)

The main reason are pointers containing NULL that are used without
an if().

Regards,
 Roland
--
R o l a n d   B l e s s |UUCP/USENET: rob@spirits.ka.sub.org        IRC: rob|
Groetzinger Strasse 44  |BITNET: UKG5@DKAUNI2.BITNET      FAX: +49211623818 |
7500 Karlsruhe - FRG    |---------spirits--in--the--material--world---------|
voice +49 721 497381    |           Die Menschheit lernt nie. Aus.          |
From: beust@aurora.unice.fr (Cedric Beust)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: More on ReadArgs() -- figured out some..
Date: 18 Dec 1992 14:58:40 +0100
Organization: University of Nice Sophia-Antipolis, France
Distribution: world
NNTP-Posting-Host: aurora.unice.fr


In article <BzFLy3.r9@usenet.ucs.indiana.edu>, shulick@navajo.ucs.indiana.edu
(Sam Hulick) writes:

	Sorry, this is not exactly the answer you're expecting (I don't
	have my autodoc handy, I prefer not to say wrong things), but
	you might want to consider a certain style guide. Rather than
	using an array of LONG like :

>  LONG arr[500];  /* plenty of space */

	define a structure with meaningful fields, thus the parsing
	will be more readable. For example :

struct {
  LONG ignore;
  char *learn;
  char *file;
} cl;

rd = ReadArgs("I=Ignore/S,L=Learn/S,Filelist/F/A", & cl, NULL);

	if (cl.ignore) {}
	else if (cl.learn) {}	
	else if (cl.file) {}

	Just an idea I'm using (all the fields must have a size of
	sizeof(LONG)).

	Now, closer to your problem, there is a special flag that tells
	ReadArgs() to include all the rest of the command line (was it
	/S?) so you would most likely get a char * pointing to the list
	of files separated with spaces (just a guess, I never used this
	flag). You might want to take a look at Delete's template which is
	probably using this flag.

--
Cedric BEUST, beust@sa.inria.fr, Bull Research Koala proj, KoalaBus & xforum
Pho:(33) 93.65.78.07(.66 Fax), INRIA, B.P.93 - 06902 Sophia Antipolis, FRANCE.
From: petter@pnilsen.adsp.sub.org (Petter Nilsen)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware Manual)
Date: 17 Dec 92 12:42:10 GMT
Reply-To: cbmehq!cbmnor!pnilsen!petter@cbmvax.commodore.com
Organization: Ultima Thule Software
X-NewsSoftware: GRn 1.16f (10.17.92) by Mike Schwartz & Michael B. Smith

In article <paulk.2r1u@terapin.com> paulk@terapin.com (Paul Kienitz) writes:
> > I'm certain that a sizable list of OS-friendly demos, and probably
> > all the well-known demos, can be supplied by the people on this
> > here net.  I'll start the list with Boing! (the first demo) and
> > Juggler.
>
> Boing! had to be revised more than once to work on evolving OS
> versions.  The first A1000 version had to be fixed in some way for
> 1.2, I think ... this is understandable when you remember that Boing!
> was written when the Amiga was a stack of wire-wrap boards instead of
> a set of chips.

Hey, I got all the demoes which were originaly used to show off the Amiga.
They ALL works on my A3000 running OS 3.0 !!   RobotCity, Boing etc. works
like a charm.

---
\\\\\\ E-Mail: petter@pnilsen.adsp.sub.org                      |\
 \\\\\\   or.. cbmehq!cbmnor!pnilsen!petter@cbmvax.commodore.com| \
  >>>>>>========================================================|  >
 ////// Disclaimer: These opinions are ALL mine !               | /
////// ->    Save the whales -- collect the whole set !     <-  |/
From: wild@nessie.cs.id.ethz.ch (Markus Wild)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: GCC & Amiga.lib
Date: 20 Dec 92 18:20:57 GMT
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH

In article <mbs.1hgf@adastra.cvl.va.us> mbs@adastra.cvl.va.us (Michael B. Smith) writes:
>Thirdly, did you remember to open dos.library? Without some special work,
>GCC does not do that automatically like DICE does.

That's a thing of the past, gcc should do this, together with initializing
SysBase.

>Fourthly, I suggest using the inline headers. They tend to generate better
>code (like the pragma concept in DICE/SAS/Manx).

Definitely, but they're quite memory hogs...

-Markus
-- 
Markus M. Wild    -  wild@nessie.cs.id.ethz.ch  |  wild@amiga.physik.unizh.ch 
Vital papers will demonstrate their vitality by spontaneously moving
from where you left them to where you can't find them.
Xref: sparky comp.sys.amiga.programmer:17571 comp.sys.amiga.hardware:21814
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
Subject: Re:  Attn Commodore: You are making a Big Mistake (Hardware
Date: 15 Dec 92 21:13:24 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

podesta@qut.edu.au (Department of Computing Science, QUT) writes:
>In article <heinz.057r@edohwg.adsp.sub.org>, heinz@edohwg.adsp.sub.org (Heinz Wrobel) writes:
>> have to make sure that you  don't mess up _your_own_ program? For me, it
>> would take longer to write a non-OS SW, because:
>> 
>>     a) No ENFORCER, MUNGWALL in the background
>
>Correct me if I'm wrong - (a redundant statement, of course) - but the 1200
>doesn't have MMU so you can't run either of these. Does this mean you need
>an A4000 to develop games for the AGA??

	I understand that there are a number of '030 cards in development for
the 1200.  I know that fastram boards exist as working prototypes.  I've even
heard people talking about '040 boards for it (I hope they replace the hatch 
with a fan, and add a MUCH bigger PS...).

>Does anybody know what the lowest end MMU AGA Amiga will be and when??

	You might want to check the WoC Toronto report in
comp.sys.amiga.announce.

-- 
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.
Xref: sparky comp.sys.amiga.programmer:17434 comp.sys.amiga.hardware:21634
From: Jon_Paddon@amusers.UUCP (Jon Paddon)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Pascal
Distribution: world
Date: 17 Dec 92 13:43:37 PST
Organization: AmUsers - The Amiga Users Group of Victoria BC

In a message dated Wed 16 Dec 92  3:02, Tlbechar@thunder.lakeheadu.ca (timo
wrote:

 T>  I am looking for Pascal for the Amiga Computer... If anyone has a
 T> Public Domain / commercial version of it, would they please reply.

I've got HiSoft Pascal and find it to be very usefull for writing Pascal
code. It is TurboPascal 5.0 compatible and supports all the standard pascal
data structures. There is also support for external libraries and UNITS.
The compiler is VERY fast and has a "smart link" system that builds all the
units easily into the main program.

On the PD side id PCQ which I used for a long time before I bought HiSpeed
Pascal. PCQ is a very good PD pascal compiler and will be more than
adequite for even the intermediate programmer. The only drawback to PCQ is
it does not support sets.


-- Via DLG Pro v0.995

Newsgroups: comp.sys.amiga.programmer
From: breese@monet.imada.ou.dk (Bjoern Reese)
Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware
Organization: Dept. of Math. & Computer Science, Odense University, Denmark
Date: Fri, 18 Dec 1992 14:01:06 GMT

In article <BzE0w1.4L4@research.canon.oz.au> andy@research.canon.oz.au (Andy  
Newman) writes:
> csg019@cch.coventry.ac.uk (-~=Zaphod=~-) writes:
> >In article <liam.0aet@durie.amigans.gen.nz> liam@durie.amigans.gen.nz (Liam  
Greenwood) writes:
> >
> >>ObApol. Sorry for the bandwith, but I can only take so much mindless  
blather
> >>        from what appears to be ex-64 Koders. Maybe if they all took an
> >>        operating systems course ....
> >
> >Maybe some of us are on the final year of an Honours degree in Comp. Sci.
> >
> 
> Doesn't mean a thing.
> -- 
> Andy Newman (andy@research.canon.oz.au)

Oh, please.... This is .advocacy stuff.

--

Bjoern Reese                   |     Email: breese@imada.ou.dk
Odense University, Denmark     |     Voice: +45 65 932 182 (private)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
From: engb@gpu.utcs.utoronto.ca (Ben Eng)
Subject: Re: CISC and RISC
Organization: Jet Penguin Lavatories
Date: Wed, 16 Dec 1992 00:41:27 GMT

In <BzAxFw.Is6@dcs.ed.ac.uk> jxp@dcs.ed.ac.uk (Joe Potter) writes:

>In article <1992Dec14.155039.7747@ugle.unit.no> skogaas@solan.unit.no (John Olav Skog}s) writes:

>>Optimizing compilers (it is easy to generate good code for the RISC
>>architecture)

>	Actually, I'm of the understanding that current compiler
>technology is rather left behind by the sheer complexity of RISC coding.
>It's easy to generate code for RISC machines, but getting turbopowered
>optimisations is hard.  CISC is easier to optimise.

I would like to see that statement qualified.

>>Hard-wired control unit
>>Optimized instruction pipeline
>>LOAD/STORE - architecture

>	What's actually so good about this, by itself?  Given all the
>other parts of RISC philosophy, great, but as a point by itself?

The features are good because they allow for a "better", faster
microprocessor.  The criteria for better are probably different for
different people, but clock speed, pipelining, scalability,
cost, the ability to be able to use new fab processes quickly,
and such are considerations.

>>One clock-cycle pr. instruction

>	Ideally.  More usually four cycles, but with a four stage pipeline.

Nominal throughput of 1 inst/clock, with a latency of 4 clock cycles.

> It may be easier to make op.sys.-software on a CISC processor.

I consider that to be an incorrect statement.  The operating system
is almost completely written in a language such as C or C++, just like
most other applications.  If the compiler handles the translation
well, where is the difficulty in generating code for RISC processors?
I don't remember seeing volumes of articles, or hearing many complaints
from RISC OS implementors about how difficult it is to generate code
for RISC as opposed to CISC.


It seems to me like your arguments against RISC are that it is more
difficult to program from a software point of view.  Well the benefits
you get are mostly embodied in the hardware improvements (speed,
design, fab processes, scalability, and whatever else RISC chip
companies deem important).  RISC vendors work closely with compiler
implementors when designing the instruction sets.  Essentially, the
machine interface for most software people becomes the compiled
language.  I mean, as an asm programmer, would you really want to
keep track of what values you have in 64 or more registers?  :-)
So get rid of the asm programmers (or lock them up in a compiler
vendor's lab) and everyone will be pretty happy.

Ben
-- 
e-mail: engb@gpu.utcs.utoronto.ca or ben@jetpen.gts.org (Ben Eng)
UofT EngSci 9T2                   ``We are all masochists here.''
Home: (416)-979-8761, (416)-979-7885
From: Tony-Preston@cup.portal.com (ANTHONY FRANCIS PRESTON)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Advice to SAS/C 5.10b users
Date: Thu, 17 Dec 92 07:34:35 PST
Organization: The Portal System (TM)

Actually, since I have found that most of my problems with 6.0/6.1
are my own, and once corrected run fine.  Other than one very large
IBM port, everything I work with is now under 6.1 and has no problems.
There are some really powerful features in 6.0/6.1 that 5.10B does
not have like:
   -- Coverage, this allows you to see how effective a test of a program
                was and helps you to completely test a program.
   -- CPR,      CPR has many improvements.  The least of which is a much
                better manual with examples of command usage.
   -- Libraries Better structured and much better documented!
   -- utilities Better documentation
   -- bugs      Well, from my experiences, 5.10B had more bugs than 6.0/6.1
                just better hidden, more subtle.
The one thing you do have with SAS is some great support.  If every product
I owned was as well supported, I would be pretty happy...
Newsgroups: comp.sys.amiga.programmer