@wawa

I believe attempting a 68K port is worthwhile. The Vampire V4 boards should be out some time this year. They will have close to SAM440 performance.

I am sure you are aware there is also bebbo's cross-compiler toolchain that has had a lot of work put into it for 68K code generation.

There is a docker setup here: https://github.com/sebastianbergmann/docker-amiga-gcc. Please note that I am no docker expert.

@wawa

I browsed some OWB code yesterday. A couple of (sad) remarks:

1) surprisingly lot of platform-specific code in seemingly "general" class (ResourceHandleManager) :(
2) almost 0 documentation for them :(
3) some comment had "OS4"... I must wonder why it wasn't inside of __amigaos4__ define then?

So is the general situation so that main/event thread is running and perhaps waiting for some trigger? What is the precondition for scrollbar theme to load?

@gregthecanuck

Quote:

They will have close to SAM440 performance.

Benchmarks show raw integer performance comparable to 100-150 MHz 440EP.

@wawa

You're free to work on it, and as Andre (who I can assure you I've been far unkinder to than you, although I respect him more) has pointed out, should you manage to sort out all those endian dependency issues you'll have people climbing over each other to get to your door.

On the multiple accounts, my University (and now part-time employer) has changed my e-mail account three times in less than 1 year (first from a student G-mail account, then to an Outlook student account, and now to an employee Outlook account) and thanks to their using some kind of weird aliasing converting the last two to @.wilmu.edu accounts, its made them incompatible or buggy with the Outlook application itself.
AND these accounts don't forward message from older to newer addresses. SO, if I lose track of and password (since I usual let the OS I'm working with save them, and they occasionally crash) I can't get a password reset message from this site.

Hey...maybe they should give us the option of a second e-mail verification address so that I could give them a backup (which I do maintain, but DON'T freakin' check).

And I would dearly love to use that old alias.
I am now using one of my oldest passwords here, on MorphZone, and on Amiga.org.

And unlike most of you, when I started out, btw, and Andre can verify this, I used my real name, not any of these geeked out nicknames.
Oh and the reason I'd prefer to use the original name here? Its not a nickname if you make it up yourself, and that one traces back to my High School days.

Karlos knows who tf I am, because I asked for this to be addressed awhile ago and it hasn't been.

But I'm not hiding or making excuses, I tried to address it and the moderators and the sysop failed me.

SO, to get back to the discussion, and your objection a some kind of "meta" discussion, your free to try and fix the problem. But its stymieing better programmers than you.

Several of the MorphOS developers have played with this source code, and one of our best, Mark Olsen, has just re-committed to finishing the JAVA JIT code we were hoping for.
But long term, the endian issues will pop up with each new revision of Webkit.

Its a moving target. So go ahead and try to solve it, because even if you can...as soon of as a new revision of WebKit is released it will popup again. It will be like a computer programming analog to "whack-a-mole".

Look the 68K is dead, the PPC (outside of the last Power revisions) is dying, and all common platforms are now little endian.

So coders are being a little lazy and releasing code specific to the hardware used the vast majority of the end user base.

And the ONE solution that will eliminate this problem, THAT you want to dismiss.

I'm not the one that's being hard-headed here. I got beat up enough in the '90s for being that way, and again, the sting of that has not yet abated.
Can't take the bad news?
Then keep looking for the light at the end of the tunnel (a get run over by the freight train headed your way).

In any case, cut out the personal crap. I'll change my account to allow direct messaging to my primary e-mail account, direct any of the snide person crap there, and then I can actually make a truly rude response that won't face censorship or get me temporarily banned.

In the meanwhile, don't reduce this site to a clone of moobunny.

@gregthecanuck

Quote:

They will have close to SAM440 performance.

No, they won't.
Its still an FPGA.

And the SAM440 is actually not that great a platform for web browsing.
One thing I'll agree with with the OS4 community, Tabor will out perform the SAM440 in that application, and many others.

And even that may be just barely enough.
Our current G4 platforms, including those that outperform Tabor, sometimes struggle with some web browsing tasks.

An real 68060 at 80 Mhz doesn't do this well, and a 200 or 300 Mhz 68060 wouldn't be that much better.

So how is and FPGA 68K going to match an 800 to 1200 MHz PPC (or much better hardware)?

Simple answer, it isn't.

When you show me a multiplayer game running on a Vampire based system, networked with other computers displaying 32 bit color screens at 1080P resolutions, THEN I'll apologize for being wrong.

But as I cut my teeth on 68K based systems in the real world, I don't think the hobbyist community is going to be able to pull off something Motorola and Freescale didn't manage do do.
Even Coldfire V5 doesn't run above 600 MHz.

I'm pretty sure you're all being led astray, as this community has in the past, by promises that won't materialize.

This doesn't mean that the Vampire 4 won't be a quantum leap over older 68K hardware, but close doesn't get you to the next rock while jumping to cross a raging stream.

Dead is dead.
And unlike on TV, dead is just what it used be..

@arthoropod

Quote:

Dead is dead

