HDTenEightyP/NetNews huggingface dataset:
From: cs_e445@ceres (Vlod Kalicun)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: A replacement for Newshell
Date: 23 Dec 1992 15:36:40 GMT
Organization: Kingston University
NNTP-Posting-Host: ceres.kingston.ac.uk
X-Newsreader: Tin 1.1 PL4

jbickers@templar.actrix.gen.nz (John Bickers) writes:
: Quoted from <fjeske.0k99@amiganet.chi.il.us> by fjeske@amiganet.chi.il.us (Felix Jeske):
: > I was just wondering if there are any good replacements for Newshell out there,
: > either commercial or PD.  I use UNIX's csh at work and miss some of its
: 
:     WShell. Commercial, but has all the features you mentioned and
:     then some.
: 
: > Felix
: --
: *** John Bickers, TAP.                   jbickers@templar.actrix.gen.nz ***
: ***    "Radioactivity - It's in the air, for you and me" - Kraftwerk    ***

Try CShell 5.19. Its most excellent. Shareware/PD and available from your
favourite ftp site.

Regards..

Vlod
-Amiga Advocate.
----------------------------------------------
Amiga - Anything else isn't worth considering
----------------------------------------------
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: Fri, 1 Jan 1993 07:34:02 GMT

In article <paulk.3182@terapin.com> paulk@terapin.com (Paul Kienitz) writes:
>>>> 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.
> 
>> No, it is specific to chunky. There's -no way-to write several
>> bitplanes at the same time except by using seperate memory banks
>> for each bitplane.
> 
>It is NOT specific to chunky, as best I can tell from your
>description... it's simply a hardware feature that allows a normally
>chunky display to temporarily act like a bitplane display using a
>small number of planes.  The planar version doesn't have to write the
>same value to several planes, it simply has to turn the other planes
>off.

Well, VRAMs do have a plane-mask feature (to affect only selected bits within
a pixel), but that is independent on the block-write described above.
With a bitplane display you can sometimes do the trick of writing to only
one plane, but that has the severe disadvantage of requiring the other planes
to be clear or set to a known value (why not just use fewer bits per pixel?)
and you can't select an arbitrary color (imagine trying this trick with
24-bit true color). In the block write mode all the data for every pixel is
physically written into memory, no tricks.   

Dan
From: rock@lakes.trenton.sc.us (Rockerboy)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware Manual)
Date: Tue, 22 Dec 92 03:38:02 EST
Reply-To: rock@lakes.trenton.sc.us (Rockerboy)
Organization: Lakes Public Access

Jesse_Michael@matrix.rain.com (Jesse Michael) writes:

> I think they should release hardware references in the future, *but* they
> must provide a good example of how to *really* use the hardware.  Not like
> the examples in the old hardware reference manuals.  (e.g. absolute
> addressing)

In addition, C= might add a few things to the OS to allow reliable 
determination of current hardware, etc.  This, of course, would require a 
little cooperation from the producers of third party hardware, but it 
would not seem much more involved than the IFF registrations.  Code 
taking control of the machine should, as a courtesy, pop up a warning 
requester, etc.  And and library call which would preserve the machine 
status/restore machine status would make things much more flexable.  
Memory could be allocated properly, the shutdown library call made, the 
hardware could could, if well behaved, play with whatever it liked, then 
call the restore os function and restore the machine...

Just some thoughts.
From: qbarnes@urbana.mcd.mot.com (Quentin Barnes)
Newsgroups: comp.sys.amiga.programmer
Subject: AmigaDOS library functions and ANSI-C programming
Date: 29 Dec 92 22:11:44 GMT
Organization: Motorola Computer Group, Urbana Design Center

I am learning to write AmigaDOS-specific programs on my Amiga using
SAS/C 6.1.

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".  For example,
the ANSI-C code:
        const char *s = "mylib";
        OpenLibrary(s,0L);

