[Coco] SDCC and other C topics

[L. Curtis Boyle]

    If you remember the task 0/1 sets of GIME MMU registers, the main OS9  
system uses task 0, and GRFDrV and everything else use task 1. GRFDRV has  
it's own 64K map... 8 K for data, 8K for Get/put buffer mapping, 32K for  
screen mapping, and 8K for actual grfdrv code... leaving an 8K block that  
is never mapped in or used. That's why some hacks allowed the x225  
modes... there was all this extra room for it. Myself, I wanted to make  
the GUI and graphics primitives a lot more extensive (and did some of this  
within the 8K GRFDRV code block... like the 224 character fonts and the  
filled ellipse/circle (the latter based on, but developed independently  
from, the Level II upgrade).
     Basically, whenever GRFDRV is required, it jumps to a routine in the  
FE00-FEFF block of RAM that stays in place between all maps, and there is  
hardcoded routiens to swap the GRFDRV MMU set in, and running programs's  
MMU set in (as well as simply switching to Task 0 for the main OS-9  
Kernal). Things would have been better if Tandy had allow 3 or 4 separate  
MMU set lists; GRFDRV could have been swapped in/out with a single store  
into the task register select, instead of having to preload all of the MMU  
registers first and then switching tasks.

On Fri, 18 Mar 2005 14:54:12 -0600, Boisy G.Pitre <boisy at boisypitre.com>  
wrote:

>
> On Mar 18, 2005, at 1:12 PM, L. Curtis Boyle wrote:
>
>>     Actually, I wanted to go further and move grfdrv from it's current  
>> location, to allow an extra 8K contiguous block to use for GRFDRV code  
>> itself. The other option was to use an extra 8K for either Get/put  
>> buffer manipulation, or a higher res screen (say, x225 instead of  
>> x199/200). I was more steering towards having an extra 8K of graphics  
>> driver code, so one could add all kinds of stuff, or even more stuff  
>> out of Windint and into grfdrv to free up more system RAM in Task #0.
>
> Curtis,
>
> Can you explain how GRFDRV uses memory?  Does it have its own entire 64K  
> address space or what?  I was never too clear on this.
> --
> Boisy G. Pitre
> E-Mail: boisy at boisypitre.com
> Mobile: (337) 781-3997
> Web: www.boisypitre.com
>
>



-- 
L. Curtis Boyle