Hi there!

I started wondering this morning while thinking about how to tackle the operating system for the WDC 65816 project my friends and I are working on about memory protection and management. I'd like to add a MMU unit to the board somewhere, but I'm not sure what is available. The main criteria is inexpensive, but I'll be happy to get any information I can.

The requirements for the MMU, as I see it, are that it must have memory protection and is able to communicate violations somehow with the processor. It also needs to be able to map memory in manageable pages -- I don't want to swap an entire 64k bank if I don't need to. Ideally, I'd like to break the zero page and stack page limits as well -- the MMU should be able to map zp and sp to any page in available memory and have it show up as the 'real' sp and zp addresses. I know the '816 already allows zp and sp to be any page within the first 64k, but I'd want the ability to stick it wherever. I'd like to be able to map a good amount of memory to the 6502...say 16M. For the '816, I think memory protection would be enough...though I can't say that I wouldn't ever find memory above 16M handy to have.

Given all that, any suggestions as to what chips I should be looking at? Has anyone tried this before?

Hmmm..

You could, assuming that it was fast enough, use a small piece of SRAM and a very small number of pieces of discrete logic.

Basicly, attach the top x address lines to the SRAM, use them to generate y address lines and flags which are ORed and ANDed with the R/W and other signal lines and then feed into the ABORT interupt.

I'm not quite sure that I follow the logic behind what you've suggested here...could you explain a little? Sorry, I'm kinda learning about how digitial electronics works as I build the computer here.

Thanks!

Hallo ccureau,


> I'd like to add a MMU unit .....

I used the 74LS612 in some of my older projects. Please see:
http://home.hccnet.nl/g.baltissen/74ls612.htm
But it is only a Memory Manager, no fancy things like protection etc. Another problem is its availability; the only ones I have I got by scrapping old PC-AT boards.

So I did what Wirehead sugested: I designed my own one using a SRAM. The functionalty is the same or better as that of the 612. You can find it back in the top left corner of:
http://home.hccnet.nl/g.baltissen/pccard2.gif

FYI: I never built it, so no guarantee that it works.

About memory protection, violation etc., IMHO you can only get that using FPGA or equivalent. But I hope I'm wrong.

_________________

to add extra memory, I have been toying with simply setting aside a 16K RAM block in the memory map, and using a single location with a 74LS374 to tell which page is being addressed within that block.

_________________
"My biggest dream in life? Building black plywood Habitrails"

Hallo Nightmaretony,


> to add extra memory, I have been toying with simply setting aside
> a 16K RAM block in the memory map, and using a single location with
> a 74LS374 to tell which page is being addressed within that block.

This brought up something in my mind that is worth some discussion or good thoughts:
I once made an 8-bits ISA-interface for my C64. In the beginning I was a bit annouyed I only had 512 bytes to my disposale to realise my idea: 256 bytes as the common memory area and 4 registers somewhere in the other 256 bytes. 12 bits were used for setting the addresslines A8..A19 and one bit for setting I/O or memory operation.

Then I thought: When doing a copy within a system, a person normally will use a routine that looks like:
LDA (zp1),Y
STA (zp2),Y
INY
BNE ...

Having copied 256 bytes one needs to update the ZP-addresse to beable to copy the next part. But there is not much difference in updating a 2-bytes ZP-address or a 3-bytes register: one byte to be precise. Loss in time: less then 1%.

So IMHO using more free address space for this purpose is a waist. But if one wants to do it, that is OK for me.
Using memory that already is in use, is dangerous IMHO. Take my C64 as example. I could use $4000-$7FFF as swapping area. Now I have a program running that ask for some data to be transferred from the RAM-disk to, let's say $6000. Because I cannot directly store it at $6000, I need to reserve some memeory elsewhere in the system that serves as a buffer. But where can I find that ????
FYI: I know some programs that use ALL the RAM of my C64 and therefore I have nothing left to be used as buffer.

My statement: if one needs paging for accessing memory outside the normal 64 KB area, 256+x free bytes is enough [*].

I would like to hear if there is a flaw in this idea. Thank you!

[*] Remark: using the well know area $DE00-$DFFF means one can not insert cartridgea anymore. That's why I modified my system a bit by using the mirrored areas of the video- and soundchip.

_________________

> I don't want to swap an entire 64k bank if I don't need to.

The '816 does not require you to. The MVN and MVP move instructions allow you to move any quantity of memory up to a 64K bank all at once. (These move instructions are interruptable too. If there's an interrupt, it can be serviced, and then the movement will continue on after the interrupt service is finished.)


> Ideally, I'd like to break the zero page and stack page limits as well --
> the MMU should be able to map zp and sp to any page in available
> memory and have it show up as the 'real' sp and zp addresses. I know
> the '816 already allows zp and sp to be any page within the first 64k,
> but I'd want the ability to stick it wherever.

The '816 allows the direct page (like 6502's ZP) to be any contiguous 256-byte range anywhere in the first 64K. It does not have to start on a page boundary. The '816 also has a 16-bit stack pointer, so your stack area can be anywhere in the first 64K and also is not limited to 256 bytes.

I've had a few thoughts about this.



ROM is cheap.

So you could have dedicated routines that you swap in that copy to or
from specific blocks, ie a routine dedicated to moving data to a specific
block and a routine dedicated to moving data from a specific block.
And a to/from set for each combination of blocks. (though I'd expect
in practice you'd just map the expansion to a specific block and have all
the routines copy to or from that one)
Presumably you'd want to keep the data block aligned or something.
I suppose, in principle, you could have dedicated routines for
any possible move, but ROM's not that cheap

You might have different routines that copied from the bottom up and
the top down and jump into the middle to copy just part of a block.

Being dedicated routines, they could be optimized for speed (absolute
addressing, unrolled loops).

It would depend on exactly how it was done of course, but for blocks
bigger than, say, 8 bytes, I don't think the overhead would be all that
much. That is to say, I think you'd want to move at least 8 bytes
per block/move routine, but I don't think you'd save much in over head
by using 32 byte blocks instead of 16 byte blocks and of course the
smaller the block the smaller the routine in this scheme, and the smaller
the window you'd need to map the routines to.



If I read the C64 memory map correctly, you ought to be able to map to
anywhere in the address space except for IO and the bottom 4k using
ultimax mode.


My thought is to build a mapper using fast SRAM (junk cache chips)
If you mapped by 256 byte pages then 32k chips could hold 128 maps.
The idea would be to set up the maps and then do context switches by
switching amongst maps.

Unused pages in a map could contain a pattern that caused an IRQ

If you're talking about adding an MMU so you can run an OS, think you're missing something.

The 6502 doesn't have restartable instructions. This makes it very difficult to implement an MMU.

Consider the case where the 6502 accesses a page which isn't mapped in. If you issue an NMI, it will be accepted at the beginning of the next instruction, not during the current instruction. So the wrong value will already have been loaded into the register, and you will have to attempt to disassemble the last instruction to re-execute it.

The disassembly won't work because the last instruction could have been a three byte instruction (such as LDA abs or LDA abs,x or LDA abs,y or LDX abs,y or LDY abs,x) or a two byte instruction (such as LDA (zp,x) or LDA (zp,y)). If the last three bytes are a valid three byte instruction AND the last two bytes are also a valid two byte instruction, then you don't know which interpretation is correct.

For example, the three byte sequence 65 B1 85 is LDA $85b1 but B1 85 is also LDA ($85),Y ... so the last instruction which was executed cannot be determined.

The original 68000 had this problem as well. There were a few 68000 Unix machines built though such as the Southwest Technical Products 68000 machine, but they had to apply a weird hack - they used TWO 68000s. When a page fault occured, the first 68000 was halted, and the second 68000 would handle the fault and map in the page, and restart the first processor - that's how it was handled.

The 68010 and later have an ABORT pin, and this forces the processor to dump the state of the instruction pipeline onto the stack so it can be restarted later. Note that this requires fairly intimate knowledge of the processor internals, as it requires various bits to be set/reset to force the processor to restart the instruction after the exception is handled and the processor state is reloaded.

I thought about how to add an MMU to the 65816 once, and if I remember correctly, it has a bug which will prevent it from working properly. It's been a while, but I seem to remember that ABORT is not handled properly on an instruction fetch, which would preclude the usage of virtually mapped executable pages.

Toshi

Hallo Toshi,

> If you're talking about adding an MMU so you can run an OS, think
> you're missing something.
> The 6502 doesn't have restartable instructions. This makes it very
> difficult to implement an MMU.

The C64, C128, 8x96 and many other Commodores have a MMU onboard. The best example are the 600 and 700 series capable of handling 1 MByte. These last machines have a 6509 onboard but that is a 6502 plus some onboard I/O.

I think you have to review your definition of MMU.

_________________

If you read the first post in this thread, you will see he's talking about an MMU for "memory protection and management".

So my post about MMUs are relevant in that context.

Toshi

He also wrote about adding the MMU for a 65816, which does support restartable instructions.

That being the case, the graphic to the circuit schematic above is a broken link. Is there an up-to-date link?

Thanks.

Rudd has a nice new url

http://www.baltissen.org/pccard2.gif

Hello everyone, I've been lurking here for years, and I'm very interested in this particular subject (sophisticated memory management on the 65816.) So, on the one hand...



... and on the other ...



Is there no consensus as to whether this is possible or not?

Ah, so we were all nodding at Toshi, but he then retracted what he said in another thread.

I think the biggest thing is that nobody's gone crazy enough to actually try it. Since I haven't even achieved the level of the Kestrel-8k, somebody else will probably beat me to it.

OTOH, once you get a functioning system, it shouldn't be that hard to try things out. Really, you can have a one-entry TLB cache (a comparator and a latch with the comparator out wired to the output enable on a second latch and then inverted and wired to the ABORT pin) and do everything else in software. To do storage protection, you hang a few gates off of the top bit of the second latch. So that's 1-2 74xx688s, 2-6 74xx573s, and maybe a 74xx00 for good measure.