Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A1200/A600 4xIDE Interface

AuthorTopic: AROS Hits the Papers.  (Read 3937 times)

0 Members and 1 Guest are viewing this topic.

Offline that_punk_guy

Re: AROS Hits the Papers.
« Reply #15 on: March 06, 2004, 11:09:26 AM »
Quote
BigBenAussie wrote:
Hmmmm....Let me get this straight. AROS is not compatable with any Amiga software at all?


You can't run Amiga executables on it directly, but...

Quote

Or is it a simple matter of recompilation?


AROS is supposed to be compatible at source-code level. As far as I'm aware, recompiling programs for AROS requires little or no changes to the program source.

Quote

I guess...errr....cool..and all.....but what does it mean?

What can I actually do with AROS?

Except look like I am using an Amiga.


No, if you want to look like you're using an Amiga, use WindowBlinds on top of Win2K.

AROS is an Amiga-like OS that aims to run on a variety of different architectures. How it looks is not really important.
 

Offline dammy

Re: AROS Hits the Papers.
« Reply #16 on: March 06, 2004, 11:30:43 AM »
by BigBenAussie on 2004/3/6 6:00:27

Quote
Hmmmm....Let me get this straight. AROS is not compatable with any Amiga software at all?


Not unless your running UAE.  68K code has to be emulated, wether it's AOS/MOS or AROS, there is emulation somewhere going on if it's being run on a none 68K machine.  Now there is a bounty for intergration of UAE for those who want it simplied.

Quote
Or is it a simple matter of recompilation?


That is the perferred method of running the code, natively.

Quote
Or do you have to write explicitly for AROS?


I should let the devs answer this one since they have more complete knowledge. Now from what I understand, if the amiga application source isn't banging on the hardware, it should recompile on AROS with minimum of hassle.  YMMV.  Since it's coming from the code intended to run on the Amiga to a portable OS with minimum hassles, is pretty impressive, IMO.

Quote
I guess...errr....cool..and all.....but what does it mean?

What can I actually do with AROS?

Except look like I am using an Amiga.


Currently, you can develope code on AROS.  In the near future, with FAT32 support and TCP/IP being worked on, it's real capabilities as a desktop OS will be more apparent to the end user.  If your not a developer, you can sit with us beta testers and watch as a OS is created in front of you.  Remember, alot of things general computer users are use to in a desktop OS were never included in any C= WB releases.  Even with the H&P 3.x releases, things such as tcp/ip were third part efforts.  AROS, OTOH, is working to bring those as apart of the OS, for free.  :-D

Dammy
Dammy

https://www.facebook.com/pages/Arix-OS/414578091930728
Unless otherwise noted, I speak only for myself.
 

Offline Emufreak

Re: AROS Hits the Papers.
« Reply #17 on: March 06, 2004, 12:17:42 PM »
For all of you who want to run Amiga Apps Natively on AROS. Put 50 Bucks on the integration of UAE into AROS bounty. It's basicly the same as just JIT-Emulation. Well maybe a little slower. But with it you could even run hardwarebanging apps "natively".
 

Offline asian1

Re: AROS Hits the Papers.
« Reply #18 on: March 06, 2004, 12:38:10 PM »
>68K emulation

Hello
With future X86 CPUs at 3 GHz / more, is 68K emulation remain
a difficult problem?
What about coldfire PCI co-processor card, or 68K Smaky
PCI card from Epsitec?

Epsitec

BTW Do TGM accept order from overseas?
 

Offline bloodline

  • Master Sock Abuser
  • Hero Member
  • *****
  • Join Date: Mar 2002
  • Posts: 12113
  • Total likes: 0
    • http://www.troubled-mind.com
Re: AROS Hits the Papers.
« Reply #19 on: March 06, 2004, 03:23:02 PM »
Quote

Emufreak wrote:
For all of you who want to run Amiga Apps Natively on AROS. Put 50 Bucks on the integration of UAE into AROS bounty. It's basicly the same as just JIT-Emulation. Well maybe a little slower. But with it you could even run hardwarebanging apps "natively".


I think I should point out that a method of running 68k apps on the x86 version of AROS has been decided.

Please listen as I'm a bit tired to retyping this :-):

1. We will have the AROS Port of UAE running as a task in AROS (with JIT etc...)
2. We will run a 68k version of AROS on UAE.
3. The 68k version of AROS will be special in as much as it will pass all system function calls to the Native (in this case x86) version of AROS.

This will mean that you will not see UAE as the 68k programs will be using the same interface as the x86 Apps, that is to say they will co-exist on the Workbench screen, even be able to share data, and access the same drives.
This will also have the benefit of allowing hardware banging apps to run on thier own Intuition screen (they will multitask with the x86 apps :-D ).

The one draw back is that 68k libraries cannot be used with x86 programs, and vice versa.


The thing we need to make this happen is for someone to work on the Amiga (UAE) port of AROS.
Yes, put money into the emulation bounty, as "wes" has already expressed an interest in doing this after the TCP/IP bounty.

Offline dammy

