HDTenEightyP/NetNews huggingface dataset:
From: smb@pern.cc.purdue.edu (Scott M. Ballew)
Subject: Re: What is htonl() ?
Organization: Purdue University
Date: Wed, 23 Dec 1992 15:22:50 GMT

In article <72250@cup.portal.com> Counsellor@cup.portal.com (Benjamin Counsellor Reich) writes:

>   I am stumped by one line of code:

>	*lmark = htonl(*lmark);


To which too@cardhu.cs.hut.fi (Tomi Ollila) replies:

>that function (Macro) return 32 bit value of its host byte order value in
>network byte order. because 680x0 processor uses network byte order in 16
>and 32 bit values (LITTLE ENDIAN) , that function is implemented as macro
>whis does no conversion:

>#define htonl(x)	(x).

>.. in that case you couild just remove the line and reduce a few cycles
>from execution time, but it would cause combabitily problems.

Any reasonable compiler/assembler will optimize these "few cycles" out
of the finished binary.  Please _leave_ those htonl() lines (and any
ntohl(), htons(), ntohs() lines) in the source code!  The only cost
of leaving them will be during compilation.  The cost of taking them
out will be pain and suffering when the code is moved to a
little-endian machine (the 680x0 family is big-endian, by the way).

Scott
Newsgroups: comp.sys.amiga.programmer
From: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: task communication and forbid()
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Wed, 23 Dec 1992 17:14:31 GMT

In <1992Dec23.134958.23831@cis.ohio-state.edu> juncewic@turtle.cis.ohio-state.edu (thomas michael juncewicz) writes:
>I thought the use of forbid() in effect 'turned off' multitasking.  Wouldn't
>it prevent a subtask from being executed, and therefore waiting for a signal
>from that task would be in vain?  Or am I misunderstanding the question
>entirely?  Please excuse my ignorance..

The trick is that 'waiting' temporarily enables multitasking again until
the signal is delivered and your task runs again.

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."
Newsgroups: comp.sys.amiga.programmer
From: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: Getting a valid FileSysStartupMsg pointers.
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Tue, 22 Dec 1992 19:13:35 GMT

In <1992Dec22.143308.26492@rzu-news.unizh.ch> cschneid@amiga.physik.unizh.ch (Christian Schneider) writes:
>This is rather dangerous. No enforcer hits? Did you have devices
>with all (five?) possible dn_Startups (NULL, four letter ASCII, char *,
>int, valid fssm are the possibilities I think to remember).

The possible values I know are:

NULL, BSTR, small integer (<64) and BPTR to fssm. The problem is the
BSTR.

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: chucks@pnet51.orb.mn.org (Erik Funkenbusch)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Stupid C question
Date: 28 Dec 92 08:25:02 GMT
Organization: People-Net [pnet51], Minneapolis, MN.

ad99s461@sycom.mi.org (Alex Deburie) writes:
>However, I have one very stupid (simple?) question. HOW DOES ONE COVERT A 
>FLOATING POINT VALUE TO AN INTEGER???!!!  I see functions like modf(), but 
>still that returns the integral part of the number as a float. And casting 
>seems to always return a 0!


funny... this return 6 when i run it.

void main(void) {

    printf ("%i\n", (int) 6.123);

}

I don't know why casting would return 0 for you..
From: stern+@pitt.edu (Eric G Stern)
Newsgroups: comp.sys.amiga.programmer
Subject: How do I start Enforcer?
Date: 22 Dec 92 17:43:07 GMT
Organization: University of Pittsburgh
Originator: stern@unixd3.cis.pitt.edu

Hi,

    Unfortunately, I will probably have to have some sort of Fortran
capabilities on my Amiga at some time in the future, so I've been
taking a look at f2c, the Fortran->C converter from Bell Labs.
I retrieved the source code from the net and was able to compile
it on a unix machine at work, so I thought I should be able to compile
and run it on my Amiga.  I found that when I compile it under
SASC v 6.00, it compiles (with a lot of warnings), but running it
just gives gibberish.    However, I can compile it
under SASC v5.10 with equivalent compilation options and
it works correctly.  What should I do?  Possibly something
is wrong that SAS should know about, but this is a huge program
that I don't really know anything about, so I can't localize the
problem as they need to do anything.    Did anything really change
so that working code breaks between 5.10 and 6.00?

				Eric Stern
