68080/68060 discussion, comparisons etc

[Chucky]

MMU have a limited use. but for developers it's use is pretty damn useful. and in a real 060 it is there. why go to less? missing instructions can be handled in 68060 lib. missing MMU can't.


well tg68 is opensourced anyway. meaning you CAN use it.. you are not locked into that one person you could maintain it.. I do not know why noone made any more effort of doing something with it yet. but heard it been whispering of someone working on something. as sources is there. nothing happens if the author thinks fck this. or get struck by a bus or anything. again. as an IT Consultant. if any of my clients get a system depending on one (or 2) persons I stronly disagree with the idea is it is simply too insecure.. (and sadly. it DOES happen shit)


080 people brag about restoring instructions. but removing a quite large function (MMU) suddenly is no problem. that is a logic that doesn't compute for me. especially when missing instructions is so simple to handle (ok with a performancepenalty)

[flype]

Originally Posted by Chucky

thing is still that it had one bug identical to TG68K (was noticed in a demo. that I for the moment cant find the reference to) so something feels weird there..

Nexus gouraud fx, maybe ?

Note that i'm not defending any cpu (i clearly like '060 for what they are), but i know well this bug since i tracked it (with big help of uae).

This is normal that both tg68k and 080 had that bug, independantely, since the 'bug' is about some undocumented side-effect, and illegal instruction, that worked by luck on real 020 (and if Motorola would have spotted it, they would even probably changed its behaviour in a new cpu).

[Promilus]

if any of my clients get a system depending on one (or 2) persons I stronly disagree with the idea is it is simply too insecure

Ok, in x86 terms you have exactly that... either intel or amd. Whole world seems so insecure now...

but for developers it's use is pretty damn useful. and in a real 060 it is there

