[Coco] Preliminary Support for SDC in HDBDOS
Brett Gordon
beretta42 at gmail.com
Tue Nov 25 15:47:21 EST 2014
Yay for *possibly* self modifying code!
On Tue, Nov 25, 2014 at 3:30 PM, William Astle <lost at l-w.ca> wrote:
> On 14-11-25 01:00 PM, Luis Antoniosi (CoCoDemus) wrote:
>>
>> With a little work it would work. SECB is copied to RAM. Whenever it
>> should
>> access the upper 8K, it must toggle the ROM. Any function jumping or
>> calling an upper bank, should do it first and then return to RAM.
>
>
> It also turns out that doing so in a manner that "just works" on any version
> of the coco isn't that difficult either.
>
> You just need a "bounce" routine to perform the correct switching.
> Basically, you detect if you're in ROM mode and if so, just transfer control
> directly. Otherwise, switch to ROM mode, call the routine, and switch back
> to RAM mode.
>
> For anyone wondering, you can do something like this:
>
> BOUNCE BSR HICALL
> JMP REALCALL
> HICALL INC L1
> L1 BRA L2
> DEC L1
> STA $FFDE
> JSR [,S++]
> PSHS CC
> STA $FFDF
> PULS CC,PC
> L2 RTS
>
> This is roughly with the SDCDOS bit does. The way it works is you call
> BOUNCE as usual. It then calls the HICALL routine to do the ROM/RAM switch
> if required.
>
> If the system is running in ROM mode, HICALL does nothing and returns to the
> BOUNCE routine and goes on with the JMP instruction. (In ROM mode, the INC
> instruction does nothing.)
>
> If, however, the system is running in RAM mode, the INC turns the BRA
> instruction into BRN and then execution goes on with the DEC instruction
> (which restores the BRA instruction). Then it switches to ROM mode and calls
> the code after the BSR HICALL instruction. Then it goes back to RAM mode
> (taking care to preserve CC in this case) and returns to the original caller
> of BOUNCE.
>
> In other words, the upper 8K of the DECB ROM can be swapped in as required
> by simply having a number of similar "BOUNCE" routines. Obviously, code
> located in the high half of the ROM can just call other code in the high
> half directly.
>
> The fun part is that the code in the high half doesn't need to know that it
> was called specially though it does mean that you can't use the stack to
> pass parameters (in the ROM/RAM switch case, there's an extra return address
> on the stack) but DECB routines don't generally do that anyway.
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
--
Brett M. Gordon,
beretta42 at gmail.com
More information about the Coco
mailing list