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

From: Mia Magnusson <mia_at_plea.se>
Date: Tue, 8 May 2018 10:25:12 +0200
Message-ID: <20180508102512.00000454@plea.se>
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 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.

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".

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.

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).

-- 
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.
Received on 2018-05-08 11:00:38

Archive generated by hypermail 2.2.0.