HDTenEightyP/NetNews huggingface dataset:
From: engb@gpu.utcs.utoronto.ca (Ben Eng)
Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware
Organization: Jet Penguin Lavatories
Date: Thu, 24 Dec 1992 02:01:23 GMT

In <38111@cbmvax.commodore.com> andy@cbmvax.commodore.com (Andy Finkel) writes:

>In article <38m5VB4w165w@lakes.trenton.sc.us> rock@lakes.trenton.sc.us (Rockerboy) writes:

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

>Not foul in context;  you were 'wondering' why certain otherwise OS
>compatible games broke on newer versions of the hardware or software...
>the answer is the copy protection, which is not OS compatible.

>You are right, though, copy protection is usually hardware hacking.

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.

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.

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
-- 
e-mail: engb@gpu.utcs.utoronto.ca or ben@jetpen.gts.org (Ben Eng)
UofT EngSci 9T2                   ``We are all masochists here.''
Home: (416)-979-8761, (416)-979-7885
Newsgroups: comp.sys.amiga.programmer
From: jdickson@jato.jpl.nasa.gov (Jeff Dickson)
Subject: Re: IPC and shared memory
Organization: Jet Propulsion Laboratory
Date: Sat, 2 Jan 1993 08:17:56 GMT

In article <paulk.317w@terapin.com> paulk@terapin.com (Paul Kienitz) writes:
>> I am looking for information on inter-process communications (IPC)
>> and shared memory functions.  Do the Amiga libraries have any
>> functions along these lines?
> 
>Sure, there's PutMsg() eh.
> 
>> 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.
> 
>Last time I messed around with a multiplayer game on a mainframe, the
>way it was done, which worked pretty well, was to have an area of
>memory that all the processes knew about, accessed through a locking
>mechanism to protect crucial sections of code.  The way to do this
>under AmigaDOS is with a named SignalSemaphore.  Tasks can arbitrate
>access to the data by taking locks on the semaphore, and the process
>of finding the semaphore by name allows the different tasks to all
>get pointers to the same piece of memory, which the semaphore happens
>to be the first item in.

Sure, a signal semaphore is the way to go, but for efficiency reasons I don't
think named ones are a good idea. You see to guard against the slight chance
the semaphore could go away whilest trying to find it via FindSemaphore - you
are supposed to protect the operation with the Forbid/Permit pair. Not only 
do you pull the plug on multitasking, but IMHO FindSemaphore is a waste of
time if your usage of it is purely for the convenience of knowing it by name.
I suggest simply making the signal semaphore globally known or just to the
tasks/processes that wish to use it and forgo the FindSemaphore bit all
together. Of course, this may not be an option. Just know that there is more
than one.

Jeff
 



 The way I
do it is to make the signal semaphore known to every task/process that wishes
to use it. This saves
From: paulk@terapin.com (Paul Kienitz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: IPC and shared memory
Date: 2 Jan 93 18:35:12 GMT
Organization: BBS

> IMHO FindSemaphore is a waste of time if your usage of it is purely
> for the convenience of knowing it by name.  I suggest simply making
> the signal semaphore globally known or just to the tasks/processes
> that wish to use it and forgo the FindSemaphore bit all together.
 
HOW do you "make it globally known"??  That's what the name is for.
 
The operation of FindSemaphore may be clunky but each task only has
to do it once.
Newsgroups: comp.sys.amiga.programmer
From: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: SAS/C 6.1 math=68881 BUG
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Tue, 22 Dec 1992 19:10:40 GMT

In <BznyMt.JA2@unx.sas.com> walker@twix.unx.sas.com (Doug Walker) writes:
>Any of them will work.  MATH=68881 will give inline code for the
>built-in math coprocessor, or at least it will after we fix it.
>This will be the best bet when fixed.

What about an m040.h that enables the inline code only for functions
that exist in the built-in math coprocessor ?

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: pochanay@cae.wisc.edu (Adisak Pochanayon)
Subject: How to legally acquire 68040 library
Organization: College of Engineering, Univ. of Wisconsin--Madison
Date: 22 Dec 92 14:28:33 CST

    I have a 68040 CPU and I am trying to run the latest version of Enforcer.
According to the docs, I should have 68040.library version 37.10 to run
Enforcer but I have only version 36.2 .  How or where can I upgrade???
I am wondering if this is one of the reasons why I am having some problems
with enforcer.

Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
From: bernie@metapro.DIALix.oz.au (Bernd Felsche)
Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware
Organization: MetaPro Systems, Perth, Western Australia
Date: Mon, 28 Dec 92 01:45:50 GMT

In <Bzus3J.70n@gpu.utcs.utoronto.ca> engb@gpu.utcs.utoronto.ca (Ben Eng) writes:

>It's easy to defeat, but it is impractical or at least inconvenient.
>As if everyone and his dog, who can only afford to purchase an A500
>or A1200, has the know-how to reprogram little pieces of hardware
>whose acronym they don't even understand.  Perhaps with the aid of
>some brilliant pirate organization's hardware/software blackmarket
>add-on.  All the more reason to make the process as inconvenient
>as possible.  Solder that darn PAL down.  Heck, mold it into the
>motherboard.  :-)  :-)

