💾 Archived View for mirrors.apple2.org.za › archive › apple.cabi.net › FAQs.and.INFO › IIGS.SPEC.INF… captured on 2023-01-29 at 07:50:05.
-=-=-=-=-=-=-
Newsgroups: comp.sys.apple2
Path: news.weeg.uiowa.edu!news.uiowa.edu!uunet!spool.mu.edu!think.com!rpi!usenet.coe.montana.edu!nntp.uoregon.edu!cie.uoregon.edu!nparker
From: nparker@cie.uoregon.edu (Neil Parker)
Subject: Re: ORCA/Pascal Question
Message-ID: <1992Oct2.010635.12095@nntp.uoregon.edu>
Summary: It ain't that easy.
Sender: news@nntp.uoregon.edu
Organization: The Universal Society for the Prevention of Reality
References: <7KJ7KIT@zelator.in-berlin.de>
Date: Fri, 2 Oct 92 01:06:35 GMT
Lines: 61
In article <7KJ7KIT@zelator.in-berlin.de> tooly@zelator.in-berlin.de (Theo Schneider) writes:
>Hi there,
>i has an problem with an Assembler Routine in ORCA/Pascal.
>
>The Routine is in short
>
>theRout start
> sub
>
> emulation ;Macro to set to emulation mode
> native long ;Macro to set to native mode
>
> ret
> end
>
>In the Pascal source the Routine is call with :
>
>procedure theRout; extern
>
>begin
> theRout;
>end.
>
>The Macros are from 'M16.Util', so i think there are correct.
>
>Now when i execute my small programm it crash, when i remove the
>emulation and the native macro all work fine.
>
>Can anybody explain me how can i go to emulation mode and back without
>an crash ??
>
>Thank's for any help
Going into emulation mode safely requires a lot more than just setting the
CPU's e-bit. The first and biggest problem is that when you go into
emulation mode, the stack pointer is forced into the $100-$1FF range, no
matter where is was previously, and the native-mode stack pointer is not
automatically saved anywhere. You need to save the native-mode stack
pointer yourself before going into emulation mode, and restore it after you
come back.
Second, unless your native-mode code is already running in bank 0, you need
to disable interrupts immediately before switching to emulation mode, and
turn them back on once you're running in bank 0. This is because
emulation-mode interrupts assume that your code is in bank 0, and if one
occurs while you're in emulation mode in some other bank, all heck will
break loose when the interrupt handler tries to return to non-existant bank
0 code.
The _Apple_IIGS_Firmware_Reference_ includes a sample routine that takes
care of these concerns.
Have you considered simply loading your emulation-mode code into bank 0
and calling it with FWEntry?
- Neil Parker
--
Neil Parker No cute ASCII art...no cute quote...no cute
nparker@cie.uoregon.edu disclaimer...no deposit, no return...
parker@corona.uoregon.edu (This space intentionally left blank: )