[Coco] Re: Coco Repack

[Kevin Diggs]

Hi,

	The applications you are talking about are those that do their own
overlay paging, right? Loading and mapping blocks in and out on its own.

	Does OS-9 have a getpagesize() call of any form? If so applications
could be parameterized, right?

					kevin

jdaggett at gate.net wrote:

> 

> 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

> 

> --

> Coco mailing list

> Coco at maltedmedia.com

> http://five.pairlist.net/mailman/listinfo/coco