[Coco] COCO4 Emulator

[jdaggett at gate.net]

Alex

I agree on the limitation present in bo th the hardware and the software. Memory 
usage on the Coco 3  is  more like 32 banks of 64k ram. There are two task 
registers that map any (8) 8K blocks to form a virtual 64K block to use. One method 
of expanding ram is to increase the bank size from 8K to either 16k up to 64k. Each 
doubling of the page size would double the addressable ram. This would take a 
major rewrite in the memory handler for OS9. 

 The cleanest way is to recompile OS9 to use a 24 bit address instead of its current 
21 bit address range. If that has not already been done. What would be needed is 
the hardware to take advantage of that. 

Hardware modifications would not be terribly difficult. Since 64Mbit SDRAMs can be 
configured as 4Mx16, yields an interesting method of increasing memory space 
probably with minimal work. A 64Mbit SDRAM configured as 4Mx16 is internally 4 
banks of 1Mx16. Expanding the current MMU of the GIME chip from a 16x6 to a 
16x8 ram will allow the GIME to address a 1Mx16 ram block. The hardware would 
simply take the 24 bit address and break it down to the following:

A0    - used to select upper or lower byte of the 16 bit data buss.

A1 to A13 form the CPU will be the row address data
XA13 to XA21 from the MMU would be the column address 
XA22 and XA23 are the SDRAM bank address. 

A1 to XA23 is multiplexed into an expanded Z-buss of 12 lines. A0 maps the WE0 
and WE1. Basically the GIME is doing this now. All One has to do is expand the row 
and column address for the SDRAM and add the logic for the bank selects lines of 
the SDRAM. 

I would believe the RSBASIC would be more difficult to rewrite than OS9. What 
would be benificial to OS9 with more memory is to add to the task regiter within the 
GIME. Ideally it would be nice to have between fou r and 16 task registers. Each 
one their own 64k of program memory and graphics and text windows. 

Also the graphics engine in the GIME just sucks. I would love to get my hands on a 
few HItachi HD63484 chips.  With those, RSBASIC can be reduced remarkably as 
most if not all the grahic commands would then be incorparated within the graphics 
engine. The HD53484 has 23 graphic commands internal to it. Besides the 
HD63484 can handle 1024x768 at 16 colors. It can do 640x480 with 16 bit color. 
This is the graphics chip that the Coco 3 should have used. It  was available when 
they designed it. 

james


On 7 May 2006 at 2:33, Alex Evans wrote:

> As far as some specifics you have mentioned.  The CoCo 3 can display 16
> colors at a time, and has no 8 color mode at all.  The CoCo 1/2 can
> display 9 colors at a time in any of the semigraphics modes.  You proposed
> a machine with more than 2M memory and smaller memory pages. It should be
> taken into consideration that in the CoCo 3 the 2M limit is what you get
> for a max of 256-8k pages.  From what I understand it would take some
> pretty serious changes to make Nitros9 use more than a single byte for
> page numbers, and I am certain that it would break nearly all of the
> software that uses paging directly.  As for DOS (BASIC) using all of the
> memory, ML applications already can, and for BASIC this is merely a
> software issue.  You just need to rewrite the interpreter to take
> advantage of more of the memory.