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

On 5/8/2018 3:25 AM, Mia Magnusson wrote:
> Den Tue, 8 May 2018 08:59:57 +0000 skrev smf <smf@null.net>:
>> On 08/05/2018 01:18, Jim Brain wrote:
>>
>>> I'd recommend using 4kB pages, using one $d50x register to hold the
>>> "task" number, and using 16 of the free registers to hold 16 "page"
>>> registers, 1 for each 4kB page  At 8bits, that'd be able to manage
>>> 1MB, while extending the MMU regs to 13 bits would allow 32MB of
>>> mapping.  With a task register, you could have 256 mappings.  The
>>> additional 3 bits could be used for "IRQ on write, mark RAM as
>>> read-only, and reserved.
>>>
>> The C128 was designed so you can configure all your banks and then
>> switch between them with $ff0x accesses, without having to page the
>> $d50x registers back in. Therefore I think you should consider adding
>> a task register into the $ff0x range.
>>
>> I believe ram/rom shows through in $ff0x except where the existing
>> registers are defined, so to remain backward compatible you'll need
>> to enable it with a magic sequence in the $d50x range first.
> There are two "threads" here.
I disagree, but I'll note why below.
>
> I propose some addition that is compatible to how the C128 works as it
> is. If you want more than a total of 256k, you could have extra
> registers in the D5xx area to hold additional information regarding the
> preconfiguration registers.
I understand.
>
> However you might configure it, it seems silly to not retain the
> existing bit meanings for the configuration register, i.e. let the low
> 6 bits map in/out rom and I/O and the two high bits select which 64k
> ram bank to use. If that is retained, it's always possible to page in
> the D5** I/O range no matter where you "are".
I agree.
>
> But if some other kind of MMU scheme would be used, you can make it
> incomaptible with the existing KERNAL memory locations and just use
> more space in the FF** area. The only limit is that you'd not want to
> move around any jump vectors into the KERNAL, as that would break more
> software than necessary.
As I look at the initial request, the easiest solution is a small CPLD, 
because you need to implement at least 1 bit for CR and all 4 PCR 
registers (to support the additional 2 64kB banks).  Once youb have a 
CPLD, now you are woefully overpowered for the task at hand, and so I 
felt it would be useful to extend the capability beyond that small 
initial goal.

I propose my ideas, not so much as I expect them to be taken up 100%, 
but that they spawn a discussion on bow best to add value to the MMU.

I also think the 64kB bank limitation is a bit extreme, as Marko notes 
as well.  Thus, one should consider a way to subdivide it into smaller 
chunks


>
> If you want some mechanism to split the CPU adress space between two or
> more memory banks, it might be a good idea to keep the existing
> registers to select which areas that's common and what size they have.
> Just add some mechanism to select which bank is common too. Afaik on a
> C128 the common areas are always RAM bank 0 (or maybe it's rom in the
> top but bank 0 ram in the bottom? Haven't checked).
>
Having a configurable common area is a nice feature, one that should be 
kept.  the 4 "quick" selects is also a nice feature, and should be 
kept.  But, I think one can "extend" the MMU in such a way to provide 
both compatibility and greatly expanded capabilities.


Jim