Re: AROS Hits the Papers.
« Reply #20 on: March 06, 2004, 04:26:16 PM »
If anyone is interested in starting a new bounty for AROS, please email damocles@thenostromo.com, thanks

Dammy
No Schedule and Rockin'!
Dammy

https://www.facebook.com/pages/Arix-OS/414578091930728
Unless otherwise noted, I speak only for myself.
 

Offline Crumb

Re: AROS Hits the Papers.
« Reply #21 on: March 06, 2004, 04:43:34 PM »
"Im sorry but as we have probably stated a zillion times ;) its quite hard implementing a 68k emulator in the same way as on MOS/OS4 in fact if we do it will dragg down the whole OS performance (on x86) and thats NOT AN OPTION (at least in my eyes)! then we should also add that there is starting to be quite vocal requests for MP and other things its impossile to add without breaking compatibility with AmigaOS! you just cant have it all im afraid."

I don't agree. You could split the ram in two sections using the MMU. The 68k programs would be put in one memory space and all accesses from 68k would be converted to little-endian and the accesses from x86 software to 68k modules as the 68k modules/programs would be in the "68k memory space" would simply convert the addresses.

That wouldn't slow down aros unless you use 68k programs/libs/etc and that wouldn't change much the design.

OS4 has done that and it's the most portable solution to emulate 68k on x86 IMHO. You should finish your MMU.hidd first, of course.

And I prefer native programs too, but I prefer programs that no programs at all.

The idea of using an UAE with a rom that calls directly to AROS functions sounds well the first time you hear it, but later you realize that you won't be able to use 68k libraries on AROS, so it's not a good solution.
The only spanish amiga news web page/club: Club de Usuarios de Amiga de Zaragoza (CUAZ)
 

Offline bloodline

  • Master Sock Abuser
  • Hero Member
  • *****
  • Join Date: Mar 2002
  • Posts: 12113
  • Total likes: 0
    • http://www.troubled-mind.com
Re: AROS Hits the Papers.
« Reply #22 on: March 06, 2004, 04:48:05 PM »
Quote

I don't agree. You could split the ram in two sections using the MMU. The 68k programs would be put in one memory space and all accesses from 68k would be converted to little-endian and the accesses from x86 software to 68k modules as the 68k modules/programs would be in the "68k memory space" would simply convert the addresses.


I have no idea how one could actually do that... Why don't you build an emulator as you've described so that we can see it.

Offline falemagn

Re: AROS Hits the Papers.
« Reply #23 on: March 06, 2004, 04:53:38 PM »
Quote

I don't agree. You could split the ram in two sections using the MMU. The 68k programs would be put in one memory space and all accesses from 68k would be converted to little-endian and the accesses from x86 software to 68k modules as the 68k modules/programs would be in the "68k memory space" would simply convert the addresses.


Sorry, not possible.

Take, for instance, this case. We have a little-endian ULONG in memory, whose value is, say, 0x01020304, hence it's stored like this (values are in HEX, pipes divide bytes from one another, leftmost digit is the one at the lowest memory address):

Little endian 0x01020304:

|04|03|02|01|

Now say a 68k program wants to access that value, but for some reasons it will do it one byte at time, storing each one of those bytes in consecutive memory locations. Now, since it's doing a byte access to memory, there's presumably no need to do any byte swapping, or rather, it's simply impossible to do any byte swapping. Now, let's see what's the end result of this operation:

Big endian 0x04030201:

|04|03|02|01|

As you can see, the 68k program read the wrong value: it read 0x04030201 whilst it should have read 0x01020304.

Quote

OS4 has done that and it's the most portable solution to emulate 68k on x86 IMHO.


AOS4 (why do you people keep forgetting the 'A'?) has not done that at all, it doesn't do any byteswapping, it simply doesn't need to.
 

  • Guest
Re: AROS Hits the Papers.
« Reply #24 on: March 06, 2004, 05:01:31 PM »
Couldn't you force all emulation accesses to read longwords (rounded down to the nearest boundary) and bytewap, then use fairly simple logic to retreive the correct byte or word? :)
 

Offline falemagn

Re: AROS Hits the Papers.
« Reply #25 on: March 06, 2004, 08:26:17 PM »
Quote

Couldn't you force all emulation accesses to read longwords (rounded down to the nearest boundary) and bytewap, then use fairly simple logic to retreive the correct byte or word? :)


Eh... that would work in that specific case, not certainly in the general case: what if the data is NOT in litte-endian mode, but it's just text being copied from one memory location to another? You see, it doesn't work.
 

Offline Crumb

Re: AROS Hits the Papers.
« Reply #26 on: March 08, 2004, 05:47:38 PM »
@Bloodline:
"I have no idea how one could actually do that... Why don't you build an emulator as you've described so that we can see it."

Firstly I would need an MMU.hidd. ;-)

And later AROS would need virtual addressing to make it work efficiently, otherwise we would have to reserve the memory of each cpu zone

@falemagna:
Of course OS4 (I ommit the "A" because it is THE AmigaOS) doesn't need to switch words, it's running on a big-endian cpu so no need to do that...
If you have the x86 and the 68k data long-word aligned you could do it this way:

