[Coco] Above 512k upgrades

[Mike Pepe]

Robert Gault wrote:

> John W. Linville wrote:

> 

>> On Tue, Aug 14, 2007 at 12:47:22PM -0400, jdaggett at gate.net wrote:

>>

>>> On 14 Aug 2007 at 9:08, John W. Linville wrote:

>>>

>>>

>>>> IIRC, isn't there something about the video memory offsets that needs

>>>> to be handled as well?  Sorry, I don't have a GIME reference handy to

>>>> ask a more specific question...

>>

>>

>>> The GIME MMU uses only 6 bits to form the part of the Address from 

>>> A13 to A18. Other methods extend the addressing range beyond that. IF 

>>> you setup extra memory as blocks of 512K, then you will  have to to 

>>> little to any existing software. One approach  is to have essentially 

>>> super task switching to where one or more programs can run in their 

>>> own 512K block.

>>

>>

>> Yes, but I think you miss the point of my question.  As I recall,

>> if you merely extend the MMU entries to the natural 8-bits then you

>> will still have to keep your video in the 0th 512k block.  To be able

>> to allocate video frames beyond the first 512k you need a means to

>> extend the video addressing as well.

>>

>> John

> 

> That issue has been handled by extending the the number of vertical 

> offset bits into $FF9B. I've got an 8Meg board made by Paul T. Barton 

> and I think he may have gotten up to 32Megs but at least 16Megs.

> 


Yes, he did do memory upgrades into that range. He gets around the 
refresh problem by inverting the RAS/CAS relationship during blanking 
intervals and letting the memory devices do RAS-before-CAS self-refresh.

Works great.

-Mike