Re: C128 memory - B series compatibility - Basic using 256k - a new version of the hardware for 256k

From: Marko Mäkelä <msmakela_at_gmail.com>
Date: Mon, 7 May 2018 18:56:39 +0300
Message-ID: <20180507155639.GA9182@jyty>
On Mon, May 07, 2018 at 12:46:53PM +0000, smf wrote:
>According to that there are two unused bits in the mode configuration 
>register. Maybe those could be used to extend to 1mb? Or add another 
>register?
>
>Either way it would make sense to latch it when the configuration or 
>preconfiguration registers are written, rather than have it switch 
>immediately.
>
>On 07/05/2018 07:33, Jim Brain wrote:
>>I assume you are referring to this doc?
>>
>>ftp://www.zimmers.net/pub/cbm/documents/projects/memory/c128/1028/1028.html
>>
>>http://www.ktverkko.fi/~msmakela/8bit/memory/memory-c128.pdf

Yes, I piggy-backed another MMU on top of the existing one, and added 
some 74xx chips to "redirect" some signals so that all 4 MMU banks are 
in use. Ignorance was a bliss; little did I know that this might not 
work due to added delays, fan-out and other timing glitches.

Each bank was independently expanded from 64 to 256 kilobytes, using 
16-kilobyte address windows. I think that this design (not mine, but 
originally developed for the Commodore 64 by Pekka Pessi) is better than 
switching all 64 kilobytes at once, because you can choose the video 
bank independently of the CPU bank, and you do not have to pollute each 
64-kilobyte page with any "trampoline" code.

OK, the C128 MMU partially solved the problem by letting you to redirect 
pages 0 and 1. You could use that feature to access small amounts of 
memory in "foreign" banks. But the C128 KERNAL still keeps writing some 
"trampoline" code in the $ff00 page if I remember correctly.

	Marko
Received on 2018-05-07 19:00:02

Archive generated by hypermail 2.2.0.