MMU prototyping

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

MMU prototyping

Jim Brain
It's a bit tough for me to prototype things on the B series, but I have been playing around with MMU functionality on the C64.

First, for those who have helped me understand the Ultimax mode, I owe many thanks.  For the longest time, that mode just completely baffled me. I am still not sure I completely understand it, but I have been able to tame it, at least a bit.

Secondly, perhaps this is heresy, but I particularly like the MMU in the Color Computer 3, so I am working to replicate it on the C64

I also like the LCR/PCR functionality of the C128 MMU, so I am also borrowing that as well.

I started by implementing the much maligned GeoRAM system in the CPLD, which was trivial.  So, I have HDL for GeoRAM now.

I then decided to implement an Ultimax memory expansion system:
  • In this mode, the memory map is split into 4kB pages
  • Each page except for 0 and D can be directly mapped to external RAM
  • To map a C64 page to external RAM, simply store the mapped page number into the slot for that page.
    • For example, to map $c000-$cfff to the 4th 4kB RAM block in external RAM, store a 3 into MMU slot 12
    • Any slot with 0 will map to internal RAM
  • The system supports 256 sets of mappings.  Change the mapping by storing a new value in the "task" register

The Ultimax mode was actually pretty simple to add, but it took a while to sort out a few bugs with the multiplexed memory address/data bus.  Still, it looks to be working at this point.  I am only pushing CPU access to external RAM, but I think I can do the same for VIC-II access. 

I did also use one of those clock multiplier PLLs I've had sitting in the parts box for a long time, to multiple the dot clock by 8 in order to see how well those work.

The system contains 2 types of RAM:

  • 512kB SRAM
  • 32kB SRAM

The second SRAM holds the mmu mappings, since the CPLD is not large enough to hold them.  The 32kB SRAM is a 15nS part, so I multiplex the memory address bus:

  • As phi2 goes high, I start counting fast clock cycles (~64MHz, or 15ns per clock cycle)
  • at count 2 and 3, I turn on 32kB SRAM and read mapping, using address: {task:address_cpu[15:12]}
  • at count 4, I acquiesce the memory bus for 15ns
  • at count 5+, I select either the 32kB SRAM (MMU mapping read or write) or the 512kB SRAM (regular memory access)

Left to add:

  • Add support for 16 LCR locations, mapping to the first 16 tasks.
  • Fix clock signal to use EasyFlash/EasyFlash3/Swiftlink clock circuitry
  • clean up memory usage (for registers)
  • See about possibly supporting VIC access.

Ideas always appreciated.  Obviously, this new mode is compatible with nothing, but it's far faster than either GeoRAM and REU.  There's probably not room to add REU support as well, but I am going to try my hand at a standalone HDL REC implementation elsewhere.

Jim

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

Re: MMU prototyping

Michał Pleban
Hello!

Just out of curiosity, does it work on the actual Ultimax too? And if
yes, where does the 2 kB of RAM at $0800 come from in this configuration?

Regards,
Michau.


Jim Brain wrote:

