HDTenEightyP/NetNews huggingface dataset:
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Chunky Pixel Mode for Low End Chip Set?
From: jbickers@templar.actrix.gen.nz (John Bickers)
Date: 28 Dec 92 10:50:02 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
 > <jbickers.0m50@templar.actrix.gen.nz><1992Dec27.155756.23491@mpifr-bonn.mpg.de>
Organization: TAP

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

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

> Then you don't do this directly in display memory. Or use some blitter
> function to generate a mask and then change the pixels through the mask.

    You're kidding, right? Sure it's _possible_ to do it with planes,
    but don't you think it is easier (and it is definitely faster) to
    do it with chunky pixels?

> >    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.
> 
> WritePixel wouldn't be much faster with chunky pixels. The large overhead
> comes from clipping and calculating bitplane/bitmap addresses.

    Well, it should be. Bypassing WritePixel() with chunky pixels will
    be quicker than bypassing WritePixel() with planes. There is only
    one address calculation, and only one write to memory.

> Yep, drawing thin lines is a plus on chunky pixel architectures. Floodfills

    Any kind of lines.

> on the other hand can be faster with bitplanes. Not sure about curve drawing

    I don't see how flood filling can be faster with planes. The
    classic method is mostly ReadPixel() and WritePixel() operations,
    which chunky pixels excel at.

> but most curve drawing routines I know need several multiplications per point.

    So? There are incremental algorithms for drawing some sorts of
    curves (like circles), and having chunky pixels isn't going to
    make the calculation of the curve faster, but it WILL speed up the
    WritePixel() part of the routine significantly.

    Anyway, I'm all for a chunky pixel chipset. Even better if it can
    be mixed with other modes on-screen. Not being a hardware person,
    it's easy for me to think that the best way to handle graphics
    boards (with RTG) would have been to have the Copper be able to
    switch to an external graphics source, so external boards could be
    "screens" in the system, scrollable and all. Being able to do this
    without an external graphics board at all would be great.

> Michael van Elst
--
*** John Bickers, TAP.                   jbickers@templar.actrix.gen.nz ***
***    "Radioactivity - It's in the air, for you and me" - Kraftwerk    ***
Xref: sparky comp.sys.amiga.programmer:17687 comp.sys.amiga.hardware:21946
From: rock@lakes.trenton.sc.us (Rockerboy)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware
Date: Mon, 21 Dec 92 05:05:37 EST
Reply-To: rock@lakes.trenton.sc.us (Rockerboy)
Organization: Lakes Public Access

andy@cbmvax.commodore.com (Andy Finkel) writes:

> Copy protection is generally added by people other than those who
> programmed the game.  Often, its added by programmers hired by
> the game publisher.  Generally, those people seem to be those
> who claim to understand the machine at its lowest level, ie democoders.
> Remember, the idea of copy protection is to allow as few people
> as possible to actually run the program :-)

Oh, foul!  Copy protection is deliberate exploitation of nonstandard 
system eccentricities to make it difficult for people to copy the 
software.  By definition, it is hardware hacking!  Ya know, this may be 
_the_ one valid reason not to release the hardware manual...  What!?  No, 
I didn't say that!  It was an evil spirit in posession of my mental 
faculties.  Fact is, dead on, copy protection makes it impossible to run 
certain games on certain systems.  But the fact that said coding was done 
by democoders doesn't place the balme entirely on _their_ shoulders.  I 
suggest that they simply did what the company asked them to do.  If 
hardware hacking _may_ cause compatability, protection schemes are almost 
guaranteed to do so...

> Without trying hard, I can come up with 10 programs that would have 
> worked fine under the OS, but got trashed by the copy protection.
> (Granted, I analyzed a number of those programs to find out
>  why they had problems under 2.0;  otherwise I might not know
>  the extent of the problem).