|0A|0B|0C|0D| addresses-> 01,02,03,04

if I wanted to read the 2nd byte from the little endian ram zone the first thing I would do is to check what byte of the longword would it be part of...

if the byte is in the address from 01-04 it is part of the first longword, if the byte is in the address 05-08 etc...

so we read the address 02 and it's detected that it's part of the first longword, so we flip the bytes and we read 0C. If we read the third byte we read 0B, if we read the 4th, 0A. So now we have in the 680x0 memory area:
0D|0C|0B|0A

if the x86 native program tries to access some bytes, as the memory will be aligned we will choose the right byte thanks to the memory alignment.

So basicly we would check ALL the accesses to memory and we would byteswap absolutly everything.

In conclusion:
-we have an MMU to mark one zone as 68k and other as x86 (that would require MMU.hidd to work, and virtual addressing activated to be efficient and to avoid wasting too much memory)
-we have everything long-word aligned (more or less easy)
-we determine if a byte is part of one longword or part of the next one (a bit slow, I know)
-we swap the bytes to copy the right one to the different memory areas (680x0 and x86)


I said that it was similar to the OS4 approach only because they also split the memory in two parts, the 680x0 zone and the x86 zone.

BTW, I've translated the AROS introduction to Spanish, where should I send it?

-edit-
I've read the other comment later...
"what if the data is NOT in litte-endian mode, but it's just text being copied from one memory location to another? You see, it doesn't work. "

mmm If I read a text in a little-endian machine, wouldn't it be stored this way?:

Original text: "THIS_IS_TEXT"

1st longword: SIHT
2nd longword: _SI_
3rd longword: TXET

Then it would be copied correctly to the 680x0 memory area swapping the bytes just like in the other situation
The only spanish amiga news web page/club: Club de Usuarios de Amiga de Zaragoza (CUAZ)
 

Offline bloodline

  • Master Sock Abuser
  • Hero Member
  • *****
  • Join Date: Mar 2002
  • Posts: 12113
  • Total likes: 0
    • http://www.troubled-mind.com
Re: AROS Hits the Papers.
« Reply #27 on: March 08, 2004, 09:51:41 PM »
Quote

BTW, I've translated the AROS introduction to Spanish, where should I send it?


That's great! Just send it to the aros-dev mailing list, thanks :-)

Offline falemagn

Re: AROS Hits the Papers.
« Reply #28 on: March 10, 2004, 01:01:17 PM »
Quote

If you have the x86 and the 68k data long-word aligned you could do it this way:


This is a requirement impossible to meet, there's no way to know the alignment of the data being accessed, since the processor doesn't know what _type_ that data is, the processor, virtual or not, just accesses some data of certain size as the program tells it, it doesn't know anything about the big picture.

Quote

|0A|0B|0C|0D| addresses-> 01,02,03,04

if I wanted to read the 2nd byte from the little endian ram zone the first thing I would do is to check what byte of the longword would it be part of...

if the byte is in the address from 01-04 it is part of the first longword, if the byte is in the address 05-08 etc...

so we read the address 02 and it's detected that it's part of the first longword, so we flip the bytes and we read 0C. If we read the third byte we read 0B, if we read the 4th, 0A. So now we have in the 680x0 memory area:
0D|0C|0B|0A


This is what Neko proposed, and I already explained why it wouldn't work.


Quote

-we have everything long-word aligned (more or less easy)


Nope, that's not easy at all, it's actually impossible.

Besides, even if everything were aligned to 4 bytes, it would simply not work anyway (again, think about text, or even about 2 WORDs being accessed as one LONG).

Quote

-edit-
I've read the other comment later...
"what if the data is NOT in litte-endian mode, but it's just text being copied from one memory location to another? You see, it doesn't work. "

mmm If I read a text in a little-endian machine, wouldn't it be stored this way?:

Original text: "THIS_IS_TEXT"

1st longword: SIHT
2nd longword: _SI_
3rd longword: TXET


Nope, not at all, it would still be stored like "THIS_IS_TEXT".
 

Offline Crumb

Re: AROS Hits the Papers.
« Reply #29 on: March 10, 2004, 01:36:30 PM »
"This is a requirement impossible to meet"

You could force your malloc() function to always align the data. Don't tell me that aligning the data is impossible because powerUP aligned ppc exes for example...

about knowing the data type... yes, I've thinked about it and it would be impossible or almost impossible...

lets say we use two bytes to store a number and then 4 bytes to store a little text. We would have:

12TEXT...

yes... even if we aligned the stuff it would be impossible... you are right. Thank you Fabio :-)

but...

That leaves me with only one idea (/doubt), using the 68k memory area as the guy who did executor (a mac emu). He used memory in the oposite order...

....TXET21

if we wanted to read the first two bytes we would only have to substract the offset of the address we want to access to the end of the memory to access to the right position.

If we wanted to access an entire word from the 3rd postition the cpu would read it correctly as the order of memory is opposite

mmm what do you think about this? The 68k emu may have to be changed...

but this should work...
The only spanish amiga news web page/club: Club de Usuarios de Amiga de Zaragoza (CUAZ)