14-Jun-2021 15:30 GMT.
UNDER CONSTRUCTION
Anonymous, there are 73 items in your selection [1 - 50] [51 - 73]
[Files] New Amithlon 1.29 update availableANN.lu
Posted on 11-Mar-2004 20:42 GMT by top (Edited on 2004-03-12 18:05:13 GMT by Christophe Decanini)73 comments
View flat
View list
the New update for Amithlon to run AmigaOS3.9 under PC hardware via Linux Drivers :

Amithlon Kernel compatible Linux PCI drivers : PC network chipsets, PC sound chipsets

Added new version of the XCat Utility (Thanks to Bernd Meyer)

FIX: Somehow the name of the installed amithlon1_com.device was wrong!

Available for download in Aminet link file: Amithlon 1.29 update

Author: geit@gmx.de (Guido Mersmann)

Author: amithlon@amithlon.net (Bernd Meyer)
and
Author: support@vmc.de (Harald Frank, VMC)
Author: bvernoux@wanadoo.fr (Benjamin Vernoux, Titan)
New Amithlon 1.29 update available : Comment 1 of 73ANN.lu
Posted by takemehomegrandma on 11-Mar-2004 20:20 GMT
:-O

Good news!

I just bought the OS3.9 CD (for other reasons), but I might as well
try this Amithlon everyone is talking about on one of my x86 boxes,
since I have actually never tried it! :-)

(BTW (thinking about another thread here on ann), could this become
some "Amiga Classic x86" (or something like that) product in the
future, fully legal with brands and all?)
New Amithlon 1.29 update available : Comment 2 of 73ANN.lu
Posted by brotheris on 11-Mar-2004 20:36 GMT
In reply to Comment 1 (takemehomegrandma):
You must have Amithlon cd to use this update.
New Amithlon 1.29 update available : Comment 3 of 73ANN.lu
Posted by takemehomegrandma on 11-Mar-2004 20:48 GMT
In reply to Comment 2 (brotheris):
Then I'll get one! :-)
New Amithlon 1.29 update available : Comment 4 of 73ANN.lu
Posted by brotheris on 11-Mar-2004 20:55 GMT
In reply to Comment 3 (takemehomegrandma):
It seems that buying it second hand from users who bought it before whole fiasco is only legal way.
New Amithlon 1.29 update available : Comment 5 of 73ANN.lu
Posted by takemehomegrandma on 11-Mar-2004 21:38 GMT
In reply to Comment 4 (brotheris):
Ah! :-/

Well, then I hope for an Amithlon "rebirth" through a possible new
sub-licensing scheme even more! I think that a community controlled
Amiga platform is still most a dream however, but one never knows! I
sure hope it comes true ... :-)
New Amithlon 1.29 update available : Comment 6 of 73ANN.lu
Posted by brotheris on 11-Mar-2004 22:07 GMT
In reply to Comment 5 (takemehomegrandma):
There's so much shit surounding amithlon, it sadeness me alot,amithlon could have been much much more than emulator given right product managment and further development.
New Amithlon 1.29 update available : Comment 7 of 73ANN.lu
Posted by Anonymous on 11-Mar-2004 22:09 GMT
In reply to Comment 1 (takemehomegrandma):
> I just bought the OS3.9 CD (for other reasons), but I might as well
try this Amithlon everyone is talking about on one of my x86 boxes,
since I have actually never tried it! :-)

Bad news, you will not be able to buy amithlon.
New Amithlon 1.29 update available : Comment 8 of 73ANN.lu
Posted by Anonymous on 11-Mar-2004 22:28 GMT
In reply to Comment 6 (brotheris):
> amithlon could have been much much more than emulator

It could never have been much more than an emulator. x86 and Amiga m68k have different endianess, that pretty much means that the OS is trapped inside the emulator. The approach used with OS4 and MOS - seamless integration of 68k code into a native OS, with access to all native OS structures - is IMHO not possible: In a mixed endianess environment, you can not use simple byte swapping code in the emulator to deal with byte order (or can you?!). Amithlon was a dead end, it doesn't matter that it's gone. In fact it's good, its death accelerates the migration to OS4 and MOS. About AROS: it would never have expected it to get where it is already but still ... a lot of work for six people.
New Amithlon 1.29 update available : Comment 9 of 73ANN.lu
Posted by red vs blue on 11-Mar-2004 22:40 GMT
which do you choose:

