in case you are interested to test new fpga accelerators for a600/a500

[biggun]

I'm talking about the vampire 2. That's "a bit bigger", but not much. Doubtful whether that's enough headroom for any extra. If you pick a completely different FPGA, sure, but there's no MMU design Gunnar has made. There are larger caches, superscalar cores and so on, but none that would feature a MMU for example.

Hello everbody.



First of all :  ALL FORUM ACCOUNT ARE NOW ACTIVATED.
So if you did sign up, you can use the account now.


2nd - if you ever have need to support - please visit the IRC channel.
There is always someone around..


3rd Lets quickly compare the cards to get a better overview.

The VAMPIRE-600-2 is product for the A600
It has a faster and bigger FPGA than the VAMPIRE-600-1.
Its a pure CPU Card. It will be pure Integer.
The maximum expected performance that we have for with
this card is something in the ballpark of a 100 MHz 68060.
But no guarantee for this yet.



The C5 Apollo Phoenix Card is a develop card for a program in the  Apollo website.
If has a much bigger FPGA. A lot more performane is here expected.
The C5 card has room for FPU.
But will be first deliveared with an Integer core.
The C5 is NOT available for end users - its a pure tester and developer program we want to do.

[biggun]

So, to be a tester is there anyone special you are looking for or can anyone become a tester. ?

Testers  do _NOT_ need to know anything about VHDL, chip design, or FPGA programming.

Ideally testers should be keen on trying out several games , programs or demos.
Phoenix comes to you with something buildin similar to an action replay.

If a demo fails - a tester should be willing to use the action replay and "grap" the failing code part.
We can show you how to do this.

I great help would be if some testers have some 68K ASM knowledge or are interested in learning this.

Testers should be willing to make screenshots / take pictures or movies e.g. showing ADoom with 50 FPS. :-)
Testers should not be afraid to own the fastest Amiga.

[biggun]

I am sorry but these cards are not 500 Mhz.

It does not matter whether these cards are clocked with 200 or 500 or 800 ...
As long as they are as FAST as an 68030 @ 500 MHz people will be happy

[biggun]

Since when is stating facts and the truth negative?

Truth is good.
Can you start posting the truth instead spreading false rumours?.

 

MacOS emulation on Phoenix would require major patchwork with the last I heard of Gunnar's ISA (no documentation or ISA encoding maps are available so no one knows for sure). Some 68020 ISA instructions which are illegal on the Amiga but necessary in MacOS like CAS and CAS2 are not implemented

What you say is not true.
CAS and CAS2 are supported.

Matt, you lack overview about Phoenix.
I've noticed that you very often post wrong and untrue stuff.
Posting wrong info does help no one.

[biggun]

What is the truth? Can you tell us when you change your mind again and update your documentation (the only documentation I find is N68050 encoding maps)? The truth can change especially where you control it. The last truth (or lie from your posts) was that you were using OPI.L #.W, which would partially overwrite encodings of some other instructions like CAS, CAS2 and CMP2.

Matt,

The Phoenix development team does meet every day in IRC channel.
The team members are therefore informed and have good overview.
Matt if you are never in IRC channel, you can not  know what is going on.
If you want to know more you need to participate.

The Phoenix development team has access to complete instruction decoding definition.
But you are not part of the development team,
therefore you have no access to this - so how can you know them?

The team members have hardware card and use Phoenix.
So the team members can speak from practical knowledge.
But if you have no card and never used Phoenix - then you have no practical knowledge.


Matt you look at the project from on outside view.
There is nothing wrong with this.

But don't you agree that from your outside view  you can not really know anything about Phoenix?

And do you not agree that as long you lack overview, and have no real knowledge - you can also spread rumours.
But spreading rumours and false information is really not helping the people at all.

[biggun]

alas. which is uncomfortable, because there is a bit too much of what depends on one person for my taste but i dont see no option.

Just include me in your good night prayer and all willbe good.

[biggun]

Your time zone is 7-8 hours different. A forum is better to provide information if it was correct.



Why make a public forum with partial and incorrect information posted by you

Matt you to agressive here.
Can you just calm down?



Your problem is  that you misunderstand stuff and or misinterpret stuff.
There was nothing is incorrect about the old forum post.

Lets look at the fact first before we start to panic ok?

The forum post did show several instructions.
In fact only the instruction behavior and name was discussed there.
The encoding was never discussed in this posting.

This means the instruction where shown in NAME only not in ENCODING.
Is this correct - Matt?

So we can state here, that the encoding was not shown and not explained.
So in fact you do NOT know the encoding of the instruction.
Nevertheless you post here that the "unknown" encoding would clash with another instruction.

Please explain this.

[biggun]

You accused me of twisting the truth

Matt I did never say that lie on purpose.
I said that you say is tell people not the truth, that you tell people simply wrong stuff.

In this case all you knew was the name of the instruction.
You did not know the encoding.
You have to admit this.

Nevertheless you warned that the encoding will break compatibility.
Matt what you did was not correct.

[biggun]

Lets clear this up:

The Core and ISA definition is available for developers today.
It is NOT available today for download by the public
The reason is that the core is not officially released yet and that the core could still change and improve before release date.
Everyone should be able to understand the benefit of this reasoning.

As good news:
The Core is continously improved:
Yesterday the core was upgraded and can now execute 3 instructions each cycle

Also good news:
The core team with hardware designers had a long discussion and came to the mutual understanding and agreement that all CPU cards from now on will have a minimum FPGA size.
This means all cards for all platform will have a minimum sizes.
This size is big enough to fit the full Apollo core plus the 68k FPU.

This means all cards for all AMIGA systems e.g. A600/A500/A1200/... will support the same instruction set and the same features and have the same capabilities.
Software developers can write/compile for Apollo as target and this will run on all cards.
All features including FPU will supported both in budget and in high end cards.

[biggun]

Just consider instructions like EORI.L #...,? What are the intended use cases, and which software would profit from that? Which compilers would support it, which assemblers would? Does it enable any "killer features"?

EORI.L #im,EA
If you mean tthe original 32bit form then this an original 68000 Instruction.
All compilers support it since always.



EORI.L #i16bitm,EA
If you mean a 16bit variant of this then this instruction does not exists.
It is NOT a Phoenix Instruction.
We have no plans to support this.

Let me tell you a bit from my personal experience: In my world (ISO business, WG1), we first make a requirements analysis before we attempt a new "work item". That is: What exactly do you attempt to do, and which requirements does it need to satisfy?

Thomas, I agree. We do the same.
The problem here is that some misunformation was posted and this misinformation is causing confusion.

[biggun]

To be honest, I'm personally not too hot about ISA extensions at all. The major problem is here that it segments the platform while not offering a reasonable return.

We agree that segmenting the platform is bad.
And actually I think that there is already a unhealthy segmentation existing.

There are Amigas which support MOVE16 and people use this instruction.
There are Amigas which have FPU and Amigas without FPU, and code that uses the FPU.

We want to improve this.
Our new cards will all have 100% the same instruction set.
All cards are designed to support all instructions including MOVE16 and FPU.
I think that this will help to provide are common coding ground.
The cards also offer a lot more CPU power e.g 200 Mips for budget pricing.

I think that this will make coding easier in the future.

[biggun]

So you've managed to get everyone to agree to buy into your ISA extensions? How depressing. It is truly a sad day.

The ISA extension are 100% compatible with old code.
There are no negative side effects.

All old code will work.
And new code has the option to use them for your benefit.

But no one is forced to upgrade now to a 200 Mips CPU.

If you do not want more Mips, more perfomrance, higher memory bandwidth or faster instructions - simple just keep your old CPU.

[biggun]

As I say, it segments the platform, and the added value is low. If the added value would be higher, I the ratio would be better and I would be for it.

Maybe the ISA should really not be discussed here.
Most people do not understand the topic and get only confused.

Regarding forward compatible of old system.
The new card offer performance levels of 68030 systems with 500-1000 MHz.
How sensible is running future games or demanding webbrowser
which will depend on this speed on 16 MHz 68020?

Regarding whether the added value is low or high.
Trust me the added value is HIGH the changes give over 300% speed up  in FPU area for example.

I can show you example code which demonstrates this.
If you want more details to understand this - lets move over to Apollo forum.
Here is not the technical audience.


Cheers

[biggun]

If you are going FPGA which is better at parallel processing instead of raw MHz just keep going with it. It will probably end up better or faster than a Coldfire system.

What can be done on the software side to fix this? Could you add libraries that make it Coldfire compatible?

To whom do you talk?
Phoenix is  faster than Coldfire already.
What do you want to fix in software?

[biggun]

The added value of the modified ISA is certainly not HIGH.

What is your definition of high?
Is trippling the FPU speed with new ISA high?