> It's a bit tough for me to prototype things on the B series, but I have
> been playing around with MMU functionality on the C64.
>
> First, for those who have helped me understand the Ultimax mode, I owe
> many thanks.  For the longest time, that mode just completely baffled
> me. I am still not sure I completely understand it, but I have been able
> to tame it, at least a bit.
>
> Secondly, perhaps this is heresy, but I particularly like the MMU in the
> Color Computer 3, so I am working to replicate it on the C64
>
> I also like the LCR/PCR functionality of the C128 MMU, so I am also
> borrowing that as well.
>
> I started by implementing the much maligned GeoRAM system in the CPLD,
> which was trivial.  So, I have HDL for GeoRAM now.
>
> I then decided to implement an Ultimax memory expansion system:
>
>   * In this mode, the memory map is split into 4kB pages
>   * Each page except for 0 and D can be directly mapped to external RAM
>   * To map a C64 page to external RAM, simply store the mapped page
>     number into the slot for that page.
>       o For example, to map $c000-$cfff to the 4th 4kB RAM block in
>         external RAM, store a 3 into MMU slot 12
>       o Any slot with 0 will map to internal RAM
>   * The system supports 256 sets of mappings.  Change the mapping by
>     storing a new value in the "task" register
>
> The Ultimax mode was actually pretty simple to add, but it took a while
> to sort out a few bugs with the multiplexed memory address/data bus.
> Still, it looks to be working at this point.  I am only pushing CPU
> access to external RAM, but I think I can do the same for VIC-II access.
>
> I did also use one of those clock multiplier PLLs I've had sitting in
> the parts box for a long time, to multiple the dot clock by 8 in order
> to see how well those work.
>
> The system contains 2 types of RAM:
>
>   * 512kB SRAM
>   * 32kB SRAM
>
> The second SRAM holds the mmu mappings, since the CPLD is not large
> enough to hold them.  The 32kB SRAM is a 15nS part, so I multiplex the
> memory address bus:
>
>   * As phi2 goes high, I start counting fast clock cycles (~64MHz, or
>     15ns per clock cycle)
>   * at count 2 and 3, I turn on 32kB SRAM and read mapping, using
>     address: {task:address_cpu[15:12]}
>   * at count 4, I acquiesce the memory bus for 15ns
>   * at count 5+, I select either the 32kB SRAM (MMU mapping read or
>     write) or the 512kB SRAM (regular memory access)
>
> Left to add:
>
>   * Add support for 16 LCR locations, mapping to the first 16 tasks.
>   * Fix clock signal to use EasyFlash/EasyFlash3/Swiftlink clock circuitry
>   * clean up memory usage (for registers)
>   * See about possibly supporting VIC access.
>
> Ideas always appreciated.  Obviously, this new mode is compatible with
> nothing, but it's far faster than either GeoRAM and REU.  There's
> probably not room to add REU support as well, but I am going to try my
> hand at a standalone HDL REC implementation elsewhere.
>
> Jim
>
> --
> Jim Brain
> [hidden email]
> www.jbrain.com
>


Reply | Threaded
Open this post in threaded view
|

Re: MMU prototyping

Jim Brain
On 5/21/2018 6:07 AM, Michał Pleban wrote:
> Hello!
>
> Just out of curiosity, does it work on the actual Ultimax too?
I highly doubt it :-)  I am sure it could be made to work, as it's just
a CPLD...
> And if
> yes, where does the 2 kB of RAM at $0800 come from in this configuration?
You'd have to know you are running on an Ultimax and then allow the
mapping for that 2kB.  Right now, I exclude mapping the entire 4k from
0-0fff.

Jim


Reply | Threaded
Open this post in threaded view
|

Re: MMU prototyping

MiaM
Den Mon, 21 May 2018 12:45:51 -0500 skrev Jim Brain <[hidden email]>:

> On 5/21/2018 6:07 AM, Michał Pleban wrote:
> > Hello!
> >
> > Just out of curiosity, does it work on the actual Ultimax too?
> I highly doubt it :-)  I am sure it could be made to work, as it's
> just a CPLD...
> > And if
> > yes, where does the 2 kB of RAM at $0800 come from in this
> > configuration?
> You'd have to know you are running on an Ultimax and then allow the
> mapping for that 2kB.  Right now, I exclude mapping the entire 4k
> from 0-0fff.

IIRC if you hook up I/O2 you can use that to adress the 2k. If on an
UltiMAX the 2k would end up in the right place. If on a C64 parts of it
will end up in unused I/O space.

--
(\_/) 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: MMU prototyping

Jim Brain
On 5/21/2018 3:14 PM, Mia Magnusson wrote:
> IIRC if you hook up I/O2 you can use that to adress the 2k. If on an
> UltiMAX the 2k would end up in the right place. If on a C64 parts of it
> will end up in unused I/O space.
Doing so would mean moving the registers around a lot, since the GeoRAM
uses IO2 for it's registers, and IO1 for RAM.

Thus, it seems more work than value for a C64 cart (one can argue the
same for every cart that leverages Ultimax mode, and almost none would
work on an Ultimax).

However, a standalone cart design could easily flip the lines and happy
work.

Jim
>

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


smf
Reply | Threaded
Open this post in threaded view
|

Re: MMU prototyping