Red: Balls without a c0ck

Blue: c0ck without balls

Billy Idol: eyes without a face
New Amithlon 1.29 update available : Comment 10 of 73ANN.lu
Posted by anon on 11-Mar-2004 22:55 GMT
In reply to Comment 9 (red vs blue):
red also doesn't have a pot to p!ss in
New Amithlon 1.29 update available : Comment 11 of 73ANN.lu
Posted by Megol on 11-Mar-2004 23:42 GMT
In reply to Comment 8 (Anonymous):
"In a mixed endianess environment, you can not use simple byte swapping code in the emulator to deal with byte order (or can you?!)."
Well... It's possible to do.
New Amithlon 1.29 update available : Comment 12 of 73ANN.lu
Posted by Bla_head on 12-Mar-2004 02:35 GMT
In reply to Comment 8 (Anonymous):
U tork shit.
New Amithlon 1.29 update available : Comment 13 of 73ANN.lu
Posted by Kjetil on 12-Mar-2004 06:45 GMT
In reply to Comment 11 (Megol):
Well the issue is when you do

Move.l 0x0000AAAA,(a0)
Add.l a0,4
Move.l 0x0000BBBB,(a0)
Sub.l a0,2
Move.l (a0),d0

What do you get as an result, when byte swap,
Well the result of this operation should be 0xAAAA0000 if it where running on 68k
How ever byte swapped it becomes 0xBBBB0000, now this only the start of the problem, once you mix bytes, words, longwords, there is no telling what the result of byte swapping becomes, when code is not accessed the same way over and over.
New Amithlon 1.29 update available : Comment 14 of 73ANN.lu
Posted by Don Cox on 12-Mar-2004 07:18 GMT
In reply to Comment 8 (Anonymous):
"It could never have been much more than an emulator. x86 and Amiga m68k have different endianess, that pretty much means that the OS is trapped inside the emulator. The approach used with OS4 and MOS - seamless integration of 68k code into a native OS, with access to all native OS structures - is IMHO not possible: In a mixed endianess environment, you can not use simple byte swapping code in the emulator to deal with byte order (or can you?!). Amithlon was a dead end, it doesn't matter that it's gone."

You may not realise that programs and libraries compiled for x86 can be used in Amithlon with no special setup - you just install them as normal. Felix Schwartz issued a couple of programs in x86, and they simply run.

The whole Amiga OS could have been ported to x86 in stages - although the emulation runs so fast that it is hardly necessary.

Bernie had it all worked out.
New Amithlon 1.29 update available : Comment 15 of 73ANN.lu
Posted by Don Cox on 12-Mar-2004 07:21 GMT
In reply to Comment 13 (Kjetil):
"Well the result of this operation should be 0xAAAA0000 if it where running on 68k
How ever byte swapped it becomes 0xBBBB0000, now this only the start of the problem, once you mix bytes, words, longwords, there is no telling what the result of byte swapping becomes, when code is not accessed the same way over and over."

Well, Bernie's emulator does work 100% perfectly, in both Amithlon and UAE, and AFAIK the UAE source code is freely available, so you can see how it is done. (The version in UAE is I believe an early one and may still have a few bugs).
New Amithlon 1.29 update available : Comment 16 of 73ANN.lu
Posted by Ole-Egil on 12-Mar-2004 08:00 GMT
In reply to Comment 13 (Kjetil):
But who in their right mind would do that? ;-)
New Amithlon 1.29 update available : Comment 17 of 73ANN.lu
Posted by code on 12-Mar-2004 08:06 GMT
In reply to Comment 13 (Kjetil):
Kjetil, what assembler is that exactly? Appears total nonsense to me.
New Amithlon 1.29 update available : Comment 18 of 73ANN.lu
Posted by brotheris on 12-Mar-2004 08:16 GMT
In reply to Comment 17 (code):
Otter assembler
New Amithlon 1.29 update available : Comment 19 of 73ANN.lu
Posted by froggie on 12-Mar-2004 08:21 GMT
In reply to Comment 17 (code):
how about just a

move.l #$0000AAAA,d0
swap d0

.. anyways, you'd need to swap the bytes, not the words
New Amithlon 1.29 update available : Comment 20 of 73ANN.lu
Posted by Crumb // AAT on 12-Mar-2004 08:39 GMT
In reply to Comment 13 (Kjetil):
What about using memory in the opposite order like Executor?
New Amithlon 1.29 update available : Comment 21 of 73ANN.lu
Posted by top on 12-Mar-2004 08:47 GMT
In reply to Comment 8 (Anonymous):
Amithlon is still developped and Improved EACH DAYS.
Several devloppers are working daily on support it.

see the amithlonopen@yahoogroups.com mailing list.
It is used daily by hundred of people that still have their classic Amiga or have their Amiga classic dead.

Amithlon allow AmigaOS3.X run on ANY PC hardware much faster then any current new Amiga PowerPC AmigaOS3.X. Well, and Cheaper.

All Amithlon users don't think that AmithlonOpen is in competition with AmigaOS4 or even Morphos...
Amithlon (like WinUAE/AmigaForEver et other UAE) are COMPLEMENTARY AmigaOS plateforme.
There, our favorite OS run fine, fast, secure and stable !!.

Amithlon (not like other AmigaOS UAE), can run Native X86 code under AmigaOS to get same speed as Linux X86 and Windows apps.

Amithlon is a fine way to let AmigaOS GROW TOO on another market like big the PC X86 market, where the potential interested users is
really enormous, if any official support from AmigaInc apperas in future.
AmigaOS classic can still grow on PC market and be a real competitor to others PC OS.

What AMithlonOpen developpers need is an official support of Amiga Inc (and why not Hyperion).
Some common work AOS4/AOS3X86/AOS3classic if still improved will allow a compatibily between these AmigaOSes.

The both AmigaOS AOS4 and AOSclassic can grow at the same time in terms of features.

Since some months the AMithlonOpen developpers has greatly improved the Amithlon features, the Amithlon Kernel and the Amithlon hability to use
tons of Linux drivers, that allow Amiga apps to support 90-95 % of the PC hardware.

Amithlon RUN ON ANY PC HARDWARE (accelerated or not) it run FAST.
Several AMithlon developpers are active and famous AMiga developpers.
Today,
Amithlon run as fast a Linux or a Windows, for same uses, and several times even faster!!.
AMITHLON support :
- Nvidia GeForce & Nforce2 GFX boards/Chipsets
- ATi GFX cards
- Matrox GFX cards
- S3 and Any other GFX cards in accelerated mode or not, but ALWAYS works !
- support for All via chipsets
- support for all USB 1.1/2.0
- support for 90 % of Ethernet pci cards accross "amithlon1_net.device" to use with Miami TCP/iP stack or other
- support for 90 % of Sound cards and sound chips via native X86 AC97/SBlaster drivers and Amithlon.audio AHI devices.
- support for 90 % of SCSi and UltraWideSCSI cards.
- support for any PS2 and USB mouse and keyboard and printer (need a TPrint driver compatible).

AmigaOS4 and AmigaOS classic/X86 can grow TOGETHER, they are not competitors, they are brothers OS,
2 GOOD commercial products for AmigaInc and Hyperion ON TWO DIFFERENT market are better then 1 product on 1 market.
New Amithlon 1.29 update available : Comment 22 of 73ANN.lu
Posted by Kjetil on 12-Mar-2004 09:04 GMT
In reply to Comment 15 (Don Cox):
Bernies JIT can possibly convert the byte order to INTEL/AMD format, it has to be inn Motorola format, at the code expects it to be.

<convert><do math><convert back> or else you will get byte order distortion, and possibly lots of programs will fail, this is the biggest problem when you recompile a program from Intel to PPC. So in other words you lots of CPU power. Approximately of the total power is lost in data conversions at worst case scenario.

How ever there are some cases where there is no need to swap data, example
Move.l (a0),(a1)
As long as its stored in the same way as It where read. This operation will give you 100% of total power

Jit only replaces 68k assembler whit INTEL assembler, the emulation is the same.
New Amithlon 1.29 update available : Comment 23 of 73ANN.lu
Posted by ujb on 12-Mar-2004 09:10 GMT
In reply to Comment 18 (brotheris):
no, its otter amitalon assembler
New Amithlon 1.29 update available : Comment 24 of 73ANN.lu
Posted by Kjetil on 12-Mar-2004 09:14 GMT
In reply to Comment 17 (code):
This is what you get when played to many computer languages
Just replace 0x whit #$ and you get 68k assembler
New Amithlon 1.29 update available : Comment 25 of 73ANN.lu
Posted by Kjetil on 12-Mar-2004 09:15 GMT
In reply to Comment 16 (Ole-Egil):
It an example, on how data distortion can go about, any thing is legal in assembler
New Amithlon 1.29 update available : Comment 26 of 73ANN.lu
Posted by Kjetil on 12-Mar-2004 09:24 GMT
In reply to Comment 19 (froggie):
No it depends on the size of the data, if you have words you swap bytes, if you have longwords(integer) you swap words(short),
If you have a byte you do nothing.

Every tried reading a file saved on an Amiga on PC using c++, its complicated.
New Amithlon 1.29 update available : Comment 27 of 73ANN.lu
Posted by Anonymous on 12-Mar-2004 09:28 GMT
In reply to Comment 14 (Don Cox):
> You may not realise that programs and libraries compiled for x86 can be used in Amithlon with no special setup

Of course I know that you can extend Amithlon with x86 code. That's not the point. The point is that you can not writen a native AmigaOS for the x86 platform, with native endianess, like AROS, and mix that with an integrated m68k JIT using m68k byte order that gives the m68k code seamless access to the OS.

> Well, Bernie's emulator does work 100% perfectly, in both Amithlon and UAE, and AFAIK the UAE source code is freely available, so you can see how it is done.

Those are emulators in a box and that solves the problems with endianess: The emulator does not work "in" UAE , it "is" UAE and contains AmigaOS. AmigaOS is completely trapped inside the emulator. The emulator creates an environment with consistent m68k endianess. x86 Code running on the x86 side, if any, has to use the same m68k endianess if it interfaces with AmigaOS. That's an entirely different scenario from a native AmigaOS on x86 hardware (which would be the "more than an emulator" thing).
New Amithlon 1.29 update available : Comment 28 of 73ANN.lu
Posted by Bla_head on 12-Mar-2004 09:38 GMT
In reply to Comment 27 (Anonymous):
A simple "run >nil: run_elf PATCH ;GUARD" would fix that :)
New Amithlon 1.29 update available : Comment 29 of 73ANN.lu
Posted by Bla_head on 12-Mar-2004 09:39 GMT
In reply to Comment 27 (Anonymous):
A simple "run >nil: run_elf PATCH ;GUARD" in the startup would fix that :)
New Amithlon 1.29 update available : Comment 30 of 73ANN.lu
Posted by brotheris on 12-Mar-2004 09:41 GMT
In reply to Comment 27 (Anonymous):
Yes it is different, because in Amithlons JIT looks after amigaos, none says that Amithlon is an OS (if it would, then JIT would be inside AmigaOS). But you can extend trapped inside AmigaOS with many x86 libraries. Compare Amithlon to PowerUP/WarpUP (without 68k cpu) not AOS4/MOS.
New Amithlon 1.29 update available : Comment 31 of 73ANN.lu
Posted by Anonymous on 12-Mar-2004 10:36 GMT
In reply to Comment 30 (brotheris):
> But you can extend trapped inside AmigaOS with many x86 libraries

But do you really want such a mess? The OS should be native.
New Amithlon 1.29 update available : Comment 32 of 73ANN.lu
Posted by Kryler on 12-Mar-2004 10:49 GMT
In reply to Comment 8 (Anonymous):
Well. AmigaOS runs emulated now. But software can be recompiled to native Amithlon-x86 version. And one of the most important things is that there's *NO* endian problem.

Check it out:

http://www.lysator.liu.se/~lcs/files/gg-cross

