[Coco] Re: Coco Repack
jdaggett at gate.net
jdaggett at gate.net
Sun Aug 8 21:03:40 EDT 2004
Mark
sorry I got off track.
The current address locations for each task, $FFA0-$FFA7 and
$FFA8-$FFAF, would remain intact. The current GIME chip when
the block value of $3F is loaded into any of the registers will map to
the same top of ram as $7FFFF. By using the whole data buss, a
block number of $FF would be at $1FFFFF as top of ram.
In addition to the two extra bits to the MMU page registers, I plan to
bring out 21 address lines. By doing that the current software will
still be compatible. New applications can be written to take
advantage of the extra bits and block addresses from $40 to $FF
can be used to take advantage the new blocks. Old applications
could be rewritten or patched to allow the new blocks. Or at least in
theory it should work that way.
If you want to extend beyond 2 megs, all you need is a system that
pretty much is intact now. Use another address, say $FFAB which is
not used and that now will page 2meg pages instead of 512K pages.
256 2 meg pages is 512Mbytes of logical memory. More than any
one could desire for an 8 bit machine.
Personally I think 2 megs is plenty unless higher resolution graphics
are needed. Something in the nature of 800x600 and more than 8
bit color. I have one idea of a program with database that will
require about 4 megs to 8 megs of ram/flash. With MMC and flash
cards and IDE interfaces, memory really is not a problem.
Oh by the way, I have the register blcok from $FF90 to $FF9F
coded except for the timer registers. I will implement those later.
What I plan to do in the next week is instantiate a few components
to form a register block with all the ports in and out to that block.
That will give me three blocks done and the next big daunting task
and most likely the hardest, the VGA section.
I may have to pause and wirte up some of this and put it up on my
web page to give you and others a flavor of what I am doing. It has
actually been fun and a learning experience. Where I used to work I
always wanted to design an IC or a part of one on my own and
never got a chance to do that. Now I am. A labor of love sort of
thing.
james
On 8 Aug 2004 at 15:47, Mark Marlette wrote:
Date sent: Sun, 08 Aug 2004 15:47:02 -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 04:38 PM 8/8/2004 -0400, you wrote:
>
> James,
>
> All well and good but how does that suggest any answer to my original
> question? I had no mention of cost, number of transistors, etc, but
> the location of the MMU's additional register space in the I/O map.
> ???
>
> Still curious......
>
> Mark
>
>
>
>
> >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
> >
> >
> >
> >--
> >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