And the alternative is to use the soft approach, set an MMU
mapping to where you want, if you have the MMU, or beat it
into the kernel. The latter is quite simple -- pirates could
distribute the setpatch utility for the cracked game.

It is impossible to provide hardware copy protection without
strangling the architecture to a point where it cannot be 
developed any further.

It's ignorant and insulting to presume that somebody will
not crack a piece of software under any circumstances. What
you need to do is to make illegal use extremely embarrassing
and individual cracking impractical (why spend $6000 to hire
a cracker, when the licence costs $2000?). With more
expensive products, that's easy to support - simply compile
and link the code with *hard* definitions of the legal
owner, etc encoded in the binary. Upsetting the bytes would
cause severe dysfunction.

-- 
+-----+ Bernd Felsche                     _--_|\  #include <std/disclaimer.h>
| | | | MetaPro Systems Pty Ltd          /      \ bernie@metapro.DIALix.oz.au
| | | | 328 Albany Highway,              X_.--._/         Fax: +61 9 472 3337
|m|p|s| Victoria Park, Western Australia 6100  v        Phone: +61 9 362 9355
Newsgroups: comp.sys.amiga.programmer
From: jdickson@jato.jpl.nasa.gov (Jeff Dickson)
Subject: Re: LockIBase
Organization: Jet Propulsion Laboratory
Distribution: inet
Date: Thu, 31 Dec 1992 03:34:08 GMT

In article <JTP.92Dec30235759@cardhu.cs.hut.fi> jtp@cs.hut.fi (Jukka Partanen) writes:
>In article <paulk.2z9x@terapin.com> paulk@terapin.com (Paul Kienitz) writes:
>
>> I ended up
>> working around this in my personal DMouse variant by grabbing the
>> MouseX and MouseY fields of the screen itself, so it activates the
>> window where the mouse was as of the PREVIOUS input event instead of
>> the current one.
>
>	Well, that's about the same approach I use, and I've found it
>	to be adequate. What I really would like to know is the
>	correct locking protocol. First I LockIBase to browse through
>	the screens and find the correct one, but then I must release
>	to IBase lock to call WhichLayer. But the owner of the screen
>	may close it after the IBase is released, so I must Forbid
>	before unlocking the IBase and Permit after finding and
>	activating the window. Yuck, I say. Isn't there a better way?
>
>> Does anyone know a way (preferably forward-compatible) to convert
>> arbitrary input event coordinates to screen coordinates?
>
>	If you find out a cool way, tell me too!
>
>	jtp
>

	In a program I wrote, I examine the Mouse X and Y fields off of
IntuitionBase to determine the mouse current screen coordinates. I don't
think it would be possible to convert arbitrary input event coordinates
into screen coordinates, because the coordinates of the mouse therein are
relative to its previous position. Another plus is that IntuitionBase
does not need to be locked.

Jeff
 

Newsgroups: comp.sys.amiga.programmer
From: danb@shell.portal.com (Dan E Babcock)
Subject: Re: New hardware reference guide?
Organization: Portal Communications Company -- 408/973-9111 (voice) 408/973-8091 (data)
Date: Mon, 28 Dec 1992 03:18:07 GMT

