MMU cartridge

[sorchard]

This is a continuation of ideas raised in this thread:

viewtopic.php?f=6&p=12786#p12786

It concerns the interesting possibility of creating a low cost cartridge containing extra memory plus a memory management unit (MMU)

@Tormod

I agree, it makes sense to design for the D32 as this should also be compatible with the D64.

Your solution for detecting vector fetch is nice and simple. Just in case there is some peculiar instruction sequence that can upset things I came up with a longer trigger sequence that has the advantage of not requiring the vectors point to any particular address:

1. xxxx (Any address)
2. xxxx-1
3. xxxx-2
4. ffff (One or more nVMA cycles)
5. fffx
6. fffx+1
7. ffff

This should be triggered by IRQ, FIRQ, NMI & SWI plus handle CWAI.

Steps 1-3 detect the final three stacking cycles. Step 4 can take more than 1 cycle during CWAI.

I searched for a while and couldn't find any examples of other people trying this technique, so I guess we have a chance of being the first to find out the hard way

[sorchard]

I was wondering what kinds of MMU could be squeezed into various sizes of CPLD and came up with the following rough estimates:

1) XC9572XL

Single task with 8 x 6 bit page registers addressing up to 512KB


2) XC95144XL

As above but with two tasks


3) XC95288XL

Two tasks each with 8 x 8 bit page registers addressing up to 2MB
This would be like the COCO3 MMU

[munkeyboy]

I am unable to add anything to this project myself as it is way over my limited ability, but, are you aware of the MC6829 MMU that Motorola produced to accompany the 6800 and 6809?
My apologies if this is barking up the wrong tree, but I am enjoying the road of discovery that is happening on this forum and the inventive solutions that you guys are coming up with for the old beast we all seem to have a soft-spot for.

All the best, Gareth

[sorchard]

@Gareth
Actually, it's good to know there are people who are interested in this kind of stuff.

You're certainly barking up the right tree. It so happens that I had a scan through the MC6829 datasheet & app notes yesterday to see what it said about switching back from the system to the user task.

I'm sure Tormod's busy trying out some ideas on his memory expansion board as we speak

[tormod]

I also looked through the 6829 datasheet just some weeks ago. It is very instructive, in particular on the system/user task switching. However I would be more tempted to build up something that is more compatible to the CoCo3 and hence easier to support on Level 2. Also the availability of the 6829 is a risk, I would prefer common components that are easier to get. I have full respect for those who enjoy building exclusively with components from "back then" though.

Also on the reading list is Bob Hall's articles posted by Ken here: http://article.gmane.org/gmane.comp.har ... coco/83497

WRT to the CPLD capacity (interesting analysis, thanks) I had in mind using SRAM for the memory maps, connected to the data bus via a latch. Then the CPLD can remain quite simple. But routing and fabrication would be more complex.

Until now, I have been more busy trying to make an enclosure for the 32K cartridge But I do have some ideas to try out. It is a finished product, but can also serve nicely for some experimentation.

[prime]

You could do the memory remap the way that the Dragon Beta/128 did it. Use a RAM chip such that you feed the top address lines into the chip and use the data lines out of the chip to generate the top address to the main RAM.

So : A15..12 on the 6809 connect to A0..3 on the RAM, then A4..7 of the RAM are connected to 4 lines to select the task, on the Beta this is a 6821 port but could be a CPLD.
Then data lines D0..D7 would be fed to address lines A19..A12 on the main RAM. You would of course have to multiplex the address and data lines to the mapping RAM so that you could write to the paging registers.

If you plugged the expansion into the CPU socket you could of course gate the R/W line then the SAM would never see a write, and you should then be able to put what the heck you wanted there. If you always forced the SAM to see the top two address lines as A15=1,A14=0, in maptype 0 then the SAM would also interpret that as being in ROM so you could access the RAM at 1.7MHz.

Cheers.

Phill.