new ixemul V62.1 for 68k.

[unusedunused]

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.

[unusedunused]

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.

[unusedunused]

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 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.

[unusedunused]

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.

[unusedunused]

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

[unusedunused]

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, ...)"

[unusedunused]

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.

[unusedunused]

>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.

[unusedunused]

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.

[unusedunused]

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

[unusedunused]

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.

[unusedunused]

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...

[unusedunused]

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.

[unusedunused]

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

[unusedunused]

>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.