HDTenEightyP/NetNews huggingface dataset:
From: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: New hardware reference guide?
Date: 27 Dec 92 15:47:36 GMT
Organization: Max-Planck-Institut f"ur Radioastronomie

In <92329.140836K3023E2@ALIJKU11.BITNET> K3023E2@ALIJKU11.BITNET writes:
>         And people can produce uncompatible code also using only library
>         calls.

Well, the problem is that it is much easier to become incompatible with
hardware banging. Libraries can reflect changes in the hardware, the
programmers intuition cannot.

>         What I'm trying to say and a lot of people don't understand is that
>         not giving away Hardware Specs does not implicate good software.

Agreed.

>         It seems that everybody thinks there is bad software just because
>         Hardware References were published. I think it's because people have
>         no software developing training or NOT ENOUGH COMMON SENSE.

Hardware banging generates bad code in 99% of the cases because:

hardware bangers do not want to be "limited" by "rules". As a software engineer
you know the importance to "rules".
hardware bangers don't buy other manuals than the hardware manual because
that would a) cost money and b) isn't needed as the hardware manual "tells
all".
harware bangers are the worst addicts of the NIH syndrome.

>         But people ARE getting wiser (I believe). And there are a lot of
>         people who just are interesting in how the AA Chips work and would
>         like to experiment for themselves and therefore need Specs.

True. But publishing specs is a tradeoff. C= decided (and I agree) that
hiding specs gets more positive results.

>         Do you really think that software doesn't run only because people
>         blindly hacked on the Custom chips? I think it's also because they did
>         not read enough of the Include&Autodocs and DOS Manual....

Agreed.

>         The only real effect of the absence of Specs is that there will be
>         no demos/(action) games for AA but just for ECS.

I don't think so. Demos might be a problem as 'coders' are of a special
mind set. But doing action games for AA is no problem.

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."
Xref: sparky comp.sys.amiga.programmer:17674 comp.sys.amiga.hardware:21929
From: amipb@amipb.gna.org (Philippe Berard)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
Subject: Re:  Attn Commodore: You are making a Big Mistake (Hardware
Date: 20 Dec 92 01:59:38 GMT
Organization: IWANIMA
X-NewsSoftware: GRn 1.16e (7/4/92) by Mike Schwartz & Michael B. Smith

In article <alien.01q4@acheron.amigans.gen.nz> alien@acheron.amigans.gen.nz (Ross Smith) writes:
> In article <Byowxw.7GH@cck.coventry.ac.uk> csg019@cch.coventry.ac.uk (-~=Zaphod=~-) writes:
> >
> >FACT:You run an OS friendly version of a game next to a hardware hacked game,
> >the hardware hacked game would look slicker and play better.
> >Check out the scroll on SIM CITY for a good laugh at OS based games.
>
> FACT: And as soon as C= release a new machine, the OS-friendly version will
> look slicker and play better, because the hardware-bashed game won't work
> at all.

  FACT: Who will buy this $6,000 game machine ???

                                   -- Philippe

.----------------------------------------------------------------------------.
|  Philippe Berard  (French Amiga User)       |                              |
|  "They hold a cup of wisdom,                | UseNet : amipb@amipb.gna.org |
|   But there is nothing within" (Kate Bush). |                              |
`----------------------------------------------------------------------------'
From: jaker@csugrad.cs.vt.edu (Jake Rose)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: AppIcons: HOW? WHICH APPS?
Keywords: prowrite
Date: 29 Dec 92 17:39:20 GMT
Organization: Virginia Tech Computer Science Dept, Blacksburg, VA

schuncke@cwis.unomaha.edu (John Schuncke) writes:

>Which programs support App(Icon|Window) in the standard WB2.x releases?

Good question - anything that uses the ASL (standard) file requester does,
in a way, since ASL requesters are appwindows (drag an icon onto one and
it goes to that directory, selects that file).

There are a good number of commercial apps starting to do this, but some,
like ProWrite, are awkward.  For example, ProWrite always opens an AppIcon
on the Workbench, which you can drop files onto to have ProWrite load them
up.  Well, this is all very nice until you set ProWrite to open on the
workbench screen.  It doesn't remove the AppIcon and become an AppWindow,
as it should.  You can't drop files into its window!  This really stinks,
to put it bluntly.  It's a pain to have to find the Workbench *under* the
largish ProWrite window (they should also let you set a magnification for
the view so you can make it use up less of your valuable desktop space),
then drop a file on the AppIcon, when the window's *right there*!

>+---------------------------------------------------------------------------+
>|    John L. Schuncke, Jr.  schuncke@cwis.unomaha.edu                       |
>|  Standard Meaningless Disclaimer:  You're takin' this WAY too seriously.  |
>+------------I Have Seen the FUN!!!--Zippy the Programmer-------------------+
-- 
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Jake Rose               :: Every cloud has a silver lining.
jaker@csugrad.cs.vt.edu :: Every silver lining has a cloud inside it.
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
From: paulk@terapin.com (Paul Kienitz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
Date: 1 Jan 93 18:51:30 GMT
Organization: BBS

> Perhaps you could divert your energies to showing how planar
> displays compete with the specific examples that people have
> mentioned already?
 
Why should I?  When did I claim they did?
 
What I've been trying to suggest to you is that your case for the
wonderfulness of chunky displays, though it started out valid, is now
being overblown way past what's realistic, and furthermore (speaking
of energies needing to be diverted) you are coming across as a foam-
mouthed lunatic instead of a reasonable person.  CALM DOWN ALREADY!
 
Chunky is NOT pure wonderfulness with zero disadvantages.  It has
valid strengths but you are claiming something more like faultless
perfection with none of the planar disadvantages, when in fact chunky
has some quite similar shortcomings when word length != screen depth.
And you never even consider any case other than using ar
display of the exact depth that chunky handles best.  Clearing the
top two bitplanes ... jeez!
 
> One thing that is becoming noticeable here is that a couple of the
> people who are trying to say that chunky pixels are not better than
> planes for the given operations were _also_ involved in the
> hardware manual thread, on the side of those who don't care about
> hitting the hardware directly. In my view, they're blowing their
> credibility with this stuff about planes.
 
Trying to sweep the legitimate shortcomings of your alternative under
the rug, and ranting like a newly converted communist revolutionary,
don't help YOUR credibility.
 
It's simple.  If chunky was universally better in every way, then no
planar systems would have been built.  Think about it.
From: fheitkamp@desire.wright.edu
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Pascal
Date: 29 Dec 92 06:32:24 EST
Followup-To: mglew@laurel.ocs.mq.edu.au (michael glew)
Organization:  Wright State University 

In article <1992Dec28.224148.26267@mailhost.ocs.mq.edu.au>, mglew@laurel.ocs.mq.edu.au (Michael Glew) writes:
> I have been using PCQ Pascal for about 2 years privately, and 6 months
> professionally.  It is a very good package for developing software
> and I thoroughly advise getting it.  It can be ftp'ed from amiga.physik
> and wuarchive.wustl.edu, or archie.au in Australia.
> 
> I aggree about it not supporting sets, but you can get around that quite
> easily.  You could probably implement it yourself.

	I down-loaded PCQ and played around with it, and thought it was
	really nice.  I didn't end up using it much though because of
	personal preferences.  I also have Turbo Pascal on my Bridgeboard.

	I really thought Mr Quaid did an excellent job and wonder why he
	never "finished" PCQ.  It seemed like he had a good enough start
	that a company specializing in Amiga software could pick it up.  

	Just making a few lame comments.  
> 
> 
> Regards,
> 
> 	Mike.
>  -----------------------------------------------------------------------------
>  Internet:	mglew@laurel.ocs.mq.edu.au
>     Phone:	+61 43 841525
> 
>                      "I have a cunning plan..."	- Baldrick (Black Adder)
>  -----------------------------------------------------------------------------
>      Michael Glew - School of Math Phys Comp & Elec - Macquarie University
>  -----------------------------------------------------------------------------
> 
Fred Heitkamp, ** Not an organization **
From: cschneid@amiga.physik.unizh.ch (Christian Schneider)
Subject: Re: Getting a valid FileSysStartupMsg pointers.
Organization: ICU - University of Zurich, Dept. of Computer Science
X-Newsreader: TIN [version 1.1 PL8]
Date: Fri, 25 Dec 1992 13:26:33 GMT

Angela Schmidt (ry53@rz.uni-karlsruhe.de) wrote:
> Maybe you will miss DF0:, DF1:, DF2: or DF3: in future... But what do
> you think about the following checks:
>   - (dn_Startup<<2)>=1024
>   - AllocAbs ((dn_Startup<<2), x) MUST fail

Hmmm... If there's something like a normal pointer or other trash
in dn_startup you'll end up with an enforcer hit.
I think I'll stay with TypeOfMem(dn_startup<<2);

> good way to avoid crashing. Flames to /dev/nil.

cschneid> echo flame >/dev/nil
/dev/nil: Permission denied

;-))

>   |>O<|         EMail: Angela@rz.uni-karlsruhe.de | 1000 // 

- 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
From: heinz@edohwg.adsp.sub.org (Heinz Wrobel)
Newsgroups: comp.sys.amiga.programmer
Subject: Re:  Attn Commodore: You are making a Big Mistake (Hardware Manual)
Date: 23 Dec 92 09:05:28 GMT
Organization: Edotronik GmbH

In article <amipb.05bh@amipb.gna.org> amipb@amipb.gna.org (Philippe Berard) writes:
>    It seems you've forgotten what makes AmigaDos so appealing : the custom
					       ^^^

AmigaDOS has _nothing_ to do with the custom chips. You probably mean
_replacable_ parts of the AmigaOS like "trackdisk.device" or
"graphics.library".

>    If you really think what you say, just buy a cheap PC with OS/2, which
>    isn't much different from AmigaDos. Of course you will need a 486 to
     ^^^^^^^^^^^^^^^^^^^^

Obviously you don't own a copy of OS/2. If you did, you knew what you are
talking about.

>				    -- Philippe

--
Heinz Wrobel, Edotronik GmbH (ECG018)
FAX +49 89 850 51 25 / TEL +49 89 850 25 20 (HOME!&VOICE, sometimes...)
From: ry53@rz.uni-karlsruhe.de (Angela Schmidt)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Getting a valid FileSysStartupMsg pointers.
Date: 21 Dec 1992 12:29:20 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 <1992Dec18.232602.24034@mail.cornell.edu>, chris@132.236.236.32 (Christopher A. Wolf) writes:
> In article <71731@cup.portal.com> Tony-Preston@cup.portal.com (ANTHONY FRANCIS PRESTON) writes:
> > What I did was create a little routine that checked the name against a
> > list which includes all the devices I wish to ignore such as:
> >
> >    PIPE, RAM, RAD, VD0, SER, PAR, ect...

> This is rather an unacceptable hack since there is no guaranteed consistency
> of device names between different configurations, OSs or machines.

That's right! You _never_ should use this method!

> SER:  and PAR:  and I think PIPE:  can easily be filtered out by doing an
> IsFileSystem().  RAM: and RAD: seem to be well-behaved and place a NULL
> in the dol_StartUp.  VD0: behavior I'm not sure about.

RAM: will place $00000000 into dol_Startup, but _my_ RAD: has a normal
fssm! So I can use DiskCopy with RAD: and my disk editor will also
be able to access it. If your RAD: has no fssm in dol_Startup, you
probably have a non-standard RAD:. BTW VD0: has a real fssm in dol_Startup,
too.

I like devices with either a real fssm or $00000000 in dol_Startup... ;-) 


     V v
  @/@@=\   Merry Christmas and a Happy New Year,
    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
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
Date: 2 Jan 93 03:24:33 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

doiron@starpt.UUCP (Glenn Doiron) writes:
>> So if you have a plane oriented memory (which is no real problem with VRAMs
>> although you may get some alignment restrictions) then you have to convert
>> it in hardware. This needs _shiftregisters_ and _buffers_. An example for
>> such a hardware is the Denise and the Lisa chip (both also have a priority
>> logic and Denise includes the RAMDAC).
>
>... which use DRAM's, not VRAMS.  No amount of 'alignment restrictions' is
>going to cut it for VRAM planar, unless, as I said, you do funky
>address/data schemes and put one plane in each VRAM, then mess further with
>your RAMDAC feeding setup.  Using VRAMS like DRAMS will result in a loss of
>all the performance gains VRAMS were supposed to give you in the first
>place.

	VRAM can be used for planar, they merely would require much larger
plane-FIFOs.  Obviously VRAMs do not lend themselves as cheaply to planar
as they do to chunky.

>But you're saying chunky->bitplane conversion is a small fraction of the
>whole operation.  It's not.  That ridiculous amount of masking/shifting
>might even take longer than the matrix multiplications.  For instance, on a
>68000, each shift takes *2* additional clock cycles! (yuck!)

	AGA machines are unlikely to ever be made with 68000's.  680(>=2)0's
have barrel shifters (and BFEXTU/BFINS).

-- 
GNU Emacs is a LISP operating system disguised as a word processor.
 - Doug Mohney, in comp.arch

Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
jesup@cbmvax.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.
Newsgroups: comp.sys.amiga.programmer
From: jamie@cdevil.unx.sas.com (James Cooper)
Subject: Re: wierd sas/c bug
Originator: jamie@cdevil.unx.sas.com
Date: Mon, 21 Dec 1992 20:39:53 GMT
Organization: SAS Institute Inc.


In article <BzMGn8.370@ccu.umanitoba.ca>, umfehr06@ccu.umanitoba.ca (John Fehr) writes:
>In <BzM6F7.E6K@unx.sas.com> walker@twix.unx.sas.com (Doug Walker) writes:
>>Please post a COMPILABLE example.  I can virtually guarantee that this
>>is not a compiler bug.  A compiler that broken would not compile
>
>OK... here's a compilable example: (hopefully I'll type it in right this
>time. :)
>
>#include <stdio.h>
>#undef WHATEVER "test"
>
>char dummy[100]="another test";
>
>main() {
>  printf("dummy='%s'\n",dummy);
>}
>
>That SHOULD (it does for me) print out something totally unexpected.
>What's almost as wierd, is if you #include something after the
>#undef.  (an empy .h file will do)
>I know that #undef WHATEVER "test" isn't ANSI-compliant (the HP-compiler
>complanes about it anyway) but some programs actually have that in
>their code.

Wow... good one!  How about an official EMITS report, just to make us happy! :-)

It appears the first "test" is getting merged with the "another test" string,
per ANSI concatenation rules, such that you get:

dummy = 'testanother test'

when you compile and run this sample program... wierd!

-- 
---------------
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.
From: jamiller@kuhub.cc.ukans.edu
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Access to BIX developer sections or Developer's Mailing lis
Date: 22 Dec 92 03:33:05 CST
Organization: University of Kansas Academic Computing Services

In article <72132@cup.portal.com>, Tony-Preston@cup.portal.com (ANTHONY FRANCIS PRESTON) writes:
> There is not way Bix is going to let you connect as a "guest" without
> paying the fees.  I used to be on BIX.   I would be interested in a 
> developer's new group or mailing list, It would be great.

Perhaps someone could approach someone from CATS and make sure they
wouldn't have a problem with something like a mailing list for now
provided mail was encoded.  They could of course approve whatever
encryption was used and maybe designate a weekly passwd or something.

The ideal solution I think would be if C= would set up a small area on
their VAX as a developer BBS where people could read AmigaMail and
maybe some kind of newgroup there or something.  

I don't see any need to support BIX or the other commercial BBS when
developers and C= aren't getting anything in particular out of it, IMHO...
-- 
jamiller@kuhub.cc.ukans.edu
James Miller

_chicchai .sig no ho ga ichiban iin janai ka..._
             Enlightenment Happens?
Xref: sparky comp.sys.amiga.programmer:17670 comp.sys.amiga.hardware:21925
From: steve@cbmtor.uucp (Steve Vetzal)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware
Date: 21 Dec 92 17:12:59 GMT
Organization: Commodore Business Machines (CANADA)

Personally, I like the way that the AmigaDOS v3.0 graphics library allows you
to query as to what the graphic screen geometry looks like. This would enable
software to be both OS compliant, and work extremely quickly with the raw bit
level graphics. With newer architectures coming out, I would hate to see too
much software break... But we don't want to see here the same thing that is
dealt with in the IBM world - maintaining compatibility at the expense of
performance and programmers' sanity. After all, the whole point of technology
is bigger/better/faster isn't it?

I enjoy watching 'euro-demos' and I have sold many a system based on the "wow"
that follows. (Back in my salesman days) It would be a shame to lose this...

Newer graphics geometries shouldn't be all that different from those available
today. You can conceivably write an application that functions today, as well
as two years from now. As to writing one that will function five years from
now, I don't think that is much of a concern. (How long do you keep your
euro-demos on file? Me - three days to a week...)

				      Steve Vetzal
From: Karsten_Weiss@ibase.stgt.sub.org (Karsten Weiss)
Newsgroups: comp.sys.amiga.programmer
Subject: Chunky Pixel Mode for Low End Chip Set?
Distribution: world
Date: 23 Dec 92 21:30:06 MET
Organization: Intuition-Base BBS Leonberg

 
Some days ago I read the feature list of the new Low End Chip Set and the
High End Chip Set Commodore is developing at the moment. I was very happy
to see that Commodore finally decided to implement a chunky pixel mode
which is very important to me. However, I recognized that the chunky mode
was only mentioned in the list of the High End Chip Set features. Was this
a mistake? I DON'T HOPE SO!!! Could anybody from Commodore confirm this?
Thanx in advance...
 
I think it is very important that the Low End Chip Set will get the
chunky mode as well because that would make it possible to convert games
such as Ultima Underworld I + II, Comanche, Strike Commander, etc. with
FULL SPEED!!! It doesn't help very much when only the High End will get
chunky because the Low End Chip Set will be in the 'game computer' of the
future - not the High End!
 
Any other opinions?
 
                                                     Karsten Weiss
 
PS: Don't tell me it is possible to code such stuff with compareable
    speed on the current Amigas...

-- Via DLG Pro v0.995

 
/================================================================\
| UUCP:  Karsten_Weiss@ibase.stgt.sub.org | 'Life Is Ours,       |
| FIDO:  2:2407/106 (Karsten Weiss)       |  We Live It Our Way' |
| Voice: +49-(0)7192-8444                 |          (Metallica) |
\================================================================/
From: beust@aurora.unice.fr (Cedric Beust)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: AmigaDOS library functions and ANSI-C programming
Date: 30 Dec 1992 10:42:49 +0100
Organization: University of Nice Sophia-Antipolis, France
Distribution: world
NNTP-Posting-Host: aurora.unice.fr


In article <1992Dec29.221144.26405@urbana.mcd.mot.com>,
qbarnes@urbana.mcd.mot.com (Quentin Barnes) writes:

>I ran across a widespread problem with the AmigaDOS specific
>prototypes/libraries with writing ANSI-C code.  AmigaDOS
>functions which take pointers to objects when the objects
>aren't modified are not marked as "const". 
>
> [short example deleted]
>
>I don't care about hacks such as marking those errors ignored
>or casting.  The real problem is that the AmigaDOS library
>function calls need their signatures cleaned up.  This may be
>an annoying problem with ANSI-C code, but it will prove fatal
>with C++.

	Funny, I had the very same thought yesterday night! (no, I wasn't
	dreaming of Amiga programming, don't worry for my mental health :-)).

	I was reading the autodoc for AddHead which looks like
	AddHead(struct List *list, struct Node *node)
	and I was wondering if a copy of the node would be done and then
	pointed to in the list or if *my* node would be directly referenced.

	This is a major difference! The safest way in my mind is when
	the system takes care of allocating a new node, copying the one
	I pass and then referencing this one, leaving me free to to what
	I will with my node (I used this scheme in my generic database
	package which I described shortly in a previous post).

	The advantage of this method? Simple : you can use the same
	static node to create a list. For example :

static struct Node *myNode;

while (condition) {
  /* fill myNode with some value */
  AddHead(list, myNode);
}

	There might be drawbacks of course but this is not my point (sorry,
	I digressed a little). Since this wasn't mentioned in the autodoc,
	I decided to go safe and allocate myself a new node at each call.
	The information might be in the RKM (I didn't check), but I really
	think this kind of detail should be mentioned, either in natural
	language, or by the use of the const keyword whenever possible.

	Just a few thoughts...
--
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.