[Coco] MC6829 Memory Management Unit

[John Mautz]

Does the GIME-X also have a 2 task limit or since it is still in
development, could it be expanded to 4 tasks of the 6829?

On Mon, Oct 10, 2022 at 8:04 PM Dave Philipsen via Coco <
coco at maltedmedia.com> wrote:

> 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.
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>