ADOOM on A600 running 22-35 FPS

[Rob]

yes, do you understand what "compact" may mean?

Compact like this?

[wawrzon]

can we return to topic? it was only a remark on my part, i see it would take pages to explain it so lets just forget this.

[biggun]

But then it would no longer be m68k, would it?

Why not?

Sometimes people ask some funny questions..

[Karlos]

Why not?

Sometimes people ask some funny questions..

I've occasionally wondered what the 680x0 might have become if it had  achieved the same sort of popularity as the x86. The latter had a lot more severe obstacles to overcome with respect to the horrible ISA, historical transitions of the architecture from 16 bit to 32, then 64, not to mention things like virtualization. Yet it managed to succeed thanks to lots of money and skilled engineers working around said train wrecks.

The 680x0 is unarguably a superior architecture than the x86 was when considering forwards compatibility. 32 bit registers from day 1, virtualization issues resolved by the 68010, sensible instruction layout, good fpu integration (the x87 is a nightmare in comparison). Imagine what the same reservoir of cash and talent could have accomplished with it.

It's not hard to imagine the registers growing to 64 bit, a few new instructions for 64 bit wide operations and additional SIMD extensions being added for multimedia.

Meanwhile, in reality...

[biggun]

I've occasionally wondered what the 680x0 might have become if it had  achieved the same sort of popularity as the x86. The latter had a lot more severe obstacles to overcome with respect to the horrible ISA, historical transitions of the architecture from 16 bit to 32, then 64, not to mention things like virtualization. Yet it managed to succeed thanks to lots of money and skilled engineers working around said train wrecks.

The 680x0 is unarguably a superior architecture than the x86 was when considering forwards compatibility. 32 bit registers from day 1, virtualization issues resolved by the 68010, sensible instruction layout, good fpu integration (the x87 is a nightmare in comparison). Imagine what the same reservoir of cash and talent could have accomplished with it.

It's not hard to imagine the registers growing to 64 bit, a few new instructions for 64 bit wide operations and additional SIMD extensions being added for multimedia.

Meanwhile, in reality...

Yes in fact, Phoenix does touch many of these areas already.

A number of improvements are in Phoenix

* some address mode restrictions removed
* more work registers
* fully pipelined FPU
* We even have developed a Vector Unit ...

[alphadec]

please continue your fantastic work I want this board.

[Rob]

can we return to topic? it was only a remark on my part, i see it would take pages to explain it so lets just forget this.

Sorry, I was just playing, and of course I really want a nice little expansion for my CD32.

[Djole]

How come nobody is seeing this card is a revolution started by Majsta. It is the best thing happened to AMIGA since AGA. A card that will be affordable and will outperform anything available thanks to majsta, biggun  and the rest of talented people. Majsta started the revolution in Amiga hw and made it open source so all of you haters and demanders can make your own version and add 100GB of fast ram and 200GB of chip ram so you can open 1000 tabs in an non existing browser for 68k.

I salute Majsta and biggun and wish them all the best in their work and if they decide to make the card 8MB i will buy it.

[ElPolloDiabl]

If you are going to the next step in 68k. How much of a speed boost would you get by adding more math units on the chip?

[fishy_fiz]

How long is a piece of string?
Seriously, that's so vague as to be unanswerable. Im not sure you even truly understand what youre asking, or else you'd have asked a question that can be answered in a way other than "how long is a piece of string"  :-)

Maths units? Interger or floating point? Also, just adding extras doesn't automatically make it faster.

[QuikSanz]

He may have a point. I don't think a 68K Amiga can ever use a good GPU, some extra math units maybe helpful.

[fishy_fiz]

Again, simply saying "maths unit" is vague to a point of it not really meaning much.
I assume it's meant to be floating point units, but that's not what has been said.

Also, *any* gpu will help a 68k cpu. Voodoo3, radeon 9200, heck even s3 virge.
There's little point in adding anything better than whats available anyway. GPU's need cpu grunt to get the most from them. Adding support for anything faster will add pretty much nothing.
It's amazing how many people are under the impression that a gpu is enough. It's not. It needs cpu grunt to get the most from a gpu.
For example, running a 5ghz i7 + radeon hd 5850 is often faster (especially for minimum framerate) than a 3.4ghz i7 + crossfire 7970's.

[guest11527]

* some address mode restrictions removed

While I'm all for the Phoenix, this is an "improvement" I do not agree with. There are reasons for these "restrictions" all along, and Mot made a choice with these restrictions. The reason why d(PC) and d(PC,Xn) is read-only is a good one: Everything that these two ea's can address is in the "text segment", also known as "code". "code is not supposed to be modified", this is what Motorola expresses here clearly. If you want data, put that into a data segment and address it either absolute or relative to a segment pointer (aka a4).  One should not forget that the Motorola FPUs have an external address space that is larger than 32 bit. It is 32+3 bit, 32 address bits plus three "function code bits". Whether these have been used in the Amiga is another question, but as far as the CPU architecture is concerned, this is very consistent with the "restrictions" of the addressing modes. d(PC) is a "instruction space access" and hence read-only, as all instruction space accesses. d(an) is a data access, and hence has a function code identifying data accesses, and hence is read-write.  I would pretty much prefer to keep this clean model, no matter whether it is actually enforced in the Amiga or not.

[biggun]

Mot made a choice with these restrictions. The reason why d(PC) and d(PC,Xn) is read-only is a good one:

Of course I can also see the "idiology" of MOTO behind it.
But lets also look at the reality.
During the project we did disasm so many programs and looked wwhat they do and how well the CPU can do it.

There were many programs programs doing this often and very often
lea (d,pc),A0
addq.l  #1,(A0)

So if a programmer or compiler decided to update local variables in such a way
and does this 1000 times in his program - then so be it.
With the old address limitations he can still do it. But the programs executed 1000 instructions more, and is 2024 Byte bigger.

[ElPolloDiabl]

As far as I know an 040 and 060 has a single branch to execute floating point operations. If you had three branches or more would you get some seriously fast math operations. If not what would limit it?

[biggun]

As far as I know an 040 and 060 has a single branch to execute floating point operations. If you had three branches or more would you get some seriously fast math operations. If not what would limit it?

68060 FPU was not pipelined and most instructions took at least 3 cycles.

Phoenix FPU is fully pipelined and can do a 80bit FMUL every clock cycle.
This means clock by clock the Phoenix FPU is already 3 times faster than an 68060.
This means a 100 Mhz Phoenix is FPU wise in theory as strong as an 68060 @ 300 MHz