[Coco] Patching NitrOS9 for 8 meg

[William Astle]

Memory blocks are also used for graphics screens, pre-loaded modules, 
the operating system itself, and possibly by other things like RAM drives.

On 2018-05-03 02:45 PM, Dave Philipsen wrote:
> So forgive me if I’m a little slow on understanding.  But I have another question.  You say that the maximum number of processes allowed under OS9 is 32, right?  And the maximum number of memory blocks allocated to a process is 8.  So right now there are only 256 possible blocks that could ever be mapped in at one time.  So that means that in addition to increasing the size of the block map you’d also have to modify how processes are numbered and kept track of, right?
> 
> So to support 8 meg you’d have to increase the number of allowable processes from 32 to 128 which would quadruple the number of process descriptors and you’d have to enlarge the block map to cover the entire 8 meg. Right?
> 
> Dave
> 
>> On May 3, 2018, at 11:17 AM, L. Curtis Boyle <curtisboyle at sasktel.net> wrote:
>>
>> We did briefly. It does run the system slower (because it has to swap MMU blocks in/out in the system map every time you went between SCF and RBF based system calls - reads, writes, getstats, setstats, etc.), and we needed to keep our printers running as fast as possible, so we went back to straight level 2. It did give us (effectively) an 80K system map.
>> Now, Jim Brains CocoMem is adding to the Task register - instead of being just 0 and 1 to choose from, he is bumping it up to 0-31 (and that is the maximum processes allowed under Coco Level II, anyways… and one would likely run out of system RAM before that happens). With the main system map being task 0, and Grfdrv/user processes being tasks 1 and up, the system has to manually change the MMU registers for every time you switch to a non-main system task. With Jim’s solution, this can be eliminated, and just change the single task register instead (you would update the MMU mappings whenever they need changing, thus maintaining compatibility with utility programs etc. that manually read those in - like MDIR, DMEM, etc. for example).
>> This will speed up multi-tasking, and the one could reserve 3 (instead of 2) tasks for the system - system/SCF, system/RBF, and Grfdrv - for faster task switching, alleviating the slowdown we encountered with Level III. Level III still needs patching to work with the current NitrOS9, however - I believe it was designed to for the “single driver” model for each device, not split apart into sub-modules (like RBSuper, then Cocosdc, or IDE, etc.), and I think it also had a tie in with the clock module for task switching or something - and that has been split in two as well.
>>
>> Bill Nobel has been looking into getting Level III going again with current builds, and has made some progress, but it is not completed (he is also working on fixing >8K grfdrv module sizes so it doesn’t try to initially link it in in the system map, which for quite a few people won’t fit, so it just crashes; and he is also very active on Roger Taylor’s Coco on a Chip family of products, so he, like me, is having our time divided between multiple projects.
>>
>> L. Curtis Boyle
>> curtisboyle at sasktel.net
>>
>>
>>
>>> On May 3, 2018, at 10:06 AM, Allen Huffman <alsplace at pobox.com> wrote:
>>>
>>> On May 3, 2018, at 11:01 AM, L. Curtis Boyle <curtisboyle at sasktel.net> wrote:
>>>>
>>>> We ran a 1 MB RAM Coco 3 system at work for 10 years.
>>>
>>> Did you ever run the Level 3 patches or was that after this?
>>>
>>> -- 
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> https://pairlist5.pair.net/mailman/listinfo/coco
>>>
>>
>>
>> -- 
>> Coco mailing list
>> Coco at maltedmedia.com
>> https://pairlist5.pair.net/mailman/listinfo/coco
> 
>