datawiz

one_on_one_gs_patch.dsk
http://204.16.8.40/other/oneonone/on...e_gs_patch.dsk
Uploaded to Asimov as well

This is a quick patch to EA's One-On-One game to run on a IIgs.
Originally, the cracked version quickly crashes after the crack
screen.
The reason why is because of an invalid opcode at $8AA. On an 8-bit
Apple, it would run this way:

08AA: 54 ??? (NOP)
08AB: 5C ??? (NOP)
08AC: A2 00 LDX #$00
08AE: A5 E1 LDA $E1
…

On a 16-bit IIgs, it runs this way:

00/08AA: 54 5C A2 MVN $5C,$A2
00/08AD: 00 A5 BRK $A5
00/C074: B8 CLV
00/C075: 5C 10 00 E1 JMP $E10010
E1/0010: 5C CC B7 FF JMP $FFB7CC
FF/B7CC: 18 CLC

The 00 aligns to create a BRK instruction, which sends the IIgs into a
different bank and it never returns, causing a lock up/loop condition.
The fix is to NOP out the instructions at 08AA and 08AB to cause
everything to line back up correctly and run through the routine.

It begs the question as to why it was invalid to begin with… Corrupted
original upload? Bug in original cracking job that was never detected?

Edits were done at Track 14 Sector 0C at byte AA:
From: 54 5C
To: EA EA

Tested on a ROM1 and ROM3 and seemed to work fine…

datawiz/rich

datawiz

UPDATE:
I found a problem. After the patch, the AI no longer shoots the ball
and there was a report of crashing at boot. Apparently some copy
protection is checksumming the code and modifying the game if anything
is different. Instead of changing the code at 8AA I reverted it and I
changed the JSR that calls it at 607 to JSR 8AC instead of JSR 8AA.
This skips over the bad opcodes, but doesn't change the code to
trigger the checksum. In the demo, the AI now shoots the ball and
matches the behavior as a non-patched copy, so hopefully all is well.
Disk image link has been updated appropriately and reuploaded to
Asimov as one_on_one_gs_patch_real.dsk

Antoine Vignau

That's weird.

Electronic Arts' games are not known for using false opcodes, more for
their track-arcing and m-code protection. I'll have a look at it if I
can find it (if I have it)

Antoine

Tempest

On Dec 30, 2:30*pm, Antoine Vignau <antoine.vig...@laposte.net> wrote:
> That's weird.
>
> Electronic Arts' games are not known for using false opcodes, more for
> their track-arcing and m-code protection. I'll have a look at it if I
> can find it (if I have it)
>
> Antoine

I can't get this disk to work on my IIgs. The drive makes an odd
noise then craps out with an Error #8. I was using ADTPro to transfer
the disk image over to a real disk. Anyone else having this problem?

A2CPM

Hi, y'all!

Back in May of 1998, when I was still enhancing the Apple2000
emulator for the Amiga O/S, I received a report that One-On-One was
crashing, when run via the emulator. I dis-assembled One-On-One but
that didn't help me find the problem. I had to modify the emulator to
produce an execution log. That allowed me to find the same problem
that Rich found. Back then, the problem was solved by having the
emulator treat $54 as a two byte NOP instruction.

Willi

Antoine Vignau

Based on the numerous messages, we can say EA has also used false
opcodes.

Ah ah! Bad bad boys!

Antoine

Steve Nickolas

On Fri, 30 Dec 2011, Antoine Vignau wrote:

> Based on the numerous messages, we can say EA has also used false
> opcodes.
>
> Ah ah! Bad bad boys!
>
> Antoine
>

Ugh. I hate illops.

Fortunately they're nowhere near as common as in C64-land.

-uso.

datawiz

On Dec 30, 2:30*pm, Antoine Vignau <antoine.vig...@laposte.net> wrote:
> That's weird.
>
> Electronic Arts' games are not known for using false opcodes, more for
> their track-arcing and m-code protection. I'll have a look at it if I
> can find it (if I have it)
>
> Antoine

I remember seeing the pseudo-opcodes as they used in their disk
protection code. The original cracker used a wildcard device, and it's
just one big b-file with no further disk access. Let us know if you
see anything there!

I've transferred the disk image over via CFFA3K and using Copy II+ to
put it on a physical floppy and it booted up on my ROM03 IIgs and the
demo played through normally.