From: stern+@pitt.edu (Eric G Stern)
Newsgroups: comp.sys.amiga.programmers
Subject: snapshot and SASC 6.0
Summary: 
Followup-To: 
Distribution: world
Organization: University of Pittsburgh
Keywords: 


From: stern+@pitt.edu (Eric G Stern)
Newsgroups: comp.sys.amiga.programmers
Subject: snapshots and SASC 6.0
Summary: 
Followup-To: 
Distribution: world
Organization: University of Pittsburgh
Keywords: 

Hi,

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

				Thanks,
				Eric Stern
From: stern+@pitt.edu (Eric G Stern)
Newsgroups: comp.sys.amiga.programmers
Subject: How do I start Enforcer with a 68040 accelerator
Summary: 
Followup-To: 
Distribution: world
Organization: University of Pittsburgh
Keywords: 


Hi,

    I would like to run Enforcer with my GVP G-force '040 accelerator
to help debug a stubborn port of a unix program.  However, when I
try to run it from the CLI, it tells me that "CPU too expensive".
I've tried turning off the mapping of kickstart into 32 bit RAM
and turning off caches, but it doesn't help.  How do I get this to
run?

    I don't have a version number for this program, but it is 6400 bytes
long if that helps.  I'm running this on a GVP G-force 040 board for the
A2000 with a hard drive on the SCSI port of the board if that makes
any difference.  The operating system is AmigaDOS 2.05 with kickstart
2.04 ROMS.  The documentation doesn't tell me what this error message
means or what to do to fix it.

				Thanks,
				Eric Stern
Newsgroups: comp.sys.amiga.programmer
From: 22black@sol.cs.wmich.edu (Martin Black)
Subject: Re: Chunky Pixel Mode for Low End Chip Set?
Organization: Western Michigan Univ. Comp. Sci. Dept.
Date: Wed, 30 Dec 1992 04:09:48 GMT

Paul_Trauth@agwbbs.new-orleans.LA.US (Paul Trauth) writes:

>In a message dated Mon 28 Dec 92 18:18, Jbickers@templar.actrix.gen.nz (joh
>wrote:

> J>     Faster AND smaller. :) Hopefully at least the folks writing the OS
> J>     routines will have access to hardware documentation, and thus be
> J>     able to write code Amigans can be proud of.

>Okay, i've been vaugely following this "Chunky Pixels Rule OK!/Bitplanes
>Rule OK!" thread.
>They BOTH have their advantages, really. I mean, i'd hate to do a
>translucency effect with chunky pixels; then again, if i needed to do
>simple shading or heavy-duty scaling, i'd use chunky, given the option...

>The REAL question, given that both the high-end and the low-end future
>chipsets will have 24-bit true color and chunky pixels, is: is this instead
>of bitplanes, and if it's not, can you access the same image data in
>bitplane and chunky mode without extra thinking? (well, maybe whacking a
>bit to switch somewhere...)
>...after all, no matter how fast your chunky writepixel routine is, it's
>going to not work too well if you try and write a chunky pixel to a
>bitplane display...

Well cbm's Lew said it will have chunky mode without losing its bitplane
nature.  take that as you might interpret it.  But at 8x and up of 
the aga bandwidth, your writepixelarray8() should be mighty speedy.
Then if they have it hardware fixed for that () it should be nice,
but even without chunky in the deep hardware it shouldn't be bad.

I would like to know where we stand as the a4000 doing the writepixel
compared to a graphics chip that is primarily chunky?

Martin

-- 
Bill SATAN LIVES Gates is the biggest enemy to personal computers ever.
Newsgroups: comp.sys.amiga.programmer
From: jmrg9881@uxa.cso.uiuc.edu (Jon Reid)
Subject: Anybody have SAS/C <--> QED macros?
Organization: University of Illinois at Urbana
Date: Wed, 23 Dec 1992 15:33:23 GMT

Hi, does anyone out there have SAS/C version 6 set up to "talk" with QED?
Please give me any info about ARexx scripts / ENV configuration files.

