• autoconfig detects now correctly that AOS have a vfork function and uses this automatically
  (help gcc, make build and I guess lots other without source changes)
  
• assert use the in newer GCC obsolete eeprintf func not.
  
• Use V48 signal method this get working CTRL+c, OWB, vfork on 68k again(was broken in V49 68k)
  
  
• if no int __stack variable is set in program source, a default stacksize from the envvar ixstack is use.
  if no envarc:ixstack env var is find, the minimum stacksize is set to 512000 bytes.
  If on shell or Icon more stack than the minimum is set, then this stack size is use.
  
  Sound large, but Unix/Linux programs need lot stack.the value of 512 kb is a praxis value, because I find no program currently that use more stack than 400 kb.but don't think 512 kb is far enough.
  
  The cygwin Unix API give Unix/Linux tasks 2 MB of stack and also windows programs get on default 2.5 MB of stack. So if you have lots of ram and you want be on the safe side better set ixstack to 2000000
  
  If you are low on amiga mem, you can lower the stack value up to 16384 same value as ixemul 48 or 49.
  
  BUT BE SURE ALWAYS look how much stack a program need. There are not many programs out, that work correctly with this low stacksize. So you need carefully set the values in shell-startup or icons by yourself to useful values.
  
  
  
• An env variable IXENVARC added, if set then ixemul read the env variables on dir envarc and not in env: This "Hack" helps make it easy to get ixemul working when envhandler or happyenv is used.
  
  Change an envarc that already exists, work in env: and envarc
  
  Limits: when you create a new env variable only in env: and not in envarc: then this is not notice. So rule is, add new env vars always in envarc.
  
  
• stack usage can see when program end, work also on vfork tasks now In ixprefs enable show stack usage and start program ixstack -s from shell.

I think it is unfortunate that you chose to bump version to V50. 68k executables asking for V50 wont run in MorphOS because its ixemul.library uses version number 49. Now 68k ixemul is not in sync with MorphOS anymore.

Quote:

if no int __stack variable is set in program source, a default stacksize from the envvar ixstack is use. if no envarc:ixstack env var is find, the minimum stacksize is set to 512000 bytes. If on shell or Icon more stack than the minimum is set, then this stack size is use. Sound large, but Unix/Linux programs need lot stack.the value of 512 kb is a praxis value, because I find no program currently that use more stack than 400 kb.but don't think 512 kb is far enough. The cygwin Unix API give Unix/Linux tasks 2 MB of stack and also windows programs get on default 2.5 MB of stack. So if you have lots of ram and you want be on the safe side better set ixstack to 2000000

In MorphOS I am usually using the default stack size (32k) and that is on PPC which needs much more stack than 68k. I have got only very few ixemul stuff using more stack than that.

Last edited by itix on 20-Feb-2009 at 08:11 PM.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

In effect v50 is represented by MorphOS/AmigaOS4.0 libraries, this could give problems...

Honestly I have almost 3-4 different versions of that library on my HD and I really don't know which one is correct for my system (and I have a 68k platform!)

Why that ?

How to make a single archive with all the release/extension within for 68k (all CPUs) AmigaOS 4.x, MorphOS and so on ? ...

_________________
BACK FOR THE FUTURE

http://www.betatesting.it/backforthefuture

Sam440ep Flex 800 Mhz 1 GB Ram + AmigaOS 4.1 Update 6
AmigaOne XE G3 800 Mhz - 640 MB Ram - Radeon 9200 SE + AmigaOS 4.1 Update 6

Wow, great stuff!
Thanks! Its probably my most used library :D

Also, a download link would be nice.

Last edited by mike on 20-Feb-2009 at 10:41 PM.

_________________
C= Amiga addict
,,,
(Oo)
⎛☮ໄ
ﮑὠՀ
Couldn't care less what other people think, seeing that there's concrete evidence they don't.

http://sourceforge.net/project/showfiles.php?group_id=48010&package_id=90649

Ah, found the source.
http://amiga.svn.sourceforge.net/viewvc/amiga/ixemul/


Shouldn't v50 be 49.30?

Last edited by mike on 20-Feb-2009 at 11:04 PM.
Last edited by mike on 20-Feb-2009 at 11:02 PM.
Last edited by mike on 20-Feb-2009 at 11:00 PM.
Last edited by mike on 20-Feb-2009 at 10:59 PM.
Last edited by mike on 20-Feb-2009 at 10:55 PM.
Last edited by mike on 20-Feb-2009 at 10:53 PM.

_________________
C= Amiga addict
,,,
(Oo)
⎛☮ໄ
ﮑὠՀ
Couldn't care less what other people think, seeing that there's concrete evidence they don't.

@bernd

thanks a lot for the work done on ixemul.library

@all

It's not easy to decide the version for a library developped at the same time on 3 platforms.

_________________
BTW, what you have done for the amiga today ????

