[Coco] Re: Coco Repack
Mark Marlette
mmarlett at isd.net
Sun Aug 8 22:03:11 EDT 2004
At 09:43 PM 8/8/2004 -0400, you wrote:
james,
I'm doing other things and not on this totally but. FExx page is REALLY
used in NitrOS-9 and always appears in block $3f...IIRC......
Mark
>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
>
>
>
>--
>Coco mailing list
>Coco at maltedmedia.com
>http://five.pairlist.net/mailman/listinfo/coco
More information about the Coco
mailing list