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

Hi!

It seems like the C128 has inherited some stuff from the P/B/CBM-II
series. The concept of banks and the concept of Y-indirect-zero-page
access to other banks is emulated by the KERNAL in a way that seems to
make it easy to port 6509 software to C128.

That makes me wounder how much of the BASIC is more or less ported from
the B series?

If they resemble each other (of course except for the graphics stuff),
maybe it could be possible to check for the differences between 128k
and 256k "B" BASIC and kind of implement those differences to C128
basic, making it use an expanded C128 with 256k?


On the net there are some descriptions of more or less the same
modification to expand the C128's memory in a way that is somewhat
useable by BASIC and 100% useable by the KERNAL funcctions. However all
theese use an extra MOS 8722 MMU (the same as the original one in a
C128). It seems like a waste to use an extra MMU (which probably comes
from scrapped C128's).

How hard can it be to make a modern MMU add-on which makes it possible
to expand RAM without using another 8722?

The MMU has a few registers that control which 64k RAM bank is accessed.

Bit 6+7 of configuration register and bit 6+7 of the four
preconfiguration registers selects in general which of four 64k banks
is selected.

The ram configuration register uses bits 0-3 to select several
configurations for having ram bank 0 appear in the bottom and top of
all ram banks. Bit 4-5 unused, bit 6-7 selects which 64k bank VIC
should see.

The page pointers can relocate zero page and the stack. It seems like
each of these pointers have a low byte selecting which page within a
bank to use, and the high byte seems to only select 64K bank 0 or 1
using bit 0. 


So to expand the memory of a C128, it seems like there is need for
latching bit 6+7 in the current configuration register, the four
preconfiguration registers, the ram configuration register and bits 0+1
of the high byte of the two page pointers.

As there anyways needs to be a mux that dynamically can switch between
the state of the configuration register, the state of the VIC bank
select of the ram configuration register, and the high bytes of the
page pointers, the mux might aswell have inputs for selecting which of
the configuration register or the four preconfiguration registers that
should be used, instead of actually transfering data from the
preconfiguration registers to the configuration register.

I'm not sure if the high bit of the two bits that select ram bank can
be read from the existing MMU. IF it can, there is no need to add some
extra logic to make that bit readable. If not, we might assume that
software won't depend on this bit being readable and ignore it anyway.

It seems like the MMU uses phi 0 clock and a modified AEC to determine
if it is the CPU or the VIC-II that accesses the RAM.

It seems like the MMU uses it's own adress inputs to enable it's own
registers. Logical as it antyways needs A8-A15 to move around the stack
and zero page and A0-A4 to selects it's internal registers. I'm not
really sure why it uses gates to combine A6+A7 and A4+A5 to two inputs
though.

So, using some kind of modern programmable it seems like we would need
all adress lines, D0, D1, D6, D7, R/W, AEC, phi 0 and reset from the
socket for the MMU. We would also need the CAS signals from the
existing MMU. Then it seems like it would probably be easiest to
implement all ram bank selection related stuff in programmable logic,
but use the existing MMU for everything else, and just combine the two
CAS signals from the MMU to one "RAM access is requested" signal and
let the programmable logic select which of four RAM banks to use.

The existing building instructions of an expansion seems to bypass the
existing 74F32 quad or gate, replacing it with a 74LS138 which uses
CASENB from the PLA and CAS from the VIC as enable signals and CAS0/CAS1
from the existing MMU as two of the three signals to decode. It seems
like a better idea to combine the existing MMU's CAS0/CAS1 signals onto
an enable signal (there are three enable inputs of an 74*138 anyways)
and let the programmable logic feed all three A/B/C decode inputs. That
way the programmable logic always has control of RAM bank selection and
there are a bunch of extra outputs for future expansion. If the
programmable logic has enough pins, this 74*138 won't be needed.


If there are enough pins on the programmable logic IC we could add
inputs for D2-D5 and more outputs to be able to adress even more ram.
That way the relocation of zero page could use any amount of ram up to
a theoretical 16MB (8-bit registers), and for example ram configuration
register bit 4 and 5 (currently unused) could select four different
256k "superbanks". With the zero page and stack relocators separate
from this "super bank selectors", it would be possible from software to
access data and code across the "super bank" boundaries as code and
data could be in (a relocated) zero page. With one 74*138 it would be
easy to have a total of 512k ram, with an additional 74*138 it would be
easy to have a total of 1MB ram. Or maybe larger RAMs could be used.
For example two banks of 256k would give a total of 640k or one bank
of 256k would give 384k. But this is a bit too much feature creep to
implement in some first development stage even for me :)




-- 
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.