In article <1992Dec27.234825.26574@mpifr-bonn.mpg.de> mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst) writes:
>In <1992Dec27.192924.2501@ugle.unit.no> mortene@Lise.Unit.NO (Morten Eriksen) writes:
>>so on. And this is just to get started! Very tedious and offputting. Lots of
>>talents would be waisted.
>
>I don't think so. Talents are supported by letting them _learn_ all the
>art of programming. Knowing the 680x0 processor and Amiga hardware specifics
>does not make a good programmer.

Bah. You can't deny that all the Amiga games that match sega/snes quality have been hardware-hitting games. I certainly don't want to see the end of nice games.
Who cares if they stop working? Most poeple get bored of arcade games after
a few weeks anyway! All that matters is that productivity stuff keeps working.
Why compromise the quality of a game now so that it -might- continue to work on
some future machine? Hit the metal and push the machine to its limits. :-)

Dan


Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.misc
From: walker@twix.unx.sas.com (Doug Walker)
Subject: Re: Advice to SAS/C 5.10b users
Originator: walker@twix.unx.sas.com
Date: Wed, 23 Dec 1992 15:55:42 GMT
Organization: SAS Institute Inc.


In article <1992Dec22.233153.17212@oracle.us.oracle.com>, dnavas@oracle.uucp (David Navas) writes:
|> In article <BzM5Kw.CuD@unx.sas.com> walker@twix.unx.sas.com (Doug Walker) writes:
|> >There are no reported bugs in far code/far data as of now.
|> >Don't complain about bugs until you have reported them.
|> 
|> Err, uhh, unless 6.2 magically made its appearance without my noticing, there
|> is at LEAST one reported far data/utillib problem that your should have
|> scheduled to fix for 6.2....

I asked tech support to check, and we do not have any bug reports
attributed to you by name.  It is possible that it is filed under
a misspelled version of your last name or something, of course.
The bug you described was stack overflows being caused by the use
of far code/far data in a program bigger than one file, which is
so unlikely that I am quite tempted to call it "impossible" despite
the fact that the impossible seems to happen regularly in software.

Your first posting didn't mention utillib or optimize, which this
one did.  This of course changes the initial reort.  Are there any 
other options we should know about?  How about code to reproduce 
the problem?  Is the symptom a stack overflow or something else?

|> Hey, and relax out there -- peace on earth, good will toward (wo)men,
|> 'member something like that from your distant past?  ;}

Remember the original posting that started all this was by someone
who was advising others not to upgrade to V6 because of all the 
bugs people were talking about on the net.  This is partially
because only "bad news" is discussed here, but it is also partially
due to the fact that people tend to blame the compiler when their
code acts funny.  Sorry if I blew up at your posting, but it
certainly looked like another "this must be a compiler bug,
but I'm not going to tell you any details" reference.

|> 
|> David C. Navas						dnavas@oracle.com
-- 
  *****
=*|_o_o|\\=====Doug Walker, Software Distiller====== BBS: (919)460-7430 =
 *|. o.| ||                                          1200/2400/9600 Dual
  | o  |//     For all you do, this bug's for you!
  ====== 
usenet: walker@unx.sas.com                            bix: djwalker 
Any opinions expressed are mine, not those of SAS Institute, Inc.
From: Rick_Lang@amusers.UUCP (Rick Lang)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Chunky Pixel Mode for Low End Chip Set?
Distribution: world
Date: 24 Dec 92 22:33:11 PST
Organization: AmUsers - The Amiga Users Group of Victoria BC

In a message dated Thu 24 Dec 92  6:54, Karsten_Weiss@ibase.stgt.sub.org
(Karsten Weiss) wrote:

 KW> happy
 KW> to see that Commodore finally decided to implement a chunky pixel mode
 KW> mode
 KW> was only mentioned in the list of the High End Chip Set features. Was
 KW> this
 KW> a mistake? 

From the tape of Lewis Eggebrecht's talk to the dealers, I can confirm he
said that chunky mode, 24 bit true colour applied to the LOW END chip set. 
Now go to bed and rest easy.  Merry Christmas.

 -- AEd V1.37/Eval

-- Via DLG Pro v0.995

-- Rick Lang
   Editor of the AmUser News - the Victoria Amiga User Group Newsletter

