I don't see the value of the task registers in this MMU at all. If you're switching to a different task, you need to reload the translation registers, which is all you need to provide full address space isolation. In my review of the data sheet, I didn't see anywhere an OS could program "RWX" bits for individual pages, so you cannot make a page read-only in one process and read-write in another, and executable in a third. Maybe I'm missing something huge.

In my estimation, like all things Motorola, this is a simple address extender which has been made into something so grandiose that half of its core functionality is of questionable value.

The three greatest chips from Motorola, in my estimation, are still the 6809, 68010, and 68020. All of these chips concentrated on their core competency admirably. Everything else was, at least to some extent, fluff.

The datasheet does illustrate a way to use an address bit to allow mapping pages as read-only. Pages can certainly appear in the maps of different tasks.

Indeed there seems not to be any execute protection, but I imagine one could use the equivalent of the SYNC signal in a similar way, at the cost of halving the physical address space.

At 1280bits of state, it's too big for a CPLD. If you were starting with an FPGA, you'd have a lot of freedom to take different design choices. Too much freedom!

I thought the task handling looked quite interesting: it caters for DMA having its own private map, and the OS having a map, and arranging for the MMU only to be configured by the OS task. The countdown timer for switching back from OS to user task is amusing - it shows how much care you need with little details to turn a sketch into a workable system.

It goes a bit off-piste when discussing using a FIFO to store page misses for replay...

I've actually used SYNC to provide execute protection ("NX bit") using my 74LS610 based MMU. The NX error condition is signalled on the bus with a special line, the main CPU is stopped using the RDY signal and an auxiliary processor takes over to "fix" the bus error. "Fix" is mostly meant for not-mapped or write-protected pages which can also be detected, though. See "Auxiliary CPU" on http://www.6502.org/users/andre/csa



If I'd have to use an FPGA, I'd rather store the mapping tables in memory and only setting the address of the current mapping table in the MMU. When the CPU then accesses a page, the MMU would halt the CPU (using RDY again), load the mapping for that page, and let the CPU continue with the mapped address (and of course cache that mapping)

Advantage: only those pages that are actually used are loaded, and loaded in a single cycle instead of LDA ... / STA ... cycles.
Disadvantage: execution times of opcodes can vary on page boundaries when a new mapping needs to be loaded. Timing critical code probably needs to be aligned to page boundaries.

André

I have implemented write protection with the PA20 output as suggested in the datasheet. The thing about using a FIFO is more a problem with the 6502/6809 than the 6829, as you can't abort an instruction before it takes effect. The W65C816S has an ABORTB input, but using it with a 6829 would waste the extra address bits it already has (not to mention the speed again).

If you use an FPGA you might as well put the CPU in there as well and modify its VHDL to add all the extra features you like.

There are more 6829s on eBay (this listing is where I bought mine).

My board is now at the stage where it has RAM and a serial port, and is currently outputting "Hello, World!". Should be able to run EhBASIC or Forth soon once I adapt them. (Or even BBC BASIC if I rewrite the MOS?)

Creepy - how did you read my mind ;-)

At least that's my long term goal

André

You don't need much MOS to bring up BBC basic - once you've initialised the machine, it's just a read and a write call, more or less. Assuming sound isn't that important to you. Or file I/O. Hmm...

(I was able to run BBC basic in Mike's py65 project using a 64k image of an initialised beeb, just patching in a read char routine at DEC5 and a write char at E0A4)

A small AVR will be added to control a PS/2 keyboard and 4D MicroVGA. Could use a PWM pin for sound. Also got a couple of AY sound chips but they have a weird interface.

RFS (for the I part at least?)

There's a problem accessing the RAM at the moment. I edited the XMODEM downloader from my previous 6502 board, and found that programs would download but fail to run. Sometimes it wouldn't start at all and the LED would stay red indicating that it never got as far as returning from the 'initialise UART' routine. Putting the (battery-backed) RAM into my EPROM programmer revealed spurious garbage writes. After changing the old 54LS139 I was using for the read/write strobes for a 74HC139 a tiny test program downloaded and ran, but there are still strange writes. Currently swapping pins 14 and 15 on the half of the 139 that does the write-protect output to see if that helps (probably not). If it doesn't I could try a 1MHz clock (ouch).

Edit: As suspected, swapping pins 14 and 15 on the 139 didn't help. Connecting the write strobe to pin 5 instead (bypassing the write protection) did solve the problem if used with the 74HC139 but not with the 54LS139.

I'll try replacing the 139 with an equivalent 00 setup to reduce propagation delays.

A nice trick!

I'm interested to hear more about this (we have stray writes too, although probably for different reasons)

Looks like you had a pretty simple combination of RnW and PHI0 and the A20 to make the WEb for your RAM. That's a delay of two halves of a '139. You found that you had stray writes, and by removing the second half of the '139 you're fine, but you've lost the A20 for write-protect.

I'm a bit surprised you're using PHI0 - it's earlier than PHI2 which might be what you need, but I've usually seen PHI2 used.

Cheers
Ed

Seems to be working now- using a 74HCT10 instead for the data strobes. The machine runs fig-FORTH, but with EhBASIC for some reason it freezes after asking me for the memory size. Most recently I've been trying to program an AVR from the 6502 (just beeps to start with, but it will also be used for a keyboard and a 4D uVGA). Next thing will be making the BRK handler capable of dealing with the MMU being used instead of running everything in task 0.


I haven't looked at the delays here, I suppose I could have used Phi2 for the data strobes but left E and Q where they are on the 6829. Would there be much difference in the timing diagram considering it's only running at 2MHz?

If you're not entering a value then EhBASIC tries to find the end of RAM by testing each byte from the predefined RAM start address. The memory size prompt actually wants the memory end address + 1 so if you have RAM up to $9FFF just enter $A000 in response to the prompt.

Lee.

I wouldn't think there would be much, but maybe enough for a glitch.