[Coco] GCC: DFLOAT / DIRECT_PAGE

[KnudsenMJ at aol.com]

In a message dated 11/15/03 1:08:20 AM Eastern Standard Time, wb8tyw at qsl.net 
writes:

> No, the case for OS9, unless OS9 reserves the direct page register for 
>  it's own use, would be for a program to have as many direct page 
>  sections as it needs.  These sections can be put at fixed memory 
>  locations by the linker, or at dynamic locations, where the compiler 
>  knows where they are.

I'm pretty sure that in OS9-L1, each process (running copy of a program) gets 
its own full DP, since the startup code points DP at that process's direct 
variables cluster (which happens to be the start of its data area in RAM).  In 
fact, now I recall that process data areas have to start on 256-byte boundaries.

Note that OS9-L1 allocates data RAM from the bottom up, and program space 
from the top down, of its 64K total available.  The "real" direct page at $0000 
is reserved for the System.

In Level 2 it's simpler -- each program gets DP at $0000 and the GIME DAT 
block mapping takes care of mapping that somewhere into the 512K or 2M of 
physical RAM.  But what this means to the process' startup code is that DP always 
gets loaded with 00, whereas L1 would be setting a nonzero value.

There is no provision in MWC for reloading the DP with anything other than 
the initial startup setting.  You may of course have at it in your own ML 
subroutines, but please put it back as you found it before leaving :-)

Maybe Roger plays with DP in his Projector-3 routines.  I never had to mess 
with it in UltiMusE, though I knew I could fall back on that if needed for more 
graphics speed, etc.  (Actually 6809 UME could use a LOT more graphics speed 
;-)
--Mike K.