25-Apr-2024 07:10 GMT.		 UNDER CONSTRUCTION
Anonymous, there are 73 items in your selection (but only 23 shown due to limitation) [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 51 of 73ANN.lu
Posted by itix on 12-Mar-2004 22:28 GMT
In reply to Comment 50 (Fabio Alemagna):
I wonder... In theory Amithlon project could throw away AmigaOS and start using 68k native AROS. AROS itself probably is not mature enough to replace 3.x now but if it was it could solve many problems.
New Amithlon 1.29 update available : Comment 52 of 73ANN.lu
Posted by Bernie Meyer on 13-Mar-2004 03:31 GMT
In reply to Comment 46 (Crumb // AAT):
Executor has a much easier time, because the people at Apple did a much better job at enforcing that *all* hardware access goes through a well-defined API (which Executor implements natively). In other words, all memory accesses in Executor-emulated code are really to RAM.On the Amiga, anyone and everyone hits all sorts of hardware directly. In particular, screen data gets written by applications directly into gfx card memory. Which means that simply using memory in reverse order would result in the display being turned 180 degrees....Also, while doing so avoids the need for byte swaps, it makes it necessary to do some maths on the addresses before using them --- which was faster on a 386 (no bswap instruction), but actually takes more time on modern processors.To avoid that, you'd have to use inverted logic all the way through, which is just too twisted to seriously consider...
New Amithlon 1.29 update available : Comment 53 of 73ANN.lu
Posted by Bernie Meyer on 13-Mar-2004 03:33 GMT
In reply to Comment 50 (Fabio Alemagna):
Is this a recent achievement? Because last time I looked at AROS code, I remember seeing that the concept of endiannes-agnosticity was there, but also remember seeing code that would have failed on big-endian processors.
New Amithlon 1.29 update available : Comment 54 of 73ANN.lu
Posted by Jupp3 on 13-Mar-2004 05:58 GMT
In reply to Comment 47 (T_Bone):
>> I wonder, did Amithlon attract any new users outside Amiga community?
>
>Maybe, it kept many from leaving.

...And brought some back.
New Amithlon 1.29 update available : Comment 55 of 73ANN.lu
Posted by Don Cox on 13-Mar-2004 06:05 GMT
In reply to Comment 48 (Fabio Alemagna):
"Not really. They have to be compiled with a special compiler that exists only thanks to Martin Blom."

Has anyone tried compiling some AROS modules and swapping them for the corresponding OS3.9 modules in Amithlon?
New Amithlon 1.29 update available : Comment 56 of 73ANN.lu
Posted by Don Cox on 13-Mar-2004 06:07 GMT
In reply to Comment 55 (Don Cox):
I mean compiling to x86.
New Amithlon 1.29 update available : Comment 57 of 73ANN.lu
Posted by Fabio Alemagna on 13-Mar-2004 08:11 GMT
In reply to Comment 53 (Bernie Meyer):
> Is this a recent achievement? Because last time I looked at AROS code, I
> remember seeing that the concept of endiannes-agnosticity was there, but also
> remember seeing code that would have failed on big-endian processors.

Quite an old achievement, actually. AROS could be booted up on a Palm Pilot emulator up to making it open windows and display graphics.

It possible that there's something that went unnoticed, if so feel free to tell us what did you spot, we'd be very thankful :-)
New Amithlon 1.29 update available : Comment 58 of 73ANN.lu
Posted by Fabio Alemagna on 13-Mar-2004 08:12 GMT
In reply to Comment 55 (Don Cox):
> Has anyone tried compiling some AROS modules and swapping them for the
> corresponding OS3.9 modules in Amithlon?

Not to my knowledge.
New Amithlon 1.29 update available : Comment 59 of 73ANN.lu
Posted by hammer on 13-Mar-2004 08:35 GMT
In reply to Comment 43 (Bernie Meyer):
>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...

Note that AMD K7 "Athlon XP"** doesn’t have "SSE2" per se i.e. it only has SSE1, 3DNow Pro.

**Rumored AMD K8 "Athlon XP" (Socket 754) has SSE2, but inactive AMD64 mode and only has 256L2 cache. This particular K8 core was rumored for HP’s very low end PC solutions or K8 cores that failed the AMD64 mode and 512KB/1024KB L2 test.
New Amithlon 1.29 update available : Comment 60 of 73ANN.lu
Posted by ikir on 13-Mar-2004 09:45 GMT
In reply to Comment 9 (red vs blue):
Billy Idol :-D
New Amithlon 1.29 update available : Comment 61 of 73ANN.lu
Posted by Megol on 13-Mar-2004 20:44 GMT
In reply to Comment 13 (Kjetil):
Yes I'm fully aware of that :)
It is still posssible to solve though, just a really big PITA...
New Amithlon 1.29 update available : Comment 62 of 73ANN.lu
Posted by Megol on 13-Mar-2004 21:52 GMT
" ... Also, while doing so avoids the need for byte swaps, it makes it necessary to do some maths on the addresses before using them --- which was faster on a 386 (no bswap instruction), but actually takes more time on modern processors."

That doesn't match my experience of JIT-emulation. Most often one have "free" instructions even in inner-loops, this fact combined with OOOE can give a very fast solution. With a more intelligent JIT one can even remove some of the extra instructions. Byte-swapping should be about the the same speed however assuming that BSWAP is a direct path instruction for Athlons.

For a x86 native AOS-lookalike one could reverse the order of fields in all public structures and use address translation in the 68k emulator. The virtual 68k would see a 100% big-endian machine with the structures as expected, the x86 side would see some differences ;) Would be a real PITA to implement though...
New Amithlon 1.29 update available : Comment 63 of 73ANN.lu
Posted by Kjetil on 13-Mar-2004 22:00 GMT
In reply to Comment 61 (Megol):
The biggest problem as I Se it is data conversions between longwords and words or bytes, assembler code is the result of C++ programs or other languages that contain information on what is what, assembler do not give you the information on what is data conversions and what is not, this the bases on how to read and write data, inn way that programs are able to know how to Handel data, so inn other word even if you created an record on what data where stored at what location, it won't help you at all, many due to not knowing when to change date types inn memory or when data conversions are supposedly going about.

