Can anyone offer a snippet of assembly code to properly set the BRK
vector on the IIgs?

I'm working on fixing a couple more Apple II games that don't work on
the IIgs, and I've noticed a trend of BRK causing problems. In the
latest case, the Apple II BRK vector at FFFE/FFFF is set to point to
user space code and it's used extensively as a method of code
obfuscation by the copy protector. In previous fixes, it's been a
single BRK event, which can be patched to jump to the exit point. In
this case, BRK instructions are littered throughout the code and sent
to it's internal handler, so I can't patch every instance and a
complete rewrite is a bit daunting.

So the path of least resistance seems to be to set the IIgs BRK vector
to point to the same Apple II BRK vector and it should work correctly,
right?

I'm not a IIgs guy at all, so any assistance would be appreciated.

Thanks!
Rich

On 1/2/2012 8:55 PM, datawiz wrote:

The IIgs actually has tools to set the BRK vector.  Here is a link to
IIgs Technote #1 which includes sample source code:

http://www.1000bit.it/support/manuali/apple/technotes/iigs/tn.iigs.00...

Charlie

Thanks Charlie, I saw that earlier.

What do the standard macros for
_GetVector
_SetVector
assemble to?

I don't have a IIgs development environment set up. Can the IIgs mini-
assembler understand those macro calls?

Sorry, I have absolutely no IIgs programming experience, so I'm pretty
much a newb. :)

On Jan 2, 10:32 pm, Charlie <charlieD...@verEYEzon.net> wrote:

On 1/2/2012 11:01 PM, datawiz wrote:

All tools can be called from assembly by loading the X register with the
toolset number in the high byte and the tool number in the low byte and
then doing a JSL $E10000.  JSL is a long JSR.  For _GetVector you would do:

LDX #$1103
JSR $E10000

and

_SetVector would be:

LDX #$1003
JSL $E10000

But the thing is you have to start the toolsets before you can use them
and some toolsets are dependent on others, etc, etc.

No.

Okay, so doing it with tools is not really an option.  Are you sure that
the BRK vector is the problem?  Are you booting a game disk on the IIgs
or are you running a game program from GS/OS?

It's been a long, long time since I did any IIgs programming but I
thought that GS/OS sets its BRK vector at $E10070-73 and I thought when
you booted an 8 bit OS that it went with the old $03F0-$03F1 pointing to
$FA59.  Someone correct me if I'm wrong.

Charlie

I'm certain that the BRK is the problem here, as I've fixed similar
issues in other non-friendly IIgs games.

On the IIe, the IRQ/BRK vector at FFFF/FFFE is set to point at $9300
(via bank switching) and then uses BRK instructions throughout the
code to return to $9300 over and over again. On an Apple II, it's not
a problem but here's what happens on a IIgs when it encounters the
first BRK instruction (trace file from Sweet 16):

00/4037: A9 F5          LDA #$F5           A=0000 X=0000 Y=0000 e=1
m=1 x=1
00/4039: 85 51          STA $51            A=00F5 X=0000 Y=0000 e=1
m=1 x=1
00/403B: FD 7A 40       SBC $407A,x        A=00F5 X=0000 Y=0000 e=1
m=1 x=1
00/403E: 00 10          BRK $10            A=0047 X=0000 Y=0000 e=1
m=1 x=1
00/C074: B8             CLV                A=0047 X=0000 Y=0000 e=1
m=1 x=1
00/C075: 5C 10 00 E1    JMP $E10010        A=0047 X=0000 Y=0000 e=1
m=1 x=1
E1/0010: 5C CC B7 FF    JMP $FFB7CC        A=0047 X=0000 Y=0000 e=1
m=1 x=1
FF/B7CC: 18             CLC                A=0047 X=0000 Y=0000 e=1
m=1 x=1

At 00/403E the first BRK instruction is encountered, and it appears to
jmp to E1/0010-- perhaps it understands the BRK index ($10) and
vectors to $E1/0000+index? But it's certainly not following the same
behavior as the 8-bit Apple.

My idea was to patch in at the first stage boot a code snippet to:
1: detect if we are running on a IIgs
2: if so, set the IIgs BRK vector to 00/9300
3: continue with standard boot

On 1/3/2012 12:46 AM, datawiz wrote:

I really have no idea what's going on here and apparently I'm wrong
about the vectors not being set up when booting to an 8 bit OS.

