HDTenEightyP/NetNews huggingface dataset:
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: Tue, 29 Dec 1992 23:06:11 GMT

In article <1992Dec29.114206.2227@mpifr-bonn.mpg.de> mlelstv@speckled.mpifr-bonn.mpg.de (Michael van Elst) writes:
>In <C00nKw.Lx7@unix.portal.com> danb@shell.portal.com (Dan E Babcock) writes:
>>mask, dest, and dest) per word transferred. On a TI graphics chip it requires
>>only 2 accesses, source and dest, because it can avoid disturbing the destination
>>byte if the source byte is 0 (transparent). It's inherently twice as fast.
>
>>Dan
>
>You meant, the TI chip performs the operation twice as fast as our blitter.
>True (besides that it is even faster because of a higher clock).
>
>With planes you could read a word of each plane (at that time OR them together
>in a register) read the destination if the generated mask is nonzero and
>different from all-one (AND it at that time with the mask) and write it back
>(just if the mask was nonzero).

That's a huge amount of additional hardware (maybe that's why it isn't
implemented in the Amiga blitter, eh?). And it gets worse when you add buffers
to take advantage of page mode, which must be duplicated for each bitplane.
Ok, here's another thing to chew on: VRAMs have a pixel-expand feature which
can effectively quadruple the data rate for monochrome fills (for example
text drawing or polygon drawing). Bitplanes need not apply.

Dan
From: peter@cbmvax.commodore.com (Peter Cherna)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: GadToolsBox & listview...
Date: 29 Dec 92 19:15:46 GMT
Reply-To: peter@cbmvax.commodore.com (Peter Cherna)
Organization: Commodore-Amiga, Inc.  West Chester, PA.

In article <1992Dec29.033548.9200@eskimo.com> dwdyer@eskimo.com (Wayne Dyer) writes:
>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())

Without INTUITICKS, ListView arrows don't repeat properly, and under
V39, the drag-scroll feature won't work right either.  You must continue
to keep INTUITICKS in your IDCMPFlags.

Waking up 10 times a second and doing nothing yourself with the INTUITICKS
is a complete non-issue as far as performance is concerned.

>Wayne Dyer, aka   || "I mistrust all systematizers and I avoid them.

     Peter
--
Peter Cherna, User Interface Development Group, Commodore-Amiga, Inc.
{uunet|rutgers}!cbmvax!peter    peter@cbmvax.commodore.com
My opinions do not necessarily represent the opinions of my employer.
"Opinions enlarged to show detail"
Xref: sparky comp.sys.amiga.programmer:17771 comp.sys.amiga.hardware:22033
From: andy@cbmvax.commodore.com (Andy Finkel)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware
Date: 24 Dec 92 05:42:42 GMT
Reply-To: andy@cbmvax.commodore.com (Andy Finkel)
Organization: Flying Cat, Inc.

In article <BzqqyC.M1o@gpu.utcs.utoronto.ca> engb@gpu.utcs.utoronto.ca (Ben Eng) writes:
>So why doesn't the Amiga have an OS friendly method of copy
>protection?  Give every Amiga a unique serial number implemented
>in hardware.  Just like every workstation has a unique hostid.
>That would allow software vendors to provide software that is
>tied to that hostid or multiple hostids.

There were a couple of reasons.  When I was at C= I advocated this
strongly;  I was not able to justify the cost of the extra PAL
to top management on an A500 class machine.

The other reason is that the unique ID protection method is
much too easy to break;  very few software companies would depend
on that alone.  (They've learned from Workstation experiences).  Unless
your machines are on the ethernet, and you use net addresses (and
broadcast them :-)  ) the ID is just too easy to fool.

>Some people complain that this prevents them from chucking their
>hardware and moving their software to a newer machine, but I have
>found that the turnaround time that is necessary to obtain a brand
>new license key from every Unix software vendors that I have dealt
>with has been less than half an hour, especially if you have a FAX
>machine.

Prices in the Unix software market more easily support such an effort
on the part of a 3rd party software vendor.  That kind of software
organization doesn't come free.  Its got to be paid for somewhere.

>For legitimate owners of commercial software there should not be
>much resistance to this type of copy protection.  It sure beats
>being chained to your floppy disks or a funny decoder wheel, or
>a piece of paper with strange symbols, or a book full of phrases
>that need to be typed in at the start of every session.  Of course,

>it is not foolproof, but nothing is.  It is effective though.

It's a lot more effective where software is sold at a high price,
with fancy license and use agreements, and where the end user is
a business or corporation which generally doesn't want to be in
the business of pirating software.  There's just not as much incentive.

>The only problem is that for Commodore to do so would offend the
>target market and it would hurt their hardware sales.  Since they
>are not really in the software business their political powers
>that be can't really be expected to care about that benefit it
>could bring to their third party software vendors.
>
>Ben


Hmm.  If you believe this, you've got to believe it of every computer
company that makes personal computers;  Commodore, IBM,  Apple, Dell, 
and so on.  That's quite a conspiracy.


		andy
-- 
andy finkel		andy@cbmvax.commodore.com

"Unix is the Operating System of the future, and always will be."

Any expressed opinions are mine; but feel free to share.
I disclaim all responsibilities, all shapes, all sizes, all colors.
Newsgroups: comp.sys.amiga.programmer
From: sburton@dres.dnd.ca (Stan Burton)
Subject: BETA testers for C cross compiler to HC11
Keywords: C compiler HC11
Reply-To: sburton@dres.dnd.ca
Organization: Defence Research Establishment Suffield
Distribution: na
Date: Mon, 21 Dec 1992 22:46:41 GMT


I'm not sure this is the best place to post this so I'll make it short.

I am looking for BETA testers for a C compiler that I have been working
on.  The compiler runs on an Amiga and produces 68HC11 source
compatible with my ADev11 assembler, linker package.  Included with
the compiler are two libraries containing many of the standard C
functions and math functions.

A suitable BETA tester would have;
  1) a 68HC11 system to run and debug programs
  2) an intention to use the compiler (as opposed to letting it sit on
       the shelf)
  3) no problem accessing the support BBS to download files and post
       bug reports.  The BBS is in area code 403 (Alberta Canada).
  4) the ability to post clear problem reports (NOT "This doesn't work.")

The life of a BETA tester is low on rewards, all I can promise is quick
fixes and perhaps a sense that you are bettering the Amiga community.

If this interests you, send me mail or login to the BBS and post a
message to the SYSOP requesting access to the SC_11 area.
BBS = (403) 528-2060
-- 

Stan Burton (DND/CRAD/DRES/DTD/MSS/AGCG)                 sburton@dres.dnd.ca
(403) 544-4737     DRE Suffield, Box 4000, Medicine Hat, AB, Canada, T1A 8K6
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Chunky Pixel Mode for Low End Chip Set?
From: jbickers@templar.actrix.gen.nz (John Bickers)
Date: 27 Dec 92 20:34:26 PST
 <jbickers.0m2n@templar.actrix.gen.nz> <72410@cup.portal.com> 
 <1992Dec26.170503.14668@mpifr-bonn.mpg.de> <jbickers.0m3z@templar.actrix.gen.nz><1992Dec27.011313.18163@mpifr-bonn.mpg.de>
Organization: TAP

Quoted from <1992Dec27.011313.18163@mpifr-bonn.mpg.de> by mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst):
> In <jbickers.0m3z@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes:

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

> The major point is that with any 'image processing' the time needed for
> chunky->planar conversion is only a small fraction of the whole calculation
> time. I also think that if you want to see pixel by pixel progress then

    This isn't always the case. For example, if you want to replace
    all the blue pixels with red pixels in order to free up a color
    slot, etc.

> the overhead for calling the WritePixel routine is larger than for the
> chunky->planar conversion. And if you want to recognize pixel by pixel

    Who said anything about calling WritePixel()? Though with chunky
    pixels WritePixel() should be faster, making use of such OS
    routines more acceptable, which is a plus for RTG.

> changes then your program _must_ be so slow that the rendering speed
> doesn't matter at all.

    I do not believe this is the case. BTW, some other examples of
    where chunky pixels can be quicker is flood fills, or CPU drawing
    like lines or curves, where the main element is the equivalent of
    a WritePixel().

