[comp.sys.amiga.games] 68010 and bootable disks

iann@cnw01.storesys.coles.oz.au (Ian Nicholls) (05/02/91)

I have a couple of games which don't like my new 68010 chip at all.  In
particular, SWIV (Silkworm four), my current favourite.

The problem is:  I bought the 68010 chip for my B2000 recently, and,
using Decigel, programs under AmigaDOS work OK.  It's when I start using
copy-protected games such as SWIV that things go wrong.

As soon as SWIV looks at the disk, the machine guru's with a "line F
exception."  This leads me to think the problem is in the boot sector, or
in the game loading program.

The shop I bought the game from said they couldn't help me except to
downgrade the machine back to a 68000.  The game designers are all the way over
in England, so I don't really want to bother them if there is an easier
solution.

Is there a way of inserting the Decigel exception handler into the operating
system before the boot sector takes over?  It occurs to me it may be
possible, but being a recent convert to the Amiga, I lack the knowledge.

p.s.  I know the Line F exception isn't the Privilege exception that I
      expected.  Is this significant?


Any help on this would be appreciated.  Thanks.
-- 
"If it's OK to start by stealing pencils, where then do we draw the line?"
Ian Nicholls         Phone : +61 3 829 6088   Fax: +61 3 829 6886    \_o_/
Coles/Myer Ltd.      E-mail: iann@cnw01.storesys.coles.oz.au         \\|
L1 M11, PO Box 480, Glen Iris 3146, Australia                         \\

DXB132@psuvm.psu.edu (05/04/91)

In article <1250@cnw01.storesys.coles.oz.au>, iann@cnw01.storesys.coles.oz.au
(Ian Nicholls) says:

>I have a couple of games which don't like my new 68010 chip at all.  In
>particular, SWIV (Silkworm four), my current favourite.

SWIV builds its own stack frame and RTEs in many, many places. It's not
a simple fix.

I can't believe this **** (explitive) coming out in 1991. In 1985 it was
perhaps OK, but today it shows big time ignorance. I don't understand
how a programmer can work so hard to create a product like this (the game
is very impressive) and then screw up on some simple stuff ??!!

The worst part is the code in these games that causes compatibility
problems is almost always extra junk added to "confuse" a cracker.
(Hint to programmers: Any time spent making code difficult to crack
is wasted. It only makes the cracker prouder of his achievement).

Ah, the frustration. :-)

-- Dan Babcock

Note to people who have emailed me about getting SpeedballII to work:

There is no "patch" per se; I just dumped the thing from memory  and
obviously can't generally distribute it. In that case the program was
doing some trap...this is the entire trap code:

addq.l #2,sp
rts
(or something like this -- can't quite remember).

That's it -- it does nothing except crash your machine. :-)
Solution: Replace the trap with a NOP. Argh....