-A1200+Mediator+VooDoo3+060/50+96mo+SCSI-KIT
-SAM440EP-667mhz-on MapowerKC3000+AOS4.1

Amiga Docs Disks Preservation Project

The link to new version is here,

http://amiga.sourceforge.net/

or direct.

http://amiga.sourceforge.net/phps/logger.php?download=ixemul-50.0-060f.lha

and below is a download buttom.also note the 060 version should work on all systems best.if you notice a slowdown to V48 let me know

older ixemul use fpu asm code for math functions that is emulate on 040 and 060.
the new lib use the amiga os math lib and is faster on 040 060.there are also mathlibs out, that speedup more.

>I think it is unfortunate that you chose to bump version to V50. 68k executables >asking for V50 wont run in MorphOS because its ixemul.library uses version >number 49. Now 68k ixemul is not in sync with MorphOS anymore.

sorry for that, the main reason was because on 68k was a V49 out, that make lots problems with ixemul software(signaling not work).V48 work better on 68k.i read always when somebody report problems with OWB, he use V49 ixemul.

to avoid problems, a dev can use the V50 crt0.o this open a requester and show the user, that the ixemul V48 V49 is too old.or if he want he can stay on old crt0.o

also V50 offer new function that MOS V49 have not.
SYSTEM_CALL (atan2, 676)
SYSTEM_CALL (strtoll, 677)
When not change revision then programs that need new functions crash silently because they miss functions.

maybe MOS version is update too to V50, the source is at sourceforge, it is also possible of cource to join here.

i think V50 contain many important fixes and help more programs to run.

>In effect v50 is represented by MorphOS/AmigaOS4.0 libraries, this could give >problems...

if the OS4 or MOS ixemul V50 offer more features, i of course add this

BTW: I use in AFA iconlib version 53.This indicate that AFA iconlib support the new OS4 iconlib features as truecolor get and put, that is need for eastern so it run unmodified on 68k with true color thumbnails.

the cybergraphics library of AFA have V45 and indicate, that there is writepixelarrayalpha and other MOS Functions here.(pen less drawing funtions)

AFA is so called MOS/OS4/amiga68k compatible.

but its of course not good that there is no common extendet API for amiga OS enhancements.I suggest long time ago be MOS compatible and offer OS4 functions as source, for example the allocsysobject sources of MOS OS4 emu are in aminet thanks to Ilka, but this can do with more functions, so MOS/AROS/68k coder coder can use if they wish OS4 functions when they think they are more usefull.

Last edited by bernd_afa on 21-Feb-2009 at 01:14 PM.
Last edited by bernd_afa on 21-Feb-2009 at 12:07 PM.
Last edited by bernd_afa on 21-Feb-2009 at 12:06 PM.
Last edited by bernd_afa on 21-Feb-2009 at 11:51 AM.
Last edited by bernd_afa on 21-Feb-2009 at 11:50 AM.
Last edited by bernd_afa on 21-Feb-2009 at 11:43 AM.
Last edited by bernd_afa on 21-Feb-2009 at 11:42 AM.

As per Usual...

"Essentially it is a BSD Unix kernel running under the Amiga OS. The code for handling Unix signals is taken almost verbatim from the BSD kernel sources, for example. Multitasking and file I/O is, of course, passed on to the Amiga OS. Because the library resembles BSD Unix so closely, it has made it possible to port almost all Unix programs."

Taken from http://amiga.sourceforge.net/index.php?sfcontent=/project/shownotes.php?release_id=315727&group_id=48010

_________________
Rage quited 29th May 2011

@bernd_afa
Quote:

i think V50 contain many important fixes and help more programs to run.

I'm currently using OS4 PPC native version 51.10 of ixemul.library in order to compile a few OS3 programs with old GCC 2.95.xx compiler. Since I do encounter a few problms with that setup, I'm wondering if your v50 works under emulation with OS4.x?

_________________
X1000 with 2GB memory & OS4.1FE

>I'm currently using OS4 PPC native version 51.10 of ixemul.library in order to >compile a few OS3 programs with old GCC 2.95.xx compiler.

to OS4 ixemul have the amicygnix Author written on amiganews, that OS4 ixemul miss vfork, 68k version is more compatible as amicygnix as far i understand this.but he have not test V50.

http://www.amiga-news.de/de/news/comments/thread/AN-2009-02-00010-DE.html

I dont know if you have test to run a 68k ixemul on OS4.
The V50 is more system friendly than older Versions and use no traps or Exceptionhandler, maybe you get luck and work under OS4 ?.let us know.

if so, if somebody enhance the makefile so OS4 native versions can build, maybe no amicygnix version is need, because ixemul is the top of Unix compatiblity and firefox get reality on amiga Systems

Thanks Bernd.

I tried the new library. OWB works better than it ever has but is still slow. OWB must be waiting somewhere because other programs run at full speed at the same time while multitasking. Hopefully this will give some insentive for the OWB author to make another 68k build.

