[Coco] Re: Coco Repack
jdaggett at gate.net
jdaggett at gate.net
Sun Aug 8 21:43:23 EDT 2004
mark
for 1K pages, it really becomes tight. The one block that seems not
to be u sed is between $FFE0 and $FFEF. The GIME does not use
those 16 bytes and neither does the processor for vectors. Ah
vector expansion area??????
like ps2 keyboard, spi, usb, ps2 mouse, parallel port with full hand
shake, A/D conversion????????
james
On 8 Aug 2004 at 20:18, Mark Marlette wrote:
Date sent: Sun, 08 Aug 2004 20:18:23 -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 09:03 PM 8/8/2004 -0400, you wrote:
>
> James,
>
> At a quick glance this all looks correct. I haven't looked at my 2meg
> design in a while, at least that section. But the video logic for
> >512k memory is at $FF9B. Paul Barton also has done a bunch of work in
> this area of >512k.
>
> As you will see the I/O map for the CoCo is TIGHT! Not much room to
> add 1k pages and still get 2MB. Unless you mux the mux..... :)
>
> Mark
>
>
> >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
> >
> >
> >
> >--
> >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