[Coco] Preliminary Support for SDC in HDBDOS

[Brett Gordon]

All good advise.  Here's what I'm taking from this:

1. No interrupt handling code in the top 8k ( BASIC doesn't do anyway )
2. Keep DSKCON modules in lower 8k ( They are already there )
3. Art's done it.  Darren's done it.
4. No stack args in top 8k. ( BASIC doesn't use the return stack for
much data anyway )
5. Bounce from top to bottom

How about if stick just the BASIC parsing routines in the top 8k.
These are the routines that are more or less meant to be run in direct
mode, like DRIVE,DIR,DW, etc...  Things that might be rarely used by
most existing BAS and BIN programs don't use much.  Much BIN programs
I use, mostly games, fart out and need a cold boot anyway after
quitting.  Let the application overwrite the top 8k...we don't need it
after LOADing anyway ?

Am I correct in saying (at least on a CoCo3) there's no way to run the
Top 8k in RAM ?  That means you wouldn't be able to run a 16k HDBDOS
from anything but ROM ?  This might hurt any generalized HDB
functionality we try to extend (like DW routines, or a new commodore
style DIR that works with Louis's Cursed ).  Also, any of the existing
utilities that dynamically load HDBDOS will break?




On Tue, Nov 25, 2014 at 9:22 PM, William Astle <lost at l-w.ca> wrote:
> On 14-11-25 04:17 PM, Arthur Flexser wrote:
>>
>> There's not a lot, but there's definitely some, and it's often frequently
>> used stuff like word processors.
>>
>> The worst situation I ever ran into with Extended ADOS-3 compatibility was
>> a word processor (Word Power 3.x) that put its STACK in that upper 8K
>> area.  Never could come up with a compatibility fix for that one.  The
>> author promised to move the stack elsewhere in a later version, but never
>> did.
>
>
> I can't think of any way around that either. Presumably the stack and other
> data was moved to high memory to maximize the contiguous logical RAM
> available for buffers or something like that. Otherwise, it makes no sense
> to do so.
>
> Still, any time you make your code space larger, there's a chance you run
> into something that fails miserably due to a conflict like that.
>
> Keeping the I and F flags unchanged after the swap and call process is not
> really all that pleasant if the routines being called might use other flag
> states to return information. If they are forbidden to do that, it's not so
> bad since you can just save CC on the way in and restore it on the way out.
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco



-- 
Brett M. Gordon,
beretta42 at gmail.com