Quote:

JimS wrote: @cdimauro Quote: It was a decision of the team leader (and company owner). He said that prefers a 3 FPGAs solution, because the synthesize phase is simpler and faster, and having FPGAs for specific purposes (CPU, display+graphic, disk+audio+I/O+expansion) let to work to a single part to synthesize without touching the other FPGAs firmwares, in a faster and simpler way to manage (albeit some sync problems that needs to be solved, of course; but it resembles the Amiga original chipset). Interesting.... of course if you consult the Ancient Lore of Amiga, it seems that Angus, Paula and Denise were supposed to be one chip, but the fab tech of the time wasn't up to it.

A single FPGA has its own merits, undoubtly. At least, it greatly simplifies the PCB design. But is more complicate to develop, and more limited too.

Anyway, we are building a system which is very similar to the old Amiga one. Only that we use 3 chips instead of 4.
Quote:

Anyway, Good luck with the project. I always like to see new players in the hardware arena.

Thanks.
Quote:

JimS wrote: @matthey Quote: I like the idea of having multiple fpgas for safety and experimentation. I would love to find an open system running the AmigaOS in one fpga while I experiment with VHDL in another. The Minimig isn't quite good enough and the fpga Arcade isn't quite open enough. Maybe the Tina will be the answer ;). I suppose, although it seems to me that having multiple FPGAs, all wanting access to the same RAM which is being controlled by one of them, seems like asking for trouble.

Yes, but at least they are the same troubles that had the original chipset, with the CPU and the chipset that contend the access to the memory.

Having a single memory type (only chip-mem) will be much easier to handle, instead of a chip + fast system.

Unfortunately we had no chance here: the chip-mem shared access must be reproduced.

However I pushed a lot to have a single, unified memory, because the overall bandwidth can be made available to all peripherals.
If you have a CPU-intensive task, and the Blitter is idle, you can use all the bandwidth (except for the display, audio, and disk, obviously) for this task.
In games, the CPU is substantially a controller the drives the chipset. The chipset (Blitter) eats almost all the bandwidth.

The same cannot happen if you have a splitted memory subsystem: most of the time you are wasting bandwidth for one of the two memories, because it cannot be used...

The CPU, also, will be provided with a very good amount of cache (32K+32K), so it can work even if the Blitter is hogging all the available bandwidth.

There's also another 16-bit bus which connects the 3 FPGAs, that can be used when they need to access "internal resources" (custom registers). So, when the CPU needs to access a chipset register, it doesn't have to use the memory bus: it just sends the request to the internal, very high speed, and (may be) in 2-3 cycles the work is done. The same applies when a coprocessor (the Copper, for example), wants to access a register that isn't found on its FPGA.

Quote:

JimS wrote: @matthey Quote: Who said they had to use the same ram? That was the idea behind the chip and fast ram from the beginning. The CPU gets priority access to the fast ram and the custom chips get priority access to the chip ram. I think an fpga for the CPU and one for the custom chips is about optimum for development. Eventually, after testing and debugging, they should all become the same SoC ASIC though ;). The way i understood it, the interface between the SD or DDR RAM usually used on these things is so fast by comparison to the old 68k buss that there's no real hardware need to split the RAM into CHIP and FAST. Could be wrong...

You're right. We have a 200Mhz 128-bit bus interface to the (unified) memory. There's a lot of bandwidth now (>3GB/s) using normal DRAM, but we are making experiments to use DDR-2, so we can be get a lot more. But right now 3GB/s is the minimum goal that we want to achieve.

And yes, I think that, due to the high bandwidth available compared to the old 68K machines, we don't need a more complicated memory sub-subsystem, having two different memory types and buses, which is also sub-optimal from my PoV, as I stated in the previous message.
Quote:

Anyway, the CPU FPGA has to have access to both, which means a whole lot of extra traces that need to be carefully routed. I'd prefer to keep everything in one chip... but I can see your point about having the cpu in one and the chips in another. Ya know.. the minimig port to the Altera DE2 board puts two 68000s and a Amiga chipset in one FPGA. The other 68k does the stuff that the ARM/PIC does on a minimig.

May be we can put another two 68K, one in the "display" FPGA and the other in the "audio / I/O" FPGA, since there are a lot of free resources. The Copper is an interesting coprocessor, but it's too much specialized and limited.

Some simple 68K used as "general purpose coprocessors" (AMP design) are much more useful in my opinion. They are 68K, so programmers don't need a new ISA to learn, and new development tools. They are regular microprocessors, so are more general purpose. And they can be made a little faster thank the original 68K.

Anyway, it was just an idea that I had. First we need to complete the SuperAmiga.