I found a different behaviour with IXNET/IXEMUL and GLQuake/BlitzQuake. GLQuake does not start and I get this message...

I_Error: NET_Init: you need a valid host name, or use -ip

On all previous versions of IXNET/IXEMUL it was not necessary to set the host name. I do NOT have this variable set in either ENV: or ENVARC:.

I was hoping this would happen for ages... so it's good to see it appear!

Now I've moved on to 4.1 so I don't need it as far as I know

Makes me want to get a 060 classic going and go back to 3.3.3 gcc

_________________
~Yes I am a Kiwi, No, I did not appear as an extra in 'Lord of the Rings'~
1x AmigaOne X5000 2.0GHz 2gM RadeonR9280X AOS4.x
3x AmigaOne X1000 1.8GHz 2gM RadeonHD7970 AOS4.x

>Makes me want to get a 060 classic going and go back to 3.3.3 gcc

there is currently a gcc 4.3.2 here.

http://www.daten-transport.de/ansicht.php?id=pYMMqJbgMgmu

and 4.4.0 for 68k i can send.it run on cygwin, but i try compile soon newest gcc 4.3.3 for run on 68k.
Because 68k amiga OS is in the main gcc sourcetree, it is very easy build a upto date 68k gcc.only some special amiga syntax addon that are not in gcc main source i dont want add, because they are not need. ixemul use since beginning only the offical GCC register to variable feature, so the special amiga feature is not need important.also MOS OS4 compiler support this special 68k register to variable feature not.

>I_Error: NET_Init: you need a valid host name, or use -ip

thanks for info, i look wy it is diffrent.

EDIT:

I dont know what blitzquake you mean, i get only this in mind, but this use no ixemul.library but work on my system. i also let run OWB and start it, work too

http://aminet.net/package/game/shoot/BlitzQuake_68k

Last edited by bernd_afa on 22-Feb-2009 at 11:20 AM.
Last edited by bernd_afa on 22-Feb-2009 at 09:59 AM.
Last edited by bernd_afa on 22-Feb-2009 at 09:55 AM.
Last edited by bernd_afa on 22-Feb-2009 at 09:54 AM.
Last edited by bernd_afa on 22-Feb-2009 at 09:51 AM.

@Bernd

Keep up the good work! Thanks and I appreciate the updated ixemul!

IKE

I figured out the problem with BlitzQuake (or rather me). I had left Genesis running and it gave me that error. I guess I had never left Genesis running before while playing. I get the same behavior as with previous versions. There wasn't really much of a chance of a problem any way if BlitzQuake doesn't use ixemul or ixnet . False alarm.

Looking forward to the GCC 4.x 68k release! Hopefully it will be compiled for 68060 (works well on 68040 too). Your efforts should bring a lot more Amiga classic support!

Last edited by matthey on 22-Feb-2009 at 03:54 PM.

I have now compile 4.3.3 68k. mmap did not work correct.

gcc is written and can work too without mmap, but browser as firefox or OWB need mmap,
the amiga versions use workaround in OWB, but i think there should better add a good working mmap to ixemul.I am too lazy to add workarounds in software.

problem is, that mmap on ixemul currently give a unaligned address in compare to pagesize. when use mmap gcc code look that it can faster work, but its important that the page adresses are aligned by pagesize.pagesize is in ixemul 2048 bytes.

this can fix easy by allocate mem of pagesize more and do a & that do address align,
but i need more test, how many mem waste this bring in praxis.also i test if it speedup when page sizes > 2048 bytes used.

or maybe need a allocater for mmap that alloc chunks 100* larger size as pagesize.so there are only 2 kb every 200kb blocks more allocate and only when 100 pages are used, a new large mem block is allocate.

maybe somebody know code of such memory allocater.maybe there is mmap emulator code out

so no hurry up, the time come that 68k maybe get a firefox or other modern browser or OWB easy

Notice that in order to compile something you need to process libc.a & libc_p.a with ranlib first !!!

x303

Bernd,

Look at the allocaligned() function here...

http://www.morphos-team.net/tlsf.html

It's not the most elegant, and may not be good for fragmentation if there is a lot of allocations, but it does work on AmigaOS classic and MOS including with TLSF and doesn't waste as much memory as allocating extra memory. Maybe it will get you up and going faster with the mmap implementation.

thanks for link, thats a good idea to save mem, but cost more speed.

but i look how often gcc call mmap, it is only call 5 times in a large program and alloc 2 MB and so my method waste only 20 kb with 4096 bytes page size.

but i add this new method too, i dont like waste mem.if a program use very often memmap i let the old code in too, so i see if the additonal allocmem free loose speed in praxis.

now the compiler work and write file to t:xxxx.s, and now come next problem a command line is send to assembler, so the assembler want read file from dh0:t//xxxxx.s

now i need look more wy compiler output and assembler input use diffrent paths and what old compiler do.