Just a note, if anyone is interested, to note an MMU project I am working on.

I've long lamented the lack of true expanded memory options for my 64, and the lack of relocatable stack and zp. After a bit of time playing with the MMU system in the TANDY Color Computer 3 and a need to replace some DRAMs in a broken 64 here, I decided to port over some of my MMU functionality and create an SRAM-based 2MB memory expansion unit for the 64. Of course, the unit can be used by any CPU/machine, but the layout is currently designed for units with 2 4464-based DRAMs. Still, I'd be happy to design a 32pin SRAM-based PCB if folks wanted to try this out.

Concerning functionality, the unit currently contains:

• 2MB of 55nS SRAM, plenty fast for the 1MHz machines
• 64kW of MMU register RAM
• relocatable register set. Initially invisible to the system, it can be enabled by reading specific locations at $c0xx
• 4kB page size
• 13 bit page address (32MB total address space, though only 2MB usable in current implementation)
• 256 MMU mapping sets can be used at one time, switchable via one register

Running out of room in the CPLD, so will probably move to the next size up, but plans include:

[list=]
[*]Interrupt on access support
[*]R/O memory support
[*]Add in a small ROM
[*]Within a range, shift addressing by 1-1024 bytes
[*]Common 256/512/1024/2048 byte page
[/list]

Repo is at: https://github.com/go4retro/Ultimem64

Unit is working and seems to be passing all tests... Interested in ideas that might make sense to add.

Jim

Github has become a royal pain of late. I can no longer open anything, and keep getting messages saying my browser is not supported.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

What browser are you using? I would assume that most reasonably recent browsers would work without complaints.

Thanks for sharing Jim! It would be great if you could stick a license on it: CC0 if you really don't care too much, BSD if you want to retain attribution. There are other choices too: we have a thread about it, which is a good place to discuss the pros and cons. I wouldn't want to derail this thread!
viewtopic.php?f=1&t=3090

I just completed a 6502MMU like this. It only reads the address and databus and decides what is going on in the 6502 based on that. Making it took some effort since you have to handle alot of different situations. One problem was multiple interrupt instances which can be triggered after each other...

I chose to use NOP opcodes that passes an address as the bank, so an interrupt between that opcode and the target opcode meant that you have to store the bank number and change it back again afterwards. And for JSR you really want a stack of bank numbers to handle jumps to different memory locations with correct return points.

But I guess it depends on how complex you want to make it. I am also planning to separate data and code, and eventually include memory protection. But my MMU is part of a larger unit which handles other things as well.

What kind of CPLD will you be using?

Seamonkey. which is built around the Firefox browsing engine.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I am currently using a xc95144xl for the implementation.

It's testing at present in my C64C sitting here...

Ahh. Thats a nice one. 5.5V tolerant and up to 3.6V output. Never thought of that. My expansion board has level converters, but it contains a lot of different things. I don't think its 5V tolerant either.

It will be interesting to see how you implement the MMU and solve it. The 6502 generally lacks MMU implementations, and there should be no reason for it!

Currently, the MMU divides the 64 space into 16 4kB "pages". The mappings are 16 bits in length, though the top 2 bits are reserved for write protection and IRQ trigger enable. Thus, the 12 bits are added to the 14 bits for 26 bits of addressing, or 64MB address space.

The registers are:
XX00:bit 0 is enable/disable
XX01 is 8 bit "mapping set" to show in the mapping window.
XX02 is the 8 bit "mapping set in use"
XX10 is the low bytes of the 16 mappings
XX20 is the high byte.

The system supports 256 mapping sets. A mapping set is a set of 16 mappings that completely map the entire 64kB into the 64MB address space. You can think of a mapping set as a fully populated TLB (in x86 speak), and that the system supports 256 TLBs.

You can map the same area of the physical memory into more than 1 mapping set, and in different places in each mapping set.

XX above is because you get to pick where the registers live. The sequence 55,aa,ff,00,xx is used to unhide and hide the registers (xx=00 hides the registers)

I will be adding a few things:

XXeY will be "quick mapping sets. Poke to xxe1, and mapping set #1 will be selected, much like the C128 PCRs Only the first 16 sets can be used this way.
I will set aside a 256 byte "common page" that can be overlaid on all maps. This can be used for OS functions, long branches, etc.

It works fine at present, but does need some cool demos to show it off. The current unit has 2MB installed, but I think 16MB is my target for production.

Jim