Well, that has always been the case with copy protection, even on 
machines where compatability was not such an issue, such as the venerable 
64.  God knows, some of the schemes, such as RapidLock, were so flakey 
that they sometimes worked, sometimes didn't, even on the same machine!  
(I remember buying three copies of Pirates before I finally got sick of 
it screwing up and just ripped the game off the disk to a normal one for 
play.  Now, that's a little rediculous if you ask me.)

> (How do I know they were democoders ?  Easy.  Democoders _always_
> sign their work :-)  )
> -- 
> andy finkel		andy@cbmvax.commodore.com

But that doesn't mean they would have made such rude code had they not 
been required to do so!  ;)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
From: jbickers@templar.actrix.gen.nz (John Bickers)
Date: 2 Jan 93 11:33:59 PST
 <1992Dec31.011428.2926@mpifr-bonn.mpg.de> <C03uC5.15o@unix.portal.com> 
 <1992Dec31.174137.10865@mpifr-bonn.mpg.de> <jbickers.0mdl@templar.actrix.gen.nz> <1993Jan1.142652.20451@mpifr-bonn.mpg.de>
Organization: TAP

Quoted from <1993Jan1.142652.20451@mpifr-bonn.mpg.de> by mlelstv@speckled.mpifr-bonn.mpg.de (Michael van Elst):
> In <jbickers.0mdl@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes:

> >    So do you concede that 8-bit chunky pixels are indeed faster than
> >    8-bit planar pixels for CPU-driven drawing operations?
> 
> *sigh*. They are slightly faster for area operations and significantly
> faster for non-horizontal line drawing. But I was not talking about

    Well, that's the key thing. As for the rest (< 8 planes), the
    differences are not so clear-cut. On the one hand you have to
    shift and mask so much for bitplanes, on the other you waste bits
    for chunky pixels, or end up stuffing several pixels into each
    byte, which approaches having planes (exactly equivalent for 1-bit
    pixels, eh?).

    You also lose all the marvellous things you can do with the
    bitplane pointers, but if such pointers aren't documented in the
    future it doesn't matter, eh? :)

> >    Can you present your algorithm for bitmap scaling that performs as
> >    well as a chunky-pixel based algorithm?
> 
> It uses a 256k table (64k longwords) or less when I have a processor that can
> do several instructions during video memory accesses. Why would that slow down 
> the algorithm ?

    This is a nice approach, though it gets more complicated when you
    want to scale by some factor other than 2 or 4. For each end of
    the horizontal lines you are scaling, you also need to mask off
    the source and destination areas, if any, that shouldn't be
    affected. You may also have to shift the results if the source and
    destination are not aligned with each other.

> >    Me. A digital dissolve is basically filling an area by writing
> >    single pixels.
> 
> Hmm. I thought it was a mapping operation.

    Well, call it what you will but it's still filling an area by
    writing single pixels.

> >    Horizontal wipes do indeed fill the screen with vertical lines.
> 
> True.. Now, who talks about special cases :) BTW, you do not want to
> make a horizontal wipe arbitrarily fast. It could become invisible :)

    Heh. I would like to be able to complete a vertical rectangle
    within one frame though. You can do it quite nicely by copying in
    8-pixel wide strips, until you get a case where you need to mask
    and shift.

