[Coco] MC6829 Memory Management Unit

[gene heskett]

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.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>