@CosmosUnivers

So whats your plan then?

And how will you execute it in practice?

Last edited by Overflow on 19-Sep-2018 at 09:20 AM.

@CosmosUnivers

why don´t you contribute to Aros 68k then?

@cdimauro

regarding Apollo team member, I am not aware of anything

In fact I have not even realized it as long as I can log in. And even if, I always say what I think, of course normally in a polite manner without personal attacks. I do not care if I am official team member or not. The reality is there was no real plan regarding Aros in the apollo team and up to now there is a problem I think with booting from IDE hindering use of Aros on Vampire. I said developing a special distribution before this is solved makes no sense to me. Up to now nothing has changed and people (including team) seem to be very happy with coffin.

I do not blame coders not supporting 68k or Aros 68k. Existing 68k developers obviously moan from time to time but are not willing to invest time in it. On UAE Aros 68k is very good useable so I do not miss anything. On Vampire is Coffin so everybody is happy. No problem to me. For Aros I see lots of opportunities on RPi (ARM). Attract new developers is difficult to impossible because market is too small when you look at Vampire (a couple of thousands at best). So vampire (or apollo) alone never could succeed, if I would seriously think about developing something for 68k I would hardly code it for vampire but general for amiga 68k at least using more ram and the higher processor power so that it runs on extended classics, vampire and UAE... we will see what happens in future

I should have seen the professional 68k developers as a apollo team member? Why? The apollo team members are testing, developing drivers and are partly directly involved in FPGA development. None of them is involved in OS development or interested to do that. No blame from me, just the fact. I talked about 68k programmer outside who could help if interested. But obviously they are not (unfortunately)

BTW it seems that they have reduced who is official team member and who is not. Not really important

Last edited by OlafS25 on 19-Sep-2018 at 10:40 AM.

@cdimauro

Yes UAE could do that

Problem is Toni Wilen is not interested in supporting something like Vampire, what is no problem to me as long people use OS calls and not directly hit the hardware. The bigger problem is the existing developers that are still there and are mostly on NG are not supporting 68k with the reason that the existing hardware base (mostly 68030 + some ram) is not powerful enough for new games. And in a discussion I mentioned UAE and one developer admitted that UAE might be powerful enough but makes no sense to him because then you could use Windows versions. Besides that amiga (in whatever form) never makes sense because everyone has Macs or PCs with Windows or Linux next to amiga as hobby, Vampire with more processor power and ram (and RTG) might motivate to support 68k in future. If people make special versions for vampire or general versions who run on different platforms is up to the potential developers.

@OlafS25

I think Toni's main issue is that Apollo Core is a moving target, since its reporgrammable.

BUT Toni has also said money/donations makes him forget he doesnt love what hes targetting (like AOS4.x support/PPC).

@Overflow

what concerns long standing problem with booting aros on vampire we have not enough cooperation from the vampire team. there was one person on aros dev ml but the communication was sparce on both sides. i myself have had long standing problem booting aros from a4k internal ide. we were investigating it with toni for months, before he realized what was wrong. it really takes time and effort to insist on things and try to motivate and help developers, its not like ping them and say: this or that doesnt work for me, please fix.

@Overflow

ah I understand ;)

@wawa

I think (despite talk) there is not much interest in the vampire team regarding aros

they have coffin what is highly illegal and not adaptable but it seems they are happy with it at the moment. Aros would need investment of plenty of time and obviously it is not on the priority list

@OlafS25

Is it lack of intrest or the issue that plague us all at this phase in life (30 years +++++), the sheer lack of time?
Core development in addition to everything else (RL), Coffin seems like a nice and relatively easy stopgap solution.

@Overflow

I do not blame anyone, just say how I see it at the moment

everybody with real world life has limited time

But Gunnar and others seem to think new software and OS comes out of thin air but that will not happen. At the moment I do not see a real strategy there. Software drives hardware (not the other way round).

@OlafS25

Quote:

there is not much interest

i think there is a basic philosophical disagreement. usually if there are some skilled people left in the scene, they dont want to engage with larger distributed projects or pursue what one would consider somewhat perspectivic approach. usually they want to concentrate on their own little project, on which they have full control and dont even need to argue with others. therefore all these rom/library replacement projects, therefore kickstart 3.1.4 is considered step forward. therefore all these concurrent approaches to port some software to your dedicated system. and this is understandable.

@Barana

Quote:

Is this guy the same bloke who forgot to put the negative rail in the new Ppc accellerators and blamed his customers for it?

I doubt it, but funny that you mention that, since"the customer" was Chucky, and Chucky is also a Vampire owner who has his views on the Apollo Core 68080.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Barana

Quote:

Kolla knows all about this, as it is just this sort of behaviour that got him first labelled as a troll on the Apollo forums, got him three warnings (and his avatar changed to that of a troll under a bridge) and finally kicked of the forums all together.

Three warnings, I wonder if you can point to them? It was really more like twenty odd hints on a scale from warnings to personal insults, changing my avatar, chning my profile name back to my real name without my consent, renaming it back (I bet Tuko was involved) certain team members using my nick on other forums, various ridicule here and there.

As for banning, I was not really banned, I can still log in....

Quote:

You have to become a verifed forum user to continue posting. Some of your posts did not match our forum usage rules. Unfortunately some people misuse the annonymity of the internet to insult people. To verify that you are a genuine person we kindly ask you to email as a proof of your identity. Please email us a copy of your ID card or driving license or similar to info@natami.net. As soon as we recieve they proove of your identity you will be able to fully use the forum again. Many thanks for your understanding!

Considering what scruffy "team" who is running the site, and "their" history of abusing such information, I have little interest in providing the kind of ID asked for - Gunnar knows _perfectly well_ that I never had multiple accounts etc. that various minions accused me of.

Anyways - these are the days of GDPR, who knows what I may end up doing...

Quote:

All I'm saying, yet again, is that kollas trolling won't be tolerated and we will report him when he does.

Interesting - who is "we"?

Last edited by kolla on 19-Sep-2018 at 01:02 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Overflow

Quote:

Overflow wrote: @CosmosUnivers So whats your plan then? And how will you execute it in practice?

Same plan and modus operandi as "Team Coffin" it seems - ignore copyrights and push his own binaries.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@OlafS25

Quote:

The reality is there was no real plan regarding Aros in the apollo team and up to now there is a problem I think with booting from IDE hindering use of Aros on Vampire.

The reality is there was no real plan in the apollo team - full stop. All signs point to a rather ad-hoc development schedule.

You can boot AROS from IDE using the AmigaOS scsi.device (which Apollo Team appears to have licensed), so that is really no big hinderance for them.

Last edited by kolla on 19-Sep-2018 at 01:09 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@OlafS25

Quote:

Problem is Toni Wilen is not interested in supporting something like Vampire,

Wrong. Toni is not interested in supporting something like Apollo Core 68080 - he is just fine with "something like Vampire".

It's the 68080 that is the problem.

The reason why there is no 68080 optimised AROS is not due to lack of 68k assembler coders, it is due to lack of support in compilers - AROS is supposed to be portable C code. And the lack of support in compilers is due to 68080 being a crusade by on or two CPU designers who appear to have little/no contact with software developers. Normally when CPU design is taking place, it happens in coordination with compiler back-end developers, so that toolchains are updated according to hardware. But in the case of 68080, there is no such cooperation.

Last edited by kolla on 19-Sep-2018 at 01:27 PM.
Last edited by kolla on 19-Sep-2018 at 01:21 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

kolla wrote: @OlafS25 Quote: Problem is Toni Wilen is not interested in supporting something like Vampire, Wrong. Toni is not interested in supporting something like Apollo Core 68080 - he is just fine with "something like Vampire". It's the 68080 that is the problem. The reason why there is no 68080 optimised AROS is not due to lack of 68k assembler coders, it is due to lack of support in compilers - AROS is supposed to be portable C code. And the lack of support in compilers is due to 68080 being a crusade by on or two CPU designers who appear to have little/no contact with software developers. Normally when CPU design is taking place, it happens in coordination with compiler back-end developers, so that toolchains are updated according to hardware. But in the case of 68080, there is no such cooperation.

Yes, that is true atm
Maybe it's due to the fact that 68080 is still WIP and so it's structure is not yet "Set in stone".
If it's like that maybe we will see this kind of cooperation whenever the CPU is more stable.

Just my 2 cents, eh...

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

Check my Amiga gameplays (ITA)!

@cdimauro

Quote:

Exactly. There's a paper which talks about PowerPC SIMD units evolution and which explains why, with VSX, they decided to "unify" the FPU and Altivec registes to provide a uniform, 64-entries, registers sets with the last SIMD extension:

Read some of that and can understand the move. Sounds better than doing it the Intel way and hacking vectors into the FPU registers. Though vectors have been bolted onto both ISAs. Interesting how they can maintain backwards compatibility.

Quote:

Anyway the above paper explains also the reasons behind the need to have more registers with SIMD computations. They found 64 to be a good compromise, but maybe 32 for a CISC can be okish too.

CISC does tend to fare better with register to register moves. That is when moving from general to floating or vector. Compared to PPC.

Quote:

What's very important is also the total number of registers, for keeping more data on registers (loops unrolling included).

And with a total register count you bring in another hard limit.

Quote:

The problem comes when/if you want both...

In this case no one can have their cake and eat it. Large data width at the expense of available registers. Or large register count at the expense of available width. A compromise between count and width. There usually is a compromise when making design decisions.

Quote:

No. Since Motorola sistematically changed the MMU for its processors, we can think about completely dropping the MMU instructions mapped on F-line, and introduce some new MMU instructions (in some 32-bit opcode space) to deal with the MMU, like it happens on all architectures which have no coprocessors support.

Looks like they dropped the F-bomb there. Well, the F-line was more suitable for FPU, since F stood the FPU when there was an FPU.

Quote:

Good question. There are pros and cons having a unified GPR set, and separated ones for addresses and data. I prefer the former, but the latter is a clear win when code density is important.

That's interesting. Another matter of compromise in design decisions one might say. When seeking other benefits.

Quote:

However each segment had single-byte granularity and can be transparently extended (up to the maximum limit: 64KB). Very nice features.

Okay, so a bit easier for small data model code? And making large data code more manageable?

Quote:

We can say that it come from 80386. However this processor is segmented, exactly like the 80286. The only difference is that every segment is max 4GB in size (instead of 64KB).

That's massive. I wonder how they did that. Going from 8K to 64K and extending that to 4GB seems no mean feat. I mean, you've got what 13-bits grown to 16, then extended to 32.

Quote:

Many o.ses decided to ignore / don't use segmentation because 4GB was enough for a segment, so basically flattening everything.

Nice trick. Makes sense. Until 64-bit comes along but then I bet the old trick comes back into play.

Quote:

No, AMMX is very different from MMX. It only uses some MMX concepts (e.g.: integer operations, and not having a separate registers set).libs.catalog It would help if Gunnar didn't recommend to read a technical guide on Intel MMX if AMMX is very different. Looks as if he is really trying to convert the last of the 68K Amigans to Intel. Right before taking their 68K souls and sacrificing it to the Intel gods. [quote]No, you can also use "odd" values for depths: 1, 2, 3, 5, 6, 7. Even with such "strange" depth values, packed/chunky modes were/are much easier to handle (and with better performances & efficiency) than bitplanes.

Well you could but it doesn't pack as well as 2 multiples. They would likely need to be right aligned to the closest nibble.

But a 1 bit depth is an interesting examples, since at 1 bit packed and planar are exactly the same. So with that in mind, how does a 1 bit packed/chunky mode handle better than a 1 bit planar mode?

Quote:

Bitplanes are the exact contrary: they are memory (space, bandwidth) inefficent. See above, and think about it.

I've thought about it. At least with an interleaved bitmap, a chunky and planar mode will take up exactly the same amount of memory, at the same 2 multiple bit depth. (1,2,4,8.) With each whole line taking up the same amount of space.

With other depths like 3,5,6 or 7 chunky would use more memory overall.

That leaves the hardware to read from each plane separately. Which would incur a penalty But given hardware was slower back then it seems a funny decision to make.

Quote:

You can do it with 2 packed pointers as well. :-8

Maybe, but the dual playfield mode on the Amiga relies on bitplanes to function. As well as other parallax layers and effects. Any disputes ocver that you can take up with saimo.

Quote:

Packed/chunky are much better. And they don't require a mask for cookie-cutting operations.

They require some form of masking out. But what about a 1 bit chunky bitmap?

Quote:

Or having smaller objects to draw. Think about gun bullets: they are have a small width, but on the Amiga they needed to be 16 pixels wide...

Which is where those 68K ANDing and ORing instructions come in handy. Or using the blitter.

Anyway, the decision was made, for better or worse the Amiga became famous or infamous for those damned bitplanes. They didn't update it. We just got a load of "fake"RTG cards wth packed modes. So it stuck.

@OlafS25

Quote:

OlafS25 wrote: @OneTimer1 shall I comment the performance of PPC based browsers without JIT versus standard hardware that is now years old?

You can, if you are bored but this would prove nothing.

This thread is about 68k and we all know how bad the last browsers on this architecture are.

Quote:

It is boring always to see OneTimer, Kolla and ppcamiga always saying the same nonsense

Maybe that's the reason why you ignore it and keep writing off topic crap.

Quote:

Why are people outside not jumping on your great PPC hardware?

I don't knwo why you are calling it 'my great PPC hardware' this thread is about 68k and we all know how bad the situation is with 68k hardware.

Quote:

Where are the millions of customers?

I don't think a list of millions of PPC user would prove anything about 68k and if I would post such a list, it might crash this forum.


Quote:

All have hidden under the table?

No, they switched to other platforms.

Quote:

Vampire is a toy, a nice hobby platform for former amigans who are willing to spend the money for it and some nerds. Nobody claims different

I was just talking about this stupid PPC bashing done by Gunnar and his minions, and your behavior confirmed my thesis.

There are a lot of Amiga Fans who try to keep their 68k hardware alive or try a simulation under Windows, Linux, AROS x86, AOS4 or MorphOS. Some of them have different systems up and running. This stupid 68k vs. PPC bashing doesn't help, it will not lead to faster 68k hardware, it will just make the Apollo team less trust worthy.

Last edited by OneTimer1 on 19-Sep-2018 at 06:38 PM.
Last edited by OneTimer1 on 19-Sep-2018 at 06:16 PM.
Last edited by OneTimer1 on 19-Sep-2018 at 06:01 PM.

@OneTimer1

I am not involved in the apollo development and I say what I want as you do

as you should have seen I have also critisized what they do and am no fanboy

For me your gunnar and vampire bashing is as stupid. It is only somewhat funny if people using and public supporting hardware that is in todays terms oldfashioned and dead end bash others who use hardware that is old fashioned in todays terms. Both are retro platforms (in case of vampire to a certain degree improved) and the PPC platforms who call themselves NG but are not really. So you and the other one should enjoy what they use and let others have their fun.

Last edited by OlafS25 on 19-Sep-2018 at 06:41 PM.