> Michael van Elst
--
*** John Bickers, TAP.                   jbickers@templar.actrix.gen.nz ***
***    "Radioactivity - It's in the air, for you and me" - Kraftwerk    ***
From: dmiller@beta.tricity.wsu.edu (David L. Miller)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Chunky Pixel Mode for Low End Chip Set?
Date: 1 Jan 93 00:13:26 GMT
Article-I.D.: serval.1993Jan1.001326.15057
Organization: Washington State University Tri-Cities

In article <paulk.30q6@terapin.com>, paulk@terapin.com (Paul Kienitz) writes:
|> > Well cbm's Lew said it will have chunky mode without losing its
|> > bitplane nature.  take that as you might interpret it.
|>  
|> Yikes.  That's the sort of prophetic pronouncement that could keep a
|> whole town full of medieval theologists busy for months.
|>  
|> I wonder if he means that there'll be some kind of address
|> translation and WritePixel and WritePixelLine8 in hardware, so you
|> write a byte to a fake address and the hardware splatters the bits
|> out into the appropriate physical planes?
|>  
|> Yikes.

Actually, building a system with both chunky and planar pixels is not that
hard.  I have worked out a technique by which a system could use both chunky
and bit-plane operations on the *SAME* video memory.  It is really not that
difficult!  This gives you the advantages of both, virtually without penalty.

-- 
*****************************************************************************
David L. Miller                       Internet: dmiller@beta.tricity.wsu.edu
Systems Programmer/Network Analyst      BITNET: MILLERD@WSUVM1
Washington State University Tri-Cities    UUCP: ...!yoda!dmiller
100 Sprout Road                          
Richland, WA 99352                       Phone: (509)375-9245
*****************************************************************************
Newsgroups: comp.sys.amiga.programmer
From: Charlie_Gibbs@mindlink.bc.ca (Charlie Gibbs)
Subject: Re: What is htonl() ?
Organization: MIND LINK! - British Columbia, Canada
Date: Thu, 24 Dec 1992 00:28:21 GMT

In article <TOO.92Dec23154643@cardhu.cs.hut.fi> too@cardhu.cs.hut.fi
(Tomi Ollila) writes:

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

     Errm, isn't the 680x0 normally referred to as big-endian?
Otherwise, the following joke wouldn't work:

Q: What do you call this?

        8086
        8088
        80186
        80188
        80286
        80386
        80386SX
        80386SL
        80486
        80486SX

A: Ten little-endians!

Charlie_Gibbs@mindlink.bc.ca
Intel put the "backward" into "backward compatible."

Newsgroups: comp.sys.amiga.programmer
From: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: Chunky Pixel Mode for Low End Chip Set?
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Sun, 27 Dec 1992 01:13:13 GMT

In <jbickers.0m3z@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes:
>    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.

The major point is that with any 'image processing' the time needed for
chunky->planar conversion is only a small fraction of the whole calculation
time. I also think that if you want to see pixel by pixel progress then
the overhead for calling the WritePixel routine is larger than for the
chunky->planar conversion. And if you want to recognize pixel by pixel
changes then your program _must_ be so slow that the rendering speed
doesn't matter at all.

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: kar5@po.CWRU.Edu (Kevin A. Roll)
Newsgroups: comp.sys.amiga.programmer
Subject: Libraries providing ZMODEM support?
Date: 22 Dec 1992 02:44:47 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: kar5@po.CWRU.Edu (Kevin A. Roll)
NNTP-Posting-Host: slc12.ins.cwru.edu


I am probing for the existance of some (preferably PD) libraries to provide
ZMODEM support for an Amiga with a 9600 baud modem. For example, on the
(YUCK) PC I have a package called Essential Communications Library. With
a simple function call, the package handles all the messy details of the
protocol and transfers your file. Does anything similar exist for the
Amiga?

Is it possible to use AREXX to control a terminal program to do this? Even
if it is, this is a rather crummy solution. Any thoughts?

