[Coco] MC6829 Memory Management Unit

[Dave Philipsen]

Yes, I was just following the original thread from Walter. I don't think 
he mentioned anything about a two task limit for OS9. We all know that 
OS9 manages up to 32 tasks. We was referring to a two task limit in the 
GIME hardware. And his comparison of maximum memory between the GIME and 
the MC6829 was correct. GIME=512K, MC6829=2048K.

The GIME bank registers only use 6 bits thus the number of banks 
available are 64. Each bank is 8K so the GIME by itself can only access 
512K of memory. The MC6829, on the other hand, has bank registers that 
contain 10 bits and each bank is 2K. The number of banks accessible is 
1,024 so with 2K banks it can access 2 Megs of memory.

The GIME has only two task registers. As Curtis points out, one is used 
for the system task and the other is used for all other tasks. That is 
not so efficient because every time you switch to a new user task, the 
bank registers must all be updated. That means extra overhead and there 
must be eight bytes of memory used for each task to keep track of how to 
load the 2nd task register. So in essence the operating system must do 
the bank switching every time a user task is switched in. The MC6829 has 
four different task registers so as long as an operating system didn't 
use more than four tasks there would be no need for the system to 
intervene and reload the bank registers every time a task was switched. 
Ultimately, a MMU for the CoCo would have 32 task registers (and 
associated bank registers) which would match up to the maximum number of 
tasks allowed under OS9. In that case, the only overhead for the 
operating system would be to select the active set of registers for the 
current task instead of reloading all of the bank registers of a single 
user task system like the GIME.

On 10/10/2022 4:38 PM, gene heskett via Coco wrote:
> On 10/10/22 13:41, Dave Philipsen via Coco wrote:
>> The GIME itself will only manage 512K of memory. If you have 2 meg 
>> running under OS9 it is because there is an extension to the 
>> registers in the GIME as part of the memory upgrade. Also, the GIME 
>> only manages two tasks. Under OS9 the operating system must reload 
>> the GIME registers every time a task is switched.
>>
>> -Dave Philipsen
> This is true, Dave, but there is no reason for a two task limit, as 
> each task can map the gime registers to suit itself.
> myram, the ramdisk I wrote, was just another of many "tasks".  Any 
> first access enabled it, formatting it if it was not
> formatted already.
>
> That was so fast you really had to be conscious of every millisecond 
> to notice the perhaps 20 milliseconds spent
> formatting it when you asked for a directory listing of /r0 the first 
> time it was accessed. Or reformatted if it had
> previously been used but had since been deinized.  At the time I went 
> public with it. I had written a script that
> opened a file in it, wrote 40k of rnd to the file, closed it, then 
> deinized it. I let it run for several days, no problems.
>
> Any other task could then use it. When you were done with it, a deiniz 
> gave every byte back to the system as
> free memory.
>>> On Oct 10, 2022, at 1:04 AM, gene heskett via Coco 
>>> <coco at maltedmedia.com> wrote:
>>>
>>> On 10/10/22 00:20, Walter ZAMBOTTI via Coco wrote:
>>>>  From what I can tell from the my brief reading of the manual the 
>>>> device works in a similar way to the GIME MMU except
>>>>
>>>> it supports up to 2 megabytes,  2K block sizes and 4 tasks.
>>>>
>>>>            Max Mem  Block Size Tasks
>>>>
>>>> GIME       512MB     8K           2
>>> Huh? level 2 had neither of those limits. I have the 2 meg kit from 
>>> Tony Disto in my coco3, and I can recall having
>>> more than 2 tasks going many times. I had two monitors, and could 
>>> have a compile going in the text screen, while
>>> I had two different editors working on pieces of rzsz. A 4th task 
>>> might have been printform doing a printout of the
>>> compile as the c compiler compiled the program.  That was all in the 
>>> half meg I hadn't used for a ramdisk for the
>>> compiler to use rather than scratchpad files.  The only limitation 
>>> was the time sharing as the more processes i had
>>> going, the slower each got.  Then Boisy started breaking up level 2 
>>> into more ever more modules, each of which
>>> demanded  its $27 bytes of vtab space using up the vtab space, so 
>>> today I can't even boot the os9boot I was using
>>> all those years ago. There appears to be zero includes or assembler 
>>> directives documenting it. And now my machine
>>> has died, I suspect from old dried out caps.
>>>
>>> Today I can't do that, and my complaints about it at the time 20+ 
>>> years ago were ignored.
>>>> 6829     2048MB     2K           4
>>>>
>>>>
>>>> The smaller 2K block size makes that quite attractive.
>>>>
>>> Not when it takes 8 of these to do the full 2 megs. That also 
>>> expands the table well beyond the $FF80 to $ff9F it now uses.
>>>
>>>> However since OS9 is written for 8x8k pages the MMU register 
>>>> structure would need to be enlarged to cater for 32x2k, if it is 
>>>> not already reserved.
>>
>
>
> Cheers, Gene Heskett.