[Coco] Re: Coco Repack
jdaggett at gate.net
jdaggett at gate.net
Sun Aug 8 16:38:50 EDT 2004
Mark
My best guess as to why there never was 2Meg support for the
GIME chip came down to cost. To expand the chip to handle the
extra two address lines is really nothing. An sram memory cell is 6
transistors times 2 times 16, or 192 transistors. Not a problem
considering that there already is about 50,000 to 100,000 transistors
on the die itslef.
The real cost driver would be that to get the extra 2 address lines
would meand the Z-Bus would have to be expanded two bits to Z10.
Having already maxed out to 68 pins, another two pins would force
the chip into a 84 pin PLCC part or an 80 pin PQFP. That would at
least add another dollar to the product cost and that must have
been foun unacceptable even though OS9 could handle 2 Megs of
memory right out of the box.
just my thoughts
james
On 8 Aug 2004 at 12:49, Mark Marlette wrote:
Date sent: Sun, 08 Aug 2004 12:49:16 -0500
To: CoCoList for Color Computer Enthusiasts
<coco at maltedmedia.com>
From: Mark Marlette <mmarlett at isd.net>
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>
> At 10:24 AM 8/8/2004 -0700, you wrote:
>
> Kevin,
>
> Since the MMU will have to grow to x8 in size to handle this and have
> the same total RAM size as the current CoCo3, tre. Where do recommend
> it be place in the I/O map. Also remember there are two MMU task
> register.
>
> Mark
> Cloud-9
>
> >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
More information about the Coco
mailing list