> Michael van Elst
--
*** John Bickers, TAP.                   jbickers@templar.actrix.gen.nz ***
***    "Radioactivity - It's in the air, for you and me" - Kraftwerk    ***
From: paulk@terapin.com (Paul Kienitz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Newbie font/screen question
Date: 21 Dec 92 20:01:02 PST
Organization: BBS

> Indeed, the correct way is:
> 
>       if ( OpenDiskFont( ... ) )
>       {
>           if ( OpenScreen( ... ) )
>           {
>               ...
>               CloseScreen( ... );
>           }
>           CloseFont( ... );
>       }      
 
At some time in the past I found that calling OpenDiskFont() will
always load from disk even if the font is already in memory.  So I
call OpenDiskFont() only if OpenFont() fails.  Is this still
necessary with the latest versions?
From: monster@mbear.apana.org.au (Martin Ozolins)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: SAS C6.1 datecmp bug [Was: Re: Advice to SAS/C 5.10b users]
Distribution: world
X-NewsSoftware: GRn-beta 1.16g (10.12.92) by Michael B. Smith & Mike Schwartz
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Date: 25 Dec 92 10:36:07 PST
Organization: Bears Incorporated

> Right now, 6.2 is being held pending discovery of a weird memory-
> trashing bug on '040 machines that was introduced after 6.1 was
> shipped.  I apologize for the delay;  I'd love to be able to ship
> it right now, but until we locate this problem, we can't ship
> anything.
> 

Thats good, but since I do not have FTP access, I still have not gotten the
6.1 patch, I have asked b4. How do I get the 6.1 & 6.2 patches ?

-- 

Martin Ozolins :Internet monster@mbear.apana.org.au
Victoria       :FIDO 3:633/359.6 AMIGANET 41:300/359.6 TRINET 42:8699/8.6
Australia      :Amiga Programmer, UniSYS 1100/2200 Systems Programmer
From: k36889m@saha.hut.fi (Jouni Salmi)
Newsgroups: comp.sys.amiga.programmer
Subject: V39 Double-Buffering routines
Date: 1 Jan 93 13:11:20 GMT
Organization: Helsinki University of Technology, Finland

Followup-To: 
Distribution: 
Organization: Helsinki University of Technology, Finland
Keywords: 


I'm planning to use the new V39 intuition.library double-buffering 
routines when making some bob-animations on intuition screens: AllocScreenBuffer() and ChangeScreenBuffer().
 
What is the exact technique when doing such animation with these routines? Am I able to run the animations on the windows (one with a BACKDROP flag set) or should I use the screen's bitmap?
 
I also want to open some windows on the screen, but not in the same time I run the BOB-animations. Does all the old ECS-displaymodes support this double-buffering or is AGA required?
From: Tony-Preston@cup.portal.com (ANTHONY FRANCIS PRESTON)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Access to BIX developer sections or Developer's Mailing lis
Date: Mon, 21 Dec 92 10:36:32 PST
Organization: The Portal System (TM)

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.
Newsgroups: comp.sys.amiga.programmer
From: Todd_Lewis@unc.edu (Todd M. Lewis)
Subject: Re: How should I learn C?
Organization: UNC Office of Information Technology
Date: Mon, 28 Dec 1992 22:26:52 GMT

In article <78849@hydra.gatech.EDU> gt6758b@prism.gatech.EDU (Michael Maverick  
Kopack) writes:
>Could somebody please tell me how I should go about trying to learn C?

A lot of it is attitude.  Hang in there and try to enjoy it.  :-)

>...solid understanding of C.... I don't care about being able to do all
>the wiz-bang graphics and such yet, I just want to be able to write a few
>useful programs in C for my Amiga!

Good attitude.  That's half the battle.

>There are a lot of things about C that I find very frustrating after comming
>from a decent course in Pascal. For one is the way that Arrays are handled.
>I like being able to do stuff like    array [6..26] of int whereas in C you
>get forced into calling the indeces 0-19. I also HATE that there are no true 
>pass by reference parameters! 

Oops.  Attitude problem.  There are ways work with these things and keep 
a good design.  This is an attitude problem.  C will never be Pascal.
That wrench just doesn't drive screws very well.  Get over it.  (I went
through the same phase, by the way.)

>It seems that C pretty much took Pascal and threw all the rules out the  
window!

It's more that Pascal took C and threw in a bunch of rules.  Either way,
it's a different tool with lots of sharp edges.  Be careful and try to
get into a C mind-set.  If you don't you will never enjoy programming C.

>I can't imbed functions so other procedures can't see them (scoping rules),

Static functions with file scope will do it.  Well-chosen function names
eliminate the problem pretty much anyway.  Most of those local functions
you wrote in Pascal could have been global and nothing would have changed.

>I have to use global variables a lot (taught as a no-no at GT)

That's what static variables with file scope are far.  It works a little
differently, but you can get the same effect.  You just have to think a
little differently about it, that's all.  Attitude.

> and it just
>seems like C is TOO flexible! How do you guys get anything done when there are
>about 500 different ways to do it?

There are usually only a few _good_ ways, though.  That's where skill
and experience come in.  Getting to make those choices is part of what
makes C programming fun.

>Please, open my mind to C! I'd hate to have to try to do everything for my 
>Amiga in Pascal, considering how much of the Amiga software is written in 
>and documented for C......

I started my Amiga programming in Modula-2.  This was a good thing, because
I had to really understand every line of every example program I studied to
be able to translate it to M2.  I came away with a much better understanding
of the Amiga and C because of it.  I use C these days, but now I know _why_ I
use C.

>Thanks a million,
>Mike Kopack

Looking forward to some great programs from you!  Hang in there.
--
 _/_/_/  _/     Todd_Lewis@unc.edu          You can lead a horse to 
  _/    _/     utoddl@guitar.oit.unc.edu   Mohammad, but you can't make
 _/    _/_/_/                             a mountain drink a mole hill.
From: ad010@rrz.uni-koeln.de (Wilhelm Stiefelhagen)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: AmigaDos Assign command
Date: 21 Dec 92 14:21:07 GMT
Organization: Regional Computing Center, University of Cologne
NNTP-Posting-Host: rs1.rrz.uni-koeln.de

In <37922@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes:

>ianm@laghey.UUCP (Ian Moran) writes:
>>I have noticed strange behaviour with the 'assign' command under 2.04 and
>>above. If I take advantage of the multiple assign facility thus :
>>
>> assign rexx: s: dh0:turbotext/rexx
>>
>>Then Arexx macros will not be located under Turbotext which is contrary to
>>what I would expect, only s: is searched.

>	Instead of trying to Lock() or Open() "rexx:<file>", it's Lock()ing
>rexx:, CurrentDir()ing to it, then trying to Open() <file>.  Lock() will
>give you a lock on the first directory.  If searching for a specific item,
>use AddPart() to build a full path first.

>>Also, why do few (if any) file requesters follow multiple assigned
>>paths similar to the above. If I enter rexx: in the C= requester then I will
>>get only the contents of s:

>	How I would handle doing something to each entry in an assign (multi-
>assign or not): 

[stuff deleted]

I think there is a patch who gives you more comfort in using
multiple assigns (I think the name was DosPatch, mail me, if you
do not find it). When applieing this patch, a list command will
show all assigned dirs and so on. (Without this patch, everytime you
need access to all of the assigned dirs, you will have only
access to the first one :-) )

Willi
.
-- 
Wilhelm Stiefelhagen               ad010@rrz.uni-koeln.de
From: mbs@adastra.cvl.va.us (Michael B. Smith)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: RKM description of WaitPort()
Distribution: world
X-NewsSoftware: GRn-beta 1.16g (01.01.93) by Michael B. Smith & Mike Schwartz
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Date: 2 Jan 93 09:44:52 EST
Organization: Well, I haven't decided on a name yet...

In article <1993Jan1.221013.26070@urbana.mcd.mot.com> qbarnes@urbana.mcd.mot.com (Quentin Barnes) writes:
> 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

The word "yet" should be deleted. Do NOT spin on GetMsg(). Instead,
gracefully handle the situation where GetMsg() == NULL, which *is* done
by the example on page 505 under "Getting a Message".
--
  //   Michael B. Smith
\X/    mbs@adastra.cvl.va.us  -or-  uunet.uu.net!virginia.edu!adastra!mbs
From: andrey@cco.caltech.edu (Andre T. Yew)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
Date: 31 Dec 1992 01:56:45 GMT
Organization: California Institute of Technology, Pasadena
NNTP-Posting-Host: punisher.caltech.edu

mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst) writes:

>In <doiron.0ka3@starpt.UUCP> doiron@starpt.UUCP (Glenn Doiron) writes:
>>Oh, obviously.  If you can make this magical piece of hardware, I'm sure
>>Commodore has a job position open for you.  Or any other number of chip
>>designers.

>I could probably make that from discrete parts of fpgas but I have no
>experience in doing asics or even full custom designs.

	Even if you could do custom designs, you generally
cannot have free shifting.  A standard shift-register
design in CMOS usually runs off a two-phase clock, so
at best you need two clock ticks between shifts, and shifts
need 2 clocks to complete.

--Andre

-- 
             Andre Yew andrey@cco.caltech.edu (131.215.139.2)
From: ry41@rz.uni-karlsruhe.de (Bernhard Moellemann)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: LockIBase
Date: 23 Dec 1992 12:20:03 GMT
Organization: University of Karlsruhe, Germany
Distribution: comp
NNTP-Posting-Host: tp72.rz.uni-karlsruhe.de
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Keywords: 

In article <JTP.92Dec23025528@laphroaig.cs.hut.fi>, jtp@cs.hut.fi (Jukka Partanen) writes:

>	What's the correct locking protocol if one wants to find a
>	particular screen, and then do something with it? The RKM
>	states that one shouldn't call any high level calls while
>	holding the IntuitionBase lock.

The _correct_ protocol is:

  if ( scr=LockPubScreen(name) ) {
    DoStuff(scr);
    UnLockPubScreen(NULL,scr);
  }

If it is no public screen rethink your strategy. There is no safe way to
play around with a screen that is not yours. So there is _no_ "correct
locking protocol".

>	[...] Isn't there a better way to
>	make sure that a particular screen (not necessarily a public
>	screen) isn't closed while I'm referencing it?

Simply don't touch other peoples screens. Then all is easy and clean.

-- 
 Bernhard Mllemann   <spare  space>   Chairman of the Nessy-Fan-Club   //
 internet=zza@rz.uni-karlsruhe.de <space> FIDO=2:241/7506.42  IRC=ZZA  //
 nessynet=008  Lifenet=77:7700/11.42  greetings to my Marsupilami  \\ //
 2000/500 Technical Reference Manual:  "A1000, the original Amiga"  \X/
From: ry53@rz.uni-karlsruhe.de (Angela Schmidt)
Newsgroups: comp.sys.amiga.programmer
Subject: Need better TypeOfMem (Was: Re: Getting a valid FileSysStartupMsg pointers.)
Date: 21 Dec 1992 12:37:19 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 <paulk.2uhc@terapin.com>, paulk@terapin.com (Paul Kienitz) writes:
> I *do* wish C= provided a supported method of asking the system "what
> addresses are legitimate ROM addresses".  I've had uses for such a
> thing about half a dozen times.  An extra MemHeader in ExecBase would
> do the trick

Yes, I'ld need this, too. But they also should add a flag as a return
value to detect if the pointer points into the used expansion space.


     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: wayne@cs.adelaide.edu.au (Wayne McKeen)
Newsgroups: comp.sys.amiga.programmer
Subject: Wanted: info on available C++ compilers
Date: 22 Dec 1992 01:03:16 GMT
Organization: Dept. of Comp. Sci., University of Adelaide
Distribution: world
NNTP-Posting-Host: achilles.cs.adelaide.edu.au


I am looking for a decent C++ compiler for the Amiga and I have not able
to find any dealers in S.A., and very few elsewhere. What compilers are
available, at what cost, and from where can I get one? I am aware of the
existence of g++, however I would like information on the commercial C++
compilers which are available.

Thanks in anticipation.

-- 
Wayne.
(wayne@cs.adelaide.edu.au)
Xref: sparky comp.sys.amiga.programmer:17693 comp.sys.amiga.hardware:21949
From: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware
Date: 22 Dec 92 12:34:16 GMT
Organization: Max-Planck-Institut f"ur Radioastronomie

In <1992Dec21.171259.24268@cbmtor.uucp> steve@cbmtor.uucp (Steve Vetzal) writes:
>Newer graphics geometries shouldn't be all that different from those available
>today.

However, many graphic cards (especially Zorro-II ones) may not be accessible
by the CPU directly. Some people will use dedicated graphic processors
or a separate DMA-I/O channel or whatever. It is also likely that most
cards will use chunky pixels.

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