-- 
Jon Reid    j-reid@uiuc.edu    GEnie: THE.REIDS
"He is no fool who gives what he cannot keep to gain what he cannot lose."
Newsgroups: comp.sys.amiga.programmer
From: bwill@athena.mit.edu (Brian F Williams)
Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
Organization: Massachusetts Institute of Technology
Date: Sun, 3 Jan 1993 15:44:50 GMT


	Just curious, but if you were to do a bitmap scaling, wouldn't
the planar and chunky implementations run at the same speed?  Couldn't
you do a 'chunky' scale on each bitplane, which in an 8-bit display
would be 1/8 the size of the full display buffer for a real chunky
display.  Yes, you'd do this 8 times, but each time with 1/8th the
data.  Or is it impossible to manipulate a planar display like this?
	You'd probably have to take special care so that pixels
in each plane stay aligned (if the scaling isn't by an integer), but I
don't think it would be that difficult.

--Brian

p.s. I prefer chunky implementations myself, but after using a Mac, which
can have anywhere from 1 to 24 bit color, I've realized that no routine
can be really fast on the average, you have to optimize your code for your
specific needs.
--
internet: bwill@athena.mit.edu
uucp    : mit-eddie!mit-athena!bwill
bitnet  : bwill@athena.mit.edu
From: jbickers@templar.actrix.gen.nz (John Bickers)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
Date: 1 Jan 93 17:07:11 PST
Organization: TAP

Quoted from <paulk.30qj@terapin.com> by paulk@terapin.com (Paul Kienitz):

> One can only get the full advantage of chunky display if you either
> access your (for example) 32 bit memory with 8 bit reads and writes,

    Cases where you handle 4 chunky pixels at a time by reading and
    writing 32-bits are still easier and quicker to code for than
    handling bitplanes a word or long at a time.

> So: chunky is way better than planar with no disadvantages, if you are
> building a display for an 8088 system, or if you are an ant or red-green
> colorblind or otherwise have a power-of-two number of primary colors
> in your eyeball.

    Perhaps you could divert your energies to showing how planar
    displays compete with the specific examples that people have
    mentioned already?

    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.
--
*** John Bickers, TAP.                   jbickers@templar.actrix.gen.nz ***
***    "Radioactivity - It's in the air, for you and me" - Kraftwerk    ***
Newsgroups: comp.sys.amiga.programmer
From: robart@agora.rain.com (Joe Bob)
Subject: Re: Sigh.. OKAY.  ReadArgs() is buggy?
Keywords: user error, RTFM 
Organization: a gora
Distribution: world 
Date: Wed, 23 Dec 1992 23:26:07 GMT


In article <BzHto9.9pG@usenet.ucs.indiana.edu> shulick@navajo.ucs.indiana.edu writes:
>
  [ profanity deleted ]

>arr[3] == 32791839!!  What the HELL?  I checked someone else's source
>code, and indeed, if it's -1, the switch (/S) was picked, and if not, 0.
>What the hell is a 32791839 doing in arr[3]?  Arr[3] corresponds to
>"V=Verbose/S".  Well, there's not much I can say about this.  I have no


  Sounds like you forgot to clear the array before passing it to ReadArgs

Newsgroups: comp.sys.amiga.programmer
From: rbatra@uceng.uc.edu (Rajesh Batra)
Subject: Help reading particular Pixels
Organization: University of Cincinnati
Distribution: na
Date: Sat, 26 Dec 1992 15:54:39 GMT


Hi,

	I'm attempting to copy only certain pixels from my bitmap. Once
	copied, I stamp them down one pixel to the left.  I need this to
	be done fast, so readpixel() / writepixel() wasn't doing the trick. 

	I am trying to use 

	BltMaskBitMapRastPort(...,minterm,bltMask), 

	where minterm is 0xc0 (exact copy) and my bltMask contains only 1's
	where I want to read the information.  Basically, I went into DPaint,
	created a 2 bitplane brush containing my points placed the data 
	into an array by using one of the many iff to C source programs.

	Is the logistics correct? I'm not getting what I anticipated.
	Is there a faster way to copy only certain pixels (272 of them)?


					Thank you for your time,

					Rajesh Batra
					Dept. of Aerospace Engineering
					University of Cincinnati
					rbatra@uceng.uc.edu
From: Paul_Trauth@agwbbs.new-orleans.LA.US (Paul Trauth)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: New hardware reference guide?
Distribution: world
Date: 27 Dec 92 20:33:20 CST
Organization: The Amiga GateWay BBS * New Orleans, La.

In a message dated Sun 27 Dec 92 10:47, Mlelstv@specklec.mpifr-Bonn.mpg.de 
wrote:

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

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

One question, has anyone TRIED doing fast, full-speed games yet? The only
thing i've heard of as a real AA game is Uchess, which may look nice (i
wouldn't know; there's no 4000s in this city yet as far as i know), but
doesn't exactly need blazing screen updates.
I mean, has anyone tried, say, something Sonic-y with nice deep
dualplayfield screens and big colorful sprites blasting around? Or a fast
scrolly shooter?

