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

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

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

Reply | Threaded
Open this post in threaded view
|

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

Jim Brain
On 5/7/2018 12:43 AM, Mia Magnusson wrote:
> Hi!
>
>
> 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).
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


> How hard can it be to make a modern MMU add-on which makes it possible
> to expand RAM without using another 8722?
I doubt it's very hard at all. Is there a datasheet for the MMU
anywhere?  I looked at:

ftp://www.zimmers.net/pub/cbm/documents/chipdata/index.html

but did not see it.
>   I'm not
> really sure why it uses gates to combine A6+A7 and A4+A5 to two inputs
> though.
I suspect they ran out of pins on the package.
>
> 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.
I think the MMU is socketed, so can you put a daughtercard in the socket
and get all the signals you need?  It may be easy to just replicate the
existing MMU logic and dispense with the original.

It *looks* like one could make a daughtercard that plugs in where the
8722 goes, with RAM on board that could replace the existing DRAM. 
You'd need to pick up the missing address lines, and get some
information from the PLA, but if it can be done, that would open up a
ton more options.

The 6809-based TANDY color computer supports a nice MMU functionality
that offers the ability to expand to 2MB RAM easily, in 8kB pages, with
a hardware based task switcher as well.  Such a design is trivial to add
to the C128, even with adding a relocatable zp and stack.  If the RAM
cna be put on board the daughtercard, such a design would be trivial.  
Such a design would also be portable to the C64 as well, I think.

Jim

smf
Reply | Threaded
Open this post in threaded view
|

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

smf
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
>

Reply | Threaded
Open this post in threaded view
|

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

MiaM
Den Mon, 7 May 2018 12:46:53 +0000 skrev smf <[hidden email]>:
> 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?

That was what I too suggested :)
 
> Either way it would make sense to latch it when the configuration or
> preconfiguration registers are written, rather than have it switch
> immediately.

But since you can relocate zero page and the stack page independent of
all other switching you don't need to care about "pulling away the
floor you are standing on".

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



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

Reply | Threaded
Open this post in threaded view
|

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

Marko Mäkelä
In reply to this post by smf
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

smf
Reply | Threaded
Open this post in threaded view
|

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

smf
In reply to this post by MiaM
On 07/05/2018 14:42, Mia Magnusson wrote:
> But since you can relocate zero page and the stack page independent of
> all other switching you don't need to care about "pulling away the
> floor you are standing on".

It's not just that, the preconfiguration registers would be kinda broken
if they didn't have their own copy of the extra bits.



Reply | Threaded
Open this post in threaded view
|

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

Jim Brain
On 5/7/2018 12:01 PM, smf wrote:
On 07/05/2018 14:42, Mia Magnusson wrote:
But since you can relocate zero page and the stack page independent of
all other switching you don't need to care about "pulling away the
floor you are standing on".

It's not just that, the preconfiguration registers would be kinda broken if they didn't have their own copy of the extra bits.



How does one get a handle on how the MMU works?  I am looking at:


https://patpend.net/technical/c128/C128io.doc.txt

http://www.oxyron.de/html/registers_mmu.html

https://ia801002.us.archive.org/10/items/Compute_s_Mapping_the_Commodore_128/Compute_s_Mapping_the_Commodore_128.pdf

I see the registers, but I'm not sure I understand the PCR and LCR regs.  Is there a document that explains these?

Jim


-- 
Jim Brain
[hidden email] 
www.jbrain.com
smf
Reply | Threaded
Open this post in threaded view
|

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

smf
I believe....

Writes to PCR registers are the same format as the CR register, you
write to them but mapping doesn't change until...

Writes to LCR register tells it to load from the corresponding PCR
register into the CR register. It's so you can quickly switch between
banks without having to keep calculating the CR register or passing it
around.

So PCRA can be the CR for where code is, PCRB could be the CR for where
the kernal reads/writes from. The kernal then only needs to know to hit
LCRB, perform the access and hit LCRA.

On 07/05/2018 19:31, Jim Brain wrote:

> https://ia801002.us.archive.org/10/items/Compute_s_Mapping_the_Commodore_128/Compute_s_Mapping_the_Commodore_128.pdf 
>
>
> I see the registers, but I'm not sure I understand the PCR and LCR
> regs.  Is there a document that explains these?
>
> Jim
>
>

smf
Reply | Threaded
Open this post in threaded view
|

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

smf
This might be clearer than my rambling
http://www.oxyron.de/html/registers_mmu.html


On 07/05/2018 20:56, smf wrote:

> I believe....
>
> Writes to PCR registers are the same format as the CR register, you
> write to them but mapping doesn't change until...
>
> Writes to LCR register tells it to load from the corresponding PCR
> register into the CR register. It's so you can quickly switch between
> banks without having to keep calculating the CR register or passing it
> around.
>
> So PCRA can be the CR for where code is, PCRB could be the CR for
> where the kernal reads/writes from. The kernal then only needs to know
> to hit LCRB, perform the access and hit LCRA.
>
> On 07/05/2018 19:31, Jim Brain wrote:
>
>> https://ia801002.us.archive.org/10/items/Compute_s_Mapping_the_Commodore_128/Compute_s_Mapping_the_Commodore_128.pdf 
>>
>>
>> I see the registers, but I'm not sure I understand the PCR and LCR
>> regs.  Is there a document that explains these?
>>
>> Jim
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

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