smf
On 22/05/2018 04:57, Jim Brain wrote:
> Doing so would mean moving the registers around a lot, since the
> GeoRAM uses IO2 for it's registers, and IO1 for RAM.
>
> Thus, it seems more work than value for a C64 cart (one can argue the
> same for every cart that leverages Ultimax mode, and almost none would
> work on an Ultimax).
>
> However, a standalone cart design could easily flip the lines and
> happy work.

For ultimax you'd want to put georam registers in the correct place by
decoding the address lines, instead of using IO2.

You could probably add a jumper to the cpld and tweak the logic a bit,
but I assume you don't have an ultimax to test on anyway.

A cartridge that adds c64 compatibility to the ultimax (with a passthru)
would be awesome, but I also think it might be impossible :D


Reply | Threaded
Open this post in threaded view
|

Re: MMU prototyping

Michał Pleban
Hello!

smf wrote:

> A cartridge that adds c64 compatibility to the ultimax (with a passthru)
> would be awesome, but I also think it might be impossible :D

I don't think it should be so hard. You will have to do most of the
memory decoding yourself, but a CPLD should be able to handle it.
Otherwise it's just a matter of adding another CIA, 62 kB of memory and
some clever way to capture writes to the I/O port in order to change the
memory layout.

Regards,
Michau.



Reply | Threaded
Open this post in threaded view
|

Re: MMU prototyping

MiaM
Den Tue, 22 May 2018 13:20:44 +0200 skrev Michał Pleban
<[hidden email]>:

> Hello!
>
> smf wrote:
>
> > A cartridge that adds c64 compatibility to the ultimax (with a
> > passthru) would be awesome, but I also think it might be
> > impossible :D
>
> I don't think it should be so hard. You will have to do most of the
> memory decoding yourself, but a CPLD should be able to handle it.
> Otherwise it's just a matter of adding another CIA, 62 kB of memory
> and some clever way to capture writes to the I/O port in order to
> change the memory layout.

Is it possible to map out the internal I/O decode (and char rom?) on an
UltiMAX?

Otherwise it would probably work with most but not all software.

--
(\_/) 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: MMU prototyping

smf
In reply to this post by Michał Pleban
On 22/05/2018 12:20, Michał Pleban wrote:
> Otherwise it's just a matter of adding another CIA, 62 kB of memory and
> some clever way to capture writes to the I/O port in order to change the
> memory layout.

You'd need kernel, basic and char roms.

I don't believe the  6510 drives the data bus on i/o writes.

VIC banking might be tricky, because the on board ram will probably be
selected in all banks & I don't think you can override it.



Reply | Threaded
Open this post in threaded view
|

Re: MMU prototyping

Michał Pleban
Hello!

smf wrote:

> You'd need kernel, basic and char roms.

Right, but one large EPROM will solve this easily.

> I don't believe the  6510 drives the data bus on i/o writes.

Doesn't it? We have recently determined that the 6509 drives it. I have
no idea about the 6510, but I would expect it to be the same.

> VIC banking might be tricky, because the on board ram will probably be
> selected in all banks & I don't think you can override it.

This can be a problem indeed. I would have to study the schematic more
thoroughly.

Regards,
Michau.

Reply | Threaded
Open this post in threaded view
|

Re: MMU prototyping

Michał Pleban
In reply to this post by MiaM
Hello!

Mia Magnusson wrote:

> Is it possible to map out the internal I/O decode (and char rom?) on an
> UltiMAX?

The $DC00-$DFFF decode signal is on the expansion port in the Ultimax.
For the char ROM, we would have to do the decoding ourselves but I don't
see it being a big problem.

Regards,
Michau.

smf
Reply | Threaded
Open this post in threaded view
|

Re: MMU prototyping

smf
In reply to this post by Michał Pleban
On 22/05/2018 13:29, Michał Pleban wrote:
Doesn't it? We have recently determined that the 6509 drives it. I have
no idea about the 6510, but I would expect it to be the same.

I don't personally know, just repeating what I read.

groepaz
Posted: Fri Apr 24, 2015 8:31 pm    Post subject:
when writing, the address will appear on the bus, however the data will go to the cpu port register. still the cpu will enable write on the bus, and the last value that appeared on the databus before will get written to ram. see here:

https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/general/ram0001/


I thought the 6509 was the same, which was that it didn't drive the data bus either &  Jim had decided to reproduce this on his newer 6509 replacement board.


