HDTenEightyP/NetNews huggingface dataset:
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 15:57:56 GMT

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
>    slot, etc.

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.

Of course, a more sophisticated algorithm might free more color slots
in one operation (where do you need exactly one color slot ?).

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

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

Yep, drawing thin lines is a plus on chunky pixel architectures. Floodfills
on the other hand can be faster with bitplanes. Not sure about curve drawing
but most curve drawing routines I know need several multiplications per point.

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: Adam.Costello <Adam.Costello@mixcom.mixcom.com>
Subject: How to write handlers?
Organization: Milwaukee Internet Xchange BBS, Milwaukee, WI U.S.A.
Date: Mon, 21 Dec 1992 07:20:21 GMT

A while back, I remember someone saying that neither the RKMs nor
the AmigaDOS Manual tell how to write handlers.  This didn't concern
me at the time, but I may be wanting to write a handler soon.  Where
do programmers get information about handlers?  I've glanced at the
source of MSH, and it's obvious that the programmer knew a lot of
details not covered in the books (I've looked in the books myself).
Thanks,
AMC
amc@cics.wustl.edu
From: andy@cbmvax.commodore.com (Andy Finkel)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Newbie font/screen question
Date: 22 Dec 92 15:01:43 GMT
Reply-To: andy@cbmvax.commodore.com (Andy Finkel)
Organization: Flying Cat, Inc.

In article <paulk.2vmr@terapin.com> paulk@terapin.com (Paul Kienitz) writes:
>> 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?

When you call OpenDiskFont, it looks at the fonts currently loaded
into ram, to decide if any of them is a close enough match to what
you are asking for to be used.  Before 2.0, OpenDiskFont was picky
about what constituted a match.  Very picky.  Unbelievably picky.
So picky, in fact, that it would almost never decide that what you had
in ram was acceptable. Under 2.0, a more rational scheme 
was adopted that will result in the ram copy of  font you've previously 
OpenDiskFonted being found in ram by a subsequent OpenDiskFont.

Occasionally you may still want to do an OpenFont first;  this allows
you to use your own judgement about what constitutes an acceptable
match.  For many purposes, however, this is now unnecessary.

			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.
From: k114636@cc.tut.fi (Kuulusa Mika)
Newsgroups: comp.sys.amiga.programmer
Subject: WindowToBack() ... BUG?!?!?!
Date: 30 Dec 1992 13:03:15 +0200
Organization: Tampere University of Technology, Computing Centre
Distribution: world
NNTP-Posting-Host: cc.tut.fi

I'll discribe a bit...

I have a program running on the background which does
WindowToBack() every 4 seconds. Then I start dragging an
icon (in Workbench) and when the program does WindowToBack(),
the icon VANISHES. Just like that. Hm.... why?

How should I make the window go background? With layers.library
I can make the windowlayer go background, but I don't know how
to refresh other layers in the screen. Can someone help me?

-MKsa



-- 
	Mika Kuulusa		                          p.931-236 304
	Yliopistonkatu 46B49,33100 TAMPERE      email k114636@cc.tut.fi
	FINLAND				"Ei saa j{{d{ tuleen makaamaan"
----------------------------------------------------------------------------
From: beust@aurora.unice.fr (Cedric Beust)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: How should I learn C?
Date: 30 Dec 1992 10:15:34 +0100
Organization: University of Nice Sophia-Antipolis, France
Distribution: world
NNTP-Posting-Host: aurora.unice.fr


In article <C01D36.BDC@unx.sas.com>, walker@twix.unx.sas.com (Doug Walker)
writes:

>|> There's nothing in C that should make you use globals where you did not use
>|> them in Pascal.  I don't understand this complaint.
>
>Probably the scoping problem - you can declare a "local" in a pascal
>procedure, and then use it in subprocedures.  The answer is to use
>statics instead of globals, or to place all such variables in a
>structure and pass the structure to all subroutines.

	On a related topic, you (Rick) might want to take a look at p2c.
	It's a Pascal to C converter that will produce C from Pascal code,
	even if it is very Pascal-dependant. This way, you will see how p2c
	handles Pascal-scoping in C. For those of you who have never seen
	this, it is a very interesting experience! Especially if you are
	interested in compilers science.

	Basically, the idea is the one described by Doug but it must
	take many other things in account.

--
Cedric BEUST, beust@sa.inria.fr, Bull Research Koala proj, KoalaBus & xforum
Pho:(33) 93.65.78.07(.66 Fax), INRIA, B.P.93 - 06902 Sophia Antipolis, FRANCE.
Newsgroups: comp.sys.amiga.programmer
From: Chris.Fortin@launchpad.unc.edu (Chris Fortin)
Subject: amidos file locking
Followup-To: comp.sys.amiga.programmer
Keywords: file locks unix ports
Organization: University of North Carolina Extended Bulletin Board Service
Date: Wed, 30 Dec 1992 21:18:17 GMT

Hello all,

	I have been trying to run a port of a pair of unix programs to
the amiga via M. Wild's gcc port. Everything compiles fine, but
the two programs communicate via one popening the other. Eventhis works
to some extent, but the pipe doesnt appear to flush until it it closed.
Similarly i have noticed the when one process has a file open, vi tst.texe
for instance, the file test.c can not be read by other procs ie tex tst
fails because tst.tex can't be opened until i quit vi. I would guess that these
two effects are related. What i would ask, is what is the easiest way to set up 
asycronous communication between the two procs? I would rather not have to
mess with their source, and would rather impilent some sort of third party
message passing system. The applications are a math package that pipes
commands to gnuplot, and obviously it wouldn't do to have all the plots
 pile up until the first app exits, and it is impractical to restart
gnuplot for each plot ( assuming i do break the pipe each time.)

I would appreciate pointers to any source that impliments this type
of message passing. As an asside, do you think AREXX would be sufficient
as a communication host?

i Thanks to everyone, and a special thanks to Markus Wild for bringing gcc to the
amiga.

			Christopher Fortin

<fortin@orca.ele.uri.edu> <fortin@tautog.npt.nuwc.navy.mil>

--
   The opinions expressed are not necessarily those of the University of
     North Carolina at Chapel Hill, the Campus Office for Information
        Technology, or the Experimental Bulletin Board Service.
           internet:  laUNChpad.unc.edu or 152.2.22.80
From: Tony-Preston@cup.portal.com (ANTHONY FRANCIS PRESTON)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Getting a valid FileSysStartupMsg pointers.
Date: Mon, 21 Dec 92 07:25:06 PST
Organization: The Portal System (TM)
Distribution: world
  <71731@cup.portal.com> <1992Dec18.232602.24034@mail.cornell.edu>
  <1h4db0INN4m0@nz12.rz.uni-karlsruhe.de>

I know I should not use this method.  The problem is there is NO 
OS friendly way to detect disk drives that works for everycase.
From: ccsw@bristol.ac.uk (Steff Watkins)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Does opening libraries require a fixed varname?
Date: 21 Dec 92 12:03:29 GMT
Organization: University of Bristol, England

In article <BzDnFz.FM5@usenet.ucs.indiana.edu> shulick@navajo.ucs.indiana.edu writes:
>
>If I wanted, for instance, to open intuition.library, does the line
>*HAVE* to be:
>
>IntuitionBase = OpenLibr.......
>
>Can it be something like "IBase = OpenLibrary(.." or "blech = Open..."
>In other words, does it matter what you call the variable?
>GadToolsBase, ExecBase, GfxBase, etc.
>

Hello.

  No, it doesn't matter what you name the variable that stores the base address
of an opened library. You just have to make sure that you always use the same
name within a code segment ie..

   If you use, IBase = OpenLibrary(, then later in the program, you must
refer to IBase to get the intuition base pointer.

OK?

PS:- Oh yeah, while you're on the subject, a quick word of advice. Try to keep
     your variable names fairly self-explanatory/simple-to-remember. It's a
     pain having to check through a huge source code, because you can't remember
     what you named a variable.


   Steff  *8)
===============================================================================
= The opinions contained in this transmission are my own. No-one else's.      =
= My very own. They belong to me. They used to belong to my girlfriend.       =
=                                                                             =
=  E-Mail:- Steff.Watkins@bristol.ac.uk  Telephone:- +44 (272) 303531         =
===============================================================================
Xref: sparky comp.sys.amiga.programmer:17819 comp.sys.amiga.hardware:22083
Organization: Queen's University at Kingston
Date: Sat, 26 Dec 1992 13:59:03 EST
From: <LEEK@QUCDN.QueensU.CA>
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware
 <38111@cbmvax.commodore.com> <BzqqyC.M1o@gpu.utcs.utoronto.ca>
 <38130@cbmvax.commodore.com> <92359.214301LEEK@QUCDN.QueensU.CA>
 <1992Dec25.154400.4669@mpifr-bonn.mpg.de>

In article <1992Dec25.154400.4669@mpifr-bonn.mpg.de>,
mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst) says:
>
>In <92359.214301LEEK@QUCDN.QueensU.CA> <LEEK@QUCDN.QueensU.CA> writes:
>>Now all the hacker has to do is to download the JEDEC fuse map to
>>'emulate' the ID that the software was written for.
>
>Provided that someone knows the ID. While it isn't impossible to

If the Amiga hardware HAD included the ID PAL, there would be OS
support routines that reads it...  (I am not talking about 3rd party
added doungles here which is another can of worms.)  It doesn't
take a lot to reconstruct the truth tables that allows one to compile
it back to JEDEC.

>crack a read-protected PAL one could use a more complex FPGA
>which can't be cracked in a reasonable time (that's what many
>dongles use).

True.  That doesn't mean priates can disassemble the program to remove
the protection.  All you need is one single priate to break the code
and the rest of the world would have it.  (As for the software side of
things, it belongs to either .programmer or .misc discussion.)

>Michael van Elst

K. C. Lee
Elec. Eng. Grad. Student
Newsgroups: comp.sys.amiga.programmer
From: cobra@coyote.datalog.com (Ken Thompson)
Subject: Re: Pascal
Organization: Datalog Consulting, Tucson, AZ
Date: Tue, 22 Dec 92 20:56:45 GMT

tlbechar@thunder.LakeheadU.Ca (Timothy Lee Bechard) writes:

> 
> 	I am looking for Pascal for the Amiga Computer... If anyone has a
> Public Domain / commercial version of it, would they please reply.
> 
> 	
> 

 
It's on a Fish Disk...sorry, I don't recall which one right off-hand, 
but it's called...er...PCQ; the version I have is V1.2; written by 
Patrick Quaid.


           _____         ______________________   _____                
       |/    |          | cobra@datalog.com   |     |        /\        
       |\ en |hompson   | cobra@jab.tus.az.us |     |ucson, /--\rizona 
     ------------------------------------------------------------------
