[Coco] Above 512k upgrades
lamune at doki-doki.net
Tue Aug 14 16:43:41 EDT 2007
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.
> 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.
More information about the Coco