Reply | Threaded
Open this post in threaded view
|

Re: MMU prototyping

Michał Pleban
Hello!

smf wrote:

> and the last value that appeared on the databus before will get written
> to ram. see here:

Oh you are right, I got confused here. It's the last value on the bus
that is written to the RAM, not the I/O value.

So it's a problem, and I think it can't be overcome - the relevant pins
of the CPU are not connected anywhere, except the P0 pin which goes to
the expansion port. But this single pin will not be enough.

OK, it was a good idea while it lasted :-)

Regards,
Michau.




> *
>
> https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/general/ram0001/
>
>
> I thought the 6509 was the same, which was that it didn't drive the data
> bus either &  Jim had decided to reproduce this on his newer 6509
> replacement board.
>
>


smf
Reply | Threaded
Open this post in threaded view
|

Re: MMU prototyping

smf
On 22/05/2018 14:04, Michał Pleban wrote:
> So it's a problem, and I think it can't be overcome - the relevant pins
> of the CPU are not connected anywhere, except the P0 pin which goes to
> the expansion port. But this single pin will not be enough.
>
> OK, it was a good idea while it lasted :-)
A board that goes in the cpu slot might do it, but how many ultimax are
there anyway?

Reply | Threaded
Open this post in threaded view
|

Re: MMU prototyping

nejat76
In reply to this post by Jim Brain
Nice project!

Does this also use hacks around the PLA like EasyFlash?

Why not use pages of 8 / 16Ks too?

I had once a simpler ram extension idea employing the same concept in
below old project which was published in the Transactor. (But of
course with a bigger 512K or 1MB sram)

http://ar.c64.org/rrwiki/images/5/57/The_Transactor_Vol07_04_1987_Jan_A_C64_Cartridge_without_Eproms.pdf

Sure this solution throws away the existing ram but it's easy to bank
in a whole 8k or 16k segment at once.

It would be nifty to have some external storage mechanism in the cart
too. It would be really cumbersome to load content into this
additional ram from the disk drive.

Regards,

Nejat

Reply | Threaded
Open this post in threaded view
|

Re: MMU prototyping

Jim Brain
On 5/22/2018 4:07 PM, Nejat Dilek wrote:
> Nice project!
>
> Does this also use hacks around the PLA like EasyFlash?
I guess it depends on what one defines as a "hack".  This unit simply
engages the GAME line anytime a memory access that should be outside the
C64 is requested.  I think that is standard behavior.

>
> Why not use pages of 8 / 16Ks too?
As I looked at the Ultimax map, all pages except for 0-fff and d000-dfff
were movable.  Doing 8kB means one needs to map in a bank, but can't use
all of it.  It seemed cleaner to map on 4kB boundaries.  One can handle
8 or 16kB by simply using 2 or 4 consecutive banks.
>
> I had once a simpler ram extension idea employing the same concept in
> below old project which was published in the Transactor. (But of
> course with a bigger 512K or 1MB sram)
Well, my solution uses a 512kB RAM, and will support up to 256MB.
>
>
>
> It would be nifty to have some external storage mechanism in the cart
> too. It would be really cumbersome to load content into this
> additional ram from the disk drive.
True, and that's a nice thing to consider.  I mainly want to understand
if anyone sees value in the MMU or the memory before I pursue more work
(I built the board for other reasons, but decided to implement this
functionality while I was testing the board asembly).

>
> Regards,
>
> Nejat
>

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


smf
Reply | Threaded
Open this post in threaded view
|

Re: MMU prototyping

smf
On 23/05/2018 00:41, Jim Brain wrote:

> I guess it depends on what one defines as a "hack".  This unit simply
> engages the GAME line anytime a memory access that should be outside
> the C64 is requested.  I think that is standard behavior.

I don't believe you were supposed to change GAME & EXROM dynamically,
although a handful of projects do for better or worse.

When aren't you asserting GAME?



Reply | Threaded
Open this post in threaded view
|

Re: MMU prototyping

MiaM
Den Wed, 23 May 2018 10:55:15 +0100 skrev smf <[hidden email]>:
> On 23/05/2018 00:41, Jim Brain wrote:
>
> > I guess it depends on what one defines as a "hack".  This unit
> > simply engages the GAME line anytime a memory access that should be
> > outside the C64 is requested.  I think that is standard behavior.
>
> I don't believe you were supposed to change GAME & EXROM dynamically,
> although a handful of projects do for better or worse.