E-mail replies use rlang@bcsc02.gov.bc.ca - not the address in this
message!
From: cschneid@amiga.physik.unizh.ch (Christian Schneider)
Subject: Re: Memory copy via blitter
Organization: ICU - University of Zurich, Dept. of Computer Science
X-Newsreader: TIN [version 1.1 PL8]
Date: Tue, 22 Dec 1992 14:58:56 GMT

Dave Plummer (plummer@hercules.cs.uregina.ca) wrote:
: Could someone email a short example of how to copy 512 bytes within Chip
: memory using the blitter?  It's totally unrelated to graphics, but since
: I want a fast way to copy 512 or 1024 bytes, I'd like to use the blitter,
: but all the documentation I can find refers to BitMaps and such.

I'd use CopyMemQuick() from exec... (Your data is long word aligned,
isn't it?)
CopyMemQuick is probably as fast as blitter for 512 or 1024 bytes on
68000 and certainly faster on A3000/A4000 ;-)

- Chris

-- 
Chris Schneider - cschneid@amiga.physik.unizh.ch BIX: hschneider IRC: cschneid
It's impossible to enjoy idling thoroughly unless one has plenty of work to do
From: engb@gpu.utcs.utoronto.ca (Ben Eng)
Subject: GCC 2.3.3 link libraries are hosed?
Summary: foobar
Keywords: blah
Organization: Jet Penguin Lavatories
Date: Thu, 31 Dec 1992 20:38:27 GMT

I just installed the gcc 2.3.3 distribution that I ftped from
amiga.physik.unizh.ch and I am unable to link anything with the
supplied link libraries.

libgcc.a, libc.a, libg++.a, libcurses.a, libauto.a, libtermcap.a,
and libm.a all appear to be hosed.

"ar tv libc.a" gives:

rw-rw-rw-       0/0         85826 Dec 29 20:28 1992 __.SYMDEF
found string >uf<
ar: libc.a: Inappropriate file type or format

Since Markus appears to be away for the next little while,
does anyone know how to rebuild those libraries?  For example,
where is the source code to the C, curses, and termcap libs?

I'm going to give the 2.2.2 libraries a try with the 2.3.3
compiler next, but it would be nice if the 2.3.3 distribution
could be "fixed".

Ben
-- 
e-mail: engb@gpu.utcs.utoronto.ca or ben@jetpen.gts.org (Ben Eng)
UofT EngSci 9T2                   ``We are all masochists here.''
Home: (416)-979-8761, (416)-979-7885
From: epa@phys.ksu.edu (Eric P. Armstrong)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: GadToolsBox's ExtNewGadget....LEGAL?
Date: 21 Dec 1992 13:09:10 GMT
Organization: Kansas State University
NNTP-Posting-Host: bohr.phys.ksu.edu

In <vac133m.724907705@nella7.cc.monash.edu.au> vac133m@nella7.cc.monash.edu.au (Richard Jones) writes:

>  If anyone has any LEGAL way of implementing a toggle button (no.. I don't
>want a checkbox) using GadTools library, then PLEASE mail (or post) me. If I
>have to go down to basic Intuition (or even.. boopsi) then I suppose I will,
>but I'd really rather not.

Using GadTools you should be able to use a GENERIC_KIND gadget as
described on page 398 of the 2.0 RKM (Libraries).  It also gives a
partial example on how to make a boolean gadget.  Hope this helps.

--
Eric P. Armstrong 				epa@phys.ksu.edu
From: cliffwd@soda.berkeley.edu (Cliff Draper)
Newsgroups: comp.sys.amiga.programmer
Subject: Enforcer HIT, say what?
Date: 4 Jan 1993 03:28:17 GMT
Organization: U.C. Berkeley, CS Undergraduate Association
Distribution: inet
NNTP-Posting-Host: soda.berkeley.edu

While working on my program the other day, I came across an intriquing
Enforcer HIT.  It seems to be somewhat consistent in its address,
it's always a LONG-WORD read from BAD1BAD3.  It looks like some sort of
message, but I can't find any doc on BAD1BAD3.  Does anyone have an idea?
I'm running SAS/C 6.1 on my A4000 and it always happens somewhere in
my initilization code, but I can't pin it down.  It never shows up with CPR
and when I put printf()'s in it, it ceases to appear as well.  I
absolutely hate this kind of bug.  I can never be too sure if its me, the
compiler, or the OS.
Anyone  have any suggestions?


