new ixemul V62.1 for 68k.

[bernd_afa]

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.

[Piru]

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.

[bernd_afa]

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.

[kolla]

I suggest respecting local variable HOME before using global HOME.

[itix]

If HOME is missing you could just throw a requester kindly asking user to reinstall GeekGadgets.

[Matt_H]

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.

[kolla]

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?

[bernd_afa]

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.

[itix]

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.

[bernd_afa]

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.

[itix]

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.

[bernd_afa]

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

[bernd_afa]

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

[itix]

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.

[bernd_afa]

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.