we are all in it for the dead stuff here. morphos, os4, aros x86/arm/x64/ppc/whatever are all in the same state of being dead in the water as m68k. "the degree of being dead" hardly matters in practice (if there is any). an attempt to get todays grade browser core on any these platforms is insane. better you realize that up front.

Last edited by wawa on 25-May-2018 at 09:25 PM.

@Mr_Capehill

Quote:

I browsed some OWB code yesterday. A couple of (sad) remarks:

this is all lack of common engagement and/or result a lack of proper maintenance. ill have to consult kas1e branch if there is anything i can refer to, but feel free to hint me for anything, that needs to be changed for os4 or ppc or big endian or even a diff of what needs to be done or tested. and thx for constructive feedback;)

@wawa

Quote:

an attempt to get todays grade browser core on any these platforms is insane. better you realize that up front.

Cool, at least we seem to share some common beliefs/points.

Good luck in your project.

Sometimes "realists" are just people that want to dump fertilizer on something that you're interested in or makes you happy.

If I held negatives against people, I'd hold a grudge against Bill Buck and Power2People for not joining in promoting the PPC boards I wanted to see built.

Instead, I found some Linux hobbyist that are as crazy as I am.

Don't let anyone ever rob you of your dreams or goals.

@wawa

Quote:

this is all lack of common engagement and/or result a lack of proper maintenance

You have to remember the original "heavy lifting" for this project was all done by one guy, who has a family now.

And the AROS X64 version works for the reasons I've previously harped on.

From what I understand (maybe misunderstand), it is Mark Olsen's intent to open up the Java JIT code (at least the was the hope I heard from some TenFourFox developers).

So that's one contribution, and you guys convinced Fab to release the code you started with (but that may have required a "ransom") , and there could be more cooperation between different "camps".

But the red and blue "camps" are promoting differing proprietary products, and only "team black" (AROS) is an open platform.

So, if you get the endian bugs worked out, are YOU willing to feed it back to the community?

Because AROS PPC and MorphOS communities could use it, and they've "kind of" been contributing.

Frequently once someone initiates this type of conversation, we all end up in a snarled s-storm, like sled dogs that when told to "mush" just attack each other.

But consider our original starting point, and our commonality, developing Odyssey as a collective project (and maybe MUI) makes more sense then say the OS4 community trying to port a monster like Firefox, while the Amiga 68K community tries to continue the development of really antique browsers, and the MorphOS and AROS communities fork off in another direction.

Having a more unified development community would allow us to spread the work load out better, and not leave us focused on or relying on a few really productive coders (or other productive, but glacially slow coders).

Probably won't happen though. After all, if the OS4 community gets an Open Office port, are they really going to share it?
When the Firefox port was announced, they were all blustering about how they didn't really need our browser.

And not many OS4 programs get ported to other NG platforms (the smart coders do it to increase their potential market, but other are just as balkanized as the user base is) .

But divided we represent even smaller markets, and I don't foresee a unification of the three OS' (four if you count AmigaOS 68K separately).
Programs that at least run on all 3.1 API based OS' would be one way to one way that might (with a little consideration) work.

Last edited by arthoropod on 26-May-2018 at 02:21 AM.
Last edited by arthoropod on 26-May-2018 at 02:16 AM.
Last edited by arthoropod on 26-May-2018 at 02:13 AM.
Last edited by arthoropod on 26-May-2018 at 12:47 AM.

@wawa

That's what's I mean. It's generally easier to cross compile on Linux. There are guides to doing it. And with CMake it needs a toolchain file. The same problems also need to be solved like locating libs and working with static output. The Linux package could do with some work when I installed it. But apart from that it works. I tend to copy my SDL Local drawer over from OS4 as it's easier to AmiUpdate than manually update it on Linux. Which I tried.

@pavlor
Quote:

Benchmarks show raw integer performance comparable to 100-150 MHz 440EP.

Are you sure we are talking about V4 benchmarks?

@arthoropod
Get your *private* google or outlook email and it stays the same whatever your university change...

Of course you should count 68K separately and same as AROS it is more "open" than OS4 and MorphOS

@ExiE

Absolutely, I should have left my registration tied to the G-mail account I've had for years.
It was not the most intelligent thing to reference my primary e-mail account.

Never insinuated that I was the most intelligent scrub here, just that I learn from past experiences, and sometimes even then, slowly.

And David Morris has been warning me that these excessively long posst look like a symptom of manic behavior, but then many of us tend to worry about the eccentric behavior of members of the Amiga community and that it might point to instability.

Right now, I'm just hyped about my current projects which span from currently unsupported PPC system to ARM.

So if I occasionally abuse any of you, my apologies.

In past professions, its sometimes came in handy the be a bit of an ahole just to end a discussion and get something productive rolling.

Bad habit with today's group oriented "touchy feely" way of doing things.

Last edited by arthoropod on 27-May-2018 at 12:43 AM.
Last edited by arthoropod on 27-May-2018 at 12:42 AM.
Last edited by arthoropod on 26-May-2018 at 09:56 PM.

