[Coco] Re: Coco Repack

[jdaggett at gate.net]

Kevin

I am not sure of that function call. .


james


On 8 Aug 2004 at 23:53, Kevin Diggs wrote:

Date sent:      	Sun, 08 Aug 2004 23:53:50 -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,
> 
>  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
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco