[Coco] Patching NitrOS9 for 8 meg

[L. Curtis Boyle]

The free/busy map has more than 2 states (Free, used, Not RAM (for ROM)), so it would be more than 1 bit per block. The process DAT images are for the blocks within a 64K process; the reason that there is enough room for 64 entries was for other OS-9 Level 2 systems with smaller block sized MMU’s (4k blocks took 32 entries, 2k blocks took 64, etc.). Now, theoretically, one could extend into the second byte (currently used to flag unused RAM with the double byte $333E, otherwise it’s $00xx). But there are tables that would have to be expanded (Block map, etc) past 1 byte per entry. Some utilities would need to be re-written to handle expanding into this.
Jim - I can’t remember - for programming which MMU blocks are active in each of the 32 tasks, do you have another byte that one sets to tell the system which task set of MMU blocks you are modifying, using one of the two existing sets ($FFA0-$FFA7 or $FFA8-$FFAF)?

L. Curtis Boyle
curtisboyle at sasktel.net



> On May 3, 2018, at 11:41 AM, RETRO Innovations <go4retro at go4retro.com> wrote:
> 
> On 5/3/2018 10:20 AM, James Jones wrote:
>> Take a look in Chapter 2 of Kevin Darling's _Inside OS-9 Level II_. (
>> http://wiki.yak.net/1087/InsideOS-9LevelII-KevinDarling_1987_.pdf)
> Looked, but I don't see the concern over moving past 2MB.  Yes, one needs to move to words across the spectrum, but P$DATImg has 64 entries, only 16 of which are used currently.  What am I missing?
> 
> I don't think one needs to know about the state of all 8kB blocks in RAM, just the 8kB blocks currently mapped by a process.
> 
> (Yes, one needs a FREE/BUSY map of all blocks, but one only needs 1 bit per 8kB block, so only 32 bytes for 2MB, 64 for 4MB, 128 for 8MB, and 16MB only needs a page of 256 bytes.)
> 
> Jim
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>