So further development of Amithlon could have been really, really interesting.
New Amithlon 1.29 update available : Comment 33 of 73ANN.lu
Posted by miksuh on 12-Mar-2004 11:34 GMT
In reply to Comment 20 (Crumb // AAT):
That's not nonsense. It's m68k assembly code, there is just one mistake: 0x should be #$.
New Amithlon 1.29 update available : Comment 34 of 73ANN.lu
Posted by miksuh on 12-Mar-2004 11:40 GMT
In reply to Comment 17 (code):
That's not nonsense. It's m68k assembly code, there is just one mistake: 0x should be #$.
New Amithlon 1.29 update available : Comment 35 of 73ANN.lu
Posted by miksuh on 12-Mar-2004 11:41 GMT
In reply to Comment 33 (miksuh):
Doh, that should have been reply to message number 17 not 20.
New Amithlon 1.29 update available : Comment 36 of 73ANN.lu
Posted by Martin Blom on 12-Mar-2004 11:49 GMT
In reply to Comment 34 (miksuh):
Just one mistake??
New Amithlon 1.29 update available : Comment 37 of 73ANN.lu
Posted by Kjetil on 12-Mar-2004 12:18 GMT
In reply to Comment 36 (Martin Blom):
Im rusty place tell me what the 2en mistake is?
New Amithlon 1.29 update available : Comment 38 of 73ANN.lu
Posted by brotheris on 12-Mar-2004 12:30 GMT
In reply to Comment 31 (Anonymous):
But do you really want such a mess?

There was a market for such a thing.
New Amithlon 1.29 update available : Comment 39 of 73ANN.lu
Posted by miksuh on 12-Mar-2004 12:31 GMT
In reply to Comment 36 (Martin Blom):
Well if there is more errors then I did not notice it :) But I'm not good in m68k assembly, or any other assembly version. x86 assembly is a bit more familiar to me though.

I'm much more C, C++, Java etc programmer. Assembly is something which I have never used much.
New Amithlon 1.29 update available : Comment 40 of 73ANN.lu
Posted by itix on 12-Mar-2004 12:33 GMT
In reply to Comment 21 (top):
"Amithlon is a fine way to let AmigaOS GROW TOO on another market like big the PC X86 market, where the potential interested users is" I wonder, did Amithlon attract any new users outside Amiga community?
New Amithlon 1.29 update available : Comment 41 of 73ANN.lu
Posted by Bernie Meyer on 12-Mar-2004 13:31 GMT
In reply to Comment 16 (Ole-Egil):
*grin* Ole, _any_ weird and wonderful (ab)use of 68k commands that you and I could think of (and many that we couldn't) has been used by some Amiga programmer.Would you ever expect to see code like "SRL.L d0,d0"? Apparently, someone found a use for it in a math library (and managed to trigger a register allocation bug in the JIT compiler).....
New Amithlon 1.29 update available : Comment 42 of 73ANN.lu
Posted by Kronos on 12-Mar-2004 13:33 GMT
In reply to Comment 40 (itix):
Not in the incompetent way it has been marketed .....

If they had left all the trash out (AmigaXL,AmigaWriter, StormC3), and reduced
the price by 50%, and offcourse if "they" had decided to work with eachother
instead of against .....
New Amithlon 1.29 update available : Comment 43 of 73ANN.lu
Posted by Bernie Meyer on 12-Mar-2004 13:41 GMT
In reply to Comment 22 (Kjetil):
The whole "the x86 needs to swap byte order when emulating 68k" thing is pretty much a non-issue.When Intel introduced the 486, they gave it the "bswap" instruction, which will do just what's needed (for longwords; For shorts, you use a rotate, and bytes don't need swapping). On any modern x86, that instruction is blindingly fast, and thanks to the whole out-of-order execution, usually happens while the processor is waiting for something else, anyway.Anyone who ever looked closely at the JIT compiler will have seen that there are a bunch of ways in which operations on registers are delayed, just in case they can be optimized away. For example, adding a constant offset to a register will not necessarily produce any "add" in x86 code; The offset is just remembered, and only once it really needs doing is the "add" done.For a while, I toyed with the idea to have another such state which stored for any x86 register whether it contained its real value, or the byte-swapped version of it --- to avoid doing double-swaps if they weren't necessary. Then I went and hacked things so that instead of one bswap, 3 were output each time --- and the change in speed was negligible. So getting rid of even *all* bswap would also result in negligible speedup.This, of course, is only true for the integer part. In the FPU code, the whole byte-swapping really sucks. A large part of that is due to the fact that the x87 FPU sucks. If I were to do the whole thing over again today, I'd use SSE2 for the FPU, ignore the x87 crap, and make a modern XP or P4 the minimum requirement...
New Amithlon 1.29 update available : Comment 44 of 73ANN.lu
Posted by Anonymous on 12-Mar-2004 14:10 GMT
In reply to Comment 43 (Bernie Meyer):
> The whole "the x86 needs to swap byte order when emulating 68k" thing is pretty much a non-issue