@cdimauro

I like the phrase "SuperAmiga"

I will support your project because it solves one problem that all "retro" projects up to now had, low sales meant high prices and that made every project uncompetitive on the market. If it is sold for other customers in high numbers and only additional sold to amiga users it offers the chance to have price levels where it becomes interesting to a lot more potential customers (amiga user, ex-amiga user and people interested in alternative hardware). And since the day I first read from Natami I always liked the idea of a community driven independent FPGA based Amiga. The Natami seemed to be but was not because it was in reality a closed-source one-man show and that was certainly one of the reasons why it failed. If the people behind this project learn from the errors done in other tries and it is a really open project it really has a chance. I will officially support it and hope others will join too because I think 68k is not only the past but also the future of amiga (in opposite what some of the NG supporter think). I think the combination of emulated environments (UAE running on Windows, Mac, Linux and even Android) and real hardware like FPGA Arcade and your hardware would offer real new opportunities for the platform.

Last edited by OlafS25 on 13-May-2013 at 09:54 AM.

@cdimauro

This is very cool. I hope that it isn't trolling or your enthusiasm will last for a long time.

_________________
A1200 + (looking for bppc060) + bvppc + Indivision AGA MKII + OS 3.9
A3000 + OS 3.9

@cdimauro

on my site http://www.amigacoding.de there are already a lot of 68k related discussions. Perhaps you and some others of your team want to join? When trying to get member you have to answer amiga-related questions. If you have a problem send me a email.

@cdimauro

It's a good approach to utilize an anyway to be developed system to make an Amiga project out of it. I am pretty fascinated by FPGAs (but didn't digged myself into VHDL _yet_). Hence I follow these projects with high interest. Best of luck for your project.

_________________
My programs: via.bckrs.de
MorphOS user since V0.4 (2001)

Quote:

OlafS25 wrote: @cdimauro I like the phrase "SuperAmiga" I will support your project because it solves one problem that all "retro" projects up to now had, low sales meant high prices and that made every project uncompetitive on the market. If it is sold for other customers in high numbers and only additional sold to amiga users it offers the chance to have price levels where it becomes interesting to a lot more potential customers (amiga user, ex-amiga user and people interested in alternative hardware).

That was the idea.
Quote:

And since the day I first read from Natami I always liked the idea of a community driven independent FPGA based Amiga. The Natami seemed to be but was not because it was in reality a closed-source one-man show and that was certainly one of the reasons why it failed. If the people behind this project learn from the errors done in other tries and it is a really open project it really has a chance.

I think that the only way to succeed for a so much complex project, is to open it to the community. So it'll be, ASAP.
Quote:

I will officially support it and hope others will join too because I think 68k is not only the past but also the future of amiga (in opposite what some of the NG supporter think). I think the combination of emulated environments (UAE running on Windows, Mac, Linux and even Android) and real hardware like FPGA Arcade and your hardware would offer real new opportunities for the platform.

Ditto, albeit I have some reservations about the 68K.

Motorola did an excellent work with this processor, but starting from the 68020 the ISA was made too much complex. It's hard to push performances of such "superCISC". Instructions are hard to decode, and the double indirect memory addressing modes are terrible from an implementation point-of-view.

Another thing that is missing is the 64-bit support. We know that AmigaOS is a 32-bit only o.s., so there's no chance to see it working on a 64-bit processor without trashing compatibility. But addressing more than 2GB of memory is a very important feature nowadays, even for an hobby project like this.

Anyway they are just my thoughts about the argument microprocessor, for which I'm very sensible, since I'm working on a brand new ISA. ;)

Quote:

coriolis wrote: @cdimauro This is very cool. I hope that it isn't trolling or your enthusiasm will last for a long time.

The project isn't mine, dear friend. I can only ensure you my passion, time, and professionalism for TiNA. And I trust the team leader which owns the project.

So I firmily believe that we can have a serious possibility to give a fresh move to the Amiga hardware.

Time will tell if I was wrong or right, as usual. But at least accept my honest speaking.

Thanks to all, guys.

@cdimauro

Quote:

We know that AmigaOS is a 32-bit only o.s., so there's no chance to see it working on a 64-bit processor without trashing compatibility. But addressing more than 2GB of memory is a very important feature nowadays, even for an hobby project like this.

68020 is a 32bit processor anyway, so your limit is that 4Gbytes of address space, I guess it might be possible to use more some kind of flash drive or RAM drive, if you have MMU that supports more than 32bit, aka paged memory (memory window), you might use it as disk cache, to speed up io reads.

Last edited by NutsAboutAmiga on 13-May-2013 at 07:28 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

