HDTenEightyP/NetNews huggingface dataset:
From: robertm@terapin.com (Robert Michaels)
Newsgroups: comp.sys.amiga.programmer
Subject: Help with changing gadtools gad info
Date: 2 Jan 93 17:35:23 PST
Organization: BBS

Does anyone know of a legal way to alter the text in a gadtools BOOLTYPE gadget
without closing the window and reopening it.  If it were a regular Intuition
gadget I would first Remove it, then change the pointer to the string in the
.IntuiText field, then re-add it and RefreshGList.  But this would probably be
illegal with a gadtools gadget and there appears to be no legal way to
accomplish this without closing and reopening the window which is really not
possible in the application I am writing.  Also if I did do the above illegal
operation, gadtools would be fouled up when closed the window an it tried to
free the IntuiText structure it had originally created.
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: ramlib & FreeMem
Date: 2 Jan 93 03:35:45 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

monster@mbear.apana.org.au (Martin Ozolins) writes:
>FreeMem points to ROM code
>Run PPMORE V2
>FreeMem gets SetFunctioned ( by ramlib )
...
>So far, it only happens when PPMORE is run.
>It only happens ONCE no matter how many times PPMORE is run.
>And yes, ramlib does the SetFunction
>I am just curious as to why this happens and why ramlib does not 
>do the SetFunction when it first starts

	When a library/device is loaded, ramlib is the process that loads it
and calls the init point.  The SetFunction is probably in a library init.

-- 
GNU Emacs is a LISP operating system disguised as a word processor.
 - Doug Mohney, in comp.arch

Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
jesup@cbmvax.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.
From: m92mmy@tdb.uu.se (Mattias Myrberg)
Newsgroups: comp.sys.amiga.programmer
Subject: Allocate timers, how ???
Date: 22 Dec 92 03:37:14 GMT
Organization: Alien Dreams Department
X-Newsreader: TIN [version 1.1 PL6]


Sorry to bother you with this, but I don't have no AutoDocs and the alikes.
I'm writing (trying to :) a music-player, and I need to allocate timer-device
or whatever it's called (access to the CIA-timers). Could someone post an
example in assembler (WITHOUT funny INCLUDE-statements, I've got no .i-files),please ?

*Many* thanks in advance.

/Mattias

_______
Mattias Myrberg

m92mmy@bellatrix.tdb.uu.se
Newsgroups: comp.sys.amiga.programmer
From: walker@twix.unx.sas.com (Doug Walker)
Subject: Re: wierd sas/c bug
Originator: walker@twix.unx.sas.com
Date: Tue, 22 Dec 1992 13:37:43 GMT
Organization: SAS Institute Inc.


In article <BzMGn8.370@ccu.umanitoba.ca>, umfehr06@ccu.umanitoba.ca (John Fehr) writes:
|> 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);
|> }

Aha!  This is very different from what you originally posted.

Here's what is happening:  whenever the tokenizer sees a quoted
string, it has to "remember" that it saw it, in case the next
non-preprocessor non-comment token is also a quoted string.
The expression parser knows when to "erase" the last quoted
string seen.  In your case, the expression parser isn't being
called because it's an error case - there isn't supposed to be
anything after the thing being #undef'd, so the error case code
just eats tokens until the newline.  Unfortunately, it doesn't
"erase" the string token, so the next quoted string gets 
concatenated to the first one.

The workaround is: don't do that!  Comment out the quoted string
on the #undef statement or something.  I've already fixed it in
the source base, but who knows when that will percolate out to
a release - I doubt if it will make 6.2 since that is already frozen.

|> I know that #undef WHATEVER "test" isn't ANSI-compliant (the HP-compiler
|> complanes about it anyway) but some programs actually have that in
|> their code.

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

|> -  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.
From: amipb@amipb.gna.org (Philippe Berard)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware Manual)
Date: 20 Dec 92 14:59:42 GMT
Organization: IWANIMA
X-NewsSoftware: GRn 1.16e (7/4/92) by Mike Schwartz & Michael B. Smith

In article <paulk.2l58@terapin.com> paulk@terapin.com (Paul Kienitz) writes:
>
> If AmigaDOS had been written for Mac or Atari hardware, the ONLY
> difference would have been somewhat slower window drawing and maybe
> no easy screen sliding.  90% or more of the OS would not have
> suffered at all.
>
> And if it had been done on them instead of on the Amiga, that's what
> I would have bought.  Because I want a REAL computer, not a Nintendo.


    It seems you've forgotten what makes AmigaDos so appealing : the custom
    chips facilitate the job of the main processor, and you would never have
    seen multiple-screens on the same monitor with a Mac or an Atari.

    If you really think what you say, just buy a cheap PC with OS/2, which
    isn't much different from AmigaDos. Of course you will need a 486 to
    have fast games, no compromise !
    
                                   -- Philippe

.----------------------------------------------------------------------------.
|  Philippe Berard  (French Amiga User)       |                              |
|  "They hold a cup of wisdom,                | UseNet : amipb@amipb.gna.org |
|   But there is nothing within" (Kate Bush). |                              |
`----------------------------------------------------------------------------'
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: Fri, 1 Jan 1993 14:26:52 GMT

In <jbickers.0mdl@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes:
>> I am talking about a single blitter architecture. The simple point that
>> you need less memory for less bitplanes makes an operation faster.

>    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
8-bit planar pixels. I have no problems with the worse efficiency when
I can use different pixel depth. Maybe I'm not concerned about doing
vector demos without hidden line removal.

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

>    Me. A digital dissolve is basically filling an area by writing
>    single pixels.

Hmm. I thought it was a mapping operation.

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

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

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: Alex_Topic@tvbbs.wimsey.bc.ca (Alex Topic)
Newsgroups: comp.sys.amiga.programmer
Subject: chunky mode questions?
Distribution: world
Date: 2 Jan 93 03:28:54 PST
Organization: Tunnel-Vision BBS!

  I would like to know will these chunky modes be available for the low-end
chipset. If they aren't, then that is stupid! I can see some uses for them
in low-end systems, which could help with some situations.
 
  Is chunky mode, similar to how the C64 has character set mode? Just
wondering... when I went to the Amiga, I though they may of had this,
but later found out the Amiga just has bitplane. To be honest that is
one feature on the C64 which really helped in some situations, since
it has 1 slow CPU. 
 
  The C64 uses some SCREEN matrix technique... and has some character set
defined somewhere. Now I really hope on the Amiga's chunky mode it can
have this screen matrix anywhere in chipram, and is somewhat similar
to the C64. I recall on the C64 I animate 1 character(8x8), and if that
character is all over the screen matrix.. all of them will animate. Now on
the Amiga you have to BLIT every single character. Talk about a HASSLE. 
 
  CHUNKY mode would be great for game coders. Though maybe have a
combination
of both. Like have DUAL-PLAYFIELD(TYPES) mode. 1 is CHUNKY, and the other
is BITPLANE. 
    
   Right now I'm just assuming what it is, but I can see great uses for
this
in games. And maybe great for MODEMING!... I guess there is the PROS and
CONS
with everything.
 
   I really hope C= makes some improve with the BLITTER and SPRITES. I
would like scalable or rotation sprite or blitter object features built
in the hardware. You know like the SNES..heh later all!
 
 -Alex


-- Via DLG Pro v0.995
From: Jean-Guy_Speton@tvbbs.wimsey.bc.ca (Jean-Guy Speton)
Newsgroups: comp.sys.amiga.programmer
Subject: IPC and shared memory
Distribution: world
Date: 30 Dec 92 16:17:20 PST
Organization: Tunnel-Vision BBS!

I am looking for information on inter-process communications (IPC) and
shared memory functions.  Do the Amiga libraries have any functions along
these lines?  The reason I'm asking is I intend on writing a multi-line
door, but have questions as to how the different processes of the door will
communicate with one another.  I have a few ideas in mind, but they all
seem as if they will become extremely slow and inefficient with more than a
few lines.

If anyone can provide any relevant information, I will be forever grateful.

J. Speton

-- Via DLG Pro v0.995

---------------------------------------------------------------------------
Jean-Guy Speton               jean-guy_speton@tvbbs.wimsey.bc.ca
Vancouver, BC,                                -OR-
Canada                              a7e192@scheme.cs.ubc.ca
Newsgroups: comp.sys.amiga.programmer
From: "david wyand" <david.wyand@canrem.com>
Subject: parnet network
Reply-To: "david wyand" <david.wyand@canrem.com>
Organization: Canada Remote Systems
Distribution: comp
Date: 26 Dec 92 21:05:17 EST

Greetings, All!

I seem to have run into a problem using ParNet: Whenever I access a
certain drive, the computer crashes with the Guru number of 80000004.
More specifically, I am using an A2500/020 as the local machine, and an
A3000T as the remote, which has a 240Meg hard drive.  When I access the
Workbench partition on the tower, no problems, I am able to get a
directory and access files.  But as soon as I try to access the Work
partition, the system crashes after the first directory call.
The Software Error window displays the task as 'Work' (Work is displayed
in the upper left of the window, but not as the window's title).  Does
this mean that ParNet is having a problem with the drive itself?  Has
anyone had problems with WB2.1, and a large hard drive (which is
relativly fast) and ParNet?  Is it possible that the data stream is
overflowing into areas that it shouldn't due to the fact that ParNet
can't keep up with the speed of the drive (I'm assuming that the network
is slower than my hard drive, of course)?

Would like to hear of _your_ successful ParNet setup, and what hardware
you are using, especially if it is simular to the above setup.
Thanx in advance...
(Oh, almost forgot...EMail is prefferable, although not required)

                                        -Dave
                                         david.wyand@canrem.com

Have a Happy New Year!! :)
--
Canada Remote Systems  - Toronto, Ontario
World's Largest PCBOARD System - 416-629-7000/629-7044
Xref: sparky comp.sys.amiga.programmer:18019 comp.sys.amiga.hardware:22270
From: marc@aargh.adsp.sub.org (Marc Heuler)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
Subject: Re:  Attn Commodore: You are making a Big Mistake (Hardware
Date: 1 Jan 93 05:57:14 GMT
Organization: ImageArts

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

When vendors can hand out new keys via the phone, the protected program has
to check whether the key and the serial number match following a certain
algorithm. And this is the problem. Nowadays crackers remove
type-in-word-xxx-of-page-yyy protections. If your scheme would be implemented,
they would remove type-in-your-personal-key protections. There's no
difference besides that C= can say "We tried it but it failed" :)

>Ben

--
  _____________ _____________________________________ ______________________
 | Marc Heuler | UUCP: marc@aargh.adsp.sub.org       | Wer hat Angst vor 'm |
 |  Wuerzburg  | ZNet: marc%aargh.incubus@aworld.zer | Schwarzen Schilling? |
 |   Germany   | Tel.: [+49]-(0)931-53295            |    - Ein Unbekannter |
  ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~
From: hebrais@mirkwood.CAM.ORG (Philippe Hebrais)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: RKM description of WaitPort()
Date: 2 Jan 93 18:21:44 GMT
Organization: Secte des adorateurs des semiconducteurs
X-Newsreader: MeNews 2.8.0

[ qbarnes@urbana.mcd.mot.com (Quentin Barnes) writes in article <1993Jan1.221013.26070@urbana.mcd.mot.com>: ]
>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. ...
>
>do this.  What am I missing?  What does the documentation actually
>saying?

It is trying to say that when a signal is received, any number of
messages may have arrived, including zero.  You should loop on
GetMsg( port) until it returns NULL.  That "yet" is a word too many.

>--
>Quentin Barnes
>qbarnes@urbana.mcd.mot.com | ..!uiucuxc!udc!qbarnes
--
--              ,
      Philippe Hebrais   hebrais@mirkwood.cam.org
   Voix: (514)731-9146   uunet!philmtl!altitude!mirkwood!hebrais
Newsgroups: comp.sys.amiga.programmer
From: cobra@coyote.datalog.com (Ken Thompson)
Subject: Programming Help Needed
Organization: Datalog Consulting, Tucson, AZ
Date: Wed, 30 Dec 92 15:16:42 GMT

  Greetings:
 
 The following message is from a friend of mine...I know *very* little
about C programming, and stretched my brain for a few milli-seconds &
couldn't figure it out, so I'll forward it here...
 
 If you would be as kind ast to E-Mail your responses, I will collect
them and forward them to my friend.  Thanks!         -Ken
 
 - - - - - - - - - - - (generic cutting line) - - - - - - - - - - - - - -
Those who have done experimentation with the Serial port routines in C 
or otherwise, please step forward
 
My problem:
 
I set up the typical things to do a serial port read such as open 
up a MsgPort structure and then create a 'request block' with a 
CreateExtIO() function.  I set up the baud rates and know that every-
thing is working properly.
 
Now, I would like to receive one byte at a time from the serial port
in real time.  No 2400 bytes per second or anything.  And, for every 
one of those bytes from the serial port, I wish to get a MsgPort mes-
sage sent to me for each one of those bits and then check for that mes-
sage with a:
 
SerialPortSignal = 1 << ReadPortPtr->IOSer.io_Message.mn_ReplyPort->mp_Sig
Bit
 
I wish to check two other message ports at the same time in the same
manner.  One is from a window and the other from a timer.
 
Therefore, I wish to have three MessagePorts that all send me slow
changing information, and I wish one of them to be from the serial
port.
 
I can't use a 'Wait(Signals=SerialPortSignal (or) WindowPortSignal 
(or) TimerPortSignal) because it locks up and I don't get any signals
from either the timer or serial port if I do that.
 
Anybody got any code which may shed some light on this?
 
I don't wish to do continuous cycling and rechecking using the 
CheckIO() function, I just want it to sit there until things are 
done, or ready, then have it proceed.
 
 - - - - - - - - - - - (generic cutting line) - - - - - - - - - - - - - -
 
 Again, if responses could be E-mailed, it'd be appreciated...thanks!
 


           _____         ______________________   _____                
       |/    |          | cobra@datalog.com   |     |        /\        
       |\ en |hompson   | cobra@jab.tus.az.us |     |ucson, /--\rizona 
     ------------------------------------------------------------------
From: jbickers@templar.actrix.gen.nz (John Bickers)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
 <1992Dec31.011428.2926@mpifr-bonn.mpg.de> <C03uC5.15o@unix.portal.com>
 <1992Dec31.174137.10865@mpifr-bonn.mpg.de>
Date: 1 Jan 93 17:15:04 PST
Organization: TAP

Quoted from <1992Dec31.174137.10865@mpifr-bonn.mpg.de> by mlelstv@speckled.mpifr-bonn.mpg.de (Michael van Elst):

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

    So do you concede that 8-bit chunky pixels are indeed faster than
    8-bit planar pixels for CPU-driven drawing operations?

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

    Can you present your algorithm for bitmap scaling that performs as
    well as a chunky-pixel based algorithm?

> >Except silly little things like drawing lines. Who'd ever want to draw a line? :-)
> 
> And who fill an area by writing single pixels ?

    Me. A digital dissolve is basically filling 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..).

    Horizontal wipes do indeed fill the screen with vertical lines.

> 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: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: Advice to SAS/C 5.10b users
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Thu, 24 Dec 1992 16:02:29 GMT

In <BzroCE.MHH@unx.sas.com> walker@twix.unx.sas.com (Doug Walker) writes:
>What the heck does that mean?  Is that another "bug report"?

Well, sometimes there can be bugs difficult to describe. Here is what I found:


System: A3000/18MB memory/OS2.04
Compiler: SAS C 6.1

Options: DATA=NEAR CPU=68020 MATH=IEEE OPTIMIZE

when trying to compile the jpeg converter from the Independent JPEG Group
(Version 4 from ftp.uu.net) the compiler generates enforcer hits when
compiling the jdpipe.c module: long word reads from $8 and Byte reads from $0,
enforcer doesn't show the hunk although the faulting instruction is in RAM.
The hit takes place before (or just when) the second pass (either optimizer
or code generator) is started.

The resulting executable crashes with a bus error.

Compiling with CPU=ANY still causes the same enforcer hit but the resulting
executable runs fine.

I've tried dozens of different compiler options (optimize, utilitylib, cpu,
memory model) with no effects.

Sorry, EMITS doesn't accept my registration number.

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: tope@enea.se (Tommy Petersson)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: OS 3.0 Manuals
Date: 28 Dec 92 13:23:43 GMT
Organization: Enea Data AB
X-Newsreader: Tin 1.1 PL3

jesup@cbmvax.commodore.com (Randell Jesup) writes:
: Mats_Pettersson@p18.aiki.bbs.bad.se (Mats Pettersson) writes:
: >Well! Since the Hardware manual doesn't seem to be released for OS 3.0, when 
: >and where does the other manuals (OS friendly) come out?? Or are they to be 
: >released at all?
: 
: 	Manuals are always later than the hardware/software, since often
: details aren't firm until release.  Note that the 2.0 manuals came out shortly
: after 2.04 (if I remember correctly).  This also gives us time to make sure
: bugs and workarounds are documented in the manuals.  BTW, even if we were to
: do a hardware manual it probably wouldn't be available for quite a few months.
: 
: -- 
: 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.

The only way to get good, actual manuals out shortly after program
release would be to relese them on CD (or floppys) in AmigaGuide format.
If this format is used during development, small corrections can be made when
the bugs are found, and the CD's/floppies then made.

If you look at Microsoft's manuals and compare them with the contents of
the help files on floppy, they contain the same information, but the
books are much more out-of-date and full of errors.

-- 
=============================================================================
 Tommy Petersson              tope@enea.se              Enea Data AB, Sweden
=============================================================================
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
From: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Sat, 26 Dec 1992 23:59:41 GMT

In <92361.135903LEEK@QUCDN.QueensU.CA> <LEEK@QUCDN.QueensU.CA> writes:
>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.)

What about using the FPGA as a decryption engine ?

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