there is no way you can make program compiled for 68k operate inn an Intel friendly way, I'm sorry
(the 68k program will lack the information on how to convert data, some thing an C program will know how to (inn most cases), this is way you have hi-level languages like java.)
New Amithlon 1.29 update available : Comment 64 of 73ANN.lu
Posted by Lost souls on 13-Mar-2004 23:47 GMT
In reply to Comment 63 (Kjetil):
Lets just move on to Coldfire and be done with it!
New Amithlon 1.29 update available : Comment 65 of 73ANN.lu
Posted by Kjetil on 14-Mar-2004 02:00 GMT
In reply to Comment 64 (Lost souls):
Well coldfire is maybe interesting run 68k code and you probably be easy to make an clean classic Amiga by using it, however on the other hand is slow by to days standards, and PPC is an Motorola processor and uses the same memory organization as an 68k system, this is way PPC allot fast, this is way PPC selected over coldfire, on the AmigaOne and Pegasus computers, and this way MacOS 9 and MacOS X runs on PPC,
New Amithlon 1.29 update available : Comment 66 of 73ANN.lu
Posted by Kjetil on 14-Mar-2004 02:26 GMT
In reply to Comment 62 (Megol):
If 68k programs ever will be hosted inn AROS, then it will be inn form of an reversion of UAE,
making UAE talk direct whit the AROS exec, this will allow programs, to open windows and screens on AROS.

the data will be sent as normal to the exec UAE, the data duplicated and translated by using the data structures inn the header files as reference, so you get tow sets of data, the new copyed/translated/data is past over to the AROS side, one way communication, this will probably only work on some of the functions inn some of the library's,

the result of this will be like you where running tow sets of workbench on different screens, most likely, uae will probably need to boot as normal (run setpatch, setup assignes, keymap etc.), it's better then running UAE on top of Workbench, however not as good as a full integration.
New Amithlon 1.29 update available : Comment 67 of 73ANN.lu
Posted by Crumb // AAT on 15-Mar-2004 08:54 GMT
In reply to Comment 52 (Bernie Meyer):
"On the Amiga, anyone and everyone hits all sorts of hardware directly. In particular, screen data gets written by applications directly into gfx card memory. Which means that simply using memory in reverse order would result in the display being turned 180 degrees...."

Thank you for your explanation, is really interesting. I don't know if you have read my comment in Amiga.org (I can't access Amiga.org now, it's explained more or less in detail in the AROS forum) about using memory in reverse order, I was refering to split the memory in two parts, one part would be for 68k programs (with reverse memory) and the other for x86. The screen would be created in the x86 area, so we shouldn't have the display rotated :-)