Quote:

NutsAboutAmiga wrote: @cdimauro Quote: We know that AmigaOS is a 32-bit only o.s., so there's no chance to see it working on a 64-bit processor without trashing compatibility. But addressing more than 2GB of memory is a very important feature nowadays, even for an hobby project like this. 68020 is a 32bit processor anyway, so your limit is that 4Gbytes of address space, I guess it might be possible to use more some kind of flash drive or RAM drive, if you have MMU that supports more than 32bit, aka paged memory (memory window), you might use it as disk cache, to speed up io reads.

Yes, an MMU can help, but AmigaOS doesn't support it very well. Some work is needed to take advantage of it.

However, even the 80386 was 32-bit processor, but AMD extended it to 64-bit with his K8.
ARM made the same with his brand new ARM64 ISA, which is also binary incompatible with the old 32-bit ARM ISA.

I think that, once the SuperAmiga was up and running, we must thought about a proper successor for the good old 68K. Extending the existing ISA adding some new istructions has limited usefulness. OK, we can also add a brand new and modern SIMD unit. Fine. But an architecture rewrite and enhancement is a completely different thing, opening the road to a much better ISA (even to implement).

Anyway, it'a MUCH premature thing to talk about.

@cdimauro

We should do one step after the other

@cdimauro

Quote:

Yes, an MMU can help, but AmigaOS doesn't support it very well.

Thats a good thing, as you are basically free to do what ever you like.

Extending the CPU ISA might also be possible in the FPGA, but it harder thing to do, and you need complete OS rewrite to take full advantage,

Way not just simply forget the 680x0 in FPGA, and go for PowerPC 64bit whit 680x0 JIT.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @cdimauro Quote: Yes, an MMU can help, but AmigaOS doesn't support it very well. Thats a good thing, as you are basically free to do what ever you like. Extending the CPU ISA might also be possible in the FPGA, but it harder thing to do, and you need complete OS rewrite to take full advantage, Way not just simply forget the 680x0 in FPGA, and go for PowerPC 64bit whit 680x0 JIT.

I think using PPC with 680x0 JIT emulation is beyond the scope of this kind of projects, their aim is to (Re)create the exact genuine 68K experience, without bothering with emulations and such (not that they do not work or something, it's just a different thing with a differente feeling and flavour).

Last edited by ErikBauer on 14-May-2013 at 10:59 AM.

_________________
God created Paula so that Allister Brimble and Dave Whittaker could do music

Check my Amiga gameplays (ITA)!

@ErikBauer

Quote:

it's just a different thing with a different feeling and flavor

I think it just comes down to not having AGA/Paula/Denise on modern computers, as you end up emulating custom chips and CPU every thing just ends up running slow as hell.

I see big difference in RTG vs Planar modes on AmigaOS4, Planar demos crawls, while RTG demos run extremely fast.
and also there big difference between EUAE/WinUAE vs Amithlon.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Agreed, in fact the purpose of such projects it is not to have a "Modern Computer" rather it is (or should be) to have an evolved 68K Amiga compatilbe with original HW. Hence the 68k and Chipset in FPGA.

_________________
God created Paula so that Allister Brimble and Dave Whittaker could do music

Check my Amiga gameplays (ITA)!

@ErikBauer

but i think all will be more (extreme) faster than the original one...
hope more faster than a classic amiga with 68060@100mhz and a cybervisionPPC...
with a full aga rtg support and with cybergraphix will be great!

_________________
I love Amiga and new hope by AmigaNG
A 500 + ; CDTV; CD32;
PowerMac G5 Quad 8GB,SSD,SSHD,7800gtx,Radeon R5 230 2GB;
MacBook Pro Retina I7 2.3ghz;
#nomorea-eoninmyhome

@ErikBauer

Sounds reasonable, think it is important to set the executable targets, during project planing.
And stick to the orignal plan, as we have seen a good amount of projects spin out of controll, not becoming anything.

Last edited by NutsAboutAmiga on 14-May-2013 at 11:46 AM.
Last edited by NutsAboutAmiga on 14-May-2013 at 11:45 AM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Exactly

_________________
God created Paula so that Allister Brimble and Dave Whittaker could do music

Check my Amiga gameplays (ITA)!

@ErikBauer

I hope that the people who have already started such a project or even finished come and work together to create something really big and make the right (in the sense of realistic) decisions

What about donations for this new Amiga-clone project? I think that it will be right to have a milestones which will have a money rewards for the tasks.

_________________
A1200 + (looking for bppc060) + bvppc + Indivision AGA MKII + OS 3.9
A3000 + OS 3.9