-- 
AMIGA///|  / |/  | | | | | \ /  |\ | | |\ |\ \ / | Intel 80586    = Pentium
    /// |  S  K  I  N   N   Y   P   U  P  P   Y  | Motorola 68060 = Sextium?
\\\///  |  / |\  | | | | |  |   |  |_| |  |   |  | -------------------------
 \XX/   |  got to keep the camera alive tell the world what's going on here
From: ad99s461@sycom.mi.org (Alex Deburie)
Newsgroups: comp.sys.amiga.programmer
Subject: ReadPixelLine8() ???
Distribution: world
X-BBS-Software: EXCELSIOR! V0.975
Date: 29 Dec 92 02:56:51 EST
Organization: Michigan Information eXchange

Scanning the AutoDocs for 2.0, I saw this function. It gives some limited 
notes on using the function, so I looked in my 2.0 Libraries manual. Guess 
what, it's not there!

I ran into this same kind of thing with AllocPooled(), which I learned was 
only in AmigaDOS 3.0. I was wondering, does my 2.0 machine have this function? 
If so, where can I get an explaination of the function - (I'm a little 
confused on how the temp rastport and bitmap should be set up). Any help would 
be greatly appreciated.

Many thanks in advance,

     -- Alex Deburie
        ad99s461@sycom.mi.org
        >> THE ART MACHINE <<
From: forgeas@swinjm.adsp.sub.org (Jean-Michel Forgeas)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: InputHandler debugging (long)
Date: 31 Dec 92 10:19:41 GMT
Reply-To: forgeas@swinjm.adsp.sub.org (Jean-Michel Forgeas)
Organization: The Software Winery
X-Newsreader: Arn V1.00 alpha rel2

In article <lk1stgINNsej@exodus.Eng.Sun.COM>, Chuck McManis writes:

> The best way to debug any sort of task (input handlers included) is
> to "create" a debug port.

An easy way is to use kprintf() (link with debug.lib from Commodore)
which acts like printf().
To have the prints to appear on a console, you have to start "Sushi"
first (a very useful tool from Commodore too). If you don't start
"Sushi" the prints go to the serial port.
You can use kprintf() from a task.

Best regards,
    Jean-Michel
--
 Jean-Michel Forgeas      uunet!cbmvax!cbmehq!cbmfra!swinjm!forgeas
 16170 Bordeville                            __
 France                                      \/
Newsgroups: comp.sys.amiga.programmer
From: dnavas@oracle.uucp (David Navas)
Subject: Re: Advice to SAS/C 5.10b users
Organization: Oracle Corporation, Redwood Shores CA
Date: Thu, 24 Dec 1992 00:09:31 GMT
X-Disclaimer: This message was written by an unauthenticated user
              at Oracle Corporation.  The opinions expressed are those
              of the user and not necessarily those of Oracle.

In article <1992Dec22.194259.26097@tom.rz.uni-passau.de> agsteine@kirk.fmi.uni-passau.de (Karlheinz Agsteiner) writes:
>This is not true at all. There may be small bugs in the new user interface,
>but the compiler itself is _much_ more reliable than 5.10b. Take the optim...

Yes, please do ;)

