Amiga.org
Amiga News and Community Announcements => Amiga News and Community Announcements => Amiga Software News => Topic started by: bernd_afa on November 11, 2009, 02:34:37 PM
-
Here is ixemul for 68k.
there is also a warning file in that this should not install on MOS or OS4 because the 68k emu miss some features here(correct SSP USP stack Emulation of 68k registers).
http://amiga.sourceforge.net/phps/logger.php?download=ixemul-62.1-m68k.lha
this are new features, note also the SDK is more enhanced to compile modern Linux programs better.
The ChangeLog is as follow:
* 2009-09-01 Bernd_afa fix a problem when more child threads use network access (fix Internet stream play with ffplay without source changes)
* Linux return a address when call malloc(0), so there are some programs out (all that use milkshape loaders) that fail if this is not do.now ixemul return too a address and this programs work.
* when there is no HOME enviroment var in your env dirs, then ./ is return from getenv. before it return 0 and this let some programs crash, or do no prefs save.
* This make complete remove of programs more easy and is amiga like. So there is no problem that HOME dir grow lots by saving all config files in 1 dir and fit better in amiga enviroment.
* If you dont like that config files are store in current dir and that it is called as HOME, then create a env var HOME with path to dir you want.
* 2009-07-11 Diegocr Added the task's blacklisting features to the buddy allocator.
* Improved poolmem to be somewhat faster...
* Removed a Forbid/Permit pair around malloc's b_alloc() call which does not seem to be needed.. (buddy allocator)
* Memory's Pool and Semaphore are created regardless of the allocator being used, but not freed on exit when using the buddy way - Fixed.
* 2009-07-01 Bernd_afa fixed a filesystem Bug introduce from MOS Version for programs that use AHI output (fopen("audio:..")).
sound is now play correct
* use now old buddy allocator again, because netsurf need very good memperformance but poolmem system do after some netsurf use lots slowdown (more than 3) because of mem fragmentation in poolmem.For using memtrackers, there is a poolmem version attached, named ixemul.library_poolmem.
* 2009-05-29 Diegocr
o Updated IXPrefs to Version 2.8 Added options which control how malloc() should react when running out of memory.
o Added a button which launches a external program to the Task's Blacklisting management, it's currently made using MUI, and loaded from SYS:Prefs/ixbl_MUI (either via WBRun if it's found, or falling back to 'C:Run <>NIL:')
* library/hwck.c
library/ix_blacklist.c (new)
library/ix_settings.c
library/ixemul.h
library/ixprotos.h
library/malloc.c: Implemented task's blacklisting features.
Certain options can be configured globally (from ixprefs) or per-task (from ixbl_MUI), When a global option is enabled but the same option over a blacklisted task is disabled, the later is taking into account. Same if you disable a global option and it's enabled over a blacklisted task.
Those options should be intuitive and easy to use. However, you'll find additional info on the buble-helps from the ixbl_MUI program.
-
Here is ixemul for 68k.
I was going to write a rant how wrong most of those changes are. Then I realized you will not listen anyway, and deleted the post.
Ixemul is a lost cause.
-
I was going to write a rant how wrong most of those changes are. Then I realized you will not listen anyway, and deleted the post.
Ixemul is a lost cause.
you can also write what you think about this.
the malloc(0) return adress feature is too in newlib in.
we also not sure what do with HOME.WHat do you suggest ?
that ixemul create HOME var always if not exist ?
But problem is, maybe some programs get confused.Miami for example set HOME.
but all in all this changes help to port with fewer work new linux/Unix Soft.
-
I suggest respecting local variable HOME before using global HOME.
-
If HOME is missing you could just throw a requester kindly asking user to reinstall GeekGadgets.
-
ixemul maintainers, you *must* fork v60+ and rename it. It is not 100% compatible with v48 even running on 68K.
If you need proof, try running Abuse (http://aminet.net/package/game/actio/Abuse060-upd) with v62 and then with v48. See which one works.
I imagine there are other programs that behave similarly.
-
OWB is another example, iirc.
I agree, fork and change name - let it be possible to have both old working pre v50 and this new experimental stuff on the system at once.
Was v49.26 ever released?
-
ixemul maintainers, you *must* fork v60+ and rename it. It is not 100% compatible with v48 even running on 68K.
If you need proof, try running Abuse (http://aminet.net/package/game/actio/Abuse060-upd) with v62 and then with v48. See which one works.
I imagine there are other programs that behave similarly.
then please report this programs.
Does 68k abuse run ok on MOS and OS4 ixemul ?
Have you test abuse 68k with ixemul V48 and wipeout and enforcer running and this do no Hits ?
can you give me a link or upload the abuse datafiles that run on this old Version ?
>OWB is another example, iirc.
this i always test if it work.have other find problems that OWB do not work with the new ixemul ?
This work on my system
>Was v49.26 ever released?
no because when do that and programs ask for V49 they get the OS4/MOS native ixemul lib and crash the system.
So the number is increase to avoid crashes on that system if a user try a ixemul program.but OS4/MOS ixemul seem not very compatible and very few programs can run, so i
when try for example 68k nzbget or 7z this crash on OS4.
it cant say 7z is wrong written because it run long years on many Linux systems, so the problem must be in OS4 ixemul.
And if there are so much ixemul programs that have problems on OS4 and MOS, i really think that not the V62 ixemul must rename, because i try it to make 100% compatible and fix bugs soon.
But of course i can only do it, when the Bugs are report.
But on OS4(maybe MOS have same Problems) side there seem nobody fix the Bugs, and so 7z 68k work since long time not on OS4.
I have no OS4 sytem, so i cant test all programs and see if the run.but when such small programs as 7z crash on OS4 is really not much hope that ixemul work good here.
>I suggest respecting local variable HOME before using global HOME.
thats same as in old ixemul.
-
I have not tried 7z on MorphOS but AFAIK there are no known bugs in MorphOS ixemul. It does not mean it is bug free but MorphOS ixemul is perfectly compatible with the original 68k ixemul software. Minor bug fixes have been here and there with enforcer hits.
Only exception is applications which are using statically linked ixemul code and wont work in MorphOS. Similary 68k ixemul.library wont work in MorphOS. IIRC vfork() is major problem there.
-
I have not tried 7z on MorphOS but AFAIK there are no known bugs in MorphOS ixemul. It does not mean it is bug free but MorphOS ixemul is perfectly compatible with the original 68k ixemul software. Minor bug fixes have been here and there with enforcer hits.
Only exception is applications which are using statically linked ixemul code and wont work in MorphOS. Similary 68k ixemul.library wont work in MorphOS. IIRC vfork() is major problem there.
maybe you can try it.just a simple start is enough.that there are not known bugs happen maybe because users do not use MOS and ixemul software.or if the soft not work, they accept and dont report, because they like more native software
But i notice lots bugs that happen in 68k programs with ixemul from MOS and new MOS code.
All in all i can say it was a mistake to use the MOS version but its possible to fix this bugs
http://amiga.svn.sourceforge.net/viewvc/amiga/ixemul/stdio/fread.c?revision=16&view=markup
If you like i can send you the image so you can test if it work on MOS
try also this test
http://aminet.net/package/mus/play/pmdplay_68k
It was compiled under "ixemul.library 48.0".
Under that it is working fine.
Under v61.1 it does not play through AHI correctly.
All Bugs are fix in V62.1 to revert to old Code fromV48
its very important to make rock solid libs to have much users that test and report if they see a problem and that there are lots programs out.
and when i change the libname, i think i dont find this bugs,because there were not much programs here.
Try also on MOS Version abuse 68k if it work.
I see now it work well on V48 but with V62 it hang during load at ca 35% in endless loop
so i can search the bug.there is no reason wy V62 or MOS code should fail.
same with abuse, the bug can not detect, when the new libs do not run with old programs.
I really want that ixemul V62 based on MOS source should be 100% compatible to old.
-
maybe you can try it.just a simple start is enough.that there are not known bugs happen maybe because users do not use MOS and ixemul software.or if the soft not work, they accept and dont report, because they like more native software
I dont know but I am using ixemul software daily because I code using GeekGadgets environment. And it is the same for rest MorphOS developers.
But i notice lots bugs that happen in 68k programs with ixemul from MOS and new MOS code.
All in all i can say it was a mistake to use the MOS version but its possible to fix this bugs
It could have been easier use the original 68k source code and import only bugfixes from MorphOS version. MorphOS version is MorphOS version and AmigaOS compatibility is not maintained there.
http://aminet.net/package/mus/play/pmdplay_68k
It was compiled under "ixemul.library 48.0".
First of all it is broken port because it is using ixemul. Ixemul is meant to be used only with software running in GeekGadgets environment.
But I can try it out later anyway. I dont have Internet at home and my Efika is not running yet either. It is the same with Abuse. Though, Abuse should not have used ixemul either...
With ixemul you run into other problems because ixemul supports Unix paths along Amiga paths and Unix paths have precedence. When I started working on SDL I thought that I should support both Unix and Amiga paths but later I realized I should only support Amiga paths. Unix paths should be fixed in the ported application instead including $HOME.
I have ported only one SDL game using ixemul where it was too problematic port it using libnix. Luckily it works even though SDL on MorphOS can load files only using Amiga paths. On every other port I have fixed Unix paths to Amiga paths and fixed $HOME to use PROGDIR:. In early days I didnt care about $HOME and my ports were cluttering $HOME on my GeekGadgets installation.
-
I dont know but I am using ixemul software daily because I code using GeekGadgets environment. And it is the same for rest MorphOS developers.
Its more easy to do a lib that run only a few programs well and dont test other programs
>First of all it is broken port because it is using ixemul. Ixemul is meant to be used only >with software running in GeekGadgets environment.
but it work with V48.there are lots programs compile in last year from diffrent devs that work well with Linux or amiga paths.so there is no reason see currently that a geek Gadget system install is need.
So limit ixemul only to few programs is not need.
because time is short the easiest way can go to get soon a result
Here i have a link to the 7z OS4 user test and fail on OS4 native ixemul
http://aminet.net/package/util/arc/p7zip-4.65b-m68k
-
It could have been easier use the original 68k source code and import only bugfixes from MorphOS version. MorphOS version is MorphOS version and AmigaOS compatibility is not maintained there.
the MOS ixemul configure script support that options, and run also good on crosscompile.ixemul V48 i cant compile on crosscompile such easy as MOS Version
# Any additions from configure.in:
ac_help="$ac_help
--enable-ppc build ixemul for MorphOS"
ac_help="$ac_help
--disable-ppc don't build ixemul for MorphOS"
ac_help="$ac_help
--enable-m68k build ixemul for AmigaOS"
ac_help="$ac_help
--disable-m68k don't build ixemul for AmigaOS"
ac_help="$ac_help
--disable-cat don't catenate sources before compiling"
ac_help="$ac_help
--with-cpu=x build the server for cpu x (x=68020.68881, 68000.soft-float, powerpc.604e, ...)"
-
Its more easy to do a lib that run only a few programs well and dont test other programs
Most if not all binaries in gg:bin are ixemul including gcc2, gcc3 and gcc4. That is plenty of software. I also ported Ruby to GeekGadgets. And when you look at Ruby you see why ixemul and GG is usually used together: directory layout of Ruby fits perfectly to GeekGadgets.
but it work with V48.there are lots programs compile in last year from diffrent devs that work well with Linux or amiga paths.so there is no reason see currently that a geek Gadget system install is need.
But there is no any reason to use ixemul for non-GG software. There is libnix for that. And clib2. Why would you use Unix paths on an Amiga Internet browser?
So limit ixemul only to few programs is not need.
because time is short the easiest way can go to get soon a result
In MorphOS we are using libnix for quick ports. Sure, lbinix for 68k is outdated but then MorphOS developers extended and developed libnix more to get it more compatible and up to date.
-
But there is no any reason to use ixemul for non-GG software. There is libnix for that. And clib2. Why would you use Unix paths on an Amiga Internet browser?
there is also no reason to use ixemul not.if there is really a problem with unix and amiga OS paths, then tell a example.
its also possible to add a function that ixemul should use amiga paths, if there is really a problem.
a program that really fail with the unix paths can maybe call the function ForceAmigaPaths.Then there is set a flag in userdate structure that all open commands of this task and subtasks use no unix path translation.
But currently i have this not add, because we see no program that make problems.
having unix paths is also a enhancement for AOS and fit good in AOS.
instead Progdir: you can just write ./
>In MorphOS we are using libnix for quick ports. Sure, lbinix for 68k is outdated but then >MorphOS developers extended and developed libnix more to get it more compatible and up >to date.
I dont know how much MOS libnix is update, is there somewhere a explain of funcs ?.Is there full C99 support ?.
Can with this ffmpeg and ffplay compile with comfigure and make ?
clib2 as far not good enough to compile a GCC or ffmpeg/ffplay without changes.also clib2 have the mess that all libs you link must written for clib2.so there need 2 sets of libs.so i think clib2 should not use.
I think ixemul have far the best Linux/Unix comapibility and when use Linux code, its best to use the best.
nobody use a Linux from 1999 and port Programs to it.All update their linux so programs can port easy.and thats reason wy i update ixemul.
>Most if not all binaries in gg:bin are ixemul including gcc2, gcc3 and gcc4. That is plenty >of software. I also ported Ruby to GeekGadgets. And when you look at Ruby you see why >ixemul and GG is usually used together: directory layout of Ruby fits perfectly to >GeekGadgets.
With ixemul you can do lots more and it work perfectly mix AOS and Linux.
If the MOS devs dont like that, and their lib is only test with GCC geek gadget and ruby and not with the ixemul programs that are out, then this lib should be better named as mini_ixemul for MOS and OS4.
but now its too late, i have spend some work to fix Problems in MOS source and add missing features that it cost lots more work to begin with V48.
But the good news is, it seem all programs (except abuse) work as before.
-
there is also no reason to use ixemul not.if there is really a problem with unix and amiga OS paths, then tell a example.
For example if you have path "/foobar" will it work right?
having unix paths is also a enhancement for AOS and fit good in AOS.
Sure, why not make it default in AfAOS.
instead Progdir: you can just write ./
But what if I want to access a file named "." or even ".." ? And I want to use PROGDIR:. This is Amiga, not some Unix clone written by some Torvalds.
I dont know how much MOS libnix is update, is there somewhere a explain of funcs ?.Is there full C99 support ?.
I dont know what C99 exactly needs from it but new headers like inttypes.h were added.
Can with this ffmpeg and ffplay compile with comfigure and make ?
Dunno. I never tried. But then, ffmpeg is shitty Unix software.
I think ixemul have far the best Linux/Unix comapibility and when use Linux code, its best to use the best.
If you want Linux compatibility I can recommend installing Ubuntu or Kubuntu. AFAIK they have better Linux compatibility.
If the MOS devs dont like that, and their lib is only test with GCC geek gadget and ruby and not with the ixemul programs that are out, then this lib should be better named as mini_ixemul for MOS and OS4.
Nah, MorphOS build is full ixemul build. It supports all ixemul features. It is just that MorphOS developers are not trying to bring Unix to Amiga. If you want Unix, get OS4.
-
>For example if you have path "/foobar" will it work right?
i make a dir /test in dopus magellan it create only a dir test in current dir.
i open a shell and type dir /test and a error come.
so what should happen on AOS when do this ?
most time GUI amiga programs use a filerequester, and here you get too no problems with amiag path or ixemul.for example amistuff have enhance ffplay to show a amiga filerequester and read Icon tooltypes.all work well with ixemul. so i see no reason wy with ixemul cant use a amiga GUI.
When create a amiga task and want use ixemul funcs in subthrerads only what you need to call is ix_CreateChildData func before any ixemul lib call.
So you can have both of 2 worlds a Amiga OS API and a complete Linux/Unix API.
also on shell. most users use only simply filesyntax that is most time same in AOS and linux.
of course ixemul support also amiga drives.for example progdir:xxxxxxx
work in ixemul and SYS: etc and volume names work in exemul too
>Sure, why not make it default in AfAOS.
the problem is on AFA OS run many amiga software, maybe this can make problems.i cant test all
>But what if I want to access a file named "." or even ".." ? And I want to use PROGDIR:. >This is Amiga, not some Unix clone written by some Torvalds.
thats more a theory.Do you know a program that use . or .. as file ?
>Nah, MorphOS build is full ixemul build. It supports all ixemul features. It is just that >MorphOS developers are not trying to bring Unix to Amiga. If you want Unix, get OS4.
sadly on OS4 ixmemul work too not full.I still have no MOS tester see, that say me that this ixemul programs work well on MOS.
I see no diffrence of OS4 or MOS.there are near 0 written amiga programs now.most come from Linux opensource world.
>If you want Linux compatibility I can recommend installing Ubuntu or Kubuntu. AFAIK they >have better Linux compatibility.
My main reason to stay on amiga is the amiga program amiblitz.here i have written lots code with that(software synthesizer Bars&Pipes wrapper to use plugins etc).I do not like MUI or Reaction, i like Storm Wizard, because it have a nice GUI Editor so i can get fast a GUI without recompile source.
My software synthesizer have 170 GUI elements in diffrent tabs and 1 window.I think its hard to keep an overview about this, when i like change something when this is in MUI or reaction syntax.
but there is also nice Linux Software here.so wy not use it.but i dont spend lots work to port Linux soft, because i dont like MUI or Reaction.Storm Wizard cant furtherdevelop so need go another way.
GTK i think is acceptable, there are nice GUI Editors here so i have hope, that i can soon change all my software to gtk+ and zune and use the GUI Editors.
I realy dislike linux and C, but C and Linux Soft is good, when you need not write lots code because the code you need is here.but if code thats not here, i can do it faster with amiblitz.
for example i write the AFA prefs program in amiblitz.have only 390 lines and there are 84 GUI elements.all in all i spend in AFA prefs 3-4 hours of work incl GUI make and test.
do the layout of the GUI can everybody easy do with storm wizard, so there are no programming skills need.
and this i hope to get soon with gtk to MUI wrapper too.
-
I dont know how much MOS libnix is update, is there somewhere a explain of funcs ?.Is there full C99 support ?.
Can with this ffmpeg and ffplay compile with comfigure and make ?
Newer C99 functions aren't all there. But i still compiled ffmpeg and ffplay today to compare behaviour against some mplayer bug. There were only two missing c99 math functions (cbrtf() and some round() variant). It's certainly not rocket science to implement them if they're missing, and a much better idea than using the full blown ixemul just because of that.
-
I compiled FFplay with libnix a long time ago, but it crahed. I have no motivation to spend my time to debug what is wrong, after all this would change nothing for me, except that FFplay would use no ixemul.lib :afro:
For example if you have path "/foobar" will it work right?
This will only work with progs when someone add a code to support paths like this. I added the code to FFplay, so something like this should work.
Dunno. I never tried. But then, ffmpeg is shitty Unix software.
These days we have only "shitty Unix software" on Amiga. Without this software Amiga couldn't even play DiVXs (MooviD also uses this "shit" -> libavcodec.library, the same FroggerNG (FFmpeg/XAnim) and I belive all of the rest PPC video players) :afro:
-
These days we have only "shitty Unix software" on Amiga.
But still we have at least some people making a little extra effort and doing proper ports and not just recompilations, all that other junk you might as well run on linux.
-
But still we have at least some people making a little extra effort and doing proper ports and not just recompilations, all that other junk you might as well run on linux.
You are welcome to do it better.
-
Developers that don't know the difference between /mydir on amiga and un*x - how reassuring - not :(
You can't say whether /mydir is un*ix or amiga path out of context, as it's valid path in both - the un*x equivalent of amiga /mydir is ../mydir and the amiga equivalent of un*x /mydir is mydir: - isn't it obvious?
I'm happy that I'm as a user no longer have to mess around with this since the amiga systems I use so often that running un*x software is relevant, are emulated ontop of linux anyways. Via scripts, mapping of /proc and /sys inside UAE, named pipes etc I can even control lots of the linux host operations from within UAE if I want/need that. :)
-
Newer C99 functions aren't all there. But i still compiled ffmpeg and ffplay today
So then please make it available for download.
I have talk about that in german forum(July 2009), because there was bashing too against ixmeul.But a well known serious MOS user was so friendly and post some links to MOS ffmpeg versions.newer versions he not find
This are all old and incomplete Versions.
http://www.amirus.org.ru/files.html
http://piru.morphos.net/%7ep/bin/old/
http://jahjah.free.fr/tools/
http://jahjah.free.fr/morphos/
he also start ffmpeg and post a list of supportet formats,
http://www.amiga-news.de/de/news/comments/236915.html
the build from ami_stuff have lots more codecs and ffplay.All builds on OS4 or MOS have no ffplay.
if you dont believe that the 68k ffmpeg have more codecs and is newer, please download the 68k file and test in UAE.
type in shell
ffmpeg -format
intresting is that there is a MOS ixemul ffmpeg Version here, and this is larger in size and it support also more codecs.
its possible to remove easy codecs in ffmpeg/ffplay if this cant compile.and when look on exe size of ffplay in MOS and OS can also see, this is lots smaller as 68k code.
but because PPC code is due to risc larger so a ffmpeg exec on PPC must be 50%-100% larger.
I also look in the ffmpeg files from MOS, to search if it load some external libs but they dont.
ffplay is build from the ffmpeg makefile and is in include in all ffmpeg packages i see.But not on OS4 or MOS.
So this seem that this OS are not able to build it and also there are no actuel Versions.
-
But still we have at least some people making a little extra effort and doing proper ports and not just recompilations, all that other junk you might as well run on linux.
the problem is, this changed Ports are not keep upto date, because the devs seem have no time.
netsurf MOS, outdate
ffmpeg MOS i find no upto date Version
sure there are some so called System seller Software as OWB mplayer, that seem upto date, but when you look who do that, you see OS Developers do that.normaly OS devs do not port programs if there is less time.normaly they can enhance the OS and other can do the ports.
sure they are excelent programmers, but they cant do all, maybe they do it only now, because they hope that more MOS or OS4 is sell and they get lots money then.Only time tell if OWB or thunderbird is upto date in 5 Years too.
The problem is there are near no programmers that write software for Amiga.
So only new what come is Unix Software.and so a amiga System must be able to make it easy possible to port Unix software, that at least upto date Unix software is on amiga
If not, then there is only few Software here that is outdate.No great reason for many, to invest much money in a Amiga system
-
So only new what come is Unix Software.and so a amiga System must be able to make it easy possible to port Unix software, that at least upto date Unix software is on amiga
All this will run much better on unix.
No great reason for many, to invest much money in a Amiga system
But what is the point of using an amiga system if all you use is unix software?
-
All this will run much better on unix.
But what is the point of using an amiga system if all you use is unix software?
this you must ask OS4 or MOS Users.I stay on 68k, because i have lots of AOS software i want run,like to use dopus magellan , amiblitz.this linux soft is develop on Linux and nobody of the devs take care with changes if amiga version work.amiga devs must change then so it still work with newer version.
but netsurf fplay ffmpeg firefox, mplayer OWB, openoffice, blender is a Unix soft, and this also not change if you make support for amiga filenames or add a MUI GUI instead of using a gtk to mui wrapper.
when time is short, then its better than nothing or a old version a straight linux port.later can of course add more features that you miss in unix software.
-
when time is short, then its better than nothing or a old version a straight linux port.later can of course add more features that you miss in unix software.
Mhh well... running UAE on Linux you could easily run these things in their native environment, saving your precious time for.. whatever else? I prefer ports that are better adapted to the "amiga" environment. Usually have remote or local access to systems much better suited for unix apps than amigaos.
-
But still we have at least some people making a little extra effort and doing proper ports and not just recompilations, all that other junk you might as well run on linux.
ffplay and netsurf have too lots amiga specific addons, that are not on linux world.
There is no reason to strip down a linux port that it run on a small libnix or newlib to add new amiga Features.
The /foobar i see now what it do and it fail on ixemul, i didnt notice because i need that feature not.Please tell when you have the last time need this feature ?
but its real no problem to tell ixemul that it not should translate paths to linux paths depend on task.i need just add a function in libc.a that set a flag in userdata so the open commands know to not translate to unix Paths.then all is same as with libnix in file behavior, when a program call this func on start.
I add that feature in coming V63 versions, i guess it need around 5-10 source lines, so if somebody need it, he can use it.
the library number must of course increase so user get inform when lib is too old...
-
Mhh well... running UAE on Linux you could easily run these things in their native environment, saving your precious time for.. whatever else? I prefer
but you know, Linux users use diffrent desktops like kde gnome and some other.I like dopus magellan 2.thats not here on linux.
Linix apps fit good on amiga OS system even if they only port, because you can use all dev tools and system tools AOS have.
for example if a program do not work, you can look on AOS with snoopdos.linux have too such things
But because Linux is a so much blow up system, you get 1000 ends of fileaccess, and system react lots slower as an amiga System on UAE.
Also linux system is much complicate to understand, the feature when click in a window that it pop to front i dont like.
so there are still lots reason, wy should use a program in amiga OS enviroment than in Linux enviroment.
>I prefer ports that are better adapted to the "amiga" environment
I too but i see no reason wy for this the Linux program must strip down to work with libnix or newlib, when there is a full Linux API(ixemul V62) that need no strip down.
-
Why would I want ffmpeg on any of my 68k systems?
Why all this talk about MorphOS and OS4 when this thread is about 68k ixemul?
-
Why would I want ffmpeg on any of my 68k systems?
Why all this talk about MorphOS and OS4 when this thread is about 68k ixemul?
Because the code based on Morph OS Version.
and when i fix bugs in the code to run ixemul software then this statement come.
@Itix
>Dunno. I never tried. But then, ffmpeg is shitty Unix software.
then i show that MOS Version that use libnix in ffmpeg is incomplete and ffmpeg in 68k support more codecs and is complete with ffplay.
I think Itix is a excellent programmer and i dont understand, that he bring as argument against ixemul the use the linux paths.
I hope he know that its the easiest of the world to add a func that a ixemul task can switch of translation to unix paths.so ixemul handle files in same way libnix do, but ixemul support lots more unix funcs and allow teh port of Unix programs more easy.
And wy a ixemul program can have no amiga GUI or amiga like code, i see too no reason.
and that ixemul is slower as libnix, is also not possible, because boith libs use Linux API code.
Only diffrence is ixemul V62 have more linuxapi funktions.
And change programs to run on a smaller lib instead enhance the lib i see too no reason.
its only useless work because this must done on all programs
-
ffmpeg and ffplay aren't up-to-date on MorphOS because we already have up-to-date mencoder and mplayer ports, that are more capable.
Anyway, i ran my compiler today (with libnix), and here's a build from a recent ffmpeg snapshot (less than a week):
http://fabportnawak.free.fr/misc/ffmpeg.lha
To be noted it has altivec (autodetected) and network support (means you can play or encode stream).
Of course, "implementing" these two features wasn't a straight compilation. It took at least 5 minutes. :)
-
then i show that MOS Version that use libnix in ffmpeg is incomplete and ffmpeg in 68k support more codecs and is complete with ffplay.
Why would anyone use ffplay on 68k?
If it's a real 68k, it is simply too slow, and if it's an emulated 68k, the host systems have much more capable native variants.
I hope he know that its the easiest of the world to add a func that a ixemul task can switch of translation to unix paths.so ixemul handle files in same way libnix do, but ixemul support lots more unix funcs and allow teh port of Unix programs more easy.
And wy a ixemul program can have no amiga GUI or amiga like code, i see too no reason.
and that ixemul is slower as libnix, is also not possible, because boith libs use Linux API code.
This makes no sense to me.
If you have time and resources to actually code AmigaOS specific additions such as a GUI, you definetly also have time and resources to fix the code so that it doesnt have to rely on ixemul for something trivial as converting paths. Anyways, I thought the point was to mimic NetBSD, not Linux. At least that is what the docs that come with ixemul say.
-
Why would anyone use ffplay on 68k?
If it's a real 68k, it is simply too slow, and if it's an emulated 68k, the host systems have much more capable native variants.
FFplay is a part of FFmpeg package - it's a bonus program. You must also remember that FFplay can play audio files like flac, wv, ra and all of the rest, not only videos plus it can show images saved to some exotic formats like jpeg2000. Also, on the real 68k I would use FFplay to see what is on the video if there is a need and no other video player support the file format or used codec. I belive it's still better to see something than nothing.
PS. When you install Amithlon there is no native variant, native variant is 68k program.
-
>ffmpeg and ffplay aren't up-to-date on MorphOS because we already have up-to-date >mencoder and mplayer ports, that are more capable.
but mencoder or mplayer are Linux programs and when there is ffmpeg or ffplay here, i see better chances to do a amiga like program that have the spirit of amiga and is easy to use and self explain.
I still want a videoplayer that is also able to cut videos and save the cut as a new file.it should be easy and fast cut, see virtuel dub seek for scene cut, and set beginning marker, end marker and press del to delete this piece.and a undo function it should have.
but all can do with ixemul
>Anyway, i ran my compiler today (with libnix), and here's a build from a recent ffmpeg >snapshot (less than a week):
oh, i hope the MOS users are not angry about me, when you as a OS dev do that instead work on MOS to get faster support to more MAC Hardware or enhance OWB.
but i see on your filesize it seem not so much features as ffmpeg 68k.i give the link to MOS user so he can test what codecs your build now support, but when i look on filesize the PPC version is very small, so it seem not all codes are support.you also say you use altivec and normal version, this increase file size more.and we know PPC code is larger as 68k code.
your unpacked PPC ffmpeg is 5 meg and ffmpeg on 68k is 7,4 megabyte in size.MOS link libnix static ???
If so, then a ixemul program is too little smaller.
newest ffmpeg from ami_stuff have(not release yet but it work) have support for liboil and libschroedinger.this is more in size.I see no liboil or libschroidinger for MOS or OS4.
but ok, i know that the MOS devs have enhanced libnix as closedsource so its better as libnix on 68k.And the MOS devs dont want it make opensource to have a common API and make porting prgrams more easy.
But this behaviour is a big reason for me to not buy MOS because i think it not very fair to use 99.99% opensource code and then add only few stuff and do it closed source and want sell the new with a new OS that run only on slow Hardware.
Why would anyone use ffplay on 68k?
On youtube and all getvideo support you can show with netsurf 3gp files.This feature is not in SDL netsurf in, Artur have add this feature and use the getvideo script.
this are for handies with low resolution and this can show on a classic too with good speeds .also ami_stuff have add feature that ffplay can show images and videos in SW.Its faster.
and its also possible to have faster native Hardware.FPGA get cheaper and faster, and whne there is software that need that faster Hardware then nobody can say wy i need faster Hardware, there is no software
I it's an emulated 68k, the host systems have much more capable native variants.
amistuff have add nice features to ffplay.you can save a picture with key s.show me videoplayers that can do it easy.
Also in ffplay you can rewind or forward in Video files with cursor keys.Show me player that can do that so easy ?
ami_stuff have speedup the seek to a video Position a lot, so ffplay 68k is faster when forward or rewind in vídeo files.
and time will show, what amiga features ffplay/ffmpeg get more.I plan a easy to Video recording/editing Software in amiblitz too.there is also no problem to do that with ixemul.
BTW: I see that was MOS devs do as bad propaganda, maybe now the blue versus yellow war have begin ?
but i dont care about this, also when MOS rule the world, i not let me force to give up 68k and ixemul and buy a MOS.
there is absolute no technical reason that a program that use ixemul can not enhance as other amiga Programs that use libnix.so Unix programs need no libnix.
with ixemul you have too full access to wbstartup message(and ami_stuff use that in ffplay) and Icons and all AOS API Calls.
ok the /foobar problem was find
I get the idea now to add a command in newest libc
ix_UseAmigaPath(bool)
If somebody have a idea for a better name, let know.now its time to change
when use this command before a open file operation
ix_UseAmigaPath(true) or ix_UseAmigaPath(1) then all following file open commands do not use the Linux Path syntax.So the /foobar open can work.
-
amistuff have add nice features to ffplay.you can save a picture with key s.show me videoplayers that can do it easy.
s in mplayer as well, it's always been there.
Also in ffplay you can rewind or forward in Video files with cursor keys.Show me player that can do that so easy ?
Again, mplayer always did this, and more.
and time will show, what amiga features ffplay/ffmpeg get more.I plan a easy to Video recording/editing Software in amiblitz too.there is also no problem to do that with ixemul.
But more importantly - there is no problem doing it without ixemul.
From my point of view, as a user, ixemul is mostly an annoyance, it's a last resort for quick&dirty ports - using it as some sort of framework for real amiga software just seems insane.
Oh, and please stop using "Linux" all over the place, it makes me cringe as there's nothing Linux about it - use posix, or un*x or something. :)
-
PS. When you install Amithlon there is no native variant, native variant is 68k program.
Why people still use Amithlon is also beyond me, it was a nice idea and all, but in its current unsupported state it doesnt make much sense, IMO.
-
>But more importantly - there is no problem doing it without ixemul.
there is a problem, its more work.and as we all know in amigaland developing and new programs are very rare and whats in PPC amigaland when do a closer look, its often incomplete and features are miss or it contain Bugs that on Linux versions not in.
maybe you should do some programming or look at portet MOS or OS4 sources that work with libnix or newlib, if you dont believe what i write.
when a program use a function that libnix not have, a porter that use libnix go then to internet and search for code example code of atan.
Now he add this code to the program.But ixemul have this function onboard, so a porter can save lots work.
how it work is like this.When somebody on 68k want port program, he report me what functions he miss.I search then from Internet and add it to ixemul so he need not always change the source, when he compile a new Version.
You can also add the same code to libnix, but libnix is a static lib and blow up program size if you increase it larger.
You can use all Amiga Funtions with ixemul too, so there is no need to add much linux funcs to libnix
Why people still use Amithlon is also beyond me, it was a nice idea and all, but in its current unsupported state it doesnt make much sense, IMO.
Amithlon run on much and fast Hardware.The Kernel is opensource, so it can port to any Hardware.
The last Kernel update was here.YOu see its from 2006 support SATA and PCIe GFX Cards.i think you know that AMithlon since 2002 was dead, but you see 2006 last update.
http://www.garycvl.f2s.com/amithlon.html
And for the OS you can use too a enhanced 68k AOS as AFA OSor port AROS to it.
-
Man, you're making so tons of wild baseless accusations these days, as well as keeping up with your unbelievable level of incompetence and ignorance.
static lib and blow up program size if you increase it larger.
Wrong.
You can use all Amiga Funtions with ixemul too
Regardless how much you keep repeating this it won't become true. There is no easy way to use amigaos calls in ixemul safely.
Seriously you're claiming to be a developer and not know basic things such as these? Maybe you should have kept to basic.
-
>Wrong
This sentence is correct 68k libnix is a static lib.when i enhance this, then program size grow.
""""
You can also add the same code to libnix, but libnix is a static lib and blow up program size if you increase it larger.
""""
when MOS need not link static and increase the program size, how is the library name then ?
Also the ffmpeg release fab do seem a static build, because when i search for text .library in the exe file i find only bsdsocket.library opening, intuition.library opening.
>Regardless how much you keep repeating this it won't become true. There is no easy way >to use amigaos calls in ixemul safely.
and wy not ?.YOu have never test it, ixemul V62 is more enhanced as V48.
i can always tell you a reason and or a program example that it work and i can show that i not tell wrong and the example you do work with ixemul too.If not then ixemul have a bug or missing feature and can enhance.
and nobody need buy a PPC Hardware to check if i say the truth when test on UAE.
-
Amithlon run on much and fast Hardware.The Kernel is opensource, so it can port to any Hardware.
The last Kernel update was here.YOu see its from 2006 support SATA and PCIe GFX Cards.i think you know that AMithlon since 2002 was dead, but you see 2006 last update.
http://www.garycvl.f2s.com/amithlon.html
And for the OS you can use too a enhanced 68k AOS as AFA OSor port AROS to it.
I'm fully aware of Amithlon updates, I bought it myself and used it for quite a while, but at some point is stopped being practical and simply using UAE was a much better option. Btw, the links on the page you link to no longer work, the linux kernel is from 2004 with just some modules from 2006.
-
Btw, the links on the page you link to no longer work, the linux kernel is from 2004 with just some modules from 2006.
i click now again on the link, it work, i see also in Forum there is some activity with Posts from Nov 2009.
And when i look how fast Amithlon is port to much new Hardware, i see its really a good design, only bad of course is, that it is not the offical announce future.
http://tech.groups.yahoo.com/group/amithlonopen/
and about speed of PPC and winuae and amithlon on 68k Software, you can look here there is a Amithlon system
http://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=29964&forum=25&viewmode=flat&order=0
-
This sentence is correct 68k libnix is a static lib.when i enhance this, then program size grow.
If you don't even understand how link libraries work I don't think it's worth trying to explain it to you now is it?
when MOS need not link static and increase the program size, how is the library name then ?
Excuse me?
Also the ffmpeg release fab do seem a static build, because when i search for text .library in the exe file i find only bsdsocket.library opening, intuition.library opening.
Of course it is static. Fab told you it is static libnix build. Why wouldn't it be?
Regardless how much you keep repeating this it won't become true. There is no easy way to use amigaos calls in ixemul safely.
and wy not ?
Well let me name some:
- the ixemul signal handling aborting an OS call in the middle of execution, possibly while holding a critical system semaphore
- total leakage of any AmigaOS allocated resources on exit() or abort() (and yes, libnix does have the same problem, naturally... the point is that you cannot mix some random nix code with amigaos code unless if you're very very careful)
The newflash is: There is absolutely nothing you can do inside ixemul to "fix" these issues. This is because ixemul never was supposed to be mixed with AmigaOS calls, it was designed this way.
I've told you this before. You ignored me.
I am sure you will find some lame excuses to ignore me again, and perhaps add some new magic flag or env-variable to fix some totally unrelated thing, and then call the probem solved.
You should have renamed your experimental "ixemul". Now it's too late.
-
If you don't even understand how link libraries work I don't think it's worth trying to explain it to you now is it?
Yes i know this, when i look in a file then i can see a xxxx.library text.
I look in some MOS filles i dont see a string as libnix.library.
Or can you show me such a programs ?
Where are the nice portet Linux libs to MOS, OS4 have sobj and with ixemul its possible with the sdk to build dynamic libs easy
http://aminet.net/package/dev/gg/a2ixlibrarysrc
its really not nice when big linux programs are used all static forever.
ffmpeg and ffplay aren't up-to-date on MorphOS because we already have up-to-date mencoder and mplayer ports, that are more capable.
>Of course it is static. Fab told you it is static libnix build. Why wouldn't it be?
thats the text from Fab here do not stand its static.i write that when link with libnix then the exe size is increase and thats also correct with that MOS ffmpeg build.Now you confirm that i am correct.
"""""
from fab
Anyway, i ran my compiler today (with libnix), and here's a build from a recent ffmpeg snapshot (less than a week):
http://fabportnawak.free.fr/misc/ffmpeg.lha
To be noted it has altivec (autodetected) and network support (means you can play or encode stream).
Of course, "implementing" these two features wasn't a straight compilation. It took at least 5 minutes.
""""
But wy you write that my text is wrong ?
static lib and blow up program size if you increase it larger.
>- total leakage of any AmigaOS allocated resources on exit() or abort()
thats on all AOS libs same, they have no resourcetracking, when a program need that it must use atexit.
>- the ixemul signal handling aborting an OS call in the middle of execution, possibly while >holding a critical system semaphore
you mean when press CTRL+c ?
then there should be the rule that the automatic CTRL+c Handling in ixemul should not use.
nothing dramatic, libnix too not support CTRL+c automatic and there is a command in every Linux API to switch it off
if you want use CTRL+c in libnix you must add code by hand.and the same code you can use with ixemul.
also ixemul have security code, that when a sub thread call abort, this give a requester and tell resources cant free and the amiga system is still stable, but some windows are open.
but when a subthread call abort, there is an error in program and not in ixemul.when the error is fixed all work.normaly only a main thread should exit a program.
but whats important, system do not crash with new ixemul
-
Qed
-
i click now again on the link, it work.
What I meant was that the download links don't work.
-
I dont have Internet at home so I am replying late.
But what if I want to access a file named "." or even ".." ? And I want to use PROGDIR:. >This is Amiga, not some Unix clone written by some Torvalds.
thats more a theory.Do you know a program that use . or .. as file ?
I think my I start using . and .. as filenames in my future developments for Amiga.
Nah, MorphOS build is full ixemul build. It supports all ixemul features. It is just that MorphOS developers are not trying to bring Unix to Amiga. If you want Unix, get OS4.
sadly on OS4 ixmemul work too not full.I still have no MOS tester see, that say me that this ixemul programs work well on MOS.
I dont care about OS4. If there is no full ixemul port -- too bad.
My software synthesizer have 170 GUI elements in diffrent tabs and 1 window.I think its hard to keep an overview about this, when i like change something when this is in MUI or reaction syntax.
but there is also nice Linux Software here.so wy not use it.but i dont spend lots work to port Linux soft, because i dont like MUI or Reaction.Storm Wizard cant furtherdevelop so need go another way.
Sure. I have ported n+1 SDL games to MorphOS. Many of them are bad while some games are brilliant.
GTK i think is acceptable, there are nice GUI Editors here so i have hope, that i can soon change all my software to gtk+ and zune and use the GUI Editors.
When it comes to GTK you probably can not port it natively to Amiga Intuition. You must either use custom screen (Cygnix style) or go GTK-MUI kind of route. And GTK-MUI needs more work because GDK-MUI layer is needed in the future. On the other hand GTK-MUI is not that bad because if you do it cleverly you can recycle lot of original GTK source code.
I have to comment this one:
>- total leakage of any AmigaOS allocated resources on exit() or abort()
thats on all AOS libs same, they have no resourcetracking, when a program need that it must use atexit.
Do you know what happens to your atexit() calls at abort() ?
-
Qed
sorry, i dont understand what you mean, i dont believe you anything if you cant post reproducable or readible Facts.
sorry that i say this, but for me your reactions look like as a little child reaction when somebody have a better toy than you.
that you spend so much time to tell some unlogic things and you bring no ceckable facts about 68k ixemul which you never test, is really unlogic.
I at least have A MOS System on my cyberstrom PPC 233 install, and test a little MOS ixemul with 68k soft and notice some problems, so i need it not.I also see that there are enough incomplete outdate Ports.
I dont understand wy you want from me that i rename ixemul.Mos devs say that ixemul should only use for geek gadget compiler and some dev tools.Wy you need a linux shell, or Linux compilers btw ?.Port it clean to amiga OS and you need no ixemul when soem say they dont want use shitty direct Ports
There are lots other ixemul soft out that run well on ixemul V48 and V62.1.
And if you dont want that it run on MOS native ixemul well and fix Bugs, then the MOS devs should rename their ixemul to mini_ixemul or maybe tiny_ixemul.
whne look at storm mesa the MOS side do it right, they do not port a stormmesa which miss man features and name it Mesa.They name it tinygl
also all the incomplete MOS Ports should better name as mini, so users see at first look that it is not a full Port, because the Linux Version support more feature.
Or is that then a real Port when it use libnix, but there are less features here ?
-----
I do updates and fix ixemul if old ixemul Soft that is well written fail on V62 and work on older V48.2 V48.3
what to do with abuse i am not sure, it crash when i use ixemul V48.3.work only with V48.2.with V48.2 the mousepointer do not move, only when i click somewhere it is draw.also there is no sound play.
I compile abuse from new source with SDL and it work with sound/ opengl and mousepointer , but have a memleak(decrement mem every sec 20 kb).need look wy, if AROS port have same Problem.
But i do my best to make the amiga Software better.......
@Itix
>Do you know what happens to your atexit() calls at abort() ?
the same as happen with libnix atexit.
http://www.opengroup.org/onlinepubs/009695399/functions/atexit.html
atexit is a standard C method and also on libnix in.
for example SDL add here code to close amiga window and free amiga resources.thats on all systems same.
when a program do abort it do not free resources.most programs use assert this call atexit too.
abort is not good on amiga, because amiga have no resource tracking, but problem is in libnix and ixemul same
-
@Itix
>But what if I want to access a file named "." or even ".." ? And I want to use PROGDIR:. >This is Amiga, not some Unix clone written by some Torvalds.
Progdir work.
but as i told i add a function
ix_AmigaPaths(true)
then the unix path translation is not done.
Or do you reall think thats not possible ?
-
but as i told i add a function
ix_AmigaPaths(true)
then the unix path translation is not done.
Or do you reall think thats not possible ?
I have found better method: I am using -noixemul switch.
Btw how is auto-open libraries working with ixemul?
There are lots other ixemul soft out that run well on ixemul V48 and V62.1.
And if you dont want that it run on MOS native ixemul well and fix Bugs, then the MOS devs should rename their ixemul to mini_ixemul or maybe tiny_ixemul.
whne look at storm mesa the MOS side do it right, they do not port a stormmesa which miss man features and name it Mesa.They name it tinygl
There is one difference. Tinygl is not based on mesa. MorphOS ixemul was ported from 68k ixemul and is compatible with the original 68k ixemul software but makes it possible use ixemul from PPC native software. So it is the same but extended for MorphOS.
Then there is someone who figures out that MorphOS ixemul has higher version number and it is somehow important to have this ixemul on 68k Amiga because it has higher version number. There was nothing wrong with the original 68k ixemul but ixemul had to be ported and now Amiga users had ixemul V49 for 68k Amiga. It didnt work but they had ixemul with higher version number which matches with MorphOS.
Okay, there are bug fixes in MorphOS ixemul, some maybe even important, but only reason why 68k ixemul went out of hand was a version number.
-
I have found better method: I am using -noixemul switch.
Btw how is auto-open libraries working with ixemul?
I and i think many other dont know how auto open in libnix work.Most do the logical Amiga OS way, that is explain in RKM.Its really not much work to open a lib.there can also do a code snippet that open often needed aos libs.you need only paste it
but its really lots more easy to use way from RKM then port a big Linux program to work with a small libnix.
struct Library *AslBase:
AslBase = OpenLibrary("asl.library");
and at end of source or in a atexit func you need do
CloseLibrary(AslBase);
>Okay, there are bug fixes in MorphOS ixemul, some maybe even important, but only >reason why 68k ixemul went out of hand was a version number.
You still have not written if the programs i post work on your MOS.Your excuse is only that this programs should not use with ixemul.
what do you say when a program use opengl functions that MOS tinygl not have.
Do you think this program should port so it work with the fewer functions of tinygl or its a shitty program ?
>I have found better method: I am using -noixemul switch.
everybody can do what he want.
enhance libnix is too possible but wy need not 2 big unix API(ixemul and libnix) i think.You yourself tell you want not use this shitty Un++ix Ports, but then i dont understand, wy MOS devs have add more functione to libnix to make porting more easy.
more functions help more easy port programs.MOS devs see that too and add this new funcs to libnix as closedsource.
But ixemul have always this functions in and more and is opensource.
I think in such a small market few devs and so slow developing, closed source is not good, because every programmer can fix or enhance opensource soft he need faster and maybe more bugfree(when on the system very few betatester here and really motivate to test), because the closed source devs have so much other things to do.
------------
If i add the function atanf in libnix or ixemul because a Unix program need it, there is no diffrence.
And its also possible when a amiga program really not run with ixemul to change it so it work.When you want port it to libnix you must do the same.
http://www.unix.org/version3/apis/t_1.html
If this functions are link from a libnix or ixemul there is really no diffrence in functions.
And if something fail due to messaging can easy see when test and the program wait in endless loop
for example pthread programs do never work with amiga OS funcs and tasks and SDL, this have also nothing to do with ixemul or libnix.
amiga and pthread cant work.here always the program need change with libnix too.
but luckily many programs can compile without pthreeads.
But my plans are here too to change pthread that it work with amiga task and signalling whne there is a reason(program that really need it).
this help also get programs more easy working.
-
I and i think many other dont know how auto open in libnix work.
Time to find it out then.
Most do the logical Amiga OS way, that is explain in RKM.Its really not much work to open a lib.there can also do a code snippet that open often needed aos libs.you need only paste it
but its really lots more easy to use way from RKM then port a big Linux program to work with a small libnix.
struct Library *AslBase:
AslBase = OpenLibrary("asl.library");
and at end of source or in a atexit func you need do
CloseLibrary(AslBase);
It is not enough for ports :-) I have created lots of shared libraries for MorphOS: powersdl.library, iconv.library, intl.library, hpdf.library, littlecms.library and many more which are used in my ports. When I am porting stuff from other systems (usually from Unix) I dont have to add code to open those libraries. It is done automatically for me.
You still have not written if the programs i post work on your MOS.Your excuse is only that this programs should not use with ixemul.
I dont have Internet at home (yet).
what do you say when a program use opengl functions that MOS tinygl not have.
Do you think this program should port so it work with the fewer functions of tinygl or its a shitty program ?
There is tinygl maintainer. When there is missing opengl call I ask what could be done about it. Sometimes there is workaround, sometimes tinygl maintainer adds missing functionality, sometimes I have to drop project.
enhance libnix is too possible but wy need not 2 big unix API(ixemul and libnix) i think.You yourself tell you want not use this shitty Un++ix Ports, but then i dont understand, wy MOS devs have add more functione to libnix to make porting more easy.
The official word is: do not used ixemul unless you know what you are doing.
more functions help more easy port programs.MOS devs see that too and add this new funcs to libnix as closedsource.
There is also clib2 developed by Olaf Barthel. It is open source. I dont know how well it compares with libnix but I think it is fairly good alternative solution.
-
>Time to find it out then.
and where is a program that use auto libopen as an example ?
I can then try out if it work with ixemul.
as far i know there is libauto.a for this.I think its really no problem of it not work in ixemul to add the code from libnix here too, if there is code in libnix to do that.
open a library by hand is not very complicate and need not much programming knowledge, its lots more work to change the program to use libnix, and btw when create a library then it must do always by hand.libauto cant work.
>There is tinygl maintainer. When there is missing opengl call I ask what could be done >about it. Sometimes there is workaround, sometimes tinygl maintainer adds missing >functionality, sometimes I have to drop project.
http://fabrice.bellard.free.fr/TinyGL/
Do you mean this maintainer or do you mean MOS maintainer ?
And what do you do if this maintainer
http://fabrice.bellard.free.fr/TinyGL/
update his tiny GL Version so its not compatible to MOS new stuff and increase lib number ?
Do you then tell him too he should rename his tinygl or should not increase lib Version ?
Bit i see diffrent on MOS sdl.its called powersdl and it is based on old SDL Version 1.2.6 that was here for AOS and AROS.You add new features, choose another name and version numbering as SDL.
But here i see you have add this new features in 1.2.13 and not say that a real good SDL Port can only done with powersdl in 1.2.6 state.
its really funny what funny reasons the MOS devs write and they want force ixemul not furtherdevelop.
Wy not do that in SDL too ?.SDL1.3 is release and support multiple windows.
Do you then too say, when a SDL program need that feature it is no good Port or program ?
wy not go to the sdl devs and tell them that they should rename their sdl instead that MOS sdl must called powersdl
its fact, ixemul is born on 68k and if you accept me as furtherdeveloper or not, you cant force that MOS devs are right when they want force that ixemul should stay forever on this low linux compatible level and instead should enhance libnix with more Linux funcs.
Most portet programs to MOS or OS4 and of course 68k are identical port Linix programs.
If your port SDL game work with ixemul or not, users do not notice.
So wy there must do much work to make this identical Ports working with the less featured libnix ?
When you tell me what functions MOS libnix have, then i also can add a compiler warning in ixemul when #define MOS_LIBNIX_COMPATIBLE
this help devs to make the program working on MOS.
but thats also simple to add, and i am sure, when not more funcs use as in libnix, then there cant more problems occur as in libnix.
the lib is called on MOS powersdl.library you yourself have written here
-
@Fab
Here i get a output what codecs are add in ffmpeg Version from MOS.
http://www.amiga-news.de/de/news/comments/thread/AN-2009-11-00044-DE.html
I do a filecompare with 68k ffmpeg from amistuff and see the MOS Version miss lots libs.so its clear it is smaller.
this libs are add automatic from ffmpeg makefile.
DEA libamr_nb libamr-nb Adaptive Multi-Rate (AMR) Narrow-Band
DEA libamr_wb libamr-wb Adaptive Multi-Rate (AMR) Wide-Band
EA libfaac libfaac AAC (Advanced Audio Codec)
D A libfaad libfaad AAC (Advanced Audio Codec)
DEA libgsm libgsm GSM
EA libmp3lame libmp3lame MP3 (MPEG audio layer 3)
D V libopenjpeg OpenJPEG based JPEG 2000 decoder
D A libspeex libspeex Speex
EV libtheora libtheora Theora
EA libvorbis libvorbis Vorbis
EV libx264 libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
EV libxvid libxvidcore MPEG-4 part 2
but all in all great what Fab do, get so much codecs work with libnix.
But this show more that Fab is a excellent coder or spend lots time and not that programming or porting for MOS is easy.
I code for amiga because it is not so much work as on windows/Linux to find bugs or program.and a AOS that need more work i dont want.
maybe you can release the source so can see what you change.
also dont forget to add in the next release of ffmpeg to add this 12 libs too in actual version
-
@Fab
Here i get a output what codecs are add in ffmpeg Version from MOS.
http://www.amiga-news.de/de/news/comments/thread/AN-2009-11-00044-DE.html
I do a filecompare with 68k ffmpeg from amistuff and see the MOS Version miss lots libs.so its clear it is smaller.
this libs are add automatic from ffmpeg makefile.
DEA libamr_nb libamr-nb Adaptive Multi-Rate (AMR) Narrow-Band
DEA libamr_wb libamr-wb Adaptive Multi-Rate (AMR) Wide-Band
EA libfaac libfaac AAC (Advanced Audio Codec)
D A libfaad libfaad AAC (Advanced Audio Codec)
DEA libgsm libgsm GSM
EA libmp3lame libmp3lame MP3 (MPEG audio layer 3)
D V libopenjpeg OpenJPEG based JPEG 2000 decoder
D A libspeex libspeex Speex
EV libtheora libtheora Theora
EA libvorbis libvorbis Vorbis
EV libx264 libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
EV libxvid libxvidcore MPEG-4 part 2
but all in all great what Fab do, get so much codecs work with libnix.
But this show more that Fab is a excellent coder or spend lots time and not that programming or porting for MOS is easy.
I code for amiga because it is not so much work as on windows/Linux to find bugs or program.and a AOS that need more work i dont want.
maybe you can release the source so can see what you change.
also dont forget to add in the next release of ffmpeg to add this 12 libs too in actual version
Remember this was a 5 minutes job, and that i didn't enable external libraries on purpose (most people use mencoder, anyway). For MPlayer and Mencoder, I have these libraries enabled (included libx264 and libxvidcore that also need some additional code for altivec autodetection, for example). But all these libraries mostly straight compile with libnix anyway.
And wtf with tinygl that would be bad because it lacks a function, or a powersdl game that would be bad because it's based on 1.2.6? Not everything requires the very last version to be usable, far from it. And it's way preferrable to have a fast OpenGL subset than a complete but amazingly slow MESA implementation.
-
and where is a program that use auto libopen as an example ?
I dont know how it works in 68k but in MorphOS it works just like SAS/C constructors/destructors work.
Maybe this one: http://aminet.net/package/mus/play/ahxplay
There is libahxplay.c which could have auto-open feature. I can not verify this without having an access to my sources and I cant bother installing LhA unpacker to this XP machine.
btw when create a library then it must do always by hand.libauto cant work.
Actually it can work if you know how to make it work. Anyway, please dont tell me you are using ixemul in shared libraries.
Do you mean this maintainer or do you mean MOS maintainer ?
MorphOS maintainer.
And what do you do if this maintainer
http://fabrice.bellard.free.fr/TinyGL/
update his tiny GL Version so its not compatible to MOS new stuff and increase lib number ?
Apples and oranges. MorphOS TinyGL (http://3d.morphos-team.net/) is heavily extended and pretty much only thing it has common with the original TinyGL is a name.
But even then, so what. The official SDL is maintained separately from PowerSDL. When there is new SDL version I maybe update PowerSDL on MorphOS. Or maybe not. It is up to me.
Bit i see diffrent on MOS sdl.its called powersdl and it is based on old SDL Version 1.2.6 that was here for AOS and AROS.You add new features, choose another name and version numbering as SDL.
There is good reason for that: I dont maintain Amiga SDL nor sdl.library. Thus any changes to sdl.library would be incompatible if Amiga SDL development was continued by its maintainer.
So wy there must do much work to make this identical Ports working with the less featured libnix ?
Ixemul is not safe.
its fact, ixemul is born on 68k and if you accept me as furtherdeveloper or not, you cant force that MOS devs are right when they want force that ixemul should stay forever on this low linux compatible level and instead should enhance libnix with more Linux funcs.
We cant force you to do anything but we would appreciate if there was more experienced developer maintaining 68k port.
-
>Ixemul is not safe.
thats no good argument, but i can easy say libnix is not so safe as ixemul .and i am fair and i show you a reason everybody can check.
try this example code
string = malloc(8);
strcpy(string,"123456789");
now with libnix you get memtrash and your program overwrite memory and crash sooner or later randomly.ixemul report this and upto 4 byte memtrash cant give system crashes.so a programmer notice this.so ixemul is more safe and bring no speedloss.
you can also get report when you use on libnix wipeout.But i see in your membenchmarks with running wipeout that your system slow down extrem.much more than winuae.
Try out a Program that use xml 2 or a C++ program.
Try out on your netsurf with running MOS wipeout memtracker.
http://www.aminet.net
and tell me the time how long your system need to show the page.i think it need more than 5 minutes.SO i guess when you develop netsurf or a C++ program you need not the recommended dev tools from Commodore to detect memtrash.
But now what test we should use to show that ixemul is not safe ?
maybe you can show me a Unix program that you think cant enhance with Amiga OS functions ?
the test is easy, i add then in a loop code that it frequently open and close a MUI gui win dow(more than 20* sec)
then we can run it on UAE and when it also run without deadlock or memory trash more than 2 hours can say ixemul is safe.
>We cant force you to do anything but we would appreciate if there was more experienced >developer maintaining 68k port
YOu should really try out ixemul V62 with more programs,then you see it run stable.Then use your MOS ixemul.I think you see this run not so stable.
but your only excuse is, that programs should not use ixemul and thats wrong.ixemul can do more than libnix and need not static link, so programs can be smaller.
if there was more experienced devloper that do that is nice, but when they only say we need no newer version the program should not use it help nothing.
Or when there are experienced devloper that do a better libnix only for a AOS that run on slow PPC Systems and this must buy.
A AOS that run not on fast and cheap hardware is not usefull for me.Wy i should use a slow system ?.Time is short and the fastest get for the money is the best.
And when my Hardware damage, i will in short time buy a new system.
>Remember this was a 5 minutes job,
where is the source so can see what you have change ?
when this is not much work, wy are the most important Ports done by OS developers on MOS ?
wy there come not so much from non OS developers ?
-
>Not everything requires the very last version to be usable, far from it. And it's way >preferrable to have a fast OpenGL subset than a complete but amazingly slow MESA >implementation.
there is not much speed differ, look at old benchmarks that show glide speed and opengl speed in some benchmarks with quake.
when the X86 CPU get more speed as 200 MHZ then the calling overhead of a full Mesa does not slowdown more than 5-10% and faster CPU glide and full opengl get more and more equal and thats the reason because tinygl or minigl is now not need and all modern systems have full Mesa
-
>(most people use mencoder, anyway).
really, i see this early GUI for MOS mencoder.
http://aminet.net/package/gfx/edit/mengui
for 68k there is a GUI that use argue and support many encoders, also ffmpeg
http://aminet.net/package/util/misc/ArgueGUIColl
-
string = malloc(8);
strcpy(string,"123456789");
now with libnix you get memtrash and your program overwrite memory and crash sooner or later randomly.ixemul report this.so a programmer notice this.so ixemul is more safe and bring no speedloss
Bleh. That is not safe. It is placebo. It can crash your system at any time. Ixemul can not magically trap malicious code.
But now what test we should use to show that ixemul is not safe ?
It just isnt. Do not mix ixemul with native Amiga API calls.
YOu should really try out ixemul V62 with more programs,then you see it run stable.Then use your MOS ixemul.I think you see this run not so stable.
I can not use your ixemul because it does not support PPC native callbacks (i.e. atexit(), obviously).
but your only excuse is, that programs should not use ixemul and thats wrong.ixemul can do more than libnix and need not static link, so programs can be smaller.
With ixemul you still have static linking because of stubs.
-
@Itix
>Bleh. That is not safe. It is placebo. It can crash your system at any time. Ixemul can not >magically trap malicious code.
No such often happen programming bugs (that 1-4 bytes more written)cant crash system, because on ixemul is a cookie here.was also on old V48 Versions
Of course this cost a little more mem, but it make all more safe and help finding programming bugs easy.this more mem doesnt matter because also AFA is small and 68k executable save too some mem.
>I can not use your ixemul because it does not support PPC native callbacks (i.e. atexit(), >obviously).
but you can use UAE and here its possible that you can run 68k Software everywhere.
>It just isnt. Do not mix ixemul with native Amiga API calls.
Every software can change so it can work, so its impossible that ixemul cant work with Amiga OS funcs when we know the reason wy it cant work to fix that.
You have no practice argument wy can not amiga OS function use in netsurf or ffplay or ffmpeg, or all the other SDL Ports or other programs that for ixemul are here
I still dont believe that without a example Program in which it is usefull to use amiga Functions, because you are a MOS developer and its possible that you not like that 68k make it more easy to port programs as MOS, because you fear that not so much buy MOS.
But really i dont understand wy so fight for users, users/devs are not stupid, and when you have no reason that explain in a real world example wy ixemul not work with amiga OS api, then you are unbelievable.
I can say you, that i planed buy a Mac mini and maybe MOS.But now i am sure, i not buy or need it, because guys that do that, the feature we not have we need not, i dont want suppport with money.
BTW:I remember MOS devs say long time ago when there are devs that ask for a newer GCC as 2.95 that there is no newer GCC need.or should i post links ?
-
but you can use UAE and here its possible that you can run 68k Software everywhere.
I dont have UAE, I dont have ROMs and I dont intend to buy ROMs.
Every software can change so it can work, so its impossible that ixemul cant work with Amiga OS funcs when we know the reason wy it cant work to fix that.
Lets see... if I recall correctly ixemul uses tc_UserData for its own purposes. Right/wrong?
I can say you, that i planed buy a Mac mini and maybe MOS.But now i am sure, i not buy or need it, because guys that do that, the feature we not have we need not, i dont want suppport with money.
And I was going to buy Amiga Forever package but I decided to not buy it.
BTW:I remember MOS devs say long time ago when there are devs that ask for a newer GCC as 2.95 that there is no newer GCC need.or should i post links ?
Yeah. Problem is that newer GCC versions are quite buggy. There are still newer GCC versions for MorphOS, I have got all three GCC2, GCC3 and GCC4. GCC2 works for me so I am using it most of time. No need to use latest stuff always.
-
>Lets see... if I recall correctly ixemul uses tc_UserData for its own purposes. Right/wrong?
Yes, and its tell, when you not use SDL task creation Function and you want create a own amiga sub task you must create before you use a ixemul file or network function with ix_CreateChildData();
the valid data for this task.thats all
if you not do that then your program stop at first try and bring a error message.but when a program not stop at first try, then there is all right and it work forever and stable.
Edit: or do you mean, this is a big problem if this entry is not usable for amiga ?
I think not, does OWB or netsurf or any other with AOS Code enhanced Linux Port use that ?
If yes, see at ixemul source, its possible to change ixemul to use the tc_trap Data field for this.
#ifdef NOTRAP
printf ("#define USERPTR_OFFSET %ld\n", offsetof (TASK, tc_UserData));
#else
printf ("#define USERPTR_OFFSET %ld\n", offsetof (TASK, tc_TrapData));
#endif
there are other unused fields in the process structure, just tell me a place which is better.
i get a better idea.
i see in process structure a field pr_shellprivate.
Is this not for all that create with CreateProc unsused and only for amiga shell used ?
-
>Yeah. Problem is that newer GCC versions are quite buggy. There are still newer GCC >versions for MorphOS, I have got all three GCC2, GCC3 and GCC4. GCC2 works for me so I >am using it most of time. No need to use latest stuff always.
But when you want sell a commerciall OS, its not enough that it working by you, the buyer of this OS must be happy with whats here.
The reason to test newest stuff always is for me and other to help make rock solid software.
We test always newest stuff and report Bugs because GCC and ffmpeg support 68k AOS we get help in ML.It can build with configure and make.
ami_stuff do not only port ffmpeg, he report bugs and he help so to make ffmpeg better.same he do on newest GCC too.
I really dont like when people say new Version have Bugs i use older without reporting the Bugs so devs have a chance to fix.when all users do that, then software get never be more features.best is test newer version and when it have bugs, then report it and use old software until fixed
But i think on MOS/OS4 its more a excuse because of the missing man power to do that additional work, but its a real bad excuse.I see the GCC 4.3 and above produce no wrong code.Have you try out 4.3/ 4.4/ or 4.5 on MOS and this are buggy ?
Because the GCC Team make not GGC as opensource so that commercial OS developers port it to their OS to have a compiler but dont want to help to make it better.
thats only a one way thing, only MOS/OS4 side profit from gcc, but gcc do not get any enhance with MOS/OS4.I think a modern OS should also in GGC source support as 68k amigaos.
>>I can say you, that i planed buy a Mac mini and maybe MOS.But now i am sure, i not >>buy or need it, because guys that do that, the feature we not have we need not, i dont >>want suppport with money.
>And I was going to buy Amiga Forever package but I decided to not buy it.
everybody is free what he do, but the compare is too much diffrent.
1. i dont sell amiga forever or get money from it.
2. amiga forever is that system we all learn in the past and know, but its now not market as a future system.so i understand more that you dont want install amigaforever.
but when users change to new system, there must be more advantages to learn a new system.at least it should have more speed than a emulate amiga forever on X86.
and BTW:
when the MOS 68k emul is fix, then ixemul should be run wirthout amiga forever
-
I can say you, that i planed buy a Mac mini and maybe MOS.But now i am sure, i not buy or need it, because guys that do that, the feature we not have we need not, i dont want suppport with money.
Excellent news!
-
I think not, does OWB or netsurf or any other with AOS Code enhanced Linux Port use that ?
I dont know. Do you?
#ifdef NOTRAP
printf ("#define USERPTR_OFFSET %ld\n", offsetof (TASK, tc_UserData));
#else
printf ("#define USERPTR_OFFSET %ld\n", offsetof (TASK, tc_TrapData));
#endif
there are other unused fields in the process structure, just tell me a place which is better.
i get a better idea.
It is not unused. I can use it in my own applications.
I really dont like when people say new Version have Bugs i use older without reporting the Bugs so devs have a chance to fix.when all users do that, then software get never be more features.best is test newer version and when it have bugs, then report it and use old software until fixed
Why? I am not a beta tester and I dont have time for that.
Have you try out 4.3/ 4.4/ or 4.5 on MOS and this are buggy ?
I tried some GCC 4.x version couple of months ago but I dont know which version it was. But it did its job.
Because the GCC Team make not GGC as opensource so that commercial OS developers port it to their OS to have a compiler but dont want to help to make it better.
If GCC developers are unhappy about it they can always quit developing GCC.
when the MOS 68k emul is fix, then ixemul should be run wirthout amiga forever
It would need support for PPC native callbacks.
-
>I dont know. Do you?
i think you should know if your netsurf store data in this field.its unused but can use in apps, but i know no practice software that use it.
when i remember correct you can count the Unix Ports that are really enhanced with amiga funcs in 1 Hand (i count all MOS AOS und OS4)
I get in mind OWB, flashplayer, netsurf, mplayer.What did i miss ?
so i think there is no program that make problems and the unchanged Feature Unix Ports i think are more than 1500.
So i really see no need wy AOS need two Unix compatible libs and the limit of ixemul dont use tc_userdata if you want use ixemul funcs in the task is not big Limit that make the work usefull to enhance and maintain 2 big unix compatible libs.
>Why? I am not a beta tester and I dont have time for that.
yes i know you and fab are the most important devs to bring applications to MOS.If you and Fab not here, who do this big Ports then. ?
I see nobody that do so much for free for MOS as you both.
From Piru i read only bashes again 68k ixemul, but i see not that he release something free for MOS.Or did i miss some information ?
But if nobody on MOS side is here to help you is also really not good i think, that MOS have actual BugFree Software.
>Excellent news!
Yes and i thank you again that you the unqualified bashes again ixemul V61 begin before MOS Mac Version, so i pay no money.
and btw, what Itix do i understand not as unqualified bashes, because he bring arguments of real Limits and this help to make it better.
The Limits are very small, i see no real reason to spend much work to add in libnix full Unix Features and must keep update 2 lib Versions.
But if MOS release libnix source, a compile that maybe need not more as 1-2 hours to 68k is ok.
ixemul have also some more advantages to libnix.ixtrace is very usefull to find slowdown problems of bad written Unix software.We all know Unix SOftware is most written today on a 2 GHZ fast X86.A dev does not notice any slowdown here.
but when port to slower systems ixtrace or library timer can help to do profiling and see where the programs waste time.
http://aminet.net/package/dev/misc/LibraryTimer
this is a great tool and help me alot.also that ixemul have fast boundcheck to detect memtrashes better.
so you see all libs have some advantages and when i need choose enhance libnix or ixemul because i have not so much time, my choose is clear ixemul have better solutions to develop more easy bugfree and fast Applications.
memory allocator is faster and do less fragment as libnix on 68k.when programs use malloc.tlsf mem do not help.
file seeking is faster on ixemul because libnix delete after a seek always the full filebuffer and read all again( i add cache to it).seeks inside filebuffer work in ixemul more than 200* faster.result is openredalert start 50* faster as compile with old 68k libnix.
But i do a new libnix that have too a cache before i begin with ixemul.but also here openredalert start 2* faster as with libnix on my system.
-
i think you should know if your netsurf store data in this field.its unused but can use in apps, but i know no practice software that use it.
Some of my Amiga software is using it. Mostly to pass pointers to subtasks.
I get in mind OWB, flashplayer, netsurf, mplayer.What did i miss ?
Any Amiga software with a GUI.
Btw Netsurf is not "Unix software". It was written for RISCOS and then ported to other systems.
-
did i miss some information ?
Yes, you miss a lot of information.
if MOS release libnix source
libnix is not open source.
BTW the limitations of the 68k libnix are mostly not present in the MorphOS version. We're not blind, obviously we have taken care of such issues. Funnily enough, under MorphOS the 68k apps built with 68k libnix have much faster memory allocation than ixemul ones.
-
>BTW the limitations of the 68k libnix are mostly not present in the MorphOS version. We're
again, where can see what API functions the libnix of MOS have ?
>not blind, obviously we have taken care of such issues. Funnily enough, under MorphOS >the 68k apps built with 68k libnix have much faster memory allocation than ixemul ones.
sure fabs benchmark it do faster, but dont believe that in real world Linux apps with C++ or programs that use xml2 lib or other that do lots of small memalloc and free.
libnix have only a small first fit allocator 4 kb pool allocator, which do lots fragment and libnix have very small pools that need a lot of free poolsearch when there are programs that use much mem.
See here the code.And i think everybody with programing knowledge should know that a buddy allocator in real world apps is lots faster.
void *malloc(unsigned long size)
{
struct MinNode *node=__memorylist.mlh_Head;
struct MemHeader *b;
ULONG size2,*a;
size+=sizeof(ULONG);
while(node->mln_Succ) /* yet some memory in my list ? */
{
if((a=Allocate((struct MemHeader *)node,size))!=NULL)
{
*a++=size;
return a;
}
node=node->mln_Succ;
}
size2=sizeof(struct MemHeader)+sizeof(ULONG)+size; /* Total memory needed */
if(size2<=_MSTEP)
size2=_MSTEP; /* Allocate a _MSTEP bytes large block if possible */
size2=(size2+4095)&~4095; /* Blow up to full MMU Page */
if((b=(struct MemHeader *)AllocMem(size2,MEMF_ANY))!=NULL)
{
b->mh_Lower=b->mh_First=(struct MemChunk *)(b+1);
b->mh_First->mc_Next=NULL;
b->mh_Free=b->mh_First->mc_Bytes=size2-sizeof(struct MemHeader);
b->mh_Upper=(char *)b+size2;
AddHead((struct List *)&__memorylist,&b->mh_Node);
a=Allocate(b,size); /* It has to work this time */
*a++=size;
return a;
}
return NULL;
}
>Any Amiga software with a GUI.
I mean only Linux Software that is enhance with amiga OS features
>Some of my Amiga software is using it. Mostly to pass pointers to subtasks.
Was this mostly based on Unix code and need much API Features ?
-
again, where can see what API functions the libnix of MOS have ?
You cant.
libnix have only a small first fit allocator 4 kb pool allocator, which do lots fragment and libnix have very small pools that need a lot of free poolsearch when there are programs that use much mem.
You forget that in MorphOS, when using TLSF, memory pools are completely different.
Was this mostly based on Unix code and need much API Features ?
Amiga native code but I recall I used it in my still uncompleted and unreleased Netsurf 68k release passing data to subthreads (my Netsurf port runs MUI GUI on separate thread). Or, I dont know. I just link with libnix and dont care about ixemul.
But even in Amiga native coding you often use at least snprintf(), maybe printf() or dos I/O. Even if you are happy with ixemul for your ports you still need good libnix for native coding.
-
in what file you set userdata ?.
I look in source here
http://source.netsurf-browser.org/branches/itix/netsurf/mui/
and btw i see that you open libs by hand also when __MORPHOS__ defines and not with libnix autoinit.so no need for libnix too.
I get also the idea just add the alloced memblock at the beginnung or end of the list tc_MemEntry that contain the userdata.
but i dont know how AOS work and add this allocate memblock to the list and on what place it come and of it is always sure that the block is at 1. or last place when i add it here.
Its also possible to change the process create function so it add additional space for that value.
task cant use dos, so ixemul funcs need no userdata
Its possible to add the iserdata address at the end of stack range.only need not forget when use stackswap to copy this value too.but here can use a function ix_stackswap that work more easy as the AOS func.
so you see no reason to enhance libnix and not use ixemul
if ((MUIMasterBase = OpenLibrary("muimaster.library", 11)))
if ((CyberGfxBase = OpenLibrary("cybergraphics.library", 41)))
if (classes_init())
if (mui_schedule_init())
if (mui_clipboard_init())
#if defined(__MORPHOS__)
if ((ZBase = OpenLibrary("z.library", 51)))
if ((JFIFBase = OpenLibrary("jfif.library", 0)))
#endif
if ((TTEngineBase = OpenLibrary("ttengine.library", TTENGINE_VERSION)))
if ((IconBase = OpenLibrary("icon.library", 0)))
if ((IntuitionBase = (APTR)OpenLibrary("intuition.library", 36)))
if ((SocketBase = OpenLibrary("bsdsocket.library", 0)))
if ((AsyncIOBase = OpenLibrary("asyncio.library", 0)))
-
and btw i see that you open libs by hand also when __MORPHOS__ defines and not with libnix autoinit.so no need for libnix too.
When using Amiga native APIs (i.e. using MUI GUI) I prefer opening libraries manually. In SDL ports I dont because I dont want Amiga specific code to otherwise fully portable application.
I get also the idea just add the alloced memblock at the beginnung or end of the list tc_MemEntry that contain the userdata.
You can not guarantee it is compatible with applications using tc_MemEntry. They can add entries to head or tail of list at their will or even remove existing entries.
but i dont know how AOS work and add this allocate memblock to the list and on what place it come and of it is always sure that the block is at 1. or last place when i add it here.
Amiga does not do much with it. Applications itself manage tc_MemEntry.
Its also possible to change the process create function so it add additional space for that value.
task cant use dos, so ixemul funcs need no userdata
So you have to hack the OS.
Its possible to add the iserdata address at the end of stack range.only need not forget when use stackswap to copy this value too.but here can use a function ix_stackswap that work more easy as the AOS func.
But again you are putting restrictions. Ixemul works as long as developer does not do X but uses Y instead.
so you see no reason to enhance libnix and not use ixemul
And how about sockets? Can I assume WaitSelect() works?
-
>And how about sockets? Can I assume WaitSelect() works?
yes of course it work, when a Amiga program use no Unix socket and amiga sockets instead it work.
this show that the libcurl amigaOSPort and the libcurl Unix Port work well and at same speed on netsurf and ixemul
>So you have to hack the OS.
thats only a enhancement of the AOS.newer AOS need bigger process structures for example for resource tracking, in furtherdevelop of AFA i need sooner or later increase the process structure amd i can then make room for more user data entries.
I think its maybe the easiest way to use the tc_TaskTrap field.thats really must not need in a amiga OS program.i dont know what amiga program use this.debuggers use only tc_ExcpetData
But i look always closer before i change something.thats only some ideas to discuss now.
----
I get also the idea to add for ixemul funcs
SetTaskUserData(slotnum,value) and GetTaskUserData(slotnum,value) and maybe support more than 1 entry(slotnum) and store this then in userdata.depent on what you use libnix or ixemul what this func really do.but when use libnix can only store 1 value.
This is then a enhancement to AOS too and its the correct way to go, when amiga OS go memory Protection.
access of structures direct is bad.
-
when amiga OS go memory Protection.
For fantasy writings I prefer J.R.R. Tolkien.
-
@itix: maybe you should try "the witcher" of sapkowski - a bestseller from poland. lol. there is also a rpg made aftert that. it is probably more like bernds world. i dont know if its available in finnish though.
-
where can see what API functions the libnix of MOS have ?
man ar then apply this knowledge.
void *malloc(unsigned long size)
{
struct MinNode *node=__memorylist.mlh_Head;
struct MemHeader *b;
ULONG size2,*a;
size+=sizeof(ULONG);
while(node->mln_Succ) /* yet some memory in my list ? */
{
if((a=Allocate((struct MemHeader *)node,size))!=NULL)
{
*a++=size;
return a;
}
node=node->mln_Succ;
}
size2=sizeof(struct MemHeader)+sizeof(ULONG)+size; /* Total memory needed */
if(size2<=_MSTEP)
size2=_MSTEP; /* Allocate a _MSTEP bytes large block if possible */
size2=(size2+4095)&~4095; /* Blow up to full MMU Page */
if((b=(struct MemHeader *)AllocMem(size2,MEMF_ANY))!=NULL)
{
b->mh_Lower=b->mh_First=(struct MemChunk *)(b+1);
b->mh_First->mc_Next=NULL;
b->mh_Free=b->mh_First->mc_Bytes=size2-sizeof(struct MemHeader);
b->mh_Upper=(char *)b+size2;
AddHead((struct List *)&__memorylist,&b->mh_Node);
a=Allocate(b,size); /* It has to work this time */
*a++=size;
return a;
}
return NULL;
}
Oh yes, forgot how braindamaged the 68k libnix was. That indeed can get really slow, even under MorphOS. Well, at least there's no such problem with MorphOS native libnix.
Which reminds me: AmigaOS 3.x memory pools have the same problem. AmigaOS 3.9 tried to fix it with AVL trees, but the whole concept is still flawed (read: based on slow first fit algorithm both for internal and external allocations).
Even the AmigaOS 3.x with TLSFMem patch fails to fix it properly: It only changes the behaviour of the external allocations. Internally the pools still use either list or tree and Allocate/Deallocate for the internal allocations.
This means that anything using memory pools in AmigaOS 3.x will inherit the performance problems aswell.
MorphOS 2.x and later took a different approach. There all memory pool allocations and deallocations are O(1).
-
@piru:
Oh yes, forgot how braindamaged the 68k libnix was. That indeed can get really slow, even under MorphOS. Well, at least there's no such problem with MorphOS native libnix.
after you mention it i made tests with two quickie opengl ports i did for 68k. i compile them usually with -noixemul > libnix but now i linked against bernds ixemul too. i using wazp3d fps counter that shows me a ms count per frame if it wents under 1 fps i cannot trace any speed difference between both libraries, but then i suspect there is not much memory allocations they do.
maybe i should try to run netsurf port on chris hodges tlsf. could it make any difference?
-
>Well, at least there's no such problem with MorphOS native libnix.
and no problem with ixemul.mem alloc is fast enough for real world C++ programs and netsurf
with that program you can measure it
http://aminet.net/package/dev/misc/LibraryTimer
malloc/free need around 2-3% of overall CPU usage with netsurf.
but with poolmem you get after longer use much more time
>For fantasy writings I prefer J.R.R. Tolkien.
I watch out for news of Hyperion Secret Project on their Webpage.maybe they do memory protection... ;-)
but anyway, a Function that set and get Task user Pointer is the cleanest solution so nobdy need hack in the task structure.
and it make no problem with ixemul.
-
@piru:
after you mention it i made tests with two quickie opengl ports i did for 68k. i compile them usually with -noixemul > libnix but now i linked against bernds ixemul too. i using wazp3d fps counter that shows me a ms count per frame if it wents under 1 fps i cannot trace any speed difference between both libraries, but then i suspect there is not much memory allocations they do.
You suspect correctly.
maybe i should try to run netsurf port on chris hodges tlsf. could it make any difference?
In practice, no.
There are several levels for the allocators, typically at least two. In amigoid systems there typically are at least 3:
OS low level: AllocMem/FreeMem (etc)
OS high level (pools): AllocPooled/FreePooled
libc level: malloc/free
For example platon42's TLSF patch only affect the OS low level. Depending on how the higher level allocators are implemented, modifying the lower level allocator might have some effect or practically none at all. For example TLSFMem has very little to no effect on AmigaOS 3.x AllocPooled/FreePooled performance. Additionally 68k libnix allocator will be slow regardless of TLSFMem.
The reason is that both memory pools and the libnix malloc actually maintain their own memory lists, which are relatively slow (due to poor choice of "first fit" algorithm). These allocators rarely call the lower level allocator.
Luckily the allocator speed is rarely an issue. It might be with some C++ apps for example, or with some complex applications such as IBrowse. With IBrowse you can easily spot the slow down after couple of days uptime.
-
>after you mention it i made tests with two quickie opengl ports i did for 68k. i compile >them usually with -noixemul > libnix but now i linked against bernds ixemul too.
memalloc performance is only important when often mem is alloc and free during program run.you must first find such a program.programs that use xml library (netsurf) or C++ programs are good candidate
>maybe i should try to run netsurf port on chris hodges tlsf. could it make any difference?
no this not help also not with libnix programs that use malloc.malloc is on both libs handled in an internal way.
>Even the AmigaOS 3.x with TLSFMem patch fails to fix it properly: It only changes the >behaviour of the external allocations. Internally the pools still use either list or tree and >
>Allocate/Deallocate for the internal allocations.
there is poolmem prog attached in tlsf mem that fix so pools work fast too.but can not use with AFA because poolmem on AFA is same as MOS and AROS and support MEMF_SEMPROTECT flag to make mempools thread safe.
-
there is poolmem prog attached in tlsf mem that fix so pools work fast too.but can not use with AFA because poolmem on AFA is same as MOS and AROS and support MEMF_SEMPROTECT flag to make mempools thread safe.
right, no problem i could turn off afaos, muforce, and copymempatch if need be, and turn the tlsfmem and tlsfmempool on in my s-s for the sake of testing. but would the speedup be measurable. i mean, in real world performance, not after hours and days of messing with the system to maximize memory fragmentation. i expect not. whadda ya think?
-
I watch out for news of Hyperion Secret Project on their Webpage.maybe they do memory protection... ;-)
Then existing Amiga software is not going to work anyway. So...
but anyway, a Function that set and get Task user Pointer is the cleanest solution so nobdy need hack in the task structure.
But the task structure is already public. Adding Set/GetTaskUserData() is not going to change anything. There is no way you could add non-co-operative memory protection, there is no way you could get existing software support new APIs, the whole Amiga API is flawed anyway.
-
>Adding Set/GetTaskUserData() is not going to change anything
it change in that way, that there is no reason to access the task structure direct.
and this is really not more additional work.
normaly you need write
struct Task * task = FindTask(0);
task->tc_UserData = dat;
or write
SetTaskUserData(FindTask(0),dat);
thats really a stupid reason, to do lots work to make a Unix soft working with libnix.and when you accidently destroy userdata by wrong written program is notice soon.
I still ask several times and i still have no link see of ffmpeg for MOS to see how much work it was or where can download a list of functions MOS libnix support.then we can see how much more functions ixemul V62 support.
A good api should always have a list of functions it support when there is no source here so can see in source what functions it support.ANd that a OS need register to download a SDK is also bad.
I think changing a big Unix program to work with libnix is lots more work than use a function
SetTaskUserData(FindTask(0),dat);
or so.
also i told you ixemul can easy change to use tc_taskTrap instead of tc_TaskUserData.
Then i maybe do that so tc_userdata is free.
>is no way you could add non-co-operative memory protection, there is no way you could >get existing software support new APIs
but when enhance a Unix program to use AOS its a new program and so can very easy avoid to use tc_userdata.there need lots more programing work to get a Big unix program with libnix MOS working i think.
You still have not told where in netsurf you access tc_userdata.I find no place when i search whole files
-
thats really a stupid reason, to do lots work to make a Unix soft working with libnix.and when you accidently destroy userdata by wrong written program is notice soon.
I still ask several times and i still have no link see of ffmpeg for MOS to see how much work it was or where can download a list of functions MOS libnix support.then we can see how much more functions ixemul V62 support.
A good api should always have a list of functions it support when there is no source here so can see in source what functions it support.ANd that a OS need register to download a SDK is also bad.
I told you there was nothing particularly interesting in these changes. Just implemented cbrtf and round and fix some bsdsocket stuff (close->closesocket and ioctl->ioctlsocket).
The list of supported functions is available in the headers and link libs. And the SDK is available for download on morphos-files.net.
-
normaly you need write
struct Task * task = FindTask(0);
task->tc_UserData = dat;
or write
SetTaskUserData(FindTask(0),dat);
This is only little bit more useful than using AllocDosObejct() to allocate FileInfoBlock. Luckily your version does not have return code.
I think changing a big Unix program to work with libnix is lots more work than use a function
You might thinks so but it isnt so. Not with MorphOS libnix.
also i told you ixemul can easy change to use tc_taskTrap instead of tc_TaskUserData.
But maybe I am using tc_TrapData field for my own purposes. Unlikely but possible.
there need lots more programing work to get a Big unix program with libnix MOS working i think.
Usually problems lie on path handling. They default to /usr/ or parse paths in Unix way. If I was using ixemul I would have to do that anyway because it is not very nice when users start getting "Please insert volume usr: to any drive" requesters. Unless it is GeekGadgets port which requires GG environment anyway.
Another big problem is porting dependencies which sometimes takes over five minutes. Five hours if I create shared library out of it.
-
>Another big problem is porting dependencies which sometimes takes over five minutes. >Five hours if I create shared library out of it.
there is ixlibray that allow easy automatic create of Unix libs.have not done it yet, because static is most time ok when there is no free time.megacz have done a new ixlibrary sdk and do some libs.see here.
http://megacz.back2roots.org/portsbttr.html
make a unix lib for MOS seem lots work.OS4 support sobj, dont know if that work fully automatic, but when look OS4 seem have most unix dynamic link libs.
>The list of supported functions is available in the headers and link libs. And the SDK is >available for download on morphos-files.net.
You mean here ?
http://www.morphos-files.net/categories/development/C
I see no headers for this.i search for atanf not find.
I find some defines but i hope the MOS devs know, this defines do not work with offical C++ stdlibc++.
they need the real thing because they do undef all
#define LOG10 ((double) 2.302585092994046)
#define FPTEN ((double) 10.0)
#define FPONE ((double) 1.0)
#define FPHALF ((double) 0.5)
#define FPZERO ((double) 0.0)
#define trunc(x) ((int) (x))
#define round(x) ((int) ((x) + 0.5))
#define itof(i) ((double) (i))
#define fabs IEEEDPAbs
#define floor IEEEDPFloor
#define ceil IEEEDPCeil
#define tan IEEEDPTan
#define atan IEEEDPAtan
#define cos IEEEDPCos
#define acos IEEEDPAcos
#define sin IEEEDPSin
#define asin IEEEDPAsin
#define exp IEEEDPExp
#define pow(a,b) IEEEDPPow((b),(a))
#define log IEEEDPLog
#define log10 IEEEDPLog10
#define sqrt IEEEDPSqrt
#define sinh IEEEDPSinh
#define cosh IEEEDPCosh
#define tanh IEEEDPTanh
see cmath file
#include
// Get rid of those macros defined in in lieu of real functions.
#undef abs
#undef div
#undef acos
#undef asin
#undef atan
#undef atan2
#undef ceil
#undef cos
#undef cosh
#undef exp
#undef fabs
#undef floor
#undef fmod
#undef frexp
#undef ldexp
#undef log
#undef log10
#undef modf
#undef pow
#undef sin
#undef sinh
#undef sqrt
#undef tan
#undef tanh
>Usually problems lie on path handling. They default to /usr/ or parse paths in Unix way.
and again, do you not think its easy possible to switch this file translation off ?
I think it can easy done.
-
I donwload also the file for vbcc.
http://www.morphos-files.net/remote/VBCC,_MorphOS_target
this also contain only very few API funcs.for example math.h is only this
/* math.h - PowerPC */
#ifndef __MATH_H
#define __MATH_H 1
extern const char __infinity[];
#define HUGE_VAL (*(const double *)(const void *)__infinity)
double sin(double);
double cos(double);
double tan(double);
double sinh(double);
double cosh(double);
double tanh(double);
double asin(double);
double acos(double);
double atan(double);
double exp(double);
double log(double);
double log10(double);
double pow(double,double);
double sqrt(double);
double ceil(double);
double floor(double);
double fabs(double);
double atan2(double,double);
double ldexp(double,int);
double frexp(double,int *);
double modf(double,double *);
double fmod(double,double);
#ifndef __NOINLINE__
double __asm_fabs(__reg("f1") double) = "\tfabs\t1,1";
#define fabs(x) __asm_fabs(x)
#endif
#endif
-
Here is math.h what ixemul support
__BEGIN_DECLS
double acos __P((double));
double asin __P((double));
double atan __P((double));
double atan2 __P((double, double));
double ceil __P((double));
double cos __P((double));
double cosh __P((double));
double exp __P((double));
double fabs __P((double));
double floor __P((double));
double fmod __P((double, double));
#define fmodl fmod
double frexp __P((double, int *));
double ldexp __P((double, int));
double log __P((double));
double log10 __P((double));
double modf __P((double, double *));
double pow __P((double, double));
double sin __P((double));
double sinh __P((double));
double sqrt __P((double));
float sqrtf __P((float));
double tan __P((double));
double tanh __P((double));
#if !defined(_ANSI_SOURCE) && !defined(_POSIX_SOURCE)
double acosh __P((double));
double asinh __P((double));
double atanh __P((double));
double cabs(); /* we can't describe cabs()'s argument properly */
//double cbrt __P((double));
double copysign __P((double, double));
double drem __P((double, double));
double erf __P((double));
double erfc __P((double));
double expm1 __P((double));
int finite __P((double));
double hypot __P((double, double));
#if defined(vax) || defined(tahoe)
double infnan __P((int));
#endif
double j0 __P((double));
double j1 __P((double));
double jn __P((int, double));
double lgamma __P((double));
double log1p __P((double));
double logb __P((double));
double rint __P((double));
double scalb __P((double, int));
double y0 __P((double));
double y1 __P((double));
double yn __P((int, double));
long lrintf __P((float));
long lrint __P((double));
float roundf __P((float));
double round __P((double));
double log2 __P((double));
float truncf __P((float));
double trunc __P((double));
__math_decl int lroundf(float x)
__math_decl int lround(double x)
__math_decl float ceilf(float x)
__math_decl float floorf(float x)
__math_decl float frexpf(float x,int * exp)
__math_decl float ldexpf(float x,int exp)
#define signbit(x) ((x) < 0)
__math_decl float powf(float x,float y)
__math_decl float sinf(float x)
__math_decl float cosf(float x)
__math_decl float fmodf(float x,float y)
__math_decl float atan2f(float x,float y)
__math_decl float atanf(float x)
__math_decl double cbrt(double x)
__math_decl float cbrtf(float x)
-
What about downloading the actual SDK instead of VBCC?
And what the f*ck with ixlibrary and shared objects. If you want an unix clone, why don't you switch to the real thing. At least it will work properly.
-
>What about downloading the actual SDK instead of VBCC?
You mean at this link ?
http://www.morphos-files.net/remote/MorphOS_includes
this i download too, see post of files above
>And what the f*ck with ixlibrary and shared objects. If you want an unix clone, why don't >you switch to the real thing. At least it will work properly.
I avoid long times to use Linux Soft(i begin only in sept 2008 to enhance ixemul and SDL and build new GCC), but if nobody do AOS software, then its better to run that on AOS instead of linux.linux is very complicate to handle and develop.windows is much more easy, but windows progs cant port so easy to AOS and enhance with Features.
also i like to use this linux libraries in amiblitz because i dont like code in C.
On MOS/OS4 there is more than 90% of native Software Linux Ports (please count the programs), without more features as on Linux, but still much software miss here.
So i think its better when it is more easy to Port Unix Software, when nobody write amiga programs that offer the functions.and when ypou can port a linux prog in 1 hour instead of 20 hours, yxou have 19 hours left to add amiga Features to it, or port more.
change to Linux is a no go for me, because i want use dopus magellan as desktop and the amiga dev tools.also i use lots 68k Software and Linux UAE is not so good.
I also want run windows games from time to time.
-
make a unix lib for MOS seem lots work.
It is basicly the same as in that ixlibrary package you posted above and if you had used it in more complex projects you would know why ixlibraries also need lot of work sometimes ;-)
-
>It is basicly the same as in that ixlibrary package you posted above and if you had used it >in more complex projects you would know why ixlibraries also need lot of work >sometimes ;-)
ixlibraries are create out of scripts, maybe it fail sometimes, but this can enhance.
I dont know, is there any script on MOS here to make a amiga library automatic ?
Still nobody post a link to full MOS sdk so can see how much and what functions MOS libnix have.so can see whats miss in libnix but ixemul have
-
You can find it here: http://teleinfo.pb.edu.pl/krashan/u/mos_sdk/
-
You mean the libnix update ?
but thats no offical page.
math.h (which contain some C99 funcs) is from 2004 and now 5 years old.In linux land much is enhance in last 5 years.because linux is free linux devs use sooner new features.
also this math.h in MOS seem from ixemul math.h and enhanced, but it still have no full C99 support.but ixemul 68k have this too not, i am too lazy to do that.
When a dev on 68k miss a function in ixemul he report me that and i update it in libc of ixemul.this take normaly not more than 5 days.But if the last update of MOS libnix is years back, so the chances to a full C99 support on libnix look not very good.
What i still not see, how libnix on MOS handle socket for Linux.I see no socket.h file
amiga bsdsockets are lots diffrent to Unix sockets.functions are same but the datatypes are diffrent.
So there need all Unix programs lots change that they work with amiga bsdsocket.
unix sockets or amiga sockets do no speed diffrence, i see with libcurl.
here is declare of Unix socket func bind und send
int bind __P((int, const struct sockaddr *, int));
ssize_t send __P((int, const void *, size_t, int));
here is declare of amiga bsdsocket bind send. you see long and int is diffrent, this give compiler errors on more strict compiler settings some programs use.ffmpeg compile for example as default with C99 Compiler flag set and compile correct in this mode with ixemul
#define bind(s, name, namelen) \
LP3(0x24, LONG, bind, LONG, s, d0, const struct sockaddr *, name, a0, LONG, namelen, d1, \
, SOCKET_BASE_NAME)
#define send(s, msg, len, flags) \
LP4(0x42, LONG, send, LONG, s, d0, const UBYTE *, msg, a0, LONG, len, d1, LONG, flags, d2, \
, SOCKET_BASE_NAME)