will generate a warning from SAS/C since the prototype in the
header file (as well as in the RKMs) says that the first argument
to the OpenLibrary() call is not qualifed as "const".  [I didn't
actually compile the example; it's for illustrative purposes only.]

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++.

Has the problem been covered before?  Is there plans in the
works to support ANSI-C/C++ clean AmigaDOS library calls?


-- 
Quentin Barnes
qbarnes@urbana.mcd.mot.com | ..!uiucuxc!udc!qbarnes
Newsgroups: comp.sys.amiga.programmer
From: mlelstv@speckled.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Thu, 31 Dec 1992 17:41:37 GMT

In <C03uC5.15o@unix.portal.com> danb@shell.portal.com (Dan E Babcock) writes:
>In article <1992Dec31.011428.2926@mpifr-bonn.mpg.de> mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst) 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.

I am talking about a single blitter architecture. The simple point that
you need less memory for less bitplanes makes an operation faster.

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

Why would it need more data ?

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

And who fill an area by writing single pixels ?

Fortunately, line drawing usually has to handle less data (you won't try to
fill the screen with vertical lines..).

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

So you write a bitplane to VRAMs and get the whole pixel depth ? Would
be identical to write to several bitplanes at the same time. I can't seen
anything chunky or bitplane specific here. Just a method to increase
bus bandwidth.

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:17752 comp.sys.amiga.hardware:22007
From: Tom_Lanhaus@fcircus.sat.tx.us (Tom Lanhaus)
Subject: 2.0 pal help
Newsgroups: comp.sys.amiga.programmer
X-NewsSoftware: BBX-UMB 0.27a beta (Nov 30 1992)
Date: 31 Dec 92 12:15:35 CST
Organization: The Flying Circus Amiga BBX, San Antonio, Texas


To any programmers out there
I have an Amiga2000 and running zkick 175.20 (2.0 emulation)
I also have a great file utility program called filemaster.
my problem is that filemaster is a PAL program and I need to be
in PAL mode with 1 meg chip ram and preferably fast memory enabled.

I also have palbooter disk from danse macambre which can put my computer
into true pal mode but part of his routines the computer must re-boot. 
Everytime it doest that it kills my 2.0 emulation and throws me back
into wb 1.3??.. help!!>>>   Tom...


Dream BIG!-- 
Tom_Lanhaus@fcircus.sat.tx.us
From: Paul_Trauth@agwbbs.new-orleans.LA.US (Paul Trauth)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Chunky Pixel Mode for Low End Chip Set?
Distribution: world
Date: 28 Dec 92 20:41:37 CST
Organization: The Amiga GateWay BBS * New Orleans, La.

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

-- 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"
Newsgroups: comp.sys.amiga.programmer
From: dwdyer@eskimo.com (Wayne Dyer)
Subject: GadToolsBox & listview...
Organization: -> ESKIMO NORTH (206) For-Ever <-
Date: Tue, 29 Dec 1992 03:35:48 GMT

Well, I create a LISTVIEW gadget with GadToolsBox 1.4a, in a window and
I get (if I want it or not) IDCMP flags of MOUSEBUTTONS, GADGETDOWN,
INTUITICKS, and MOUSEMOVE in addition to the ones I want of CLOSEWINDOW,
GADGETUP.  When I create source from GadToolsBox 1.4a for this window,
I get LISTVIEWIDCMP replacing the (above) flags.

Why?

Why does a LISTVIEW gadget require all this (crap) ?  Or is this
something I can ignore?   The INTUITICKS is particularly annoying as it
means my task won't -really- be sleeping for input, it will be awakened
at each INTUITICKS interval!  (At least with WaitPort())

-- 
Wayne Dyer, aka   || "I mistrust all systematizers and I avoid them.
dwdyer@eskimo.com ||  The will to a system is a lack of integrity."  F.W.N.
From: stern+@pitt.edu (Eric G Stern)
Newsgroups: comp.sys.amiga.programmer
Subject: How do I start Enforcer
Date: 22 Dec 92 17:46:47 GMT
Organization: University of Pittsburgh
Originator: stern@unixd3.cis.pitt.edu



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
From: salnick@dejavu.spk.wa.us (There is no substitute for displacement...)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Bug in cback?  (SAS C 6.1)
Date: 3 Jan 93 14:53:51 GMT
Organization: Not Organized

In article <72801@cup.portal.com> Elrador@cup.portal.com (Charles E Massey) writes:

I assume that you used the 1.3 libraries when you compiled for 1.3... 
right?

bob
_______________________

