@pavlor

this thread is about Natami, or general FPGA hardware. That are geek machines that are fun to be used in spare time. It is certainly not competition to modern platforms but there would be a market for it. But for that we would not need MMU. 4 GB RAM (if it is adressable) is a lot, my Notebook runs with it and there are certainly not many applications that need more RAM than that (except database server or heavy graphical applications). Memory protection would be nice of course but at the moment none of our platforms supports it yet and all are in use. So I do not think we should create problems where no real problems are.

@pavlor

they are testing it if it is possible at all and what changes would be needed. The situation on AROS X86/X64 is very different to that on 68k. You have only a limited number of applications and mostly are available in source so you can adapt them if necessary. Do the same on 68k and you get serious problems because there are many applications without sources.

@pavlor

Quote:

Then why threads like this? (New PowerPC roadmap and Power8 roadmap)

It is only talk.

Quote:

I applaud all people who keep trying. (link to Forbid() free Semaphore commit)

This has nothing to do with MMU.

But indeed, they are somewhat rebuilding it from ground up, at least a little.

Last edited by itix on 21-Feb-2014 at 05:12 PM.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

I really forgot that NatAmi still exists. Too bad that it's still 2014 and we have seen nothing.

Hope that a NatAmi board will be available soon, but I'm not quite optimistic now.

_________________

@itix

Quote:

It is only talk.

That is purpose of this site, I think.

@Phantom

+1 too bad... but today the hardware would be outdated and it would have been too expensive. There are two projects still in development (one project by one developer and another project by a group of developers) who want to create a core that runs on standard FPGA hardware and that would be both much cheaper and modern.

@OlafS25

Why it would be outdated? Even now, comparing what the NatAmi has to offer with the classic range of original Amiga hardware, it's still superior to them. I don't put NatAmi in the same league with the next-gen PPC Amiga hardware, as those two are completely different things.

Two years ago, some NatAmi MX boards were shipped to devs/beta-testers. No news since then?

_________________

@Phantom

the hardware was designed a couple of years ago and a lot has changed since then and it would have had the same problem as X1000 and many other products produced in small quantitives... it would have been very expensive. Using standard solutions would make new hardware affordable for everyone.

I have left when Thomas H. left "Natami" and have not heard anything about it. But I was no member of inner circle so I do not know for sure. But I think it is dead.

@OlafS25

Yup, I've heard that about Thomas; too bad really. It seems a dead-end to me.

_________________

@Phantom

it would have been above FPGA Arcade with daughterboard (price) and the problem was that many of the nice features people talked about did not exist. I read somewhere that there were RAM problems that could not be solved and the project was only one developer who was not interested that anyone helps him. "His project" how he said to me.

I sometimes think that amiga-developer are less interested in a real product than doing everything themselves and prefer failing of a project than letting other people join. Really sad attitude in my view.

Last edited by OlafS25 on 21-Feb-2014 at 05:55 PM.

@OlafS25

Quote:

as far as I know is the apollo core without MMU (and also not planned) and the FPGA Arcade has no MMU either so i do not care about it right now. Memory protection for 68k without (heavily) breaking compatibility?

The 68030 core by the Suska team (Atari ST equivalent of Minimig/Natami) is implementing an MMU.

Suska Blog from December 2013:

Quote:

Beside the work on the Suska-III-C IP core, which has again get some improvements and enhancements, the modelling of the 68K30 CISC processor was the most intensive work which has been done this year. It was a rather big deal but in the end the processor is now feature complete. Some information for specialists: it is a complex core with about 21.000 LEs in an Altera Cyclone-III device. But therefore the core features a MMU, Cache and the coprozessor interface, a barrel shifter and fast integer arithmetics. The bus controller rules dynamic bus resizing and cache burst mode filling. This project was by far the most time consuming this year.

_________________
All glory to the Hypnotoad!

@tygre

http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=38744&forum=17#729551

Quote:

Here in lies the flaws of RISC thinking. 1) High level programmers don't know what the hardware needs to do and compilers can't figure out what high level programmers want. Most modern high level languages are inadequate for producing quality code from the compiler. Hardware hints are possible in some high level languages with advanced compilers like GCC but they are rarely utilized and instead the compiler makes assumptions or produces a bunch of code to avoid making assumptions. PowerPC was counting on compilers to generate optimal code so the complexity could be taken out of the CPU but we can see how that's worked out for PowerPC. 2) Low level programmers are no longer needed so there is no need to make the assembler code readable anymore. The low level learning becomes tedious and less interesting so people don't learn it. Most programmers end up using high level languages without an understanding of the low level that needs to be manually tweaked correctly. They generally can't even read disassembled code in their debugger. The work that PowerPC can do is not that far behind because of diminishing returns in parallel execution of a sequential stream of instructions. PowerPC can be competitive with optimal "perfect" code but that is rare instead of common. The fact that most PowerPC processors have moved to OoO execution is proof that compilers failed to schedule instructions adequately for superscalar. I believe some of the modern PowerPC processors have stream detection despite the lack of need if compilers generated the correct manual prefetch instructions. ARM64 is one the few RISC processors to decide that unaligned memory access support was a good idea but aren't compilers supposed to avoid that also? All of the RISC compiler avoidance code ends up eating up the caches that are already large due to poor code density.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@itix

Yep. If you look at recent (post-2005 or so) articles on optimization, they mostly focus on how to make the best use of your L1 and L2 caches. RISC was a pretty good strategy in the 1980s and 1990s when main memory was as fast or faster than the CPU, but these days where the CPU is running multiple instructions per clock cycle you want high code density so more of it will fit in your caches. A good example of this is ARM: it's a pretty standard RISC design, but they added 16 bit long instruction words (thumb/thumb2) so they could get better code density than the original 32 bit long ARM opcodes - some Cortex cores are even permanently in thumb mode and can't be switched to ARM mode. On the other side x86 lucked out in that their more complex instructions, designed to make it easier to write in assembler, ended up also being more cache-friendly 40 years down the road (recent Intel CPUs do split up the complex opcodes into simpler micro-ops internally that do resemble RISC opcodes, but that happens inside the CPU cores where the registers run at the same speed as the CPU, replicating the environment of the 1980s).

Last edited by CodeSmith on 22-Feb-2014 at 05:53 AM.

@AmigaBlitter

I am have been reading the forum on natami.net but now it is all very silent there. Some news say the team members have fall out. Does anyone have any information on what is going on with this project. ?

Did try to register on their forum but you do not get a activation mail.

is there any chance we will see these card being a consumer product something a amiga user can go and buy.

Hope so because I think this is the most interesting amiga project I have read about for a very long time.

@tangoone

To my understanding:
The original Natami guy went his own way, the rest are developing 68k and GPU cores anyway. There should be NEW CPU accelerator for classics based on the developed 68k FPGA CPU, later perhaps whole system.

This thread should cover the latest news around FPGA Amiga:
http://www.amiga.org/forums/showthread.php?t=67561&page=7


In the meanwhile, MiniMig+ is coming, MIST can be bought with Amiga core, etc...

Last edited by KimmoK on 03-Jul-2014 at 03:17 PM.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@tangoone

Natami is dead. Maybe some fruit of this great project (eg. FPGA based accellerator for classic Amigas) will be released at some time.


...and of course

Welcome!

There is already FPGA accelerator for Amiga 600 http://www.majsta.com/

Last edited by Comi on 03-Jul-2014 at 11:07 PM.
Last edited by Comi on 03-Jul-2014 at 11:07 PM.

_________________
F1 Srbija

@pavlor

It would be great to see AmigaKit (+ other classic hardware vendors) get together and produce an FPGA accelerator for the classic market; specifically an 060 accelerator.

I assume there must be some demand for it. It could be tweaked to be even faster if required. Once we have a gold standard accelerator for classics as an option, it could really invigorate the classic market, with people producing new software for the machines.

Ultimately though a AAA+ classic Amiga running with an 060 or faster would be an amazing piece of retro hardware that I think would go down well with classic hobbyists and collectors alike.

Q!

"i am home"

@QuBe,

Want them real bad. 060 FPGA running 80Mhz or better, fast bus with fast mem and SATA.
Would be the most awesome 4000T ever.

Chris

@thread

If we once get fpga based 68k+AGA++ stand alone HW, how should it be named?
Amiga5000 / A4000F / AmigaII / AmigaClassic2 / ???

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?