Jim Brain
In reply to this post by smf
On 5/7/2018 2:56 PM, smf wrote:
> I believe....
>
> Writes to PCR registers are the same format as the CR register, you
> write to them but mapping doesn't change until...
>
> Writes to LCR register tells it to load from the corresponding PCR
> register into the CR register. It's so you can quickly switch between
> banks without having to keep calculating the CR register or passing it
> around.
Yep, got it.
>
> So PCRA can be the CR for where code is, PCRB could be the CR for
> where the kernal reads/writes from. The kernal then only needs to know
> to hit LCRB, perform the access and hit LCRA.
I am keenly interested in MMU design, since I am working on one for
another platform.

It looks like, even with the weird address sharing of A&/A6 and A5/A4,
there are 3 additional 16 byte windows in $d5xx that could be used to
extend the system.

I'd favor an approach like the TANDY Color computer, that splits the
64kB into "pages" that can reside in 512kB of memory.  IN the Coco MMU,
the system uses 8 6-bit values to denote the "bank" value for each 8kB
slice of main memory, and then they offer a "task" register that can
quickly flip between a complete set of mappings.

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.

Jim




Reply | Threaded
Open this post in threaded view
|

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

André Fachat


Am 8. Mai 2018 02:20:11 schrieb Jim Brain <[hidden email]>:

>
> I am keenly interested in MMU design, since I am working on one for
> another platform.
>

FYI, here http://www.6502.org/users/andre/hwinfo/ls610/index.html I built a
replacement for the 74ls610 MMU using cache RAM, where most address lines
are kept zero.

I use the ls610 in my system to map 16 pages of 4k from a 1MB physical
address space. But external logic is used to have the MMU (all IO)  
available in all mappings, and to have a defined state at reset. Also the
upper 4 bits of the MMU are used as write protect, valid and NoExecute
bits. Still 4 data bits of one of the cache RAMs are unused and could be
used as additional address lines.

Using a task register for more of the address bits would indeed allow
quickly switching between mappings. But extra logic should probably be
included for shared memory windows on top or for IO to avoid trampoline
code etc. But IO could also be protected from some mappings for
"unprivileged" programs.

Regards
André



smf
Reply | Threaded
Open this post in threaded view
|

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

smf
In reply to this post by Jim Brain
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.



Reply | Threaded
Open this post in threaded view
|

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

MiaM
Den Tue, 8 May 2018 08:59:57 +0000 skrev smf <[hidden email]>:

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

smf
Reply | Threaded
Open this post in threaded view
|

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

smf

On 08/05/2018 09:25, Mia Magnusson wrote:
>
> There are two "threads" here.

yes

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

The reason I suggested using two unused bits and latching them when the
preconfiguration or configuration registers were written, is that it
becomes easy to use the extra memory from basic.

This was the problem with the "PIA" method for 512k/1024mb, but with
latching you can POKE the bits into the register and then configure the
BANK.

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

It's fine to make it incompatible when you're running software that uses
the extra functionality but I don't see the point in creating an MMU
that is always incompatible, because then it's no longer a C128.

If you're going to create a 1MB computer that isn't compatible with C128
software, then I think it's possible to come up with one that is much
better :D



Reply | Threaded
Open this post in threaded view
|

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

Jim Brain
In reply to this post by MiaM
On 5/8/2018 3:25 AM, Mia Magnusson wrote:

> Den Tue, 8 May 2018 08:59:57 +0000 skrev smf <[hidden email]>:
>> 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



Reply | Threaded
Open this post in threaded view
|

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

Jim Brain
In reply to this post by André Fachat
On 5/8/2018 12:23 AM, And Fachat wrote:

>
>
> Am 8. Mai 2018 02:20:11 schrieb Jim Brain <[hidden email]>:
>
>>
>> I am keenly interested in MMU design, since I am working on one for
>> another platform.
>>
>
> FYI, here http://www.6502.org/users/andre/hwinfo/ls610/index.html I
> built a replacement for the 74ls610 MMU using cache RAM, where most
> address lines are kept zero.
I referenced your design as I worked on some designs, so a belated thanks.
>
> I use the ls610 in my system to map 16 pages of 4k from a 1MB physical
> address space. But external logic is used to have the MMU (all IO)  
> available in all mappings, and to have a defined state at reset. Also
> the upper 4 bits of the MMU are used as write protect, valid and
> NoExecute bits. Still 4 data bits of one of the cache RAMs are unused
> and could be used as additional address lines.
I decided to implement my MMU in a CPLD with a fast SRAM for the
"mapping" registers, and extended it to 16 bits, using the top 3 bits as
you do.
>
> Using a task register for more of the address bits would indeed allow
> quickly switching between mappings. But extra logic should probably be
> included for shared memory windows on top or for IO to avoid
> trampoline code etc. But IO could also be protected from some mappings
> for "unprivileged" programs.
The CPLD provides that capability easily.