>GO 5.1 had lots of bad bugs, which made it totally unusable for me (most of my

The only problems I had with 5.1 were with the case: statements.  Unbelievably
-bad- problems, but at least I knew where the problems were....

>this to EMITS - it's a bug in the tail recursion code)).

Yep, I found this one too, along with a CXERR (Ty was nice enough to track
this one down and report it while my harddrive was dead) and a bizarre
problem with the optimizer AND the utillib option (it doesn't compile my
function properly, but I'll be darned if I know why -- occurs within
a LockIBase too, fun eh?  NOT).

Apparently some of my modules have long-int math problems that go away
without the utillib/optimizer combination, and utillib far_data is just
completely hosed.  I haven't even -tested- this bug myself yet, though :(

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

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

>e-mail: agsteine@kirk.fmi.uni-passau.de


David C. Navas						dnavas@oracle.com
Working for, but not speaking on behalf of, Oracle Corp.
From: jamiller@kuhub.cc.ukans.edu
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Access to BIX developer sections or Developer's Mailing lis
Date: 29 Dec 92 03:13:30 CST
Organization: University of Kansas Academic Computing Services

In article <72503@cup.portal.com>, Tony-Preston@cup.portal.com (ANTHONY FRANCIS PRESTON) writes:
> I would love a developer only mailing list, but what do you do about
> proprietary data?  Encrypt it?

Encrypting it sounds fine to me.  Does anyone want to be the keeper of
the holy mailing list then?  I won't have enough block space on this
school account.  Perhaps there is someone with a little extra time and
resources available that could swing this?

We could require developer number, name of business, and address when
registering and change what ever password for the encryption was
decided on every week or something like that.
-- 
jamiller@kuhub.cc.ukans.edu
James Miller

_chicchai .sig no ho ga ichiban iin janai ka..._
             Enlightenment Happens?
From: 2575brooksr@vms.csd.mu.edu (Ryan K. Brooks)
Newsgroups: comp.sys.amiga.programmer
Subject: ilbm2raw
Date: 2 Jan 1993 23:26:41 GMT
Organization: Marquette University - Computer Services
Reply-To: 2575brooksr@vms.csd.mu.edu
NNTP-Posting-Host: vmsa.csd.mu.edu

Does anyone have a newer version of EA's ilbm2raw (supports >5 bitplanes)?

Just trying to save a little time...    Thanks!
 ----------------------------
 Ryan K. Brooks                        "You're never dead till you're        
 2575BrooksR@vms.csd.mu.edu                  out of quarters."     
 Marquette University EECE              
 NemeSys Corporation
 "Curtains for Windows"
From: Paul_Trauth@agwbbs.new-orleans.LA.US (Paul Trauth)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Big mistake - A compromise (of sorts)
Distribution: world
Date: 23 Dec 92 00:37:47 CST
Organization: The Amiga GateWay BBS * New Orleans, La.

In a message dated Sun 20 Dec 92 15:19, Cg@ami-Cg.graysage.edmonton.ab.ca (
wrote:

 CC> CBM has said they are working on two new chip sets/architectures. One
 CC> is low
 CC> end and one is high end. OK, so deliberately make the two sets as
 CC> incompatible
 CC> as possible! Then, release the full specs on the low-end
 CC> architecture, but
 CC> not for the high-end one. The hacker/demo folks can then hack away on
 CC> the
 CC> low-end systems, and their stuff will be shared with and appreciated
 CC> by all
 CC> the folks with such systems. Folks like me who want a very stable
 CC> system for
 CC> software development will likely have a high-end system anyway (I'm
 CC> typing
 CC> this on my A3000/25). If the two architectures are quite different,
 CC> there is
 CC> much less chance of any hackers developing something for the high-end
 CC> systems,
 CC> which appears to be one of the main concerns about releasing hardware
 CC> specs.
 CC> Things like big role-playing games, which can make good use of extra
 CC> memory
 CC> and hard disks, don't really need hardware access, and should run
 CC> just fine
 CC> on the high-end machines by going through the OS for everything.

 CC> Folks with lots of money will buy one of each, and will have a stable
 CC> system
 CC> on which to run BBS's, develop software, run WP's, spreadsheets, etc.
 CC> and
 CC> will have a possibly highly unstable (boot all the time) system on
 CC> which to
 CC> run arcade games, demos, mods, etc.

 CC> Aside from it not solving the problem for AGA, anyone see problems
 CC> with this?

Yes. I covet the HIGH-end system. I use my Amiga mostly for pure
entertainment purposes - demos, games, art, programming, music. And I want
the high-end system for the wonderful graphics capabilities it has!
Folks with lots of money can just bloody well keep their existing Amiga and
buy another one, then turn the old one into a UUCP node, debugging
terminal, etc, for those things that you don't want to take down for a game
that wants the whole system. Me, i can live with one machine. Probably
wouldn't be able to afford not to.

Actually, i have a feeling that a lot of the people on the "I want a CPU
and the chips, no system" side -MAY- change their mind once they see the
thing in action. I'm trying my best to not form an opinion on it until
AFTER i've actually seen one in action, to judge the speed for myself...

-- 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,comp.sys.amiga.datacomm,comp.unix.amiga