From: ludde@cyklop.nada.kth.se (Erik Lundevall)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Aztec Tech Support on BIX -- address?
Date: 25 Dec 92 21:45:15 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

In <BzM63B.DJL@unx.sas.com> walker@twix.unx.sas.com (Doug Walker) writes:

>This might be a good time to mention that there is a Manx-SAS
>upgrade offer for version 6.0.  You send in one page from your
>Manx manual and get a 50% discount off the retail price, which
>brings your cost to $197.50 for the full SAS/C package.

>European customers, I don't know what the SAS Heidelberg office's
>policy is on competitive upgrades, but you can ask them:

An upgrade from Aztec C to SAS/C costs DM 395 if going through SAS Heidelberg.


>-- 
>  *****
>=*|_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.
-- 
-Erik Lundevall             ludde@nada.kth.se           
                            ludde@adder.adsp.sub.org    
Your fault. Core dumped.
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: ASL and GadTools under 1.3 - can this work?
Keywords: 2.0 compatible 1.3 compatibility
Date: 28 Dec 92 20:40:17 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

alex@bilver.uucp (Alex Matulich) writes:
>Specifically, my application must use many gadgets, of different kinds.
>The task of writing this program in a 1.3-compatible way is much too
>daunting for me, and I would MUCH rather use the gadtools.library.  I will
>also be using the ASL library for a file requester.
>
>Neither of these libraries are available under 1.3.  BUT... tell me if
>these workarounds will actually work.

	David Joiner (if I remember correctly) sells a 1.3-compatible gadtools.
For ASL, it's very similar to the ARP requester, so you could conditionally
use ARP (or some other 1.3 requester) under 1.3, and ASL under >=2.0.  Note
that ARP doesn't work very well under 2.0 (or at least parts of it don't).

-- 
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: simonart@vnet.ibm.com
Date: Thu, 31 Dec 92 13:28:28 FWT
Newsgroups: comp.sys.amiga.programmer
Subject: Re: AMOS - is it any good?
News-Software: UReply 3.1

In <crystal.725777678@glia> Crystal writes:
> I've been told that AMOS is some sort  of "easy to program" language
> and that demos and "real" programs can be created with it.
>
> Is it a compiled language?  Or an interactive one?
>
> If I write a program in it, does the person who tries to run it also
> need to have AMOS on their system? (Like GWBASIC...*washes mouth out
> with soap*)
>
> Thanks in advance,
> Crystal

AMOS is an fast interpreted language with a compiler version available

Interpreted mode is better for the debugging, compiled mode is better
for the run time

AMOS is send with a RAMOS program (Run-only AMOS). It allow someone to
run your program without AMOS product on-line.

I don't have AMOS PRO, things may be different in that case.

It is possible to write 'real' programs with AMOS, but I think that
AMOS owners use it more for 'personal' development than for a public
usage (this only represents MY opinion)

D. Simonart
From: fheitkamp@desire.wright.edu
Newsgroups: comp.sys.amiga.programmer
Subject: Re: SAS/C 6.1 math=68881 BUG
Date: 22 Dec 92 07:12:45 EST
Organization:  Wright State University 

In article <BzM65q.Dpy@unx.sas.com>, walker@twix.unx.sas.com (Doug Walker) writes:
> 
> In article <rlcarr.0969@animato.network23.com>, rlcarr@animato.network23.com (Rich Carreiro) writes:
> |> 
> |> Has anyone else been bitten by this weird one?  I have reported it via
> |> EMITS.  Haven't heard anything yet.
> |> 
> 
> MATH=68881 is broken under 6.1.  Please use other math options until
> a fix can be produced.

	While we're on this math option stuff:  What is the correct math
	options to use on the '040 CPU?
> 
> -- 
>   *****
> =*|_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.
Fred Heitkamp,  ** Not an organization **

Newsgroups: comp.sys.amiga.programmer
From: shulick@navajo.ucs.indiana.edu (Sam Hulick)
Subject: Re: wierd sas/c bug
Organization: Vallen Software
Date: Mon, 21 Dec 1992 20:44:04 GMT

In article <BzMGn8.370@ccu.umanitoba.ca>, umfehr06@ccu.umanitoba.ca (John Fehr) says most sayishly:
>In <BzM6F7.E6K@unx.sas.com> walker@twix.unx.sas.com (Doug Walker) writes:
>>Please post a COMPILABLE example.  I can virtually guarantee that this
>>is not a compiler bug.  A compiler that broken would not compile
>
>OK... here's a compilable example: (hopefully I'll type it in right this
>time. :)
>
>#include <stdio.h>
>#undef WHATEVER "test"
 ^^^^^^^^^^^^^^^^^^^^^^
>
>char dummy[100]="another test";
>
>main() {
>  printf("dummy='%s'\n",dummy);
>}

It's the #undef line that's causing the problem.  I don't know why, but
I get problems.  I see:

dummy='testanother test'

First, I don't think #undef takes two arguments.  Even if it doesn't,
SAS/C shouldn't spew that garbage.

