NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/sys/amiga/games/18318

Text File | 1993-01-21 | 3.8 KB | 85 lines

Newsgroups: comp.sys.amiga.games
Path: sparky!uunet!gatech!concert!sas!mozart.unx.sas.com!jamie
From: [e-mail] (James Cooper)
Subject: Re: Gaming on 68030+ and KS2.0+ machines.
Originator: [e-mail]
Sender: [e-mail] (Noter of Newsworthy Events)
Message-ID: <[e-mail]>
Date: Thu, 21 Jan 1993 15:57:21 GMT
References:  <[e-mail]>
Nntp-Posting-Host: cdevil.unx.sas.com
Organization: SAS Institute Inc.
Lines: 71


In article <[e-mail]>, [e-mail] (Bill Chiu) writes:
>So many games broke as a consequence of my new machine, Amiga 3000/25.
>
>This must have something to do with the 68030 and it's caches and privileged
>instructions.  (BTW, tell me how caches/privileged instr. break games)
>Games that wasn't designed with KS2.0+ in mind ranked high in the dead game
>list.

This one's easy.

CACHES

A lot of games have the executable encoded, with a small decoder at the
beginning.  If the cache is big enough to contain the first bit of code that the
decoding routines try to jump to, you'll see the problem.  See, the stuff will
be decoded in RAM, but the encoded image is still in the cache, and when the
jump is done, the CPU know that code is already in the cache, so it essentially
jumps to garbage -- GURU!  All they needed to do was force the cache to clear
before jumping to the just-decoded stuff, and all would be fine.  Of course,
since they only had 68000's when they did the code (it doesn't matter that the
higher processors were available and well documented), they didn't do this.

Also, simple self-modifying code has the same problem.  If the cache was cleared
after the mod was made, but before you tried to use it, everything would be fine
with these programs.

Of course, clearing the cache does take a few precious cycles...

PRIVILEDGED INSTRUCTIONS

There was an instruction on the 68000, "MOVE  <ea>,SR", which was a regular user
instruction on the 68000, but became a Priviliged instruction as of the release
of the 68010.  SR is the machine Status Register (the place where the Zero,
Carry, etc. flags are stored, and a couple of others).  Unfortunately, a lot of
the Game programmers decided they needed to directly poke these flags for
various reason, mainly because it was faster than using system calls like SetCC.
This causes machine level privilege violations if you are not in Supervisor mode
when this instruction is executed.

>Would you people share me with your experience of games that will work with
>A3000, or a list of games that won't.  I use Christ Hames' Degrader quite
>often "to get stupid programs working", and I'll include any games that can
>be revived this method as working.

Most newer games work with the A3000, and even a fair number of old ones.  It
all depends on what "tricks," copy-protection methods, etc. were used when the
game was written.  In fact, the copy-protection is the main place most of the
older programs fail.

As for a list, someone was posting one for a while, and I think there's one
floating around some of the FTP sites, but I can't remember the name of the file
you need to get.  Something like "compat.lha" or "3kcompat.lha" or something
else with the letters "compat" in it.

>One last thing.  Are there other programs that can specialize in one or
>more abilities of degrader that performs better then degrader?  One thing
>odd about degrader I found is that when I select "SelectReset" to boot off
>a Amiga DOS volumn in PAL mode, it never want to open the inital shell
>window.  This can cause problems in some diskettes.

Sure there are others, but are you using the latest degrader?  The current
version is 1.30...

--
---------------
Jim Cooper
([e-mail])                             bix: jcooper

Any opinions expressed herein are mine (Mine, all mine!  Ha, ha, ha!),
and not necessarily those of my employer.