[Coco] CoCo 3 68000/RAM board project

[jdaggett at gate.net]

Steve 

You are correct on all those issue. Improving graphics performance alone 
will no make a Coco3 batter. Increasing memory for higher resolutions also 
will not make a coco better. What is needed is for the internals to get 
faster. Everything from the processor down to the memory interface. 

WIth an FPGA, a 6809 or even a 6309 core could run as fast as 25 MHz or 
more depending on the FPGA and how the core is coded. I have taken 
John Kent's latest core and synthesized it alone in a XC3S500E FPGA. The 
static estimated propogation delays through the chip and routing yielded a 
speed of near 40MHz. Now that is a 20 times speed improvement over the 
current Coco3. It also means that if you keep the same IDMA process that 
the GIME uses you need 12 nS ram as your slowest speed ram. Current 
GIME needs 150nS ram. 

Memory issues are not to bad if I can get enoough speed todo what I want. 
That way the processor will have its own 2 meg of ram and the video will 
also have its own 2 meg of ram. I hope it works.

james
On 10 May 2009 at 21:34, Steve Bjork wrote:

> James, please tell Bookworm the price for adding something like this
> to a CoCo.  I don't think he caught it in your post.
> 
> Also, 1,790,000 16-bit words per second does not make for a very fast
> memory interface. (Even a two decades old system.) It would had press
> to get a better graphics with that slow of memory. An 800 by 600 by
> 256 color graphics mode would need a memory speed of 15,000,000 16-bit
> words per second and triple that speed for true (24-bit) color mode.
> 
> But speed is not the only issue.  It would take 480K bytes just to
> display an 800 by 600 bye 256 color screen.  There would be no room
> left in the CoCo's memory to run anything but a Mega-Bug ROM game.
> 
> You could expand the memory limit while you updating the GIME to 2
> megabytes since it's easy to add the extra bits to the MMU.  But you
> are still limits how fast you can access the memory and a full screen
> update would take 500 ms (about 1/2 second) and that makes the game
> frame rate of 2 per second.  Too slow in my book.
> 
> The CoCo screen resolution was kept low not just because of the memory
> limit but the speed of updating the memory.  The speed of the Coco was
> a wall that I hit time and time again when creating my games for
> Tandy.
> 
> Steve (Z-89) Bjork
> 
> jdaggett at gate.net wrote:
> > It is a essentially a replacement Coco but done in either two or
> > three FPGAs. Currently I am lenaing towards three FPGAs. This can be
> > used as an embedded sytem or as a stand alone system. 
> >
> > What I am about to share is a work that I started several years ago
> > and has undergone several intese modifications. First off was to do
> > a Coco3 into a single FPGA. While that is doable, in fact has been.
> > None of the development boards out there that are under $300 in cost
> > are lacking in either I/O or VGA color depth withour modification. 
> >
> > This all coincided with my understanding of several handheld
> > computers that are out there to control a telescope. Two in
> > particular use a processor that runs no faster than a Coco3. To give
> > it in a nutshell, I decided to investigate using a Coco3 for a
> > telescope controller. To my surprise it can be very well adapted to
> > such a task with some external motor drivers. 
> >
> > The main sticking point is that setting up a laptop, and a coco
> > system is a bit to much for the field use in a remote area. I need a
> > Coco3 that is small and portable. No bulky disk drives and monitor.
> > Just the computer, a small LCD, and a flash drive. 
> >
> > The current direction is now more in line with what Sockmaster had
> > proposed years ago which at first I rejected. Now in retrospect some
> > of his ideas are not bad all. One FPGA will house the CPU and any
> > enhancements to the instruction set like a math coprossesor. The
> > second chip is the main guts of the GIME chip like the MMU,
> > registers and such. The third FPGA is the actual video section. All
> > are separate boards and are plugable into a main board that is but a
> > carrier. A fourth board will have the Vinculum chip that gives me
> > direct access to a USB flash drive for storage. The Vinculum chip
> > handles all the FAT issues for drive access. 
> >
> > Like I stated it started from first being a GIME replacement into a
> > Coco3 that has grown maybe out of proportion. But size is now a
> > driving factor and the ability to operate off of batteries. 
> >
> > i hope this is less than a minute but a synopsis of what I am doing.
> > I am hoping to have some form of a working unit by the end of the
> > summer. I finally have the finances and hopefully the time to
> > realize a dream of mine for the last four years. Also to learn
> > something in the process. 
> >
> >
> > james
> >
> >   
> 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco