[Coco] Patching NitrOS9 for 8 meg

[L. Curtis Boyle]

Yes, that is correct. 32 process limit is due to a couple of factors, I think:
1) The size of process descriptors (which, if I recall correctly, is larger than in level 1), which have to fit in the 64k system map.
2) The fact that each process can have up to 16 I/O paths (default is 3) for std in, std out, std err, extra printer/file paths, etc. Each of these take 64 bytes of system RAM as well.
3) The windowing system has a hard limit of 16 physical screens, and 32 windows (and that includes overlay windows), basically done to make sure it was a reasonable limit to fit into 512k. With hardware text screens (which are actually smart enough to share a single MMU block for multiple screens/windows) you could get up to that limit. With graphics screens, you could max out 512k with just screens alone. This is one specific place that having >512k really helps (get/put buffers as well, since those can be mapped outside 512k easily). There is still the compatibility issue going past 2MB, though, as the system MMU block used/unused map is currently a 256 byte structure, and there is stuff defined immediately afterwards. Some system calls, utilities, etc. would all have to be patched if this was either expanded (and everything after it is shifted), or if it was split into multiple chunks.

The extra task registers should require the least patching. The DAT images for each process would remain the same as before, and get updated the same as before. Only when there is a change would “special” code need to be ran to map those onto the real MMU registers, assigned to the extended task registers Jim is doing. (and those extra 4 bits are currently undefined/unused, so no code should be touching them). Thus, for normal run time and multitasking, instead of having to get the process #, point to it’s process descriptor, point to the DAT image (8 MMU block #’s) within that, and then copy them onto the task 1 MMU registers, one would just change the task register itself. This would be faster, obviously. System calls that allocation memory (F$Mem) would need the changes to update both the DAT image (for backwards compatibility) and the MMU block numbers for the specific task; the task register itself would be based on the process number itself, since it is limited to 0-31 anyways. So even when allocating additional RAM to a process (which doesn’t happen very often - process initialization, and a few apps will dynamically add more as they need it), the system overall will be faster. Grfdrv itself, which gets called for every graphics command and text block write, would be faster, for example.

L. Curtis Boyle
curtisboyle at sasktel.net



> On May 4, 2018, at 1:32 AM, Dave Philipsen <dave at davebiz.com> wrote:
> 
> I'm not 100% sure but if you look at Kevin Darling's book on page 2-1-4 it shows some stuff that's in system RAM.  It confirms what I mentioned from Boisy's document about the block map being 256 bytes long and that bits 0, 1, and 7 of each byte are used to describe how the block is used.  It also mentions a task table (at $0100-011F) that only has 32 entries.  Could it be that this table contains the process IDs of all processes and there's only room for 32?
> 
> There's also mention of the virtual DAT task map which appears to be a set of up to 32 pointers (64 bytes since each pointer is 16 bits) which point to DAT images which are stored in the process descriptors.  So if I'm reading this correctly (and I may not be!), the time-slicer steps through the virtual DAT task map (or perhaps the task table which then references the virtual task map) and gets a pointer to a DAT image which is then copied to the task registers ($FFA8-FFAF for user programs) for each time slice (1/10 of a second). This sets up the MMU for the correct memory to be mapped in for each individual process.  I would assume that if the time-slicer finds a zero or some other terminator there in the table that it resets and goes back to the first entry of the virtual DAT task map.  This *seems* to be proof that, indeed, there are only 32 tasks available of which the first two are reserved for the system so, in reality, there may only be 30 available for user programs.
> 
> Apparently, Jim's CoCoMEM allows for more than just two sets of task registers (as we have in the CoCo 3) so that DAT tables would not be needed in the OS9 system because the DAT images for each process could be stored in multiple sets of task registers in hardware obviating the need for OS9 to lookup and copy the DAT image at every time slice.  It could just step through the selects for the task registers.  This could slightly reduce the amount of time spent in system mode and give slightly more CPU time to user programs (although the improvement might be minimal).
> 
> I am just postulating here based upon what I'm reading and may not be understanding 100%.  Please correct me if I'm wrong.
> 
> Dave
> 
> 
> On 5/3/2018 4:27 PM, Allen Huffman wrote:
>> On May 3, 2018, at 3:45 PM, Dave Philipsen <dave at davebiz.com> wrote:
>>>  You say that the maximum number of processes allowed under OS9 is 32, right?
>> Wasn’t 32 just the number of task registers for the enhanced MMU of the memory board?
>> 
>> OS-9 6809 surely supports more than 32 processes, doesn’t it???
>> 
>> I just tested OS-9 Level 1 and have 40 processes running right now.
>> 
> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>