Like all freezers and similar cartridges...

The only problem is afaik carts that does this timed on the reset
signal instead of actual accesses to the bus. They fail on the C128.

--
(\_/) 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: MMU prototyping

nejat76
In reply to this post by Jim Brain
On Wed, May 23, 2018 at 2:41 AM, Jim Brain <[hidden email]> wrote:

> On 5/22/2018 4:07 PM, Nejat Dilek wrote:
>>
>> Nice project!
>>
>> Does this also use hacks around the PLA like EasyFlash?
>
> I guess it depends on what one defines as a "hack".  This unit simply
> engages the GAME line anytime a memory access that should be outside the C64
> is requested.  I think that is standard behavior.
>

"Hack" in my sentence was not used in a devaluing context.
Specifically in this context one need a much higher clock speed and/or
rely on specific timing properties. (Like the kernal replacement in
newer easy flash incarnations. )

Not a direct analogy but it's like shifting the gear in a car
continuously between say 2 and 3 because it results in better fuel
consumption. Proper implementation would be to change the gear
mechanism that makes this more natural.

In the same way, a proper (I'm just using this term to explain how I
define the "hack") solution to the problem might be changing the PLA
to a more capable one  instead of fooling it.

Anyway, my actual curiosity was around the technical side actually.
Easyflash employs a much broad "hack" to accomplish it's kernal
replacement goal. So I understand this is much simpler to achieve.
Much less obtrusive "hack" :)


>>
>> Why not use pages of 8 / 16Ks too?
>
> As I looked at the Ultimax map, all pages except for 0-fff and d000-dfff
> were movable.  Doing 8kB means one needs to map in a bank, but can't use all
> of it.  It seemed cleaner to map on 4kB boundaries.  One can handle 8 or
> 16kB by simply using 2 or 4 consecutive banks.
>>

If VIC will readily access the switched ram, it would be imho wiser to
keep the ability of mapping 16k with just a single paging access. It
would be useful for stuff like video playing.


>>
>> I had once a simpler ram extension idea employing the same concept in
>> below old project which was published in the Transactor. (But of
>> course with a bigger 512K or 1MB sram)
>
> Well, my solution uses a 512kB RAM, and will support up to 256MB.

Well static ram is expensive and the large sizes are much more
expensive and not easy to handle coming in bga packages.
The biggest alternative on Mouser is 16Mx8 and it is a 3.6V part, ~€10 a piece.

>>
>> It would be nifty to have some external storage mechanism in the cart
>> too. It would be really cumbersome to load content into this
>> additional ram from the disk drive.
>
> True, and that's a nice thing to consider.  I mainly want to understand if
> anyone sees value in the MMU or the memory before I pursue more work (I
> built the board for other reasons, but decided to implement this
> functionality while I was testing the board asembly).
>
>
> --
> Jim Brain

It's a bit hard to evaluate beforehand. 90% of the crowd cares about
playing with existing stuff, quite lot of people developing stuff in
the remaining 10% mostly prefer the stock hardware.
Unless a specific software/game title unleashes the power of such
hardware the probability of it being mainstream  is very limited.

The price is of course a big determining factor too,

Regards,

Nejat

Reply | Threaded
Open this post in threaded view
|

Re: MMU prototyping

Jim Brain
In reply to this post by smf
On 5/23/2018 4:55 AM, smf wrote:
On 23/05/2018 00:41, Jim Brain wrote:

I guess it depends on what one defines as a "hack".  This unit simply engages the GAME line anytime a memory access that should be outside the C64 is requested.  I think that is standard behavior.

I don't believe you were supposed to change GAME & EXROM dynamically, although a handful of projects do for better or worse.
Ah, then I am a hack, in the grand spirit of hacks :-)

When aren't you asserting GAME?
_game is asserted:

  • PHI2 is HIGH AND
  • Address[15:12] != 0 AND
  • Address[15:12] != D AND
  • the current PAGE!= 0

PAGE is an 8 bit (soon to be 16 bit) value denoting which 4kB page is mapped into the selected page of main system RAM.



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