>Hello,
>
>  I have a strange problem:
>
>I wrote a new program and decided I wanted it to run as a background
>process, so I compiled it under SAS C 6.1 as
>>sc myprog startup=cback nostandardio opt link
>
>It works just fine under AmigaDOS 2.04, but it crashes all the time
>under 1.3 with a guru number of 00000004 (illegal instruction).  To see
>if perhaps this code was only supposed to work under 2.0, I
>compiled it regularly with a standard startup and it WORKED JUST FINE
>under 1.3.
>
>So I've concluded that the problem must be the cback startup code that
>crashes the program under ados 1.3.
>
>Has anyone else ever had these problems?  If so and you know what the
>problem is, can you share it with me.
>
>Thanks,
>charles  (elrador@cup.portal.com)

--
RW Salnick, Spokane,WA  |  Home: salnick@dejavu.spk.wa.us
  Amiga 1000, WB 1.3    |  Work: mfgsys!salnick@kaiser.spk.wa.us
      WA9BVE            |
Newsgroups: comp.sys.amiga.programmer
From: qbarnes@urbana.mcd.mot.com (Quentin Barnes)
Subject: RKM description of WaitPort()
Organization: Motorola Computer Group, Urbana Design Center
Date: Fri, 1 Jan 1993 22:10:13 GMT

I was reading the description of the WaitPort() call in the RKM:Libraries
and was confused by the description.  On page 504, it says:

	...  It is possible to receive a signal for a port without
	a message being present yet.  The code processing the 
	messages should be able to handle this. ...

It seems to me to OS is waking up the task before it has attached the
message to the specified port and it would be up the the application
to spin on the GetMsg() call until the message generating the signal
showed up.  This seems terribly wrong and the example code does not
do this.  What am I missing?  What does the documentation actually
saying?
-- 
Quentin Barnes
qbarnes@urbana.mcd.mot.com | ..!uiucuxc!udc!qbarnes
Newsgroups: comp.sys.amiga.programmer
From: walker@twix.unx.sas.com (Doug Walker)
Subject: Re: Advice to SAS/C 5.10b users
Originator: walker@twix.unx.sas.com
Date: Thu, 24 Dec 1992 14:02:37 GMT
Organization: SAS Institute Inc.


In article <1992Dec24.000931.22609@oracle.us.oracle.com>, dnavas@oracle.uucp (David Navas) writes:
|> Yes, I would say there were quite a few problems.  But I -don't- get enforcer
|> hits from the compiler/optimizer.  The darned thing -still- biffs the
|> FindTask(NULL)->ln_Name field, but it doesn't get enforcer hits.  And that's
|> a big plus for me....

What the heck does that mean?  Is that another "bug report"?

BUG NUMBER: nnnn
DATE: 23DEC92
REPORTER: Navas, David

"The Darned Thing Still Biffs The FindTask(NULL)->ln_Name Field."

We'll get right on it.  It's obviously a bug in the biffing 
algorithm, or possibly the peephole optibiffer.

|> >it's Your own fault. I can only recommend upgrading to 6.1 to every version 5
|> 
|> I would too.  Just don't use utillib, M68881, or the optimizer for the next
|> few months.  That's okay, the base code creation is quite adequate.

Hundreds if not thousands of users are using the optimizer with no
complaints.  If I were any good at flaming, I'd be doing it right
now, but I'll settle for this:  If you can't come up with specific
examples right now, stop telling people not to use a major part of
our product.

I don't mind if people report bugs on the net to keep others from
running into them, but you are spreading gossip and malicious rumors.
If there is a bug you are running into, report it and we will fix it.
By all means, narrow it down and report it to the net, but don't
blast the whole thing because of one small part.  What if everyone
dropped AmigaDOS 3.0 when the first bug was found in it?

Now for a constructive suggestion: Try your case with OPTIMIZE but
also with NOOPTPEEP.  This will run the global optimizer but not
the peephole optimizer.  We have had virtually NO reported bugs 
in the global optimizer, which is portable and runs on many other
systems, but the peephole optimizer is new for 6.0 and has had
its share.  Odds are good that NOOPTPEEP will fix the problem.

|> Very competitive with SAS/C 5.x, although I have yet to figure out how to
|> make VERY SMALL (yet WB supported) programs.  These seem about 200-400
|> bytes bigger than their 5.x equivalents.