The current features are:

5 bit task register (32 main tasks)
8 16 bit values per task (8kB mapping granularity, >2MB address space
capable)
optional common RAM area
7 bits of "secondary task" capability (multiple mappings per task, etc.).

Jim


>
> Regards
> André
>
>
>

--
Jim Brain
[hidden email]
www.jbrain.com


Reply | Threaded
Open this post in threaded view
|

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

Chriz
Am 08.05.2018 um 19:58 schrieb Jim Brain <[hidden email]>:

On 5/8/2018 12:23 AM, And Fachat wrote:


Am 8. Mai 2018 02:20:11 schrieb Jim Brain <[hidden email]>:


I am keenly interested in MMU design, since I am working on one for
another platform.


FYI, here http://www.6502.org/users/andre/hwinfo/ls610/index.html I built a replacement for the 74ls610 MMU using cache RAM, where most address lines are kept zero.
I referenced your design as I worked on some designs, so a belated thanks.

I use the ls610 in my system to map 16 pages of 4k from a 1MB physical address space. But external logic is used to have the MMU (all IO)   available in all mappings, and to have a defined state at reset. Also the upper 4 bits of the MMU are used as write protect, valid and NoExecute bits. Still 4 data bits of one of the cache RAMs are unused and could be used as additional address lines.
I decided to implement my MMU in a CPLD with a fast SRAM for the "mapping" registers, and extended it to 16 bits, using the top 3 bits as you do.

Using a task register for more of the address bits would indeed allow quickly switching between mappings. But extra logic should probably be included for shared memory windows on top or for IO to avoid trampoline code etc. But IO could also be protected from some mappings for "unprivileged" programs.
The CPLD provides that capability easily.

The current features are:

5 bit task register (32 main tasks)
8 16 bit values per task (8kB mapping granularity, >2MB address space capable)
optional common RAM area
7 bits of "secondary task" capability (multiple mappings per task, etc.).


I would like to add another aspect you might consider:

If your MMU design allows the Z80 processor to see memory mappings similar to the ones which are possible in CPC 6128 or MSX computers, there's a good chance for Jörn Mika's magnificent SymbOS getting ported to the C128!
(Until now the C128 memory organisation has been the "show stopper".)

Regards,
Chriz

Reply | Threaded
Open this post in threaded view
|

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

Jim Brain
On 5/8/2018 2:36 PM, Chriz wrote:
>
> I would like to add another aspect you might consider:
>
> If your MMU design allows the Z80 processor to see memory mappings
> similar to the ones which are possible in CPC 6128 or MSX computers,
> there's a good chance for Jörn Mika's magnificent SymbOS getting
> ported to the C128!
> (Until now the C128 memory organisation has been the "show stopper".)
Is there a document that is easily perusable that shows the organization
needed?

Jim


Reply | Threaded
Open this post in threaded view
|

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

David Wood-2
As I remember the MSX memory mapper is fairly simple-  It maps 16k blocks of CPU space to any area of physical memory.  Basically cocomem jr with a 16k page rather than 2k ;-)

https://www.msx.org/wiki/Memory_Mapper

On Tue, May 8, 2018 at 7:04 PM, Jim Brain <[hidden email]> wrote:
On 5/8/2018 2:36 PM, Chriz wrote:

I would like to add another aspect you might consider:

If your MMU design allows the Z80 processor to see memory mappings similar to the ones which are possible in CPC 6128 or MSX computers, there's a good chance for Jörn Mika's magnificent SymbOS getting ported to the C128!
(Until now the C128 memory organisation has been the "show stopper".)
Is there a document that is easily perusable that shows the organization needed?

Jim



Reply | Threaded
Open this post in threaded view
|

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

Chriz
The CPC memory mapping also seems to use 16k blocks, although a bit more restricted regarding "configurations":


Am 09.05.2018 um 03:13 schrieb David Wood <[hidden email]>:

As I remember the MSX memory mapper is fairly simple-  It maps 16k blocks of CPU space to any area of physical memory.  Basically cocomem jr with a 16k page rather than 2k ;-)

https://www.msx.org/wiki/Memory_Mapper

On Tue, May 8, 2018 at 7:04 PM, Jim Brain <[hidden email]> wrote:
On 5/8/2018 2:36 PM, Chriz wrote:

I would like to add another aspect you might consider:

If your MMU design allows the Z80 processor to see memory mappings similar to the ones which are possible in CPC 6128 or MSX computers, there's a good chance for Jörn Mika's magnificent SymbOS getting ported to the C128!
(Until now the C128 memory organisation has been the "show stopper".)
Is there a document that is easily perusable that shows the organization needed?

Jim



12