On a IIgs 00/C071 to 00/C07F is a ROM interrupt jump table (why its in
the I/O area I don't know).  E10010 is the vector for the main system
interrupt manager.  It can be patched so I guess what you are asking is
how to do that.

Assumming that your code is 8-bit (emulation mode) then to patch the
vector you would need to switch to native mode and back:

CLC
XCE             ;switches on native mode
REP #$110000    ; make the regs 16 bit

LDA #$5C00      ; patch the vector
STA $E10010
LDA #$9300
STA $E10012

SEC
XCE             ;back to emulation mode (8 bit)

Keep in mind that I haven't done any coding for the IIgs in many years
so don't take this code as gospel.

I think the problem is going to be when you now come back from this
patched vector you will probably be in the wrong mode.  Native instead
of emulation.  At the very least you are going to have to add some code
(and store it somewhere) to make sure you come back in the same mode you
left.  You'll also probably have to ensure that the machine registers,
stack pointer, etc. are in the same state as when the BRK occurred.
Take a look at the code at $FFB7CC to see how the IIgs is handling it.

Charlie

Charlie,
Thanks, this is more than enough to get me started down the path. I
think I've seen IIgs code to save/switch/restore emulation mode, so I
can do some research and start playing around.

Many regards!
Rich

news:6875625a-f276-4d22-8cf3-895f9cceb506@k28g2000yqn.googlegroups.com...

I'm not an Apple guy at all, so I can't help you with that, but I'm
wondering a little about this assertion. Are you sure? You may be right, but
software BRKs skip a byte when returning. It's possible, and occasionally
done, to use that behavior to implement "extra" instructions by setting that
skipped byte to a particular value and examining it from within BRK handler.

For example, one way to implement an OS for a 65xx-series processor would be
to have all OS calls be made as BRKs followed by a "signature" byte. That
way the OS could be re-written at will (ie., routine entry points changed)
without user software being any the wiser. Something like an x86's software
interrupt approach to BIOS and OS calls, actually.

So without having seen that code, I'd say it's possible that the BRK handler
is actually doing something important to the game itself. Even if it is
completely copy protection it might be setting flags that other parts of the
game want to see.

- Anton Treuenfels

On Jan 3, 9:17 pm, "Anton Treuenfels" <teamtemp...@yahoo.com> wrote:

I'm positive it's implemented as a part of the copy protection
measures. In fact, once the main game is loaded up and execution goes
beyond the demo, it no longer uses the BRK vector at $9300 at all. I
did not tear apart the handler, but I imagine that it does need some
way of determining which subroutine initiated the BRK, so it probably
does use an index immediately after the BRK as a value into a table to
return to proper execution.

If anyone wants to have a look, the game is Earth Orbit Station (EOS)
by Electronic Arts, and is available on Asimov.
There's a ton of obfuscation, decryption, and self modifying code
going on during the first 2-3 stages of boot loading. If you set a
Breakpoint at $AABF, this will finally lead to an exit of this stage
of the boot via an indirect JMP ($0042) which goes to $42E2. In that
subroutine, you'll encounter the first BRK instruction.

That said, I think I've fixed it-- it turns out to be rather simple.
If you download that image and boot it on a IIgs, it will lock up
shortly after the boot (you'll see a screen full of multi-color
squares, typical for Electronics Arts protection of this time). Break
out and get into the monitor and directly patch the IIgs break vector
to jump to bank 00, $9300 which is where the program redirects it to
in the game:
e1/0010: 5c 00 93 00

then boot the disk:
c600g

Game boots past the multi-color screen it previously locked up at, and
proceeds to the demo and eventually game start.
I'll patch it into the T0/S0 boot and test it out on a real IIgs
later. Thanks for all the input and the assistance, hopefully that
will do it!

Rich

Of course, I just learned that this is not just a BRK vector, but the
main interrupt vector so I can't just clobber it-- I've got to play
nicely. Man, I'm learning more and more about the IIgs... :)

Rich

On Jan 4, 9:10 am, datawiz <rich.mar...@gmail.com> wrote:

And doing a good job of making it possible to play games on it that
wouldn't run on it back in the day! I'm enjoying playing Questron on
Sweet 16, just need to move it to my flash drive so I can load it into
the CFFA3000 and play it on the real hardware.

Dean