[Coco] Preliminary Support for SDC in HDBDOS

[William Astle]

Yup. I usually don't like self modifying code (it's unclear) but in this 
case, it's about the best way to do it since it doesn't require a 
register or keeping a flag.

Incidentally, on the subject of a 16K HDBDOS, I'd say "go for it". 
Nothing says there can't be a "classic" HDBDOS and an "extended" HDBDOS 
with more bits so those who are allergic to 16K ROMs for whatever reason 
can stick with the classic version.

For the record, I can't take credit for the code below since I mostly 
lifted it from SDCDOS. If you do go down the road of a 16K ROM, there 
are a couple of things that need to be considered in addition:

1. Error handling. You need to ensure that RAM mode gets restored 
properly during error handling if any of your routines can through a 
basic error (?SN, etc.). You can actually get away with appropriating 
the unused "on error goto" ram hook to do the map fixup. Even though it 
gets patched out by the SECB error handler, the actual call to the hook 
is present in the ROM so when in ROM mode, it will fire, even on a 
coco3. It does require a bit of special code to make sure it behaves 
correctly on all models but it can be done.

2. Interrupts. You need to make sure that any interrupt handling does 
not occur in the upper 8K of the "ROM" space since that will crash when 
the map is switched. Disabling interrupts would be overkill, though, 
since you can just make certain that no interrupt handling happens in 
the upper 8K. It's just something to be aware of when implementing any 
extensions to the interrupt handling. None of the interrupt handling 
routines on the Coco3 are in the SECB area so it shouldn't be problematic.

On 14-11-25 01:47 PM, Brett Gordon wrote:
> 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
>
>
>