Generate a linker map and take a look at what is getting linked in.
Compare it with the 5.10 linker map.  Use the MAPHUNK and MAPXREF
options - MAPHUNK tells you what gets linked in and how big it is,
MAPXREF lets you figure out who is pulling it in.

|> David C. Navas						dnavas@oracle.com

-- 
  *****
=*|_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: jbickers@templar.actrix.gen.nz (John Bickers)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Chunky Pixel Mode for Low End Chip Set?
Date: 27 Dec 92 13:04:48 PST
Organization: TAP

Quoted from <1992Dec26.170503.14668@mpifr-bonn.mpg.de> by mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst):
> In <72410@cup.portal.com> Lee_Robert_Willis@cup.portal.com writes:

> >I don't know about him, but I'd like chunky pixel mode so I can
> >do image processing (part of my job) on my Amiga.  Image processing

> You can do the same with any graphics hardware. AmigaOS already supports
> rendering 'big arrays of numbers' with the WritePixelArray8 function.

    Having chunky pixels to start with is quicker than having to
    convert to planar when you update your display, and if you're
    only using 8-bit data then chunky pixels also let you be more
    "interactive", where screen updates are fast enough that you can
    show the progress of your processing pixel by pixel.

> Michael van Elst
--
*** 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: Duane_Eddingfield@mindlink.bc.ca (Duane Eddingfield)
Subject: Re: SASC6.1: Unfreed memory with cpr.
Organization: MIND LINK! - British Columbia, Canada
Date: Tue, 29 Dec 1992 06:27:49 GMT

> Trevor Allan Smigiel writes:
>
> Msg-ID: <BzpnHL.H1o@ccu.umanitoba.ca>
> Posted: Wed, 23 Dec 1992 11:48:5
>
> Org.  : University of Manitoba, Winnipeg, Canada
>
>      Is there some memory problems with cpr?  Everytime I run it,
> Cpr seem to not Free 136 bytes, and sometimes more.

Are you running from CLI or WB?
If CLI, are you using WShell 2.0 or do you have CB-Handler installed?
Just a guess but, if the latter is the matter, it's the buffer stealing bytes
from you and not CPR. Just a guess... it happened to a friend of mine and
confused him for days.

Newsgroups: comp.sys.amiga.programmer
From: schuncke@cwis.unomaha.edu (John Schuncke)
Subject: AppIcons:  HOW? WHICH APPS?
Organization: University of Nebraska at Omaha
Date: Mon, 28 Dec 1992 05:25:36 GMT


I've been following threads about AppIcons and AppWindows for a little while
now.  I think I understand the underlying principle--drag an icon into the App
Icon or AppWindow and the application associated with the App(Icon|Window)
fires up and operates on the dragged-in icon.

IconEdit seems to function as an AppWindow... and YAK 1.2c creates an AppIcon
for its configuration (as if the Commodities Exchange and fifty-grillion hot
keys to trigger its window weren't enough)...

But the App(Icon|Window) capability doesn't seem advertised in the WB 2.04
docs I have...

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

And, if this is a FAQ, I apologize.  I can't seem to find the FAQ file for
this newsgroup.

				>JS<
--
+---------------------------------------------------------------------------+
|    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-------------------+
From: rzsaj@sbusol.rz.uni-sb.de (Andreas Jung)
Newsgroups: comp.sys.amiga.programmer
Subject: How to use CreateProc() under Kickstart 1.3 ?
Date: 28 Dec 1992 10:11:21 GMT
Organization: Universitaet des Saarlandes,Rechenzentrum
NNTP-Posting-Host: sbusol.rz.uni-sb.de

I want to start an procedure as a process (not a task):

main()
{

	process=CreateProc(....,MyProcedure);

}


MyProcedure(void)
{

}

The program worked with CreateTask() but not with CreateProc(). Where is the problem ?



--------------------------------------------------------------------------
-                                                                        -
-       ///    Andreas Jung         Internet: ajung@rz.uni-sb.de         -
-      ///     Klosterstrasse 21              rzsaj@sbusol.rz.uni-sb.de  - 
-  \\\///      D-6602 Dudweiler     -----------------------------------  - 
-   \XX/       Germany                                                   -
-                                                                        -
--------------------------------------------------------------------------