@Mr_Capehill

Quote:

What is the precondition for scrollbar theme to load?

i have started from the other end (curl) but it is still uncertain where it actually halts, becuase cmake tends to either not to recompile after some slight change, like adding debug statements, or to recompile the whole source, which takes ages. maybe i should really look for where loading scrollbar theme is tiggeed from.

Last edited by wawa on 29-May-2018 at 06:25 AM.

Talking about up to date web-browsers.

It is what made me sell my Amiga 060, CVPPC around 15 years ago.

Odyssey web-browser on AROS is very compatible. If only the security part where updated it would be almost like any other web-browser out there.

Sure also the html 5 player need some love on AROS version. There is something strange with the synch, video, sound I think that makes it behave kind of buggy.

Talking about all this. As browser sitiuation was worse 15 or more years ago on a platform that in that time lost almost all its users.

Flash is no longer a problem. We have Amigalike OS running on x86 CPUs.
In my view it is simple. AROS is the only way for the future of web-browsing on amiga like platforms.
Probably the only way for future ports of most applications.

It is just a shame so little people see this. I understand it is little money as it is open source. Might be the biggest problem. There is still a chance to earn money on the bounty system or find a way to support a developer to work on it.

I'm very happy wawa have brought this up and eventualy there will probably be some updates.

Don't give up wawa. I'm backing you 100%. I'm just afraid the 68k version from what I understood will never happen. I know it is what you realy want from it but still hope you consider and see the importance of the project for x86 or even arm.

Last edited by nikosidis on 29-May-2018 at 10:20 AM.
Last edited by nikosidis on 29-May-2018 at 10:18 AM.
Last edited by nikosidis on 29-May-2018 at 10:15 AM.
Last edited by nikosidis on 29-May-2018 at 10:09 AM.
Last edited by nikosidis on 29-May-2018 at 10:09 AM.
Last edited by nikosidis on 29-May-2018 at 10:07 AM.

@nikosidis

Quote:

I know it is what you realy want from it but still hope you consider and see the importance of the project for x86 or even arm.

i have already started the work on merging the current webkit with the existing aros code., but since it isnt simply a patch and because the source changed quite a bit, it is complex to handle. i could perhaps be comitting it to my git repo as i go. and of course the first platfom to be compiled would be x86 anyway, it s what it is supposed to run on nevertheless, right? though and as i dont know if i really do the right thing and i dont see anyone who would help or counsel me with it anyway, so i dont see any reason to come forward with it at this point.

other than that please accept my priorities. they are as they are. should m68k be dropped id probably go away.

@arthoropod

Quote:

and you guys convinced Fab to release the code you started with (but that may have required a "ransom") , and there could be more cooperation between different "camps".

I helped write that ransom note(bounty) tyvm ;)

_________________
Support AROS sponsor a developer.

"AROS is prolly illegal ~ Evert Carton" intentionally quoted out of context for dramatic effect

testing odyssey on sam-440 emulation reveals that aros gcc-ppc backend emits lwsync instruction, which is not supported by this cpu similarly as on e500 cpus. id like to know if and how os4 gcc handles this.

with gcc-6.3.0 we thought about adding sam specifivation to gcc/config/rs6000/rs6000.h after line 713 in the manner:

Quote:

diff -ruN gcc-6.3.0/gcc/config/rs6000/rs6000.h gcc-6.3.0.aros/gcc/config/rs6000/rs6000.h --- gcc-6.3.0/gcc/config/rs6000/rs6000.h 2016-07-07 21:42:07.000000000 +0200 +++ gcc-6.3.0.aros/gcc/config/rs6000/rs6000.h 2018-06-05 16:41:15.686870318 +0200 @@ -712,8 +712,8 @@ /* E500 cores only support plain "sync", not lwsync. */ #define TARGET_NO_LWSYNC (rs6000_cpu == PROCESSOR_PPC8540 \ - || rs6000_cpu == PROCESSOR_PPC8548) - + || rs6000_cpu == PROCESSOR_PPC8548 \ + || rs6000_cpu == PROCESSOR_PPC440)

(not sure if something like that is correct, just trying, therefore my question)

@wawa

doesnt seem to work that way. is there an explicit flag to pass to gcc in order to compile ppc code for that processor?

@wawa

Quote:

lwsync instruction, which is not supported by this cpu similarly as on e500 cpus.

never mind. it has been solved, at least locally on my build environment, fix, or rather workaround, emulating the missing instruction in result of a trap, has not yet been committed.

there are further issues to sort out, though, on ppc.

meanwhile, for those interested, here is an x86 binary of odyssey that should contain newer openssl (1.1.0) and video support (untested):

https://1drv.ms/u/s!AuvzEgbTrkxPgaxFf54VWguW4XwPCw

(i remind, that these are avi v1 binaries. they wont work with aros distribution, only with x86 abi v1 nightly)

Last edited by wawa on 14-Jun-2018 at 12:09 PM.
Last edited by wawa on 14-Jun-2018 at 07:25 AM.