[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