On a different subject, how bad is it to do a lot of (>100) small (but
varying) AllocMem()s.  Am I fragmenting memory pretty badly or is all
taking care of itself?

Thanks,
-Cliff
 cliffwd@soda.Berkeley.Edu          UC Berkeley

"Simple things should be simple &
 complex things should be possible"  -Alan Kay
 
Xref: sparky comp.sys.amiga.programmer:17794 comp.sys.amiga.hardware:22056
Organization: Queen's University at Kingston
Date: Thu, 24 Dec 1992 21:43:01 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>

In article <38130@cbmvax.commodore.com>, andy@cbmvax.commodore.com (Andy Finkel)
says:
>
>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.

A hardware hacker would replace the PAL with a ispGAL (In System
Programmable programmable GAL) on a daughter board.  The chip has extra
pins that allows it to be reprogrammed on the fly (yes, while machine
is running) and it emulates common PALs.

Now all the hacker has to do is to download the JEDEC fuse map to
'emulate' the ID that the software was written for.

BTW the application of the chip ispGAL16Z8 (by Lattice) includes
Copy Protection and Security Scheme...  :) :) :)

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

Now if your machine is down (eg. need a new chip), but you can't run
to the guy next door to borrow his Amiga as it has a different ID and
won't run your software.  :(

The ID code thingy is more a problem than a solution in the long run.

>andy finkel             andy@cbmvax.commodore.com

K. C. Lee
Elec. Eng. Grad. Student

P.S.  I show an easy solution to defeat the ID code implementation on
      a PAL chip.  It is meant to show the ease of defeating such an
      approach.  It is however NOT meant to support software pirating.
From: too@laphroaig.cs.hut.fi (Tomi Ollila)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: IPC and shared memory
Date: 31 Dec 92 14:59:40 GMT
Organization: /u/users10/too/.organization
NNTP-Posting-Host: laphroaig.cs.hut.fi
In-reply-to: Jean-Guy_Speton@tvbbs.wimsey.bc.ca's message of 30 Dec 92 16:17:20 PST

In article <Jean-Guy_Speton.056u@tvbbs.wimsey.bc.ca> Jean-Guy_Speton@tvbbs.wimsey.bc.ca (Jean-Guy Speton) writes:

   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.


Are you familiar w/ exec messages & ports. Read about those issues from Rom
Kernel Reference Manual, Libraries (& D Aevices), second or third edition.
read also section about exec libraries (Chapter 18 in RKM lib 3rd ed.)

I'd imagine that the most efficient results are achieved by using shared
libray, and returning different base pointer for each OpenLibrary() call.
This way library functions can put process spesific infromation in library
base data area and have one (or more) global variables to access and
mainpulate common information. Library functions are executed in caller's
context, so your functions can easily allocate signals and messageports for
IPC. Store that data wisely to commonly accessed data structures and youu
achieve fast IPC. Using Pete Goodeve's ppipc.library along w/ your
functions makes your code more safe against sudden deaths (without closing
your library) of some process using your library.

Tomi
From: vishart@ubvmsb.cc.buffalo.edu (Joseph Hart)
Newsgroups: comp.sys.amiga.programmer
Subject: requesters, custom image gadgets, and gadtoolsbox
Date: 28 Dec 92 18:47:00 GMT
Organization: University at Buffalo
News-Software: VAX/VMS VNEWS 1.41

I was wondering if gadtoolsbox was capable of generating
code for requesters, or for gadgets with custom imagery.
The support for requesters in PowerWindows is a tad weak,
though otherwise PowerWindows is an excellent product.
___________________________________________________________________
                  |         Internet: vishart@ubvmsd.cc.buffalo.edu
Joe Hart          |     ///    Plink: OSS542
Niagara Falls, NY | \\\///  Ham call: WA2SND
                  |  \XX/   AMIGA - Computers for REAL MEN
===================================================================
Newsgroups: comp.sys.amiga.programmer