ADOOM on A600 running 22-35 FPS

[vxm]

It's a matter of finding the right balance, and the size of the cache. The current core already requires software support for integer arithmetic and - quite like the 68060 - does not suffer from that because only exotic instructions require emlation that are rarely ever needed.

Consider an ATC of 256 entries, 4K per entry. This is already pretty small. The core could then address 1MB of memory without ever requiring a table walk. Put this into perspective to the typical Amiga program, probably at one tenth of this size.

Thus, the core would at worst initiate a table walk when loading a program.

Anyhow, this is all theory. I'm not saying that anyone should focus on this right now. There are more serious matters.

In an AMP context, your idea seems very promising. Especially as the architecture of the Amiga should facilitate this development.
And no, I have not forgotten the many discussions around a possible AMP based solution. In fact, I quietly waiting it.

[ppcamiga1]

This crap natami has a standard 68060 CPU on board, and hence a standard 68060 MMU.

This crappy natami is on my crappy desk. Here you go.

gunnar von boehn promised NatAmi faster than powerpc.

I do not want NatAmi with 060.  

I want NatAmi faster than g4 with PS2 level graphics, for 100 euros only.  

gunnar promised that in autumn 2009, everyone will be able to buy it.  

gunnar where is my NatAmi?

[eliyahu]

@ppcamiga1

you were warned to stop trolling in this thread, and you ignored it. enjoy your two-week break.

-- eliyahu

[ferrellsl]

@ppcamiga1

you were warned to stop trolling in this thread, and you ignored it. enjoy your two-week break.

-- eliyahu

Thank you!

[Nickman]

Thank you!

Yes Thank you!

[Oldsmobile_Mike]

Sometimes people make moderating decisions too easy.  

:banana:  :banana:  :banana:  :banana:  :banana:  :banana:  :banana:


:pint:  :pint:  :pint:  :pint:  :pint:  :pint:

[matthey]

@ThoR
I used the term virtual address instead of logical address, hoping non-technical people would understand it better. I guess I won't be writing any technical manuals on the MMU.

I wouldn't go for a hierarchy, it's all complicating matters. A flat page table within which the MMU finds entries by trying several hash algorithms to find a suitable table entry would be entirely sufficient. Everything else, like filling the page table, or replacing descriptors in the page, can be done entirely in software. This software can do the table walk and emulate whatever 68K MMU there is.

So would support code be loaded before boot which would trap when 68040 MMU instructions not in hardware were used? Then offer a supervisor space library interface to the same code (like fpsp.resource but supervisor only) which can be used to reduce the trap overhead? This could make it easy to get an OS using a 68040 MMU up and running and then slowly replace the trapped MMU instructions?

[ChaosLord]

gunnar von boehn promised NatAmi faster than powerpc.

I do not want NatAmi with 060.  

I want NatAmi faster than g4 with PS2 level graphics, for 100 euros only.  

gunnar promised that in autumn 2009, everyone will be able to buy it.  

Gunnar overpromised many things but I don't remember any "for 100 euros only" promise.  Maybe you are referring to "CPU only"?

And the deal with "faster than g4" was actually "Mhz for Mhz faster than G4".

That means a 100 Mhz Natami/Apollo would be faster than a 100Mhz G4.  A 300Mhz Natami/Apollo would be faster than a 300Mhz G4.  And a 400Mhz Apollo/Natami would be faster at copying memory from Point A to Point B than a 2200Mhz G4 due to the spectacularly bad memory interface endemic to all publicly available PPC processors.

If you are going to criticize someone, fine, but be truthful about it.

[kolla]

Not sure I understand the question.
If we would not put SAGA into the FPGA how could we run Amiga OS?

Exactly, and for Amiga (and Atari) this is pretty much done deal, FPGA implementations of chipsets exists, but I don't this is the case for other m68k systems.

@matthey, a "cherry pi" would need an FPGA anyhow to be useful for AmigaOS. Price wise, what is more expencive you think, a bigger FPGA to hold both CPU and chipset and whatnot, or an ASIC for CPU and a "cheaper" FPGA for chipset++?

[matthey]

Exactly, and for Amiga (and Atari) this is pretty much done deal, FPGA implementations of chipsets exists, but I don't this is the case for other m68k systems.

@matthey, a "cherry pi" would need an FPGA anyhow to be useful for AmigaOS. Price wise, what is more expencive you think, a bigger FPGA to hold both CPU and chipset and whatnot, or an ASIC for CPU and a "cheaper" FPGA for chipset++?

It should be possible to bake the Amiga chipset and possibly even other chipsets into the ASIC, although a small FPGA for a chipset would be more flexible. I believe the power could be switched off to the chipsets if someone wanted a CPU only. Then again, it would be useful if the CPU came with a chipset, more I/O support like ethernet and USB, memory controller and even a small amount of memory. One of the reasons ARM SoCs are used so much is that they are convenient, cheap to build a board and low power. If there was a decent 68k SoC on the market, I bet there would be a slew of new Amiga hardware projects pop up over night.

[kolla]

I'm curious if old MacOS 8 under Shapeshifter has been tested on Vampire600?

[biggun]

Exactly, and for Amiga (and Atari) this is pretty much done deal, FPGA implementations of chipsets exists, but I don't this is the case for other m68k systems.

If you run BSD or Linux then you are not banging the chipset anyway.
So where is the point to have diffrent chipset for these users?
Isn't one chipset which is supported all they need?

[kolla]

Of course both BSDs and Linux are banging the chipset, how else would they provide screen output and sound? Of course these also have the advantage that they will be able to support and make use of SAGA too, when that time comes. Other OSes are not so fortunate, and require that people replicate their old chipsets in the FPGA.

[biggun]

Of course both BSDs and Linux are banging the chipset,

The point is on BSD and Linux all software goes through a driver - there is nothing banging the chipset directly. So on BSD or LINUX it does not matter what hardware you have. The same is true for MAC-OS.

For ATARI and AMIGA the story is different. An AMIGA without AMIGA chipset is no AMIGA ...

[guest11527]

So would support code be loaded before boot which would trap when 68040 MMU instructions not in hardware were used? Then offer a supervisor space library interface to the same code (like fpsp.resource but supervisor only) which can be used to reduce the trap overhead? This could make it easy to get an OS using a 68040 MMU up and running and then slowly replace the trapped MMU instructions?

Look, you are asking a lot of questions on concrete software implementation in a situation where even requirements and use cases are not strictly defined. Thus, it is really a bit premature to say anything, given that no single thought has been wasted on an actual MMU in the Phoenix.

If you want me to cook something up in a minute, I would say that a typical solution would possibly make the CPU trap in case it does not find its descriptor in the cache. A mmu support package (mmusp) would catch this exception, perform the table walk as the 68K MMUs would do, replace descriptors in the cache, and resume operation. In case it does not find the descriptor in the table, it would initiate the bus error from the software side.  

There are not really many MMU instructions that would need to be trapped. Actually, none of them are user accessible, so none of them require - strictly speaking - any trapping.  You would probably have to emulate the TTx registers to allow exec to start up, probably even as a no-op, but that's only an implementation detail.

What then could happen is that is extensive mmusp could be replaced by something simpler, for example the mmu.library, as soon as it comes into play.

But anyhow, these are all rough design ideas without really having them checked, and whether they might survive contact with reality is another story.  

One way or another, at this point I would rather prefer to get the current core done "as a product" (i.e. can be bought as expansion card in stores). Since that's all on an FPGA, it shouldn't really cause too much trouble replacing that in the future, should the card be successful, should there be enough users, should Gunnar find enough time for the design... Many "if's" in this equation, so please, I don't think it makes much sense to discuss this right now.

[biggun]

It should be possible to bake the Amiga chipset and possibly even other chipsets into the ASIC, although a small FPGA for a chipset would be more flexible.

Maybe it makes sense to sum up the difference:

CPU

in FPGA  ~ 600 Mhz 68020 Speed
in Very Good FPGA ~ 1200 Mhz 68020 Speed
+ needed investment to develop an FPGA system is low - some hundred to maybe thousand $ to get prototype
+  Bugs can be fixed in the field

 
CPU
in low end ASIC  ~ 1000 MHz 68020 Speed
in high end ASIC  ~ 5000 MHz 68020 Speed
- needed investment is huge for high end Asic the price for prototype can be in range of $200,000
- if there is a bug then the ASIC can not be fixed.
- To fix a bug again $100,000 need to be invested.



GFX Chipset
If you do the chipset well then you can get with todays entry level FPGA already super performance.
16bit CD quality audio is no problem.
FULL HD video output is no problem, 24bit truecolor is no problem,
If you do it right then having 100 times DMA performance compared to AGA is no problem with todays entry level FPGAs.

an ASIC could again improve over this.
But would have huge cost and huge risk.

I'm personally happy with FULL HD - I do not need 4K display ...

In regards of the chipset I would certainly prefer to use an FPGA to keep the risk and investments lower and to have the possibility to improve the chipset if we want to.