:-)

And yes it's true i am not a MMU fan.

Well, perhaps not "lot of effort" but everything could be done through the OS which at least meant a theoretical chance that the hardware could have been changed without the software breaking. AFAIR you could build copperlists through OS functions but you had to pass the precise data to the function that you otherwise would have put into the copperlist. OS-compliant games were possible though. As I wrote above I made a small tech demo of a parallax scroller with a character sprite, joystick support, blitter objects and copperlist for colour fades that was 100% OS-compliant. It was written completely in asm. Since I'm no graphician, all graphics objects were black blocks, though :)

 

Banging the hardware is a requirement for the NatAmi.

I never said that hardware banging was a complete taboo. Even with an MMU and multiple OS instances you could just allow each task and each OS instance to access the chip registers/chipmem. If one program messes up chipmem or registers, you have the same situation as before: it will be your problem if you run that type of software. But at least most of the OS would be protected and tasks from each other.

In addition having an MMU in place doesn't mean that you have to use it. Outside the amiga world there is multiboot.

BTW, the reason we're not putting an MMU in the NatAmi is mainly because there isn't room for one.

I doubt this is the reason. If you can put a 3D core into the FPGA, there certainly is enough space for something as simple as an MMU. There was an MMU add-on for the 68020 when gates were still counted in thousands.

The N68050 will not have an MMU. Period.

Oh really? Question Mark?

It's perfectly fine if nobody but me wants to have an MMU. It is also perfectly fine if nobody wants to spend any time on the subject. I have enough experience with open-source software to know that the person having an idea is the only one who might put it to test if anybody does at all.

What I don't like is when people put down an idea they don't like without convincing reasons and in a condescending way.

The only one I know of is uC linux which in my opinion is not a UNIX precisely because it hasn't got an MMU and the features that are only possible with an MMU.

It is also a clockrate issue and thus a performance issue. We don't have any chances of achieving competitive CPU speeds with the N68050 if we integrate a MMU into the design. This has been discussed extensively over the years.

This sounds much more convincing than the FPGA space thing. Will the code be public so that one could modify the CPU design?

This has been discussed extensively over the years.

I'm sorry, I didn't know this was discussed so extensively.

general concensus is that the added perfomance penalty does not outweigh the gains.

I have to mention this to be fair it has been mentioned to do a MMU outside the CPU and directly into the memory controller part of the system since both CPU and chipset need to pass through it.

Marcel Verdaasdonk wrote:

general concensus is that the added perfomance penalty does not outweigh the gains.

"General consensus" is a nice word. No, it's not "general" since I disagree. I appreciate that there are more important issues to work on, and that given the time and money constraints, this issue has no priority right now, but I do not agree that the performance penalty outweights its gains, basically because I do not see any penalty below 20% even worth discussing. You get the same speedup by just waiting a couple of months and picking the next generation of chips, and taking this as an argument for an engineering decision is folly.

Marcel Verdaasdonk wrote:

I have to mention this to be fair it has been mentioned to do a MMU outside the CPU and directly into the memory controller part of the system since both CPU and chipset need to pass through it.

That's a DMA MMU, and if you want a simpler integration of any type of DMA device, for example including for PATA DMA, then routing this through such a channel as well has the additional benefit of simplifying the software layer. It is not exactly necessary as the Os could handle it as well.

Same goes for the hardware registers. Of course you could virtualize them, and let the os check whether the operations to be performed by the hardware are valid for the currently loaded program. I'm not saying that this is practical - it is however possible. In principle, you could get rid of the old Amiga hardware completely and emulate it by new more powerful chips, plus a virtualization layer, plus a CPU that is fast enough. It is not what this project is about, but it is not impossible.

Do you actually have any numbers? I highly doubt this, namely the unability to achieve a competitive CPU speed. Yes, things will be slower, but not much slower as it extends the pipeline by a couple of stages - but why bother?

Thus, how much slower is slower? Any numbers?

and about your wait a month and there is a 20% increase was true in the late 90's and early last decade.
But no this kite won't fly these days, we are looking at bounds in physics which needs to be overcome first.

you can't stop me from cycle counting, call me old fashion but that is how performance is a guaranty.(and no i do not hand code all my code in ASM i do it in time critical loops.)

And of course the design choices could and should be revised when better FPGA tech is available further on.

What do you mean? The FPGA configuration is always read from flash at boot. And there are always two FPGA configurations to choose from with a jumper: main side and backup side.
Reconfiguring any of the two FPGA loads is already as easy as writing a single AmigaDOS command, waiting a few seconds and rebooting. And eventually it will be as simple as a few GUI clicks. Loading a small file of a few hundred kilobytes from HDD vs flash mem does not really make a big difference, if that is what you meant.

but i thought the flash ROM also contained a copy of the OS

The FPGA configuration is always read in full at boot. This takes a quarter of a second or so.
When writing a new FPGA configuration to flash, you need to erase the area first anyway. Writing diffs is out of the question.

Marcel Verdaasdonk wrote:

but i thought the flash ROM also contained a copy of the OS

Yes, it has four slots for kickstart ROM images. What is your point?

It's possible to implement MMU functionality without too much performance impact but it isn't compatible with the rest: all caches are virtually addressed and translation is done on main memory accesses.

That isn't what i meant i meant dynamic so to dump a image in RAM but i guess that is technically not feasable while there is no memory controller.

I was comparing it to existing 68k CPUs, though.