This is more or less the method I thought for AROS:
We split memory in two parts, we detect if a program wants to access the memory part of the 68k or the x86 side using the MMU. The 68k memory chunks will have reversed their addresses.

"Also, while doing so avoids the need for byte swaps, it makes it necessary to do some maths on the addresses before using them --- which was faster on a 386 (no bswap instruction), but actually takes more time on modern processors.
To avoid that, you'd have to use inverted logic all the way through, which is just too twisted to seriously consider..."

Well, using the MMU and the method I have described you may have a little-endian OS and you wouldn't need to do byte swaps with native programs. The emulated ones may run more or less fast than byte swapping, but you wouldn't have to change much the design of AROS, the native programs would continue running and it would be a portable approach (AROS PPC would know also use two memory parts, one for 68k and the other for the ppc but it wouldn't need to reverse the addresses)
New Amithlon 1.29 update available : Comment 68 of 73ANN.lu
Posted by Crumb // AAT on 15-Mar-2004 15:10 GMT
In reply to Comment 67 (Crumb // AAT):
I explained it in one of my latest posts:

http://www.amiga.org/modules/newbb/viewtopic.php?topic_id=15667&forum=27&start=25
New Amithlon 1.29 update available : Comment 69 of 73ANN.lu
Posted by Kjetil on 15-Mar-2004 16:27 GMT
In reply to Comment 68 (Crumb // AAT):
As I explained before, data is not inn reveres order, it word swapped if its longwords, if it's word is's byte swapped, if it's byte it the same,

you memory translate idea fails, takes to long words stored on +1,+2,+3 addresses, secondly data translations will fail whit your idea, due to not knowing what data is stored there (longword,word,byte) and what part of the data you are reading or writing to the there is the problem whit the api's that uses stack to store function arguments,

if it's relay that easy as you try to explain then, there is no need to port a program from Intel to ppc, just recompile, your idea is to simplistic and it has noting to do whit the reality of the subject.

memmory exsampel first line will be address, secend line be data,
this is byte storeage exsampel inn Intel format

0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
T E S T - T E X T /0

the same text stored on Motorola as bytes (no different)

0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
T E S T - T E X T /0

now we show you short Intel format (words) count from 0 to 5

0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
0x01 0x00 0x02 0x00 0x03 0x00 0x04 0x00 0x05 0x00

now in Motorola format (words) from 0 to 5

0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
0x00 0x01 0x00 0x02 0x00 0x03 0x00 0x04 0x00 0x05
New Amithlon 1.29 update available : Comment 70 of 73ANN.lu
Posted by Crumb // AAT on 15-Mar-2004 16:49 GMT
In reply to Comment 69 (Kjetil):
Note that I was talking about a native AROS port and not about running AROS on Amithlon.

And with native AROS yes, you should only recompile the sources to port a program to x86 or ppc.

My approach would work (in natives AROS) regardless of reading a byte, a word or a longword. With the addresses in reverse order in the 68k memory part like in Executor and the x86 native binaries with the memory in normal order it should work without adverse effects like the screen rotated 180degrees etc...

The emulation design would be similar to the one used in OS4 but when running on x86 the 68k memory area would have the memory in reverse order. It would require a 68k emulator different to those used in UAE/UAE JIT because it would need to support memory in reverse order.
New Amithlon 1.29 update available : Comment 71 of 73ANN.lu
Posted by Kjetil on 15-Mar-2004 17:47 GMT
In reply to Comment 70 (Crumb // AAT):
And what do think you can gain by having it in reverse order? it will not be Intel format and it will not be Motorola format, so what's the point?
New Amithlon 1.29 update available : Comment 72 of 73ANN.lu
Posted by Kjetil on 15-Mar-2004 18:04 GMT
In reply to Comment 71 (Kjetil):
Amiga long words

0xA0 0x00 0x00 0x00
becomes
0x00 0x00 0x00 0xA0 (not intel format, stored at the wrong place)

Amiga Words

0xA0 0x00
becomes
0x00 0xA0 (intel format, only stored at the wrong place)

Amiga bytes

0xA0
becomes
0xA0 (intel format,only stored at the wrong place)
New Amithlon 1.29 update available : Comment 73 of 73ANN.lu
Posted by Kjetil on 15-Mar-2004 18:19 GMT
In reply to Comment 72 (Kjetil):
the problem whil be when a Intel Task trys to read a short (word) from an intager (integer)
Anonymous, there are 73 items in your selection (but only 23 shown due to limitation) [1 - 50] [51 - 73]
Back to Top