Not in EC versions... and when it comes to relying on unsupported instructions, illegal ops that just makes things crazy (and in your terms that's way too insecure!) Both TG68 and AC68080 reacts as they supposed to per 68k specs. Now there might be ppl missing MMU functionality but when it comes to "either MMU or FPU, either MMU or RTG" it's pretty obvious it just makes no sense to dwell on the subject. It gives too little benefit for the work it takes to implement. And while it just might someday appear it doesn't mean that's the main focus of those developing softcore 68k based turbo cards. It's basically way down the list of "nice to have".

[Chucky]

intel or amd is quite large companies. it requires quite alof for them to go down. compared to a 1 or 2 person team.


EC versions hey yes exactly you hit the spot the 080 is an EC cpu. Embedded Controller.. exactly what i tell people.. it is not a full CPU.. they want to make it a "modern cpu" still it doesn't have a MMU.. even YES very few use it. it is still not there. so it is not a full cpu. it lacks the MMU! and if you add lots of fancy stuff. you want developers.. but if they cannot use their debuggingtools they are used to?


actually it was the same with the FPU! Gunnar refused to accept that people wanted it. people even got kicked out of the forum asking about it.. then femu arrived. showing people it could run fpu code (SLOWLY) THEN suddenly he noticed that "ok maybe people want it" simply just not listening to the requests. HOW could you then licence your work into a thing like that where you need to forcly prove that "this would be great" lack of communication is the biggest issue. .(that and a way to big ego. there is an MMU you cannot reach it but it is the best of MMUs ever) (ok not exactly phrased but yeah telling the attitude)

it is sad. Gunnar DO know his shit. (EVEN if it is a copynpaste job. still requires skills) but he for sure need to work on his communicationskills..

(like I need to work on my spelling etc :-D )

[Promilus]

it requires quite alof for them to go down

Tell that to commodore, 3dfx, NEXTStep and plenty of other companies who failed along the way ... and AMD is even smaller than nvidia

it is not a full CPU

It is. It has no MMU-included version. It never had. It's the way it was designed. It is exactly what is named AC68080

it lacks the MMU

It's not requirement. 68000 or 68020 does not have it either and still that's CPU. What's funny 8086 or 80286 didn't have either and both were CPUs as well. You must understand MMU is peripheral unit just like FPU and not a part of core itself. It was later integrated but initially 68k had MMU as separate chip MC68451 just like it had separate die FPU 68881 or 68882.

people even got kicked out of the forum asking about it

Well while tracking what's going on there with all those "gold" cores for V2 I know an answer for that. It has become impossible to implement full 64bit FPU (not even extended 80bit precision of 68881/2) AND AC68080 AND AMMX AND RTG AND SAGA in FPGA that small. Something has to go. It's nearing it's limit with 77k LE they have with cyclone V from E series as well. And most ppl wouldn't even need FPU it they had no SAGA or RTG to back this up. Seriously... what would you need FPU for when using OCS? Exactly. For nothing particularly. Having RTG actually gives some more options but there really aren't all that much software which does require FPU. There are things which were higher on the list. That's most likely cause it was getting on Gunnar's nerve to keep asking for FPU.

HOW could you then licence your work into a thing like that where you need to forcly prove that "this would be great" lack of communication is the biggest issue

Well let me then spell it for you... at this very moment this is the ONLY ONE really powerful 68k compatible softcore you can get. So it's either that... or nothing. Having choice between 1 man show and nothing - well you can't blame ppl for joining his camp. It's perfectly valid decision if that's what you really need. Raw power. Why? Because there ISN'T any alternative except going to emu camp all the way. Might be harsh but beggars can't be choosers. We're starving for attention. We have been for more than 20 years now. With every possible solution gaining supporters and opposition as well. Like PowerPC movement. And within PPC community Blue Team and Red Team... so MorphOS and AmigaOS4. This whole thing is insecure, fragmented and fragile. I'd love to see less of those internal wars. It just doesn't help. At all.

way to big ego

Well he has results to back this up. And with circle of followers ego just happens to bloom. Ppl are like that. Not just Gunnar.

[Mr-Z]

Originally Posted by Chucky

RTG have NOTHING to do with the 080!.. I have RTG on my 060 machines aswell, both my Warp and my bigbox. (or well. currenltly I have no bigbox as I haven't built my AA3000+ yet )

it is bearly faster than the 060. stop comparing sysinfo screenshots.
but I do not care.. I watch a MPEG video on a raspberry pi much smoother if that is a thing I want to do. and my Warp plays mp3 without breaking a sweat

Then i wonder why everything is running so much faster on my 080 then on my 060/60 (that also has RTG trough CVPPC)....
My PC plays MPEG even faster!
But since you don't care why are you responding ?

[Chucky]

RTG via CVPPC goes via a 25MHz (!) PCI bus while RTG via vamp (080) goes through a direct databus to cpu.

and why is everything running faster. well why does audio sound better for audiophiles when they stack their cables on expensive woodenboxes? they WANT it to be better so it feels better

[Promilus]

@Chucky - RTG on Warp is in Artix7 which bridges DDR3 DRAM to 68060. And part of that memory is directly available to RTG without any small-throughput bus. But 060 performance is still lower and 060 bus is much slower - that's a limiting factor. It doesn't make much difference when it comes to 3D games, neither of those RTG (CS, Apollo Team) supports hw acceleration of 3D (Warp3D). I can hardly believe 3D titles using hw accel can run on V4SA faster than on BVisionPPC or CVPPC and Warp3D.
That's in reference to

why everything is running so much faster on my 080 then on my 060/60 (that also has RTG trough CVPPC)

And to make long story short - every classic motorola CPU will be limiting factor even if you get a full PCI or even PCI-E class performance for video cards. Not that RTG on Vampire is state of the art. It's severely lacking in 3D aspects and won't improve much. To get anisotropic filtering and anti aliasing you'll still have to have 3D card.

[Chucky]

yes on the warp the RTG is directly and you notice that on RTG tests.

060 performance lower? well if you read my texts if you check my review video and systest results it shows a higher result than vampirescreenshots i have seen. sure at 95MHz but still it shows a better result.

3D acceleration on Amiga is more or less not used anyway, I see no reason to put alot of FPGA space into that as it is so exemly limited anyway.

[Promilus]

I see no reason to put alot of FPGA space into that as it is so exemly limited anyway

Well then you missed the point which I made... to have dedicated hw to do that
In terms of 2D games it's hardly any real advantage to have faster CPU. Even Baldur's Gate used 3D acceleration (in some parts, like spell effects and character rendering, the rest of the screen was flat like a pancake). Heroes of might and magic was DirectDraw, yes, same with Red Alert. We don't see either despite VCMI and OpenRA being available for quite some time now (and yes, GemRB as well, this only worked on AOS4 iirc). Arguing what is faster in 2D... well then go ahead, that's not really what I'm worrying about.

[Chucky]

then I also must confess: I have not a single clue about games on the Amiga. never played any

[AMike]

Originally Posted by Chucky

060 performance lower?

jubimark (Lightwave 3.5) is a real world benchmark that also needs the FPU - even a Warp1260/105 or MKII60/125 is slower than a normal V1200 X12 core. And as owner of several 060 systems I can confirm this, I don't know any application where a 060 would be faster.
https://drive.google.com/file/d/1_Vx...Th0gfgp3n/view

[Chucky]

well. if a fpu gets a "double" instruction but only handles it as "float" good enough for most yes. but it will run faster..
you know. it is faster to do a half-assed job than a real

[AMike]

Originally Posted by Chucky

it is faster to do a half-assed job than a real

The result is the exact same picture as on my A4000 - no difference.

[Chucky]

diffed files?

[Don_Adan]

Originally Posted by AMike

The result is the exact same picture as on my A4000 - no difference.

Do you compared binary files output from 68060 and 68080? If i remember right 68080 for A1200 has only 64 bit precision, like all (?) UAE results for jubimark. Then output file is perhaps different, even if this is not visible. FPU 80 bit for UAE works slower.

[Chucky]

thats why I asked if he have diffed the files

[Promilus]

@Don_Adan - quoting FAQ

The Vampire Standalone has an Altera Cyclone V FPGA, which has enough space to accommodate the full 64-bit FPU Core. However, Vampire accelerator boards connected to a classic Amiga have an Altera Cyclone III FPGA, which does not have enough space for the full 64-bit FPU Core. Therefore, on these boards, the FPU Core had to be reduced to 52-bit precision, to make it fit. This precision should be enough to run most apps, games and demos requiring an FPU.

It doesn't seem to be apple to apple comparison when 060 indeed works with full ieee754 compliant double precision.

[Don_Adan]

Originally Posted by Promilus

@Don_Adan - quoting FAQ

It doesn't seem to be apple to apple comparison when 060 indeed works with full ieee754 compliant double precision.

Seems you dont understand me. Apollo FPU in V4SA must works identical like others 68882, all output/CCR results must be same. If dont works identical then has bug, maybe invisible for average Amiga user. Im almost sure that renders from Jubimark for 68060 and for 68080 (Cyclone III) are different, differences can be not visible, but exist. Same for WinUAE results in 64 bit mode. For V4SA, I dont know. But if V4SA has not buggy FPU then must be same.

[Chucky]

it it should be "compatible" it needs to behave like one!