Amiga.org
Amiga News and Community Announcements => Amiga News and Community Announcements => Amiga Software News => Topic started by: ami_stuff on May 22, 2009, 07:19:26 AM
-
FFmpeg is a complete, cross-platform solution to record, convert and stream audio and video. FFmpeg can also convert from any sample rate to any other, and resize video on the fly with a high quality polyphase filter.
1. convert avi video file to mpg with audio bitrate 128kb & video bitrate
1024kb:
ffmpeg -i test.avi -acodec mp2 -ab 128kb -vcodec mpeg1video -b 1024kb test.mpg
2. convert wmv video file to avi (divx) with audio bitrate 256kb and video
bitrate 1024kb:
ffmpeg -i test.wmv -acodec libmp3lame -ab 256kb -vcodec msmpeg4v2 -b 1024kb test.avi
3. convert jpeg2000 image file to bmp:
ffmpeg -i test.jp2 test.bmp
4. convert wma audio file to flac:
ffmpeg -i test.wma test.flac
You will also find FFplay video player in the archive.
FFplay requires ixemul.library v61. You can download it from here:
http://amiga.sourceforge.net/?showpackage=ixemul.library
Two versions of FFplay are included:
FFplay - compiled with High-Quality MP3 decoder
FFplay_MP3LQ - compiled with Lower-Quality MP3 decoder
To reduce CPU usage, you can set AHI unit 3 to "Paula: DMA 8 bit stereo".
IMPORTANT: When you want to use FFplay with WinUAE, you must copy
"env/ahi_minbufflen" file to "ENV:" and "ENVARC:".
While playing:
q, ESC quit
f, ENTER toggle full screen
p, SPACE pause
a cycle audio channel
v cycle video channel
t cycle subtitle channel
w show audio waves
s skip frame
x save screenshot
left/right seek backward/forward 15 seconds
down/up seek backward/forward 1 minute
LMB click seek to percentage in file corresponding to fraction of width
RMB click hide/show mouse pointer
If your Amiga is too slow to play videos, you can try some tricks:
1. disable audio:
FFplay -an file.avi
2. skip B-frames:
FFplay -skipframe 16
3. play lowres version of the video:
(be careful with this option, because it can crash your system
when used with some codecs - this is not Amiga-related bug)
FFplay -lowres 1 file.avi
or
FFplay -lowres 2 file.avi
4. play video in grayscale:
FFplay -gray file.avi
5. hardcore version :)
FFplay -an -fast -gray -quiet -skipframe 16 -lowres 2 file.avi
Thanks to Bernd Roesch for his bugfixed/improved ixemul and SDL libraries.
Amiga 68k port by Piotr Bandurski
Download link:
http://aminet.net/gfx/conv/ffmpeg-svnr18880-m68k.lha
-
Nice but I doubt it will make much fun even on 68060.
-
Thanks for this great proggy!!!!!
-
GREAT JOBBBB!!!! i just tried it on my a4k 060, its faster than megacz's port of mplayer. the test porky.mov is played back insync with audio on!. i tried also a couple of other more complex avis up to 640x480. up till now if they were playable then only with warpos enchanced players. now with low_quality_mp3 and -lowres and skipframe it is possible to view them even if with distorted sound and frameskip. if it could be optimized further we could even have a working 68k amiga media player. i do not dare to hope...
it seems to be quite stable too!! no hits whatsoever, responsive while execution!
-
if it could be optimized further we could even have a working 68k amiga media player. i do not dare to hope...
I'm afraid you can forget about the optimizations. The code is pretty much as optimal as it can get.
Also, I wonder what is going on with those "ixemul" version numbers... Unlike what some have speculated elsewhere, those bumps weren't my idea. My request was to rename the library, as it clearly no longer is compatible. If you're wondering why I care about the 68k library: 68k ixemul applications also work on MorphOS, but any binary linked with link libraries from the "new ixemul" SDK will not. Just because of the version bump... The correct way to handle this is to rename the new library, especially since library API changes appear to have occurred (why else would there be a bump?).
When I was requested the ixemul source code I wondered what could be the worst case situation resulting from it. I came up with: "Some less clued developer releasing incompatible versions with bumped version." Too bad this has come to pass.
Please Bernd, stop breaking ixemul, rename your branch.
-
@piru: if im not mistaken this port still seems to use sdl for display. but even if its not optimizable still its quite impressive on pure 68k
edit: well, yes it was me that supposed that discussions between you and bernd result in this wild version numbers. edit: sorry, bullshit on my side. yes, renaming the lib might be a good solution and wouldnt harm anyone. but are you sure that new functions in ixemul break things on mos? did you try and found an example?
-
well, yes it was me that supposed that discussions between you and bernd result in this wild version numbers. but as far as ive been able to test the 68k versions of sdl ports do not work on os4 and of course vice versa, unfortunatelly i do not know of mos, since ive got no machine i could run it on.
MorphOS ixemul can run both original 68k and PPC native binaries.
but i dont believe mos has to rely on 68k sdl ports anyway, so how does this break anything on mos?
Any application built for 68k using the new SDK fails to start on MorphOS. Remember: ixemul can also be used for closed source projects, so source code might not be always available.
To correct the situation the library must be renamed, and fast. The longer anyone has the non-renamed ixemul SDK installed, more probable are the broken binaries being generated. Having the library renamed would have several benefits:
1) Developers would be able to build binaries targeted for known shared API (ixemul) which would work on both classic AmigaOS and MorphOS or for the bernd-ixemul. If needed, binaries for both could be provided.
2) Bernd could keep on expirementing on his own "ixemul" fork freely, without upsetting developers involved in the ixemul at every release.
3) If bernd-ixemul actually ends up having some useful changes, then either those can be backported to "original" ixemul (without actually being FORCED TO, as would be the case now), or the bernd-ixemul could be built for the target system. This way both could co-exists easily.
but are you sure that new functions in ixemul break things on mos? did you try and found an example?
The new functionality breaks even with 68k: namely trying to make ixemul amigaos thread safe. This is not possible mainly because of the way unix like signalling works. So the current 68k bernd-ixemuls are broken, especially when anything relying on this "thread-safety" is used, for example SDL. It might seem to work for now, but certain usage patterns will make it die horribly. In general ixemul does not mix with amigaos calls and ixemul should only be used to build non-amigaos code. Bernd is not experienced enough to understand this, it seems.
-
bernd may be less experienced than you and a stubborn person, but if he wasnt we would miss one of the few remaining programmers that still move things on 68k forward. if you are really concerned about above why dont you talk privately to bernd? im sure he is eager to learn and improve things and would accomodate every constructive advice into his work. since the code seems to be on sf you even could work together to assure keeping mos compatibility in ixemul.
-
if you are really concerned about above why dont you talk privately to bernd?
I have tried talking to him. It didn't help, it seems (the library did not get renamed).
im sure he is eager to learn and improve things and would accomodate every constructive advice into his work. since the code seems to be on sf you even could work together to assure keeping mos compatibility in ixemul
MorphOS ixemul will only accompany changes we approve of. So far none of them have. Considering bernd and I disagree on fundamental issues co-operation isn't possible (I doubt he would be willing to revert most of his changes).
-
@Piru
I have write here and send you a PM because you give no answer in the last ffmpeg news.I can not find a link, maybe somebody can post it here ?
here i explain more, that i think about it and i am near sure i make a 100% compatible solution and i explain how it work.but you do not asnwer or have some arguments wy it not work.
everything is possible and ixemul can also work with amiga tasks.
BTW; I make zune working together with MUI.and if i can get MUI4 sources i want make it too working together with MUI3, because for my matter of taste MUI4 is too incompatible to MUI3.
maybe you know not much about me, i like to have perfect compatible solutions, and no feature loss and unlimitet feature enhance , and i like the fastest and cheapest CPU ;-)
A also offer you, that you change the lib.I have no time for that, there is lots more needed to do.
MorphOS ixemul can run both original 68k and PPC native binaries.
Any application built for 68k using the new SDK fails to start on MorphOS. Remember: ixemul can also be used for closed source projects, so source code might not be always available.
The new functionality breaks even with 68k: namely trying to make ixemul amigaos thread safe. This is not possible mainly because of the way unix like signalling works.
what is your problem, wy should ixemul 68k not get new functionality ?.
Have somebody cry when OS4 the ixemul without working vfork and other problems number it as V51.1 instead of rename it ?
have somebody cry when MOS number his ixemul to V49 and miss features or break compatibility without reason, or add the 60 features, because the change userdate structure order, or dont implement ixtrace ?
As i told V61 is full compatible.You can see this also when you look on source.
So there is more reason to rename MOS or OS4 ixemul lib.But i never told that ixmeul for MOS and OS4 should rename.
I for example make zune seperate of MUI, the same i do with MUI4 if i have sources, because zune and MUI4 are less compatible to MUI3.
But ixemul V61 is much more compatible as MUI4 and MUI3, so wy i should rename lib ?
when you see the new features, most of them can need on old programs too.so wy i should implement this twice ?
I accept that a library get progress, and i see that on MOS in last years not much progress done.no C99 funcs add.missing features are not add.(no ixtrace)
I think zapek was the guy who mainly work and implement over 60 Unix functions to enhance MOS ixemul(what is enhance in OS4 i dont know).I think he make the buildscripts and make it possible to build this lib also on 68k with amogaos option in buildscript.
But zapek give up MOS long time ago and release ixemul and some other sources.
And there is since year not much necessary enhance i see.
so if MOS or OS4 ixemul never reach V61 then there is no problem possible.MOS have since years V49 OS4 since years V51, so its easy to speculate that MOS or OS4 ixemul maybe never reach V60.
I think ixemul with his ixtrace and profile features very good to develop fast programs and find where the slowdown is
The new functionality breaks even with 68k: namely trying to make ixemul amigaos thread safe. This is not possible mainly because of the way unix like signalling works.
But sdl programs use no unix signalling.SDL have own signalling and thread functions that are based on amiga os.look on SDL source and sdl program.
same when use pthread.this too use own signalling
ffplay is very complex in threading, there run 5 SDL treads together, so if something is really wrong, crashes and enforcer hits can see very soon.and if somebody know that ffplay play sound and no video, this is a known problem on all systems.
-
The only problem I see here is that ixemul.lib v61 is not 100% compatible to MorphOS's version, but of course software compiled for ixemul.lib v48 (m68k) will run without problems with ixemul.lib v61.
Why it's not compatible anymore? Because there are new fuctions added to ixemul.lib v61.
Bernd bumped ixemul's version so high to preven ixemul+SDL mixed binaries to run on the MorphOS, because these binaries would only crash the system.
I don't know if it is OK or NOT to mix ixemul & SDL code, but I can tell that FFplay works OK, the same about some other programs which didn't work before.
Normal binaries which don't use SDL code and new ixemul's functions can run without problems on the MorphOS, but here is a version's check problem (v61 vs v49). Bernd may remove version check, but as a result programs linked with libSDL will crash on the MorphOS without any warning.
It's not a easy situation, because m68k users don't need any new library. There is only need for improved ixemul.lib which will work better with already ported software (for example, Bernd's ixemul.lib will not crash the system when there is not enough memory).
My solution is to have 2 lib (lib/lib_61) dirs, so I use lib_61 only when I need ixemul+libSDL compatibility or any new ixemul's functions implemented by Bernd.
-
I ask you again: Please rename your ixemul library. These version number tricks are NOT helping at all. They're just polluting the name/versionspace needlessly.
As you say, old program will work just fine when using the old library.
When the new features are needed, the new library is used.
What you've done now is to make it impossible to release any ixemul library unless if you bump version to 62. That is just unacceptable.
-
From a user perspective, I completely agree with Piru.
The v61 naming convention is confusing. I kept thinking it was a typo for v51. If it's not 100% API compatible across all systems, it should be forked. One might conceivably install v61 on a MorphOS system because of its higher version number and end up breaking things.
Down the line, what happens when other programs or system components start using the v61 numbering convention? Version numbering is a good way to lock out use within architectures (like v34 and v36 on 68K), but now that we have multiple architectures evolving independently, using version number lockouts between architectures lays the framework for serious problems in the future.
Besides, shouldn't a name change be as simple as a find-and-replace operation in the source code?
-
As you say, old program will work just fine when using the old library.
with the new library they work much better.the first was increase of buffer size.gcc compile faster and many programs start faster.
and when there come later speedup on some funcs old programs are too faster.maybe a new mem allocator
see also ixemul V61 featurelist.
* because most Linux programs do not check if enough memory is here and to avoid them crash badly after a failed malloc
a check is add if memory cant allocate.
then a requester come that show how many mem need, and the user can free memory on other programs
and can then click on try again.
also i know when there are more programs use code, then Bugs find better.i for example always test a little new ixemul lib with OWB 68k.if that make problems, i see fast i have add a bug.
this is one of the importants of software developing.the more programs or users execute functions and the faster can tell it is rock solid.
If it's not 100% API compatible across all systems, it should be forked.
thats not my fault.ixemul is create on 68k
ixemul is port to MOS.MOS add in V49 functions that V48 ixemul dont have and MOS V49 miss some functions and is not 100% compatible.i have add all funcs MOS V49 have so i do all right.when i add additional features then it is clean to increase libnum to V50.
But see here the readme.morphos
Remaining issues:
"""""
- traps are not handled yet.
- ix_panic() does not work properly (varargs conversion needed).
- 'man' crashes here. I've not investigated why yet.
- programs that rely on low-level internal ixemul structs won't work.
The only one I know doing that is 'gdb'. Recompiling it with some minor
changes should take care of the problem.
- ixtrace is not yet supported.
- neither is profiling.
- not compatible with the powerup bridge currently. That may or may
not change.
- DTYPE_MEM is broken, disabled for now.
""""
ixemul is port to OS4.it have number V51.1.But it contain not the features MOS V49 ixemul have.
also OS4 version miss more features as vfork, than MOS V49 have.
here is readme of OS4 Version, and there is since several years no update
""""
You can use this AmigaOS4 port of ixemul.library to run most m68k ixemul
software on AmigaOS4, but it's not a complete port, especially for PPC
native software some functions are not implemented (actually the most
important ones, you can only build simple PPC native programs for which
you wouldn't need ixemul ...), and even for running m68k ixemul software
it's not complete: It has no automatic stack enlargment, if the stack is
too small it will crash the application with a "trap".
"""""
if there really need a lib rename, then i think it is the ixemul of MOS and OS4 and not ixemul 68k.
because they break compatibility much more, thats a Fact.
and if they want emulate 68k then they need upgrade their lib, or less programs run, but dont force 68k side to stop further developing on ixemul.
i dont understand wy on MOS or OS4 the 68k ixemul V61 not work.it use ne special 68k code and no traps.
if somebody want help then 68k ixemul can use and then the incompatible native libs are not need.
sure i know there are some guys that want that 68k make no feature progress and stay retro and new features should only MOS or OS4 have.
-
with the new library they work much better.the first was increase of buffer size.gcc compile faster and many programs start faster.
You're adding large default buffers just to get good performance with specific programs?
If a program needs larger buffers it can set them via setvbuf call.
Making the libc level buffer excessively large is a bad idea. If you need general faster I/O, add cache to device level (dynamicache for example). That will give you much better results, without eating precious system memory for every single filehandle.
and when there come later speedup on some funcs old programs are too faster.maybe a new mem allocator
Good luck with that. The ixemul memory system is quite fast in fact. But even if you add a new memory system it will still be bound by the memory system of the OS itself, so the correct place to fix it is at the OS level.
* because most Linux programs do not check if enough memory is here and to avoid them crash badly after a failed malloc
a check is add if memory cant allocate.
then a requester come that show how many mem need, and the user can free memory on other programs
and can then click on try again.
This should not be in libc, or at least it should be off by default.
also i know when there are more programs use code, then Bugs find better.i for example always test a little new ixemul lib with OWB 68k.if that make problems, i see fast i have add a bug.
Huh, OWB uses ixemul? That's just horrible. Please tell me ain't so!?
this is one of the importants of software developing.the more programs or users execute functions and the faster can tell it is rock solid.
Have you heard of unit testing?
Please rename the library. You're ruining ixemul for everyone with this mess.
- MorphOS ixemul.library missing features: Irrelevant. Those only affect MorphOS, not ixemul overall.
- Regarding OS4 ixemul.library version foul up: Two wrongs don't make one good.
- Your version fuckups ruin it for EVERYONE else. Please rename the library
-
You're adding large default buffers just to get good performance with specific programs?
I use the default buffer size other systems have.clib2 use 8192 bytes, so i use that too.
i know from very program on my real classic, that 1024 bytes of buffer is too small.aztec c use default 4096 bytes.this also cause some speedloss.8192 used on clib2 is a good value.
most do no benchmarks, so they dont notice that.
Good luck with that. The ixemul memory system is quite fast in fact. But even if you add a new memory system it will still be bound by the memory system of the OS itself, so the correct place to fix it is at the OS level.
sure but old ixemul have own mem system.when i have tlsf in amiga os, then i must change ixemul that it support stright amiga os alloc
and that is need on both versions.
This should not be in libc, or at least it should be off by default.
Wy do you write its in libc ?
its of course in malloc func.look the source
and if malloc return 0 then the requester come.
and this feature is testet and confirm its lots better than crash whole system because Linux programs assume unlimitet memory, because of virtualmem and selden check for enough mem.
Huh, OWB uses ixemul? That's just horrible. Please tell me ain't so!?
thats the Version Jörg Strohmayr do, 1.4 work stable.
the OWB 1.2 use SDL and is 2-3 * faster than 1.4.
that 1.2 is faster with SDL is also confirm from more User.but 1.2 is unstable but thats because SDL 1.2.6 used for OWB was too old and buggy and slow
-
most do no benchmarks, so they dont notice that.
You're running what kind of benchmark exactly?
sure but old ixemul have own mem system.when i have tlsf in amiga os, then i must change ixemul that it support stright amiga os alloc
and that is need on both versions.
No, it's not. ixemul allocator is fast enough as it is. Changing it to use OS allocator (even when TLSF) directly doesn't give enough performance boost to justify such a change.
Wy do you write its in libc ?
Because it is. malloc is provided by the C library, which ixemul is.
and if malloc return 0 then the requester come.
and this feature is testet and confirm its lots better than crash whole system because Linux programs assume unlimitet memory, because of virtualmem and selden check for enough mem.
And how can you tell that the application is not testing for the result? This is moving the application level functionality to the libc. This is not a good design: malloc is supposed to either return memory or quietly return 0. Adding requesters requiring user interaction is a bad idea. What if your program does handle the low memory situation, and could continue just fine even if the allocation fails, but now is stuck in some requester requiring user input? The program cannot continue. Imagine running for example apache that runs out of memory. Instead of recovering, the web server will now be stuck waiting for user input.
Please, don't break ixemul anymore. Please rename your library.
-
Nice but I doubt it will make much fun even on 68060.
*laughs*
Imagine running it on an 030, which is what most people have! :lol:
-
*laughs*
Imagine running it on an 030, which is what most people have! :lol:
Sure, imagine running it on 68000. :hammer:
Good luck with DivX on your 030 even with asm-optimized MooVId.
-
If he renames it, then surely old applications will not work with it (And some of the changes he has mentioned would benefit some older applications)
Isn't he free to call it what he likes. Those that don't want to use it, can use the older library.
-
If he renames it, then surely old applications will not work with it
The old applications will continue to use the old ixemul.library and work adequately, as before.
Isn't he free to call it what he likes.
Unfortunately he doesn't seem to listen to reason.
Those that don't want to use it, can use the older library.
The problem is, as it is now the decision is not left to the user. If the developer makes the mistake of installing the latest bernd-ixemul he will automagically create binaries that are only able to work with bernd-ware (even if none of the bernd-ixemul features would be needed!). Regardless what the user does he can only use bernd-ixemul. This is the very heart of the problem.
The library should be renamed. Then there would be no issues from the version conflicts. As it is now the situation is very damaging for the future of ixemul (both non-bernd and bernd).
-
The old applications will continue to use the old ixemul.library and work adequately, as before.
There is no such thing as an old ixemul.library that works adequately.
Every ixemul I ever tested was a hopelessly bug-ridden hack.
I found all that out the hard way. :(
Recently people have been insisting at me that it has become safe to once again start using ixemul software if I will only use Bernd's new bugfixed version. But today I see that Piru has exposed at least 1 bug in Berndemul.
I even created my own ixesux.library to try to "go around" the problems of ixemul and that did fix one set of problems but other problems persisted if someone used ixemul and ixesux at the same time they magically conflicted with each other. There is some heavily illegal code in there somewhere. That is why I said above it is "hopeless". Nobody is ever going to spend the needed 200 hours of work to fix all the bugs in ixemul.
So I simply refuse to use ixemul software.
The above message was a friendly informational message.
Warning: if anyone flames me for this message I will cease & desist from trying to help out with the Grand Ixemul Problem.
-
GREAT JOBBBB!!!! i just tried it on my a4k 060, its faster than megacz's port of mplayer. the test porky.mov is played back insync with audio on!. i tried also a couple of other more complex avis up to 640x480. up till now if they were playable then only with warpos enchanced players. now with low_quality_mp3 and -lowres and skipframe it is possible to view them even if with distorted sound and frameskip. if it could be optimized further we could even have a working 68k amiga media player. i do not dare to hope...
it seems to be quite stable too!! no hits whatsoever, responsive while execution!
@wawrzon:
Do you have 060@50MHz or maybe overclocked?
I think that I can try to optimize mpegaudio decoder to run faster on the 68060 CPU, but to test if it really work faster I would need someone with a real 68060 CPU + installed OxyPatcher.
The problem is that 68060 CPU don't have "muls" instruction and this instruction SHOULD be used a lot with mpegaudio decoder. Right now this instruction is NOT USED, because I compiled ffmpeg for 68060 CPU, so GCC "emulates" "muls" instruction with longer code supported by 68060 CPU. I think it may be possible that 68060 + OxyPatcher would be faster compared to GCC's "emulated" code.
On the WinUAE mpegaduio decoder compiled for 68040 (with "muls" instruction) needs only 29 sec. to decode 5 min. MP3 file. 68060 build needs for the same task 1:25 min., so you can see how slow GCC code is.
x86, PPC and ARM CPUs have belowe functions asm-optimized:
#ifndef MULL
# define MULL(a,b,s) (((int64_t)(a) * (int64_t)(b)) >> (s))
#endif
#ifndef MULH
//gcc 3.4 creates an incredibly bloated mess out of this
//# define MULH(a,b) (((int64_t)(a) * (int64_t)(b))>>32)
static av_always_inline int MULH(int a, int b){
return ((int64_t)(a) * (int64_t)(b))>>32;
}
#endif
#ifndef MUL64
# define MUL64(a,b) ((int64_t)(a) * (int64_t)(b))
#endif
#ifndef MAC64
# define MAC64(d, a, b) ((d) += MUL64(a, b))
#endif
#ifndef MLS64
# define MLS64(d, a, b) ((d) -= MUL64(a, b))
#endif
/* signed 16x16 -> 32 multiply add accumulate */
#ifndef MAC16
# define MAC16(rt, ra, rb) rt += (ra) * (rb)
#endif
/* signed 16x16 -> 32 multiply */
#ifndef MUL16
# define MUL16(ra, rb) ((ra) * (rb))
#endif
#ifndef MLS16
# define MLS16(rt, ra, rb) ((rt) -= (ra) * (rb))
#endif
Someone optimized for me two of the functions for 68020-68040 CPUs:
static inline av_const int64_t MAC64(int64_t d, int a, int b)
{
union { int64_t x; int hl[2]; } x = { d };
int h, l;
__asm__ ("muls.l %5, %2:%3 \n\t"
"add.l %3, %1 \n\t"
"addx.l %2, %0 \n\t"
: "+dm"(x.hl[0]), "+dm"(x.hl[1]),
"=d"(h), "=&d"(l)
: "3"(a), "dmi"(b));
return x.x;
}
#define MAC64(d, a, b) ((d) = MAC64(d, a, b))
static inline av_const int64_t MLS64(int64_t d, int a, int b)
{
union { int64_t x; int hl[2]; } x = { d };
int h, l;
__asm__ ("muls.l %5, %2:%3 \n\t"
"sub.l %3, %1 \n\t"
"subx.l %2, %0 \n\t"
: "+dm"(x.hl[0]), "+dm"(x.hl[1]),
"=d"(h), "=&d"(l)
: "3"(a), "dmi"(b));
return x.x;
}
#define MLS64(d, a, b) ((d) = MLS64(d, a, b))
but I need 68060 versions. The rest of the C functions should also be asm-optimized for 68060.
-
https://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/2009-May/022626.html
-
@ami_stuff: no. it is not overclocked. as far as understand oxypatcher just like cyberpatcher patches non optimized exes on the fly. so you want someone to run your current exe on a regular 060/50 with oxypatcher on? unfortunatelly i do not recall to have this soft but i havnt examined the software boxes i got lately with my last purchuase. i see softwarehut has this too, maybe i could get it if need be.
-
Nice but I doubt it will make much fun even on 68060.
This rocks! I installed it last night and ran it this morning and its really good. I encoded a Futurama episode on my PC, using PocketDVD_Studio using the lowest settings for Video and Audio. Video 61kbs 15 fps; Audio AM raio quality 24kbps Mono and set the resolution to 160x128. I then burned the file to a DVD and transferred to my A4000D. Fired it up in FFPlay and hey presto its runnning fine - video at least; (my audio circuit is flakey due to leaky caps).
A4000D Specs as follows:
A4000D Kick v45.57 Workbench v45.3 BB1, BB2
CSMK11 060 128MB Ram
Z3 Fastlane 48MB
CV3D with scan doubler
Deneb 2.0
80GB IDE HD
-
This rocks! I installed it last night and ran it this morning and its really good. I encoded a Futurama episode on my PC, using PocketDVD_Studio using the lowest settings for Video and Audio. Video 61kbs 15 fps; Audio AM raio quality 24kbps Mono and set the resolution to 160x128. I then burned the file to a DVD and transferred to my A4000D. Fired it up in FFPlay and hey presto its runnning fine - video at least; (my audio circuit is flakey due to leaky caps).
A4000D Specs as follows:
A4000D Kick v45.57 Workbench v45.3 BB1, BB2
CSMK11 060 128MB Ram
Z3 Fastlane 48MB
CV3D with scan doubler
Deneb 2.0
80GB IDE HD
If you really need to re-compress your episodes, next time try to use Cinepak.
The only problem is that the code is not optimized at all, but no one will do it for free just to read that it is still not fast enough to watch your episodes on your 20 years old hardware. At least you can slideshow videos with the recent codecs. On WinUAE there is no problem with speed :)
-
how about replacing sdl parts of code, it displays via sdl i take it? maybe we should create a bounty to optimize it for the last century hw? :P no, im serious..
-
how about replacing sdl parts of code, it displays via sdl i take it? maybe we should create a bounty to optimize it for the last century hw? :P no, im serious..
Yes, without SDL it might be faster because less code would be used. Also, SDL is not asm-optimized, only C code. FFmpeg's MP3 decoder should be repleaced with optimized mpega.library, but no one will do it.
-
And how can you tell that the application is not testing for the result? This
do you want faking me ?
everybody know when linux run out of virtuel mem, apps crash, because devs are most part lazy and dont check for enough mem.
If somebody know this not, please lower ram and deactivate swap space and use linux try ffplay or other player progs show some images etc.
The problem is, as it is now the decision is not left to the user. If the developer makes the mistake of installing the latest bernd-ixemul he will automagically create binaries that are only able to work with bernd-ware
ok it seem you think i am stupid, but now it seem you think all developers are stupid and dont know that the dev files must copy by hand to lib dir.
If a developer not copy crt0.o from V61 and not use libc.a from V61 and use instead the old versions from V49 or V48 all should work on MOS.if it not work on MOS, then its a Bug in MOS ixemul.
also the attached crt0.o is named crt0_v61.o.a dev must foirst rename it
what you want is this.
You want force that ixemul on 68k is not furtherdevdelop because it is port since long time to MOS.right ?
burt what rights MOS have, that now that ixemul run on MOS 68k ixemul cant get new features ?
That you write here so much wrong text, instead change the source so the buildsystem can create another lib show me too its not enough to only change the name.
as you know ixemul is a BSD kernel running on AOS.Can you 100% sure that all work well, if a program use ixemul V48 and 1 program ixemul_ng at same time ?
then there run unnecessary 2 Unix kernels, that need additional signalling , shedulling mem etc.
Can you be sure, that it not slowdown system, when there now 2 ixemultaskswitchers are installed ?
But today I see that Piru has exposed at least 1 bug in Berndemul.
what bug you mean have V61 ?
i read Piru post, they are very long but i see no Bug
I even created my own ixesux.library to try to "go around" the problems of ixemul and that did fix one set of problems but other problems persisted if someone used ixemul and ixesux at the same time they magically conflicted with each other. There is some heavily illegal code in there somewhere.
so and here are the Facts, what i think, just a rename is not enough.
-
@Bernd_afa:
I'm with you.
Go on with your work, improving things on 68k Amiga, and don't bother what people like Piru are saying!
-
@Bernd_afa:
Go on with your work, improving things on 68k Amiga, and don't bother what people like Piru are saying!
There is absolutely nothing wrong with that. But he should still rename the library.
-
@ami_stuff: thinking again im not sure mp3 decoding and sdl display fuctions are critical. disabling audio doesnt bring that much speedup suprisingly at least at low quality player. i know, on 060 mp3 decoding is in fact already an expensive task, but anyway. from what was posted on amigans on topic of the new flash port, replacing sdl drawing fuctions with os4 native has not brought a major speedup. so probably it is just decoding that matters most.
@bernd: after all i too think you are right.
-
@ami_stuff: thinking again im not sure mp3 decoding and sdl display fuctions are critical. disabling audio doesnt bring that much speedup suprisingly at least at low quality player. i know, on 060 mp3 decoding is in fact already an expensive task, but anyway. from what was posted on amigans on topic of the new flash port, replacing sdl drawing fuctions with os4 native has not brought a major speedup. so probably it is just decoding that matters most.
This should be a start when someone want to optimized video player for m68k. MP2/MP3 codecs are used with all of the video files like AVI, MPG and when mpegaduio decoder is slow, you will not get any decent speed even with Cinepak video codec.
FFplay supports a lot of codecs, when you optimize DIvX, it will not speedup MPEG decoding process. Run "FFplay -formats", so you will see how much work it would require to optimize all of this stuff.
Again, SDL code is C only. When you repleace SDL with direct asm-rountines, it will be a lot faster WHEN you use for test uncompressed AVI files.
-
do you want faking me ?
Um, probably not. I didn't quite understand that, sorry.
everybody know when linux run out of virtuel mem, apps crash, because devs are most part lazy and dont check for enough mem.
This is often the case, but yet it does not justify f*cking up libc for the cases where it is not. libc should not bring up some requester when malloc() fails.
The correct way to handle this would be to have a link-library that replaces malloc/realloc/free. This link library would then have the requester code. When building a program that can be expected to crash if malloc fails just add the linklib to the link cmdline in makefile (say -lsafemalloc). Clean, easy, no need to mess up the libc with silly requesters.
Anyone with even decent emount of design experience can see this.
also the attached crt0.o is named crt0_v61.o.a dev must foirst rename it
Bad design again.
With proper GCC 'specs' file it would be trivial to specify the target library you want. This is the industry standard way to handle it.
You want force that ixemul on 68k is not furtherdevdelop because it is port since long time to MOS.right ?
No. I want you to rename your branch of ixemul. Then you can do whatever you like with the API and functionality, without need to worry about messing things up (you'd only mess your stuff then, not everyone elses).
burt what rights MOS have, that now that ixemul run on MOS 68k ixemul cant get new features ?
Sorry, I didn't quite get that.
I suppose you're trying to suggest I somehow try to block your ixemul development. That's not the case; I merely want you to rename the library.
change the source so the buildsystem can create another lib show me too its not enough to only change the name.
Huh, what?
as you know ixemul is a BSD kernel running on AOS.Can you 100% sure that all work well, if a program use ixemul V48 and 1 program ixemul_ng at same time ?
Yes.
then there run unnecessary 2 Unix kernels, that need additional signalling , shedulling mem etc.
Can you be sure, that it not slowdown system, when there now 2 ixemultaskswitchers are installed ?
Yes.
-
@ami_stuff: yeah. i could get this damn delfina with a mp3 decoder dsp, i wantde to do it for weeks. but i could throw as well these >100eur into the basket to optimize mpega.library. are you sure it has to be done from the scratch, there are numerous versions on the net. none asm optimized for mp3 decoding?
-
@ami_stuff: yeah. i could get this damn delfina with a mp3 decoder dsp, i wantde to do it for weeks. but i could throw as well these >100eur into the basket to optimize mpega.library. are you sure it has to be done from the scratch, there are numerous versions on the net. none asm optimized for mp3 decoding?
Yes, mpega.library should be fine for MP3 decoding, but it will not optimize DIvX codec, so as a result you will still have slow playback.
MP3's hardware decoder will not help you as long as FFplay don't support it or there is no mpega.library repleacement which uses your hardware decoder.
But of course first FFplay needs to have mpega.library support :)
When you have AVI file with DIvX video codec and MP3 audio codec, all of these codecs needs to be optimized, not only one, or you will not see any different.
-
Um, probably not. I didn't quite understand that, sorry.
The correct way to handle this would be to have a link-library that replaces malloc/realloc/free. This link library would then have the requester code. When building a program that can be expected to crash if malloc fails just add the linklib to the link cmdline in makefile (say -lsafemalloc). Clean, easy, no need to mess up the libc with silly requesters.
Anyone with even decent emount of design experience can see this.
.
i see no reason, that programmer need do additional work.A requester is always 1000* more usefull than a complete amiga OS crash.
but if there is really a reason that it is better that amiga crash than show a error requester that users should free more memory, i can add a envvar that switch it off.no problem
With proper GCC 'specs' file it would be trivial to specify the target library you want. This is the industry standard way to handle it.
But MOS ixemul handle this not.there are no diffrent spec files to support programs that run on V48.
when use the V49 MOS libc or cr0.o this programs fail on V48 ixemul because V48 miss features.
when use such a program on OS4, then it crash badly, because OS4 ixemul have number V51.
on ixemul V61 such a program work, because this ixemul support V49 MOS funcs too.
so you see MOS V49 is exact same problem, this should rename.there should be a V48 that is compatible and a ixemul_ng for MOS that offer this new functions.
and when you do that what you want from me on the ixemul code, and it work well, i do same.
But dont be believe that i am so stupid and do extra work others want to do.
So my offer is easy, change MOS ixemul to be clean, name the V49 MOS Version that have new functions to a new name.if then both ixemul work on MOS (i have a cybppc and can test)then i make that too.
You still have no logical arguments wy 68k ixemul should rename, but MOS ixemul V49 not.
if you want discusss more, then we can this together with neutral people here.
Morphos is already known on the GPL Violaters, see that entry and read the comments.
http://developers.slashdot.org/comments.pl?sid=142894&cid=11973934
if they say that the furtherdevelop 68k ixemul should rename and the MOS furtherdevelop ixemul need not not renaim, then i accept it.
-
i see no reason, that programmer need do additional work.
Adding -lsafemalloc to the link cmd would be a lot of additional work?
A requester is always 1000* more usefull than a complete amiga OS crash. but if there is really a reason that it is better that amiga crash than show a error requester that users should free more memory, i can add a envvar that switch it off.no problem
The code should not be there at all. If it is there, it should be disabled by default. I've already explained why having such functionality by default is a very bad idea (see the apache example).
With proper GCC 'specs' file it would be trivial to specify the target library you want. This is the industry standard way to handle it.
But MOS ixemul handle this not.
Irrelevant as MorphOS ixemul or SDK do not generate m68k binaries. See below.
there are no diffrent spec files to support programs that run on V48.
when use the V49 MOS libc or cr0.o this programs fail on V48 ixemul because V48 miss features.
But ixemul devkit on MorphOS is used to create powerpc binaries not m68k. As such there is no problem.
when use such a program on OS4, then it crash badly, because OS4 ixemul have number V51.
That is a problem of OS4. Why you chose to repeat it, is a mystery.
But dont be believe that i am so stupid and do extra work others want to do.
Um, what?
So my offer is easy, change MOS ixemul to be clean, name the V49 MOS Version that have new functions to a new name.if then both ixemul work on MOS (i have a cybppc and can test)then i make that too.
If you wish you release your renamed library for MorphOS that is just fine! In fact, I'd welcome it. There's no reason why the two couldn't co-exist.
You still have no logical arguments wy 68k ixemul should rename, but MOS ixemul V49 not.
MorphOS ixemul doesn't allow developers to create 68k binaries that don't run on other ixemul versions.
Morphos is already known on the GPL Violaters, see that entry and read the comments.
Lets examine the claims in that post in detail:
ixemul
Did or didn't you get the source code for ixemul when you requested it?
libnix
Isn't open source that'd require distribution of the sources.
gcc & binutils
http://www.lysator.liu.se/~lcs/files/gg-cross/
I find it quite insulting that you're speading these lies even further. There are no GPL violations in MorphOS. This sounds almost like the rerun of the "MorphOS is based on stolen AmigaOS source code" -lies. Really lame, and childish. I guess people will default to such tactics when all else fails.
if they say that the furtherdevelop 68k ixemul should rename and the MOS furtherdevelop ixemul need not not renaim, then i accept it.
Who exactly? All I can see is a anon post in a slashdot thread. The post is full of lies. Hello!? That's as intelligent as pulling a nazi card or something.
[EDIT]
After some deciphering I think you're referring to the gpl-violations.org thread (http://lists.gpl-violations.org/pipermail/legal/2005-August/000467.html). If you read carefully you learn that the problem was with the wording of the powerup download page. As soon as we found out about the problem (which a) we were never told about b) isn't really a GPL violation [I should also mention that the GPL and LGPL is included on the CD.]), we fixed the download page wording (http://powerup.morphos-team.net/terms.html).
This is the only time MorphOS is mentioned on the gpl-violations.org.
Regardless, gpl-violations.org has no authority on this matter at all, so "asking them" is quite useless.
[/EDIT]
Stop that foolishness and rename the fork already. By insisting on this version bump trickery you're only causing harm to all ixemul versions.
-
MorphOS ixemul doesn't allow developers to create 68k binaries that don't run on other ixemul versions.
then all is clear.ixemul V61 doesnt allow developers to create programs that need V61 funcs to run on other ixemul Versions.
if in the readme stand need V61 ixemul then its clear and the requester show this.
again, it seem not easy possible to run 2 ixemul.Have you not read the Post ?
if it is only a rename this take 5 minutes, i think you need more than 5 minutes to read and post about that, and it is more clever, when you instead of writing here only spend 3 minutes to rename ixemul and post here the diff.
Whats your roadmap about ixemul.after how many years you think reach V60 with MOS ixemul ?.
Or do you think 68k programmers should always force that new programs with modern features run on MOS too and MOS devs should not write programs to use new features that run on 68k ?
I have also the new function add from MOS, so programs can common written with V49 functions on 68k and MOS.
currenlty you have bring no facts, is it true that MOS give a PPC program a ppc ixemul before a 68k version ?
and a 68k program that want a V61 ixemul but there is only a V49 PPC ixemul open then a 68k ixemul with that number ?
so wy cant V61 68k ixemul not run on MOS, if there is no native lib ?
I use no traps.
then MOS user and you can see, that all work stable and clean and 100% backward compatible.i am sure if V61 run on MOS, then there run more 68k ixemul programs than with V49 ixemul.
-
Yes, without SDL it might be faster because less code would be used. Also, SDL is not asm-optimized, only C code.
most speedcritical is in sdl the YUV to RGB conversion and scaler.MOS or OS4 SDL support working cgx or P96 overlay code, so code can merge easy i think.
but if on classic amigas cards are out that support HW overlay Bug free i dont know.
i remember on my cybervision PPC and the phase5 videoplayer that support overlay (forget name) crash randomly.
so i also dont know if overlay can work stable.
sound is slow, because it use 64 bit commands a 68060 dont have.this is used in the DCT code and antialiasing Filter code.
if somebody know a fast DCT code for 68k cpu, then this func can add.i dont like the gcc assembler mess and i like a amiga dspmath.library i can code in amiblitz, that is systemspecific for 68060 winuae or other CPU.
on winuae it call then native ISSE code, for 68060 asm optimized code.
BTW: You forget in your feature list, that ffplay with no filename open a amiga filerequester.
here is the code of the DCT.i think this are the few speedcritical lines but MULH use a 64 bit mul.the antialiasing filter can also work with FPU, maybe thats faster on a 060.
maybe this code can move in a amiga library imdct36 and more programs can use it ?
same with other speedcritical funcs ?
static void imdct36(int *out, int *buf, int *in, int *win)
{
int i, j, t0, t1, t2, t3, s0, s1, s2, s3;
int tmp[18], *tmp1, *in1;
for(i=17;i>=1;i--)
in += in[i-1];
for(i=17;i>=3;i-=2)
in += in[i-2];
for(j=0;j<2;j++) {
tmp1 = tmp + j;
in1 = in + j;
t2 = in1[2*4] + in1[2*8] - in1[2*2];
t3 = in1[2*0] + (in1[2*6]>>1);
t1 = in1[2*0] - in1[2*6];
tmp1[ 6] = t1 - (t2>>1);
tmp1[16] = t1 + t2;
t0 = MULH(2*(in1[2*2] + in1[2*4]), C2);
t1 = MULH( in1[2*4] - in1[2*8] , -2*C8);
t2 = MULH(2*(in1[2*2] + in1[2*8]), -C4);
tmp1[10] = t3 - t0 - t2;
tmp1[ 2] = t3 + t0 + t1;
tmp1[14] = t3 + t2 - t1;
tmp1[ 4] = MULH(2*(in1[2*5] + in1[2*7] - in1[2*1]), -C3);
t2 = MULH(2*(in1[2*1] + in1[2*5]), C1);
t3 = MULH( in1[2*5] - in1[2*7] , -2*C7);
t0 = MULH(2*in1[2*3], C3);
t1 = MULH(2*(in1[2*1] + in1[2*7]), -C5);
tmp1[ 0] = t2 + t3 + t0;
tmp1[12] = t2 + t1 - t0;
tmp1[ 8] = t3 - t1 - t0;
}
i = 0;
for(j=0;j<4;j++) {
t0 = tmp;
t1 = tmp[i + 2];
s0 = t1 + t0;
s2 = t1 - t0;
t2 = tmp[i + 1];
t3 = tmp[i + 3];
s1 = MULH(2*(t3 + t2), icos36h[j]);
s3 = MULL(t3 - t2, icos36[8 - j], FRAC_BITS);
t0 = s0 + s1;
t1 = s0 - s1;
out[(9 + j)*SBLIMIT] = MULH(t1, win[9 + j]) + buf[9 + j];
out[(8 - j)*SBLIMIT] = MULH(t1, win[8 - j]) + buf[8 - j];
buf[9 + j] = MULH(t0, win[18 + 9 + j]);
buf[8 - j] = MULH(t0, win[18 + 8 - j]);
t0 = s2 + s3;
t1 = s2 - s3;
out[(9 + 8 - j)*SBLIMIT] = MULH(t1, win[9 + 8 - j]) + buf[9 + 8 - j];
out[( j)*SBLIMIT] = MULH(t1, win[ j]) + buf[ j];
buf[9 + 8 - j] = MULH(t0, win[18 + 9 + 8 - j]);
buf[ + j] = MULH(t0, win[18 + j]);
i += 4;
}
s0 = tmp[16];
s1 = MULH(2*tmp[17], icos36h[4]);
t0 = s0 + s1;
t1 = s0 - s1;
out[(9 + 4)*SBLIMIT] = MULH(t1, win[9 + 4]) + buf[9 + 4];
out[(8 - 4)*SBLIMIT] = MULH(t1, win[8 - 4]) + buf[8 - 4];
buf[9 + 4] = MULH(t0, win[18 + 9 + 4]);
buf[8 - 4] = MULH(t0, win[18 + 8 - 4]);
}
-
I see it is pointless to try argue the matter further. You're just unwilling or unable to understand even the basic concepts of good design and good development practices.
Anyone using the new ixemul for development will lose the ability to run the binaries under MorphOS. Instead the programs will just crash and die horribly (there is no way to avoid this now, it is inevitable because of the bernd version mess).
It would be possible to avoid this all, and have all binaries running on different platforms just fine, if only the bernd-ixemul library would be renamed.
It is very unfortunate that the stubborness of one developer has lead to this.
Overall this will lead to death of ixemul as a portability platform. Such incompatible versions will spell total chaos and confusion for both developers and end users.
I won't be bothering you again about this. Have a nice day.
-
@ bernd:
voodoo supports overlay atl east as far as its used by elbox driver to display dma signal streaming from a tv card in a workbench window. its fully resizable and all. i dont know exactly of p4 but i could test it someow. but since there was also tv-receiver module for p4 once i believe also p4 supports overlay to some extent. i have both graphic cards installed in my both main amiga machines so i can test. i have also some cv64 layin around here, so i could build system to test that too. have been too lazy so far..
-
Background:
The version number problem with ixemul has been around since before Bernd came onto the scene. Probably since before MOS.
There have always been certain programs that required vA of ixemul.library while others demanded vB. When the new vB version of ixemul was used certain older programs stopped working correctly. But switching back to vA did not solve everything either. Some other different programs broke under vA. Its been a long standing problem.
This same thing has happened with lots of other shared libraries also. Basically any complex library that gets steady development over time seems to develop this problem eventually. The more coders that work on the library the more likely it seems to be to occur.
PROBLEM: Libraries are Global.
The filename "ixemul.library" is global.
The code inside ixemul.library is global.
ixemul.library can be considered to be one gigantic global variable.
This is all true for any shared library.
When 2 different people write 2 different programs that expect a particular global variable to behave differently, there will be bugs and crashes.
SOLUTION: Stop using global variables. Use local variables instead.
Everyone who wants "ixemul" functionality must link in a static .lib (ixemul.lib) into their exe.
That is the only solution that will ever work 100% for everyone.
-
Anyone using the new ixemul for development will lose the ability to run the binaries under MorphOS.
Instead the programs will just crash and die horribly (there is no way to avoid this now, it is inevitable because of the bernd version mess).
thats complete wrong, because MOS have only a V49 ixemul, a program that need V61 ixemul bring a requester V61 ixemul need.
then User can try 68k ixemul V61.If thats not work on MOS, thats not my fault.MOS is announce as 68k compatible, and when ixemul V61 not work, then MOS 68k EMU have Bugs until you show me whats wrong in ixemul V61 Code.
and currently you have not show me whats wrong, about the out of mem requester it is also easy possible to change.
Overall this will lead to death of ixemul as a portability platform. Such incompatible versions will spell total chaos and confusion for both developers and end users.
again this is done with your MOS V49.
A MOS developer can choose if he want develop faster and use V49 funcs or develop slower and have 68k compatibilty.
and what do you guess is the choose ?
A developer can also on V61 choose that he want only use V48 V49 funcs so the 68k program run maybe on MOS.again if it not work there is possible that MOS ixemul is incompatible.
working together seem not possible of diffrent platforms on amiga land,
and thats not my fault, i make you many suggestions to solve this problem, but you react in my eyes as a little child without logical reason, wy 68k ixemul should always stay on functionaltiy as V48 and never should get more features as V48.
You also dont want help to get running ixemul V61 on MOS or post the changes need in the buildscript to change the name.
-
This thread blows my mind. I don't know how somebody could accumulate enough skill and experience to develop stuff like this and come to the conclusion that modifying the standard behavior of malloc is a good idea. Mind blowing.
-
and currently you have not show me whats wrong, about the out of mem requester it is also easy possible to change.
apache was a very good example.. and using a global environment variable to disable your "hack" (requester) is not good either for other programs which may need it.. The best should be to create a "blacklist" (or "whitelist") where to add programs which should or not use that extra check over malloc(), IMHO.
That said, IIRC all that regarding "strange versions bumps" started due the broken V49 version for m68k. Well, what about REMOVING from Amiga.sf ixemul V49, 50, and 61, AND THEN change your ixemul 61.1 to version eg 49.30 (i think last MOS version is ixemul 49.26) ?? Can't this be ok for both parts?.. (if this cause certain m68k programs to crash under MOS/OS4, don't worry, we should interpret it as a MOS/OS4 fault, the same way other programs already crashes under OS4 by the V51 version used there(?))
-
most speedcritical is in sdl the YUV to RGB conversion and scaler.MOS or OS4 SDL support working cgx or P96 overlay code, so code can merge easy i think.
but if on classic amigas cards are out that support HW overlay Bug free i dont know.
Classic Amigas have overlay with various cards:
CV3D, PicassoIV, Prometheus/Mediator/G-rex+3dfx Voodoo... IMHO it's a good idea supporting it
@Diego
Jumping back to version 49.30 sounds better. The main problem here is IMHO that there's no cooperation between OS4/MOS/OS3 developers and they don't work together to bring new ixemul versions... I would prefer something using SDI headers, like sourceforge MCC classes, that compiled in the three OSes. And global variables are not a good idea. Perhaps it could be changed to create some kind of ixemul.resource in memory with all that global variable stuff. Then the code could be changed to use the same name as the library, e.g. newixemul.library and newixemul.resource.
I think that Bernd could simply add some "experimental version warning" for developers and that he should keep separated the malloc stuff. The idea of adding a simple flag when compiling like -lsafemalloc proposed by Piru is quite reasonable.
BTW, is libnix updated to latest MorphOS versions? I usually avoid using ixemul...
I really appreciate the efforts Bernd does in the 68k front but Piru knowledge of AmigaOS inner working is impressive and his advice should be followed.
I would prefer there was some cooperation between OS4/OS3/MOS devs. It doesn't make much sense that there are 3 people reinventing the wheel with incompatible versions of the same library...
As ChaosLord as suggested, couldn't new v61 ixemul be statically linked? that way we would fix the problem temporarily until the 3 teams cooperate.
Good job with the ffmpeg port for 68k... does it convert FLV to Cinepak? that could make possible to use Tubexx with AmigaOS3 and use common avi/mov players like Moovid to play the files with weak cpus.
BTW, 680x0 cpus usually decode mp3 faster using integers.
-
They don't really need to "work together" to bring new ixemul versions... there we had V48 for ages and a new V49 was made for MOS bringing new API functions, then that lib gets backported to OS3.. if new functions are added later to that os3/68k version, the MOS's ixemul-maintainer should implement such new api functions to create THE compatibility, and so on for each platform.
How the library itself works internally on each platform does not "really" matter.. while it works ok (without causing conflicts between systems), of course. For example, for the ixemul >= 50 Bernd had to get the vfork/signals stuff from the V48, because the one re-implemented for V49-MOS didn't worked ok under OS3/m68k.. but thats ok after all, the new ixemuls are (should be) compatible with the <= V49 branch, regardless how it works internally.
and about SDI headers, thats ixemul.. not a simple OOP "program" ;) i doubt it can be done by using macros, i think everything would need to be ifdef'ed to compile ok around systems.
-
This thread blows my mind. I don't know how somebody could accumulate enough skill and experience to develop stuff like this and come to the conclusion that modifying the standard behavior of malloc is a good idea. Mind blowing.
on a harddrive this behaviour is standard, there come message disk full, and a user can free some memory and try again.Is this not usefull ?.Or is it better to change as in memalloc case, to crash the system, if not enough hardisk space is here, or end the program, or force a developer to check if there is always enough diskspace free ?
i have now download apache and search for malloc
the first entry i find was in support.ab.c
""""
ssl_info = malloc(128);
apr_snprintf(ssl_info, 128, "%s,%s,%d,%d",
SSL_CIPHER_get_version(ci),
SSL_CIPHER_get_name(ci),
pk_bits, sk_bits);
""""
here you see no check for enough mem, result is crash, with overwrite of execbase.i can make ixemul more stable when i do a check in snprintf that it do nothing when 0 pointer, so all programs work better, annother reason again 2 Versions.
""""
if ((cleanenv = (char **) calloc(AP_ENVBUF, sizeof(char *))) == NULL) {
log_err("failed to malloc memory for environment\n");
exit(120);
}
""""
here if the memalloc fail the program is end (exit(120)) do that and a user cant free some memory so the program contiue to work
there are other places that do mem alloc check in apache, but i think all result in that case that apache end.but the requester in ixemul allow a user to free some mem and he can then click on try again and apache do not end and continue to work.
A black and white list is too much work for this feature, but there are only contra about that feature here read only pro from me, i deactivate it as default, and if a user want be more sure that his system not crash, he can activate that.
Jumping back to version 49.30 sounds better. The main problem here is IMHO that there's no cooperation between OS4/MOS/OS3 developers and they don't work together to bring new ixemul versions...
[/ QUOTE]
this too not work.OS4 have their lib number as V51.1 but this support not OS4 functions.
Also when you say, we should stay at a same level, then look on programs that are out.
every dev side do additional work, to support only their features.
for example read here about the itf8_decode function only in MOS 2.0
http://utilitybase.com/
for this few lines, netsurf is not easy portable and need MOS 2.0.o think with codepage.library utf comvert is too possible, maybe it need not char by char call and is faster, i dont know.
My experience is, that new MOS or OS4 functions are mostly small functions, and devs do their best to make their programs not easy portable.
.see netsurf or OWB or other opensource programs that are portet opensource.Yam /simple mail have much more complex GUI as OWB or netsurf and there is a sourcetree possible without changes.
but when look on netsurf, i see 1,3 megabyte OS4 only code and 960 kb MOS MUI only sourcecode.
I really ask how it is possible to write so much diffrent code only for diffrent GUI that is far not so large as YAM or simplemail.
Is reaction really worth to do this big extra work ?
in the linux world there is tolerance for each system.but not an amiga OS.the comercial aspect, that every commercial AOS need enough user to support further development, introduce the red versus blue war i think and some strange comments to other systems that enhance AOS features too.
Again it is not easy to change the ixemul name only and programs can work together.
if it is easy, then i think Piru have done this and post the diffs here.I have suggest him this at beginnung to do, but he write instead long in my eyes unlogical and senseless Posts with wrong Facts, i must correct, so i need write too much.
As ChaosLord as suggested, couldn't new v61 ixemul be statically linked? that way we would fix the problem temporarily until the 3 teams cooperate.
i prefer that with 68k SDL, but sdl is also a static lib, so it is easy.
but for ixemul this also is too much work in compare the advantage you get, i really dont know what problem it have.
ixemul V61 programs dont crash MOS, situation is same as a MUI4 program run not on MUI3.
-
@bernd
I think the problem here is one of perspective. This discussion is a wasps nest, but I'll still try to venture an opinion here.
Perhaps it is so that you persive ixemul as an application, it seems so to me as you persive the code from a users perspective.
This is not a bad thing, but we also try to think architecture. One thing we then should think of is separation of concerns.
Ixemul is a common module, component aka library. It has an API with a defined behaviour. Even if this behaviour is bad, or allows clients (applications) to behave badly, it should not be ixemuls concern.
It gets messy. Even though the intentions of changeing the behaviour is good, the concequences might be very messy.
The Apache example is a good example because it's not a user program. It's a webserver which won't have a user infront of a desktop at all times. It will for exaple run headless (no monitor/screen attatched) on a computer, and when it crashes will be autorestarted by a script or other admin tools. It's up to the admin to setup and configure such a system. If a library then start dioing GUI requesters, the admin gets unexpected behaviour, and the server cannot recover by its self. There are many readily made scripts for apache and other server tools which does this, they don't know or have any way of muting such a requester.
My preference both as a user and potential developer for amiga would be a separate patch to ixemul, which could intercept "return 0" from malloc and treat the incident based on blacklists and whitelists. A good separation of concerns, and ixemul behaves according to it's API contract.
I really applaude you bernd for your efforts for 68k amiga, and it's rare that programmers are good enough to see their programs from an end users perspective. This is a good trait of yours.
I understand your reluctance to change your code. It apparently works. But it's obviously creating some problems for others.
It does seem like the critisism you've received is a case of the pot calling the kettle black, and both sides here needs to take a breather and think a bit about how they address the other part. Both sides have not used a respectfull tone at all times, however it's apparent that you've tried to excercise restraint :-)
A problem here is obvious that language is a barrier, you are talking past eachother. Now just stop for a moment, and try to see if there is a middle ground.
All of this isn't only addressed to you bernd. Hence the kettle and pot comment as the malloc issue just seem to be one of the many issues beihg discussed here (version number, name and expanded functionality).
-
@bernd
The Apache example is a good example because it's not a user program. It's a webserver which won't have a user infront of a desktop at all times. It will for exaple run headless (no monitor/screen attatched) on a computer, and when it crashes will be autorestarted by a script or other admin tools. It's up to the admin to setup and configure such a system. If a library then start dioing GUI requesters, the admin gets unexpected behaviour, and the server cannot recover by its self. There are many readily made scripts for apache and other server tools which does this, they don't know or have any way of muting such a requester.
ok, i add a env var, a blacklist is too much work.adding this usefull requester cost me 20 minutes and help a lot.thats a good effort in time to usability.but for coding several hours on such a feature i have no patience because many other i want do that i need more important, maybe something other do that perfect with black and whitelist ?
you are right, i think more as a user, because i want use amiga OS Software and not only coding for fun.i know lots of programs that theoretic, selten used functions can easy use and the everday functions are hard to reach.
I like a feature that give in 99,9% of real world usage a advantage or easier to use.if this is in 0,1% give more work, then overall the time save is a better result.
i think in praxis it more happen get 6 rights in lottery than on amiga os a apache run out of mem ;-)
i think when somebody set up a webserver that run standalone he look that he can not run out of mem carefull on amiga and look that at least 5 megabytes of mem stay free.
And he mus also be carefull that the harddrives are not run out of diskspace.
and when he have appache running and start another program, that need more mem, he have access on his computer, the requester come and he can close the other program or free some mem.
-
A black and white list is too much work for this feature
This isn't much work at all, imho. i can write such code myself if you want.
Jumping back to version 49.30 sounds better.
this too not work.OS4 have their lib number as V51.1 but this support not OS4 functions.
Please, forget about the existence of ixemul for OS4, and then tell us, what do you think now?
(You DON't need to worry about if a ixemul program crash under OS4, it is just not your problem)
netsurf is not easy portable and need MOS 2.0.
Wasn't NetSurf first made for another platform not related to Amiga at all? how it could require some MOS specific stuff?.. (if some implementation indeed requires mos, then just skip it, you know what i mean ;) )
Again it is not easy to change the ixemul name only and programs can work together.
Well, in those last posts we didn't mention to rename the lib, i just suggested to set the version back to 49.x considering it should be ok to both parts (you Bernd, and Piru).
ixemul V61 programs dont crash MOS.
I really wonder why you worry too much regarding if 68k programs could crash under MOS/OS4, seeing you don't said good things about those OSs at all.
-
treat the incident based on blacklists and whitelists.
Yeah... you had a very good idea there.. :D ;)
-
@dcr8520
Yes, indeed ;-)
-
ok, i add a env var, a blacklist is too much work.adding this usefull requester cost me 20 minutes and help a lot.thats a good effort in time to usability.but for coding several hours on such a feature i have no patience because many other i want do that i need more important, maybe something other do that perfect with black and whitelist ?
Great :-)
How about letting dcr8520 or someone else write a tool that patches (using wht/blck list) malloc functionality, or at least have the default operation to be no requester?
If this compromise can be agreed upon, maybe there is hope for the rest? :-)
What other functionality has been disputed?
-
Well, in those last posts we didn't mention to rename the lib, i just suggested to set the version back to 49.x considering it should be ok to both parts (you Bernd, and Piru).
Yes, i can do that
Please, forget about the existence of ixemul for OS4, and then tell us, what do you think now?
the Facts are this.
68k have a unix emul lib that want MOS devs port to use ixemul Software on MOS.
but during time, ixemul miss more and more features (C99) so they need add.
But when there is somebody that enhance this ixemul library on the Home platform, Piru didnt like that.
now we find out, that it is from MOS dev side not suppport to create 68k progs that use V49 functions on MOS.
i think thats nearly the same as when i add a requester in ixemul 68k V61 libc.new ixemul progs cant use on MOS.
then i can name the ixemul libnum as V51.
should i do that, is then Piru happy ?
thats exact the same situation, because V49 funcs on MOS can only run on PPC.68k they want not support.
MOS have a 68k emulator and can exute 68k progs.
so to follow the MOS side rule, i must add a requester this code cant run on MOS.
Is this now better ?
But i think its better to get new features on MOS too running and increase the feature of all ixemul
If you add blacklist whitelist code is nice.
i think best is only a blacklist, here can add the few programs as apache, that can restart on crash.
What do you think about this ?
-
Wasn't NetSurf first made for another platform not related to Amiga at all? how it could require some MOS specific stuff?.. (if some implementation indeed requires mos, then just skip it, you know what i mean )
the OS4 and MOS side add own code, look on source, OS4 side add a amiga folder with 1,2 megabyte source, and MOS side add a mui folder with 900 kb size.but this folder contain 400 kb of OWB source.
So it look like coding on MOS the same features, there is not so much code typing need
the dir render that contain the browser engine use too 900 kb
another folder css contain 730 kb
so on the source contents can say netsurf is amiga browser, because many is code for amiga specific ;-)
there is a folder for beos, this use 568kb of code.
I like OS that can with less typing reach features, maybe i should change to Beos ;-)
-
Good job with the ffmpeg port for 68k...
Thanks.
does it convert FLV to Cinepak? that could make possible to use Tubexx with AmigaOS3 and use common avi/mov players like Moovid to play the files with weak cpus.
No, FFmpeg have only Cinepak's decoder and as I can see most of the encoders seems to be very CPU-intensive. Of couse raw can be used, but probably output files would be too big. :(
-
If I understand Piru's arguments correctly, the changes to the ixemul includes will affect anything compiled with them, even if they don't use v61 features and that's why running those programs under MorphOS will result in crashes. It's my understanding that with most libraries, compatibility with old versions can be maintained by not using new features, but that doesn't seem to be how ixemul is evolving. Someone who wants to write a 68k program that is compatible with MorphOS will have to use the old includes.
While I still agree that v61 ixemul should be renamed, someone mentioned the idea of unifying development across the Amiga architectures, as with the NList, Texteditor, and codesets projects. I think that's a good compromise, and would like to read other comments on its feasibility.
-
If I understand Piru's arguments correctly, the changes to the ixemul includes will affect anything compiled with
do you think Piru is god ?
Wy you dont believe what i write or wy you not download the ffmpeg and try out on MOS ?.Here you see it do not crash.a requester come need V61 ixemul.
the new includes cant crash on MOS.
but i get in mind, its possible when you do stupid thing.
When you use new V61 libc (that must copy by hand in lib dir)AND not the corresponding V61 crt0.o is copy to lib dir, then it can crash on MOS, because ixemul have the bad design that the version check is in crt0.o and not in libc.
but it is easy possible to remove the check in crt0.o so they are always the same and add the version check in libc.maybe in further release i do that.
-
Well, in those last posts we didn't mention to rename the lib, i just suggested to set the version back to 49.x considering it should be ok to both parts (you Bernd, and Piru).
Yes, i can do that
Ok, we achieved something ;)
then, Piru, it is ok to you as well to set the ixemul-68k's version back to 49.30?
so to follow the MOS side rule, i must add a requester this code cant run on MOS.
Is this now better ?
No, if you really hate MOS let those programs crash :D :D ;)
If you add blacklist whitelist code is nice.
i think best is only a blacklist, here can add the few programs as apache, that can restart on crash.
What do you think about this ?
I hope you do not mean to auto re-start programs when an allocation fails.. in the worst case we can add a per-task flags/options for the behavior to be achieved when an allocation fails, EG: a) show a requester b) kill the application c) let the app continue, etc...
I'll start working on this the next weekend.
-
If I understand Piru's arguments correctly, the changes to the ixemul includes will affect anything compiled with them, even if they don't use v61 features
isn't (only) about the ixemul includes, it's mainly related to the crt#?.o files (startup code each program is linked with, which requires a newer ixemul version regardless if it really needs it)
and that's why running those programs under MorphOS will result in crashes.
No, ATM those programs can't crash under MOS because those programs can't even run there (no ixemul V5x or V6x there)
But, those programs will start to crash under MOS if we set the ixemul-68k version back to 49.30 (until the Ixemul-MOS is updated to implement the new API functions added on newer m68k builds), whatever it is, setting the version back to 49.30 seems the correct action, rather than bumping to 50, 61.1, 70..
-
If I understand Piru's arguments correctly, the changes to the ixemul includes will affect anything compiled with
do you think Piru is god ?
Well, in the Amiga World... yes, almost at least :)
Do you know/remember he rewrote the Exec? with that i said all :D
but it is easy possible to remove the check in crt0.o so they are always the same and add the version check in libc.maybe in further release i do that.
Yes... we need to find a proper way to not require always the higher ixemul version, if new features are not really required/needed/used.
-
Wy you dont believe what i write or wy you not download the ffmpeg and try out on MOS ?.Here you see it do not crash.a requester come need V61 ixemul.
I have absolutely no doubt that is what will happen - because ffmpeg specifically requires v61.
But consider a program that specifies v48. Compile it once with the v48 includes. Compile it again with the v61 includes. Run each of them under MorphOS. What will happen? If nothing bad happens, then I'll shut up and say no more on the matter. :-)
Don't get me wrong - I appriciate the improvements you're making (it's fantastic that we now have ffmpeg and ffplay for 68k). I simply think that because of the divergence of OS3, OS4, and MorphOS, a more pragmatic way to distinguish changes between architectures is in order.
I again refer back to the suggestion to integrate multiplatform builds in the style of Jens Langner's projects.
-
I have absolutely no doubt that is what will happen - because ffmpeg specifically requires v61.
But consider a program that specifies v48. Compile it once with the v48 includes. Compile it again with the v61 includes. Run each of them under MorphOS. What will happen? If nothing bad happens, then I'll shut up and say no more on the matter. :-)
this work too.if a program crash because new features are miss, is not dependent from includes.
it depend on lib you link.the libc contain the functions for ixemul.
when you link with V48 libc then only the V48 functions can use.if a Unix program use a function that V48 not have, but V61 then you get a compiler error.the program cant build, no executable here, that can crash.
same happen when you use SDL for ixemul.on V48 libc.You get compiler error ix_CreateChildData not find.
when you use V61 libc stuff, then it compile well but on MOS get now error ixemul V61 need.
>I again refer back to the suggestion to integrate multiplatform >builds in the style of Jens Langner's projects.
but thats not my problem, we have ixemul on amiga sourceforge and everybody can jump in and do a MOS or OS4 native Port.
But there is red versus blue war and as can see on netsurf, OWB, or other ports that OS4 and MOS cant working together, same on ixemul lib too.MOS V49 and OS4 V51.1 are some kind of diffrent and diffrent sourcetree.
I ask some times about the OS4 source of ixemul, this i not get.
No, if you really hate MOS let those programs crash
i dont hate MOS.
-
i dont hate MOS.
it was an ironic joke, meaning it should be better doing nothing (let it crash or whatever) rather than showing annoying requesters about a program [MAY] not work under MOS and making it die. (unless you create a crt0 which check for version AND revision of installed ixemul..)
-
Um, probably not. I didn't quite understand that, sorry.
This is often the case, but yet it does not justify f*cking up libc for the cases where it is not. libc should not bring up some requester when malloc() fails.
The correct way to handle this would be to have a link-library that replaces malloc/realloc/free. This link library would then have the requester code. When building a program that can be expected to crash if malloc fails just add the linklib to the link cmdline in makefile (say -lsafemalloc). Clean, easy, no need to mess up the libc with silly requesters.
Anyone with even decent emount of design experience can see this.
Completely agree with Piru here. I even think the -lsafemalloc is not needed (overkill). It's up to the host application (and programmer) who calls malloc to see whether it worked or not. There shouldn't be any requesters or something like that coming from malloc. It is indeed a bad design idea.
We should not care what apache does in unix, instead if someone ports it over to Amiga, he should add the proper checks to malloc.
Btw, this is just my opinion, don't get me wrong. I'm very grateful with what Bernd is doing on 68k, and he should definitely keep it up! I also hope this ixemul thing is resolved soon.
-
it was an ironic joke, meaning it should be better doing nothing (let it crash or whatever) rather than showing annoying requesters about a program [MAY] not work under MOS and making it die. (unless you create a crt0 which check for version AND revision of installed ixemul..)
on german anews there are more lies tell about ixemul V61 , but nobody tell wy this version not work.MOS os4 can run 68k programs.
So to have same effect as rename the library, a check for MOS and OS4 must done and the program end and if really a MOS or OS4 user copy the ixemul v61 lib to his system, then this is not load.
but of course nobody can test and find bugs wy this ixemul not work on MOS or OS4.
when enhance a amiga library for OS3, for example intuition library, or guigfx library this make then too problems on MOS or OS4.
because MOS and OS4 have diffrent enhancement, that make only no problem because mos binaries cant execute on OS4 and OS4 benaries cant execute on MOS without emu.
but 68k executable can run on both.
So thats the reason that there some guys that want that 68k not furrtherdevelop.the degrade 68k to a retro system that should not enhance.And this is bad.
and this problem can either solved complete by rename the lib or by check for MOS or OS4.
how mos can detect i know, but how is OS4 detect in clean way ?
-
Completely
We should not care what apache does in unix, instead if someone ports it over to Amiga, he should add the proper checks to malloc.
and thats the main reason, wy many devs left amiga, amiga devs should do more than other.they should make their program run on a 060/50 well or in case of MOS OS4 should run too on slow PPC 600-1 GHZ Systems.
When look what systems are currently on desktop, they are all more powerfull as this systems.so devs safe time, when they develop not for Amiga systems.
the Amiga OS does only very few grow in compare to other OS, there is red versus blue war.this mean user say sometimes new features are crap because their loved OS have them not(.This should demotivate the "enemy" side to enhance more to avoid trolling.so all in all AOS stay on low quality level.
Programs can not easy port from MOS to OS4 etc.some programs are done seperate by a OS4 or MOS OS developer or other, but very few working together.
Additional work cost time, and if a dev not love the amiga very much, wy he should spend additional time and stay on Amiga ?
On Unix there is virtual unlimited mem on amiga not.68k have luck so there is a virtual mem solution, but using virtual mem is slow.i dont like virtual mem, and notice suddenly much slowdown, so i better switch off.and many 68k users have no vmem active.
ffplay is over 12 megabyte sourcecode, this mean 12 million characters, now a porter should find out in this 12 million source lines which do the crash.
its hopless and much work, that Linux or windows progs work in low memory situation, because coders are so lazy here and dont check for enough mem, because of virtual mem system never can run out of mem.
I dont understand wy in the memalloc there is a diffrence in compare to Harddrive, so i think this feature is same usefull as on hardrives standard.
when harddrive is full then a requester come and the user can free mem and continue, wy should not do same on memalloc by default ?
If some rare situations as apache without User dont need it, it can switch off.
without the feature ffplay crash when show a digicam pic of size 3000*2000 when there are not 50 megabyte ram free.
i have more todo than fixing all Unix programs that do not check for enough mem.
and so nobody can report ffplay is crap because it crash showing a pic, this message was mainly add, because the other "sides" maybe dont like that 68k is furtherdevelop, and they look carefully in the hope to find something negative
So its no wonder that there are more and more left amiga and there is really less progress here and the disadvantage for amiga and other OS get more and more.
the reason that this happen is not the bancrupt of commodore i think , it is the split and the users who want fight that the commercial side get more users.
there are not left much here, so other side cant get much users that buy for much money a new amiga system.when i look on download for OS4 ffmpeg and ffmpeg GUI in OS4 depot, (newest version is only here and news links are to os4depot and its longer here)
it have 280 downloads.68k version come in the 6 days to 245 downloads and also some amikit downloads that contain this files.numbers i not know
so there is no reason that 68k should not furtherdevelop both systems are valid on more or less same dead or alive
amiga should make fun and not fight for all costs for users.
i dont want fight for system, i like use amiga dopus magellan2 and i think when i really spend much work on change ixemul name, there come other that bashing, so do only what go in fastest time.
-
bernd, quit here and go back to work.:P it makes no sence to endlessly discuss here conspiracy theories. you can prove your point best by effects of your work.
those who dont like or want, what bernd has done with ixemul or sdl are free to stay away from it. frankly, i do not recall an unix port on amiga that installs _any_ ixemul version by default, let alone not asking the user, but ixemul of this or that versionsnummer is usually named as required. alas not always so with other libraries. construtive criticism along with founded propositions will help all of us to advance. hate-wars will not.
-
@wawrzon:
Please read your PM.
-
I find now a solution that is easy to add, and PPC User can happy that they have the higher library number ;-)
I open in crt0.o the ixemul library V48
when a lib is open, i check in library structure for V48 number and the revisionsnumber.
But the Question is, when the program run on MOS, the library is open, i must check if its V48.is there a correct AOS conform library structure here, or can i identify elsewhere that this is a ppc library and not the 68k ixemul ?
if i detect the 68k lib, then i check for revision
so newer versions with increased API get then a higher revisionsnum.
-
I find now a solution that is easy to add, and PPC User can happy that they have the higher library number ;-)
I open in crt0.o the ixemul library V48
when a lib is open, i check in library structure for V48 number and the revisionsnumber.
But the Question is, when the program run on MOS, the library is open, i must check if its V48.is there a correct AOS conform library structure here, or can i identify elsewhere that this is a ppc library and not the 68k ixemul ?
if i detect the 68k lib, then i check for revision
so newer versions with increased API get then a higher revisionsnum.
Why not simply rename the MOS version to ixemul.library.mos ? This way the 68k programs under mos can safely use ixemul.library and mos programs can use ixemul.library.mos !!! Instead of renaming the 68k version which exists a lot longer than the mos one.
x303 :D :D :D
-
BTW. About stability: You can try to run multiple videos at the same time... of course only under emulation. Nice effect :)
-
I find now a solution that is easy to add, and PPC User can happy that they have the higher library number ;-)
I open in crt0.o the ixemul library V48
when a lib is open, i check in library structure for V48 number and the revisionsnumber.
Don't do this.
Yesterday, I started testing a method to open only the required library, meaning that if someone compiles a program using V61 SDK, and that program only uses V48 functions, the program will only require ixemul.library V48. that's nice/best, isn't it? :)
First tests i did succedd, and for now i only found a problem... that method only works with no-baserel programs... anyhow, i guess thats the 90% of the software..
i'll continue with it sometime soon.. (yesterday i just had some free time, and i decided to try that rather than the blacklist implementation which will require more time than i used for this ;))
-
Don't do this.
Yesterday, I started testing a method to open only the required library, meaning that if someone compiles a program using V61 SDK, and that program only uses V48 functions, the program will only require ixemul.library V48. that's nice/best, isn't it? :)
)
yes this work, when the libc and crt0.o from V48 is used.
but the arguments are from PPC side, if a program want install ixemul lib V61(from installer), MOS or OS4 show a requester if they should replace the library because existing is V49 and new is V61.
so i should not have a libnum over V49
of course thats not good argument, because there are no ixemul programs that install ixemul lib in lib folder with a installer.ixemul programs need no installer.i know only cubic ide with installer, but this install lib in a seperate folder on later search path.only is the ppc libnum is not good enough this lib is used.
also the correct issue is that MOS or OS4 print on install a warning, if the user want overwrite the library with a higher 68k Version, this can make problems.
win vista for example bring such a requester when you want install a XP driver.
But to say 68k libs should not have more features that need of course a libnum increase, or they should rename is really bad.
-
yes this work, when the libc and crt0.o from V48 is used.
I do not mean to use V48 files, this will work dynamically (at runtime) from whatever ixemul version you build next. well, i already provided you the details by email ;)
win vista for example bring such a requester when you want install a XP driver.
Vista brings a requester everywhere with everything ;P