First of all APOLLO has an MMU.
But its not 100% 68K compatible.
Its designed to be internally simpler and faster than the old 68k MMU.


Quote:

1. Copying the Kickstart ROM into FASTram.

The existing Phoenix card does provide this already.


Quote:

2. MuRedox is a MuLib based "on the fly" speedup patch for 68040 and 68060 based Amiga boards. The 68040 and 68060 do not implement all instructions of the MC 68K family. The unimplemented instructions - mainly FPU instructions - generate an exception and need to be emulated by the 68040 resp. 68060.library. This is the job of the so- called "FPSP routines" (floating point support package) within the CPU libraries. MuRedox detects these instructions as soon as they generate the emulator exceptions, runs a "just-in-time" compiler that generates a "stub replacement routine" for this specific instruction and patches the replacement routine into the running program. Hence, MuRedox replaces the overhead of the emulator trap on the next use of the same instruction sequence.

Want you mean is trapping on unimplemented code
and then patching the program on the fly.
This made sense on the 68060 but you do not need an MMU for this.

Quote:

3. An MMU makes Mac Emulation massively faster.

What makes the MAC emulation faster is moving the MAC global into fastmem.
But you do not need an 68K MMU for this.

A trick which was used in MAC Video emulation on AGA was using tables to mark destroyed pages and only do C2P on those. This meant the MAC Video was complex done.
First render in the Fastmem buffer then sort out updated pages, and then C2P those to AGA chipmem. A complex setup done to reduce the mem-copy over the relative slow chipmem bus. If you recall AGA chipmem bus peaks out at 7 MB/sec.

Our new cards have local Video out. We have about 100 times faster memory access to this video memory. Doing an MMU trick would now only slow you down. What you do want to do now is direct update.

Using the MMU to find access to mem address $0 is a nice trick to help find uninitialized pointers. But this you do not need a complex 68K MMU.
This feature is build in Phoenix already.

An MMU also has drawback.
Just think of how the Branch Acceleration Caches of the 68060 work - and that you have to flush them complete when you use MMU with virtual memory. This is a drawback.

_________________
APOLLO the new 68K : www.apollo-core.com

@chaoslord
dont get me wrong, im actually a supporter of mmu for the reasons you have listed. thouagh look at your list yourself. so far i see over tha half of it are mutools by thor, who himself is involved with the work on the core to certain extent, at least as consultant. then there are vmem solutions that never were of much use, since it was a lottery if the software will work with them or not. in the prospect to eventually have more real memory at disposal with the fpga accels, this point isnt really significant. then there are various debuggers, catching illegal memory access and this is the only crucial thing fornthose who use them. but here while not much can be done for sas-c or whatever it was, we again still may have chance that thor provides some adaptation of software enabling these abilities for the limited mmu contained in the fpga core.

and what concerns voodoo drivers there are mmu and nommu versions, which is kind of mess only confusing inexperienced users. user shoulnt need to mess withbthe driver choice. the driver should detect hardware config and set it up itself accordingly.

@BigGun

Quote:

Developing a CISC CPUs give some challenges 1) Its difficult to decode long and complex CISC instructions quickly. 2) That all instructions can have different length makes decoding several instruction per cycle more difficult. 3) The testing effort for CISC CPU is very high RISC offer simple development of the CPU 1) As the core is simpler, the testing can be done with less man power/time 2) As all instructions have the same length decoding multiply instructions is easy. All you need to do is copy 2 paste.

1) We solve this by using a massively wide logic net, since transistor count is no longer an obstacle.
2) We leave this up to the pipeline, using lots of transistors.
3) Intel doesn't exactly seem to have a problem with manpower :)

1) How cares as long as we can make the fastest possible CPU on earth.
2) Let the pipeline deal with the division of the byte stream into whole instructions.

What I'm saying is that RISC was invented to get around the obstacle of slow and power-consuming transistors. This is no longer a problem and the GHz roof was reached 10 years ago. Now we increase speed in ways that doesn't really benefit the basic RISC architecture.

Only if one needs ultra low power it makes sense to reduce the transistors count and go RICS, like ARM.

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

i wonder way dont there make an kickstarter site. this softcore cpu has intrast even outside the amiga communaty, maby atray fans and maby unix pepole would like this cpu avalible. way not make an kickstarter i would love to trow in an 100 doller. now i am gonna get my an classics agen. beside the cd32 that i have. i hope for an minimig2 and that the apollo2 card can be fittet on the minimig 2 board. then it would kick ass.. wee have the new aeon sound card on the horizon but what do wee do with gfx on the minimig... bvision simulation ??

Quote:

i hope for an minimig2 and that the apollo2 card can be fittet on the minimig 2 board

A new standalone system like the NATAMI is in the planning pipe...

_________________
APOLLO the new 68K : www.apollo-core.com