-- 
    // Amiga 3000   ___ \ Sam Hulick: shulick@indiana.edu (NeXTmail OK!)
   // 68030 25 MHz /__/\ \ My opinions wear combat boots.  Or whatever.
\\// OS 2.04       \__\/ / "Walk!  Not bloody likely.  I am going in a
 \/                     / taxi."  --George Bernard Shaw
From: walker@twix.unx.sas.com (Doug Walker)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: wierd sas/c bug
Date: 21 Dec 92 14:47:30 GMT
Organization: SAS Institute Inc.
Originator: walker@twix.unx.sas.com


In article <BzIw0y.n31@ccu.umanitoba.ca>, umfehr06@ccu.umanitoba.ca (John Fehr) writes:
|> I've been trying to compile an lpmud driver with sas/c, and I've
|> come upon a wierd bug...  In my main program file, I have the following
|> code:

|> char master_file = "obj/master";
        ^ Obvious typo.  Missing a '*'

Please post a COMPILABLE example.  I can virtually guarantee that this
is not a compiler bug.  A compiler that broken would not compile
itself.  I typed in the following and it works fine (all default
options):

   #include <stdio.h>
   char *master_file = "obj/master";

   int main(void)
   {
      printf("%s\n", master_file);
      return(0);
   }

|>   Any help would be greatly appreciated.

The correct place to go for help is tech support, which is
available via net mail using the EMITS facility described
in Chapter 3 of the User's Guide volume I.

|> -  John Fehr                        -    DoD#505    -

-- 
  *****
=*|_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.
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:33:17 GMT

In <1htk0tINN53e@gap.caltech.edu> andrey@cco.caltech.edu (Andre T. Yew) writes:
>	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.

Maybe this was a bit misunderstanding. The shifting of course takes
some time, but because of pipelining in your blitter (and the fact
that it is still faster than a memory cycle) makes it a no-cost operation.

You may say that you have to fill/flush your pipeline. But that's usually
hidden by any setup operation. A FIFO for blitter commands might again
make that visible but it is still only a small fraction of the whole
blit operation.

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: mikel@bbs.draco.bison.mb.ca (Michael Linton)
Newsgroups: comp.sys.amiga.programmer
Subject: SeaScape Software
Date: Thu, 31 Dec 1992 08:01:54 GMT
Organization: The Draco Unix System [BBS]

Hi, I just heard about Canada's first offical AMOS PD distributor,  
located right here in good ol' Winnipeg, Manitoba!  If anyone is 
interested in more info, here's the phone number and address so you can 
get in contact with him:
 
SeaScape Software
P.O. Box 1514
Winnipeg, Manitoba
CANADA
R3C 2Z4
 
(204) 452-0624
 
He's selling the disks for $3.25 each (includes postage, and packaging, 
shipping etc).  That's $3.25 Canadian, or $3.25 US if you're ordering 
from there.  Anyways, if you're interested write to him, he's also 
interesting in starting up a Canadian AMOS PD section for Canadian AMOS 
Programmers to submit their material.  'nuff said.
 



---
mikel@bbs.draco.bison.mb.ca (Michael Linton)
The Draco Unix System [BBS]
From: robertm@terapin.com (Robert Michaels)
Newsgroups: comp.sys.amiga.programmer
Subject: CreateNewProc NP_Arguments
Date: 2 Jan 93 17:38:25 PST
Organization: BBS

Has anyone ever used the NP_Arguments tag using CreateNewProc or
CreateNewProcTags.  The Bantam dos manual makes reference to needing to put the
length of the argument string in one register and the pointer to it in another.
 This makes no sense as the registers would hold info based on the
CreateNewProc call and not on the specific tags you did or did not happen to
specify--these are on the stack.  At any rate, I'm programming in C and just
can not understand what they're getting at, wouldn't it be more logical to
specify the CLI arguments when creating a new process as follows:
       NP_Arguments, "these are the arguments to be passed", TAG_DONE....