Do you mean in terms of speed? I don't care. But is it possible on a logical level to mix endianess (e.g. to have something like amithlon in AROS and allow executables in amithlon to call AROS OS functions)? How could you ever know how to reverse the byte order? With 16 bit data, you reverse the order of two bytes, with 32 bit data, you reverse the order of four bytes. That means that 16bit is not a subset of 32bit: two reversed 16 bit words produce a different result than one eversed 32 bit longword. In other words, you must know the data size to choose the strategy for reversal. But you don't know the size, do you? You can't assume that the access size is identical with the data size.
New Amithlon 1.29 update available : Comment 45 of 73ANN.lu
Posted by Bernie Meyer on 12-Mar-2004 14:29 GMT
In reply to Comment 44 (Anonymous):
There are two answers:a) No, you'd have to agree on one endianness; As your existing executables are big-endian, you'd have to make your native OS use big-endian, too. Martin Blom's big-endian x86 gcc port shows that that's no problem at all; And if you just want that last bit of performance, nobody stops you from using little-endian for everything except data exchanged with big-endian code.b) Yes, as long as you get to define the API accordingly. Of course, that's very much not the case when talking about existing 68k executables, so it doesn't really apply.So in general, yes, you run into trouble when you want to thunk between two existing parts, one big and one little-endian, which are supposed to share data and were not designed with endianness-agnosticity in mind. Which is why just adding a 68k emulator to AROS/x86 won't work.On the other hand, as soon as you get to design and write at least one of the parts, the problem becomes pretty much a non-issue, both performance and complexity-wise. Which would have been the case for, say, step-by-step migrating from 68k-AmigaOS-in-Amithlon to big-endian-x86-AmigaOS-in-Amithlon.It would be interesting to compile AROS/x86 in big-endian, and then add a 68k emulator. But I'd feel much more confident about that if I knew that AROS can successfully be compiled for PPC, and thus has avoided any endianness-assumptions...
New Amithlon 1.29 update available : Comment 46 of 73ANN.lu
Posted by Crumb // AAT on 12-Mar-2004 14:38 GMT
In reply to Comment 45 (Bernie Meyer):
Hi bernie! what do you think about using the 68k memory in opposite order on little-endian systems (like executor did)? I think that AROS may use this system with the MMU to use x86 and 68k code...
New Amithlon 1.29 update available : Comment 47 of 73ANN.lu
Posted by T_Bone on 12-Mar-2004 17:02 GMT
In reply to Comment 40 (itix):
> I wonder, did Amithlon attract any new users outside Amiga community?

Maybe, it kept many from leaving.
New Amithlon 1.29 update available : Comment 48 of 73ANN.lu
Posted by Fabio Alemagna on 12-Mar-2004 17:49 GMT
In reply to Comment 14 (Don Cox):
> You may not realise that programs and libraries compiled for x86 can be used in
> Amithlon with no special setup - you just install them as normal. Felix Schwartz
> issued a couple of programs in x86, and they simply run.

Not really. They have to be compiled with a special compiler that exists only thanks to Martin blom.

And programs generated by that compiler are about 30% slower than "real" native programs.
New Amithlon 1.29 update available : Comment 49 of 73ANN.lu
Posted by Fabio Alemagna on 12-Mar-2004 17:50 GMT
In reply to Comment 15 (Don Cox):
> Well, Bernie's emulator does work 100% perfectly, in both Amithlon and UAE, and
> AFAIK the UAE source code is freely available, so you can see how it is done.
> (The version in UAE is I believe an early one and may still have a few bugs).

It works because the memory _IS_ accessed the same way by both the 68k and x86: memory is kept in big endian, and the x86 side does byte swapping for every memory access.
New Amithlon 1.29 update available : Comment 50 of 73ANN.lu
Posted by Fabio Alemagna on 12-Mar-2004 18:10 GMT
In reply to Comment 45 (Bernie Meyer):
> It would be interesting to compile AROS/x86 in big-endian, and then add a 68k
> emulator. But I'd feel much more confident about that if I knew that AROS can
> successfully be compiled for PPC, and thus has avoided any endianness-assumption

AROS has been compiled for the Dragonball, 68k compatible processor, thus you can be sure there's no endianess assumption anywhere, the problem is parameters-on-stack assumption, which affects some parts of AROS, but this is a non issue on x86, not even a bigendian-x86.
Anonymous, there are 73 items in your selection [1 - 50] [51 - 73]
Back to Top