(I'm doing my best to NOT judge AA until i've seen it in action, preferably
actually tried to bang it around a bit and put it through its paces...)

-- Via DLG Pro v0.995

- be zorch, daddi-o --------------- paul (raccoon) trauth ----------------
--------------------------------------------------------------------------
Internet -> paul_trauth@agwbbs.new-orleans.LA.US        \\\///\\\///\\\
Usenet   -> rex!agwbbs!paul_trauth                      \\\///\\\///\\\
--------------------------------------------------------------------------
  "eagles may fly, but a weasel will never get sucked into a jet engine"
From: heinz@edohwg.adsp.sub.org (Heinz Wrobel)
Newsgroups: comp.sys.amiga.programmer
Subject: Re:  task communication and forbid()
Date: 28 Dec 92 22:54:14 GMT
Organization: Edotronik GmbH

In article <1992Dec23.134958.23831@cis.ohio-state.edu> juncewic@turtle.cis.ohio-state.edu (thomas michael juncewicz) writes:
>I thought the use of forbid() in effect 'turned off' multitasking.  Wouldn't
>it prevent a subtask from being executed, and therefore waiting for a signal
    ^^^^^^^						 ^^^^^^^

Prevent yes, but only until you wait on some event.
Wait() temporarily breaks a Forbid() or a Disable(). Read the Autodocs.

>Tom

--
Heinz Wrobel, Edotronik GmbH (ECG018)
FAX +49 89 850 51 25 / TEL +49 89 850 25 20 (HOME!&VOICE, sometimes...)
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Getting a valid FileSysStartupMsg pointers.
Date: 28 Dec 92 19:40:46 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

chris@alchemy.tn.cornell.edu writes:
>I -think- that a valid FSSM and a valid DosEnvec vector (obtained from
>the FSSM) are always in RAM and thus only check those two entries with
>TypeOfMem.  So far haven't run into any problems using this method.

	I think DF0-DF3 may well be in ROM (and TypeOfMem has no MEMF_ROM).

>> This is rather dangerous. No enforcer hits? Did you have devices
>> with all (five?) possible dn_Startups (NULL, four letter ASCII, char *,
>> int, valid fssm are the possibilities I think to remember).

>Four letter ASCII????  Ack!  Randell didn't mention this as a valid
>possibility in his original reply.  Can anyone give me some examples of
>devices which use this?

	4-letter ascii is NOT valid.  char * is not either - it's a BSTR
(i.e. BPTR to <length><chars>).

-- 
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: rock@lakes.trenton.sc.us (Rockerboy)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Going to the metal
Date: Sat, 02 Jan 93 03:32:26 EST
Reply-To: rock@lakes.trenton.sc.us (Rockerboy)
Organization: Lakes Public Access

cmcmanis@pepper.Eng.Sun.COM (Chuck McManis) writes:

> The problem, presented in these terms, is much more simply stated:
>   "The O/S model embodied in the Amiga is too complex and thus
>    unsuitable for the development of short lifetime, real time
>    applications."

I am in complete agreement on this point.  I have, in fact, mentioned it 
several times.  (That is, that from a game perspective, coimptability is 
not so terribly important...)

> One solution to this problem might be to provide an Operating system
> model that is tuned to game writers. Clearly such an O/S would have
> the appearance of writing directly to the hardware, however that
> hardware could be suitably masked behind the OS. A really good example
> of how one might accomplish this is the "virtual" 8086 mode of the
> '386 and '486. Here a hardware page fault mechanism is used to "catch"
> writes to the things that are hardware registers on the original
> PC, and do something "useful" with them based on the actual hardware
> of the system. Certainly something like that could be done on any
> Amiga with a MMU, but it could also be done using the existing messaging
> system. Imagine if you will a "spec" that says that address X contains
> the X position of the mouse, Y contains the Y position, and Z contains
> the state of the buttons. Further, J contains the bits associated with
> joysticks 1 and 2 in the upper and lower 4 bits and at address I
> is the bits for the display plane 0, I+n plane 1, etc. Now using this
> virtual machine is just as easy as using the actual hardware, except
> that now, the changes in the O/S are "invisible" to games that use
> them.

I think this is a great idea, and an acceptable one at that.  Perhaps a 
library of sorts, a hardware.library?  In fact, I suspect it would prove 
itself nicely. Programmers might even release 'custom' versions, etc., as 
we have seen with other libraries.  Then the only issue one would see 
would be whther or not people were using the 'official' library.  It 
would be patently obvious why programs crashed if the user were running 
the 'elite7hardware.library'.  ;)

And with any luck, the library would not be written in C...
Newsgroups: comp.sys.amiga.programmer
From: danb@shell.portal.com (Dan E Babcock)
Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
Organization: Portal Communications Company -- 408/973-9111 (voice) 408/973-8091 (data)
Date: Thu, 31 Dec 1992 03:43:17 GMT

In article <1992Dec31.011428.2926@mpifr-bonn.mpg.de> mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst) writes:
>In <doiron.0ka3@starpt.UUCP> doiron@starpt.UUCP (Glenn Doiron) writes:
>
>Thus bitplane devices are usually same speed as chunky pixel devices. But
>you can scale bitplane devices easily with the obvious performance advantages.
>You can never scale chunky pixel devices.


Well, that's misleading. If you are talking about a blitter-per-plane type of
architecture, the only one created (a few years ago from National) was a dismal
flop. Too expensive with minimal advantages.

>>You are doing the same transformations 8 times, once for each bitplane.
>>This is not 8x the number of transformations?  You deny facts?
>
>Again, with the example of doubling a bitmap you handle multiple pixels
>at a time which exactly compensates for the number of bitplanes.

No, it can rarely exactly compensate. The bitplane version of the algorithm
will require the use of more temporary data, slowing it down. The best
case is almost-as-fast. 

>Special-case optimizations. Right. But the "special cases" cover most graphics
>operations.

Except silly little things like drawing lines. Who'd ever want to draw a line? :-)

>>See above.  You still have to clear the other bitplanes.  And some chunky
>>hardware supports color expansion, too, where you take a single-bit image
>>and can expand all 0's to one color and 1's to another.  Of course, a
>>similar thing could be done for planar, but you still have the
>>masking/shifting/bandwidth on unaffected pixels problems.  (Say it 3 times
>>real fast.)
>
>The special hardware cannot magically expand the pixels since the bitmap
>in the frame buffer (VRAM) needs all pixels to be defined. In chunky you
>cannot write single bits into a pixel and have any speed advantage.

No, the VRAMs contain a color register. The "1" expands to whatever color was
previously loaded. Again, this allows text writing and polygon filling to be
done 4 times faster than usual.

Dan


Newsgroups: comp.sys.amiga.programmer
From: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: wierd sas/c bug
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Tue, 22 Dec 1992 19:08:10 GMT

In <Bznxuv.InB@unx.sas.com> walker@twix.unx.sas.com (Doug Walker) writes:
>|> 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.

>What the heck does it mean?  This doesn't mean anything in K&R dialects
>either, as far as I know.

In K&R the "test" (or anything behind an #undef or #endif or #else)
is silently ignored.

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: jbickers@templar.actrix.gen.nz (John Bickers)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Console RAW mode.
Date: 1 Jan 93 17:09:01 PST
Organization: TAP

Quoted from <lk58p9INN3kd@exodus.Eng.Sun.COM> by cmcmanis@pepper.Eng.Sun.COM (Chuck McManis):
> Some very old code that did this at one time for SAS/C programs.

    I still email this out to people sometimes. Also, for KS2.0
    programs, the OS now has a SetMode() function which can be used
    instead.

> --Chuck McManis			    Mr. NIS+			    Sunsoft
--
*** John Bickers, TAP.                   jbickers@templar.actrix.gen.nz ***
***    "Radioactivity - It's in the air, for you and me" - Kraftwerk    ***