[Coco] Re: Coco Repack
jdaggett at gate.net
jdaggett at gate.net
Sun Aug 8 13:55:34 EDT 2004
Kevin
Yes you can establish page size to any size block of memory that you want. 1K to
32K is doable. But remember that not only the OS but any and all application
software has to be compiled to use that memory page size.
Example:
I have an application that is written around the fact that the page memory expansion
is based on 8K pages. This application stores a database in 256K of ram. I ft he
system is configured to do 2K pages in paged memeory expansion then the
application is going to have a major problem.
Once you set the page size for the paged memeory expansion, the OS and all the
applications must know that and be compiled and written for that page size.
Every one has to sing off the same sheet of music or you have chaos.
james
On 8 Aug 2004 at 10:24, Kevin Diggs wrote:
Date sent: Sun, 08 Aug 2004 10:24:53 -0700
From: Kevin Diggs <kevdig at hypersurf.com>
To: CoCoList for Color Computer Enthusiasts
<coco at maltedmedia.com>
Subject: Re: [Coco] Re: Coco Repack
Send reply to: CoCoList for Color Computer Enthusiasts
<coco at maltedmedia.com>
<mailto:coco-
request at maltedmedia.com?subject=unsubscribe>
<mailto:coco-
request at maltedmedia.com?subject=subscribe>
> Hi,
>
> I'm not talking on a per process basis, but a per system
> basis. For example, maybe the quatro will use 1k.
>
> kevin
>
> jdaggett at gate.net wrote:
> >
> > Kevin
> >
> > There can be a danger in allowing dynamic size on the fly. Two or
> > more processes with differing page size requirements are sure to
> > have memory over write issues.
> >
> > james
> >
> > On 8 Aug 2004 at 9:51, Kevin Diggs wrote:
> >
> > Date sent: Sun, 08 Aug 2004 09:51:14 -0700
> > From: Kevin Diggs <kevdig at hypersurf.com>
> > To: CoCoList for Color Computer Enthusiasts
> > <coco at maltedmedia.com> Subject: Re: [Coco] Re: Coco
> > Repack Send reply to: CoCoList for Color Computer
> > Enthusiasts <coco at maltedmedia.com>
> > <mailto:coco-
> > request at maltedmedia.com?subject=unsubscribe>
> > <mailto:coco-
> > request at maltedmedia.com?subject=subscribe>
> >
> > > Hi,
> > >
> > > I get it. The segment (block, page, whatever you want to call
> > > them)
> > > count is fixed at 256 (i.e. 8-bit). We can change that to if we
> > > wanna.
> > >
> > > And yes I do realize that NitrOS9 would have to be ... reworked.
> > > Maybe it should be parameterized to handle differing MMU page
> > > sizes anyway.
> > >
> > > kevin
> > > KnudsenMJ at aol.com wrote:
> > > >
> > > > In a message dated 8/7/04 10:09:18 PM Eastern Daylight Time,
> > > > kevdig at hypersurf.com writes:
> > > >
> > > > > Forgive my stupidity, but why does reallocating the bits in
> > > > > the
> > > > > address cut the max memory to 1 Meg (from 2?)?
> > > >
> > > > Let's assume you restrict the MMU registers to 8 bits, so
> > > > process DAT images can be stored in one byte per segment. 8
> > > > bits means 256 total RAM segments, no more!
> > > >
> > > > Currently those are 8K apiece, times 256 = 2 Megs.
> > > > Many of us once longer for smaller segments, like 4K, but times
> > > > 256 is only 1 Meg total.
> > > >
> > > > It's a tradeoff between total RAM size and segment sizes. After
> > > > a lot of public head bashing against the walls, some years ago
> > > > we concluded that Tandy's original design of 8K wasn't so bad
> > > > after all.
> > > >
> > > > Besides, it's what the DEC PDP-11 family used -- the machines
> > > > where UNIX was nurtured, if not born. --Mike K.
> > > >
> > > > --
> > > > Coco mailing list
> > > > Coco at maltedmedia.com
> > > > http://five.pairlist.net/mailman/listinfo/coco
> > >
> > > --
> > > Coco mailing list
> > > Coco at maltedmedia.com
> > > http://five.pairlist.net/mailman/listinfo/coco
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > http://five.pairlist.net/mailman/listinfo/coco
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
More information about the Coco
mailing list