Amiga.org
Amiga News and Community Announcements => Amiga News and Community Announcements => Announcements and Press Releases => Topic started by: falemagn on March 08, 2004, 11:53:07 PM
-
Finally it's here, the long awaited new status update about the development of AROS.
To know what has happened during the latest months in the AROS realm and what new features have been or are being implemented here (http://www.aros.org/news/archive/2004.php#20040308), and don't forget to take a look at the new screenshots (http://www.aros.org/pictures/screenshots/#20040308).
-
Looking good guys!
Dammy
-
Funny, I was just thinking to myself earlier "I wonder what has been going on with AROS lately." Nice screen shots...Keep it up guys!
-
if this keeps up i'll be forced to see if it will work on my laptop!
:roflmao:
-
Wow! Does anyone know, what nightly build has these changes in it?
-
My god AROS is starting to look damn good. Keep it up guys!
:pint:
-
aros.org seems to be down. Site overloaded eh ;-).
-
Rock on!
Looking better and better :-D
-
Very nice indeed :-)
-
Poster: cecilia Posted: 2004/3/9 1:43:56
if this keeps up i'll be forced to see if it will work on my laptop!
You mean your poor laptop has been denied AROS all this time!!! :-(
:-D
-
Animated PNGs... are they viewable on PowerIcons or MOS?
BTW good job!
I hope you release a 68k version when the integrated 68k emu is developed...
And I'd like to have direct 68k emulation (without the UAE thingie) on big-endian systems...
-
And I'd like to have direct 68k emulation (without the UAE thingie) on big-endian systems...
On Big endien systems direct 68k emulation is possible, but is it desirable?
I personally think the benefits of UAE outweigh the use of a direct emulator.
-
I don't. I prefer to mix native libraries with 68k ones. I have looots of 68k stuff and libraries that could benefit from this.
And remember that these solutions aren't mutually exclusive... on PPC you could select one mode or the other
-
I don't. I prefer to mix native libraries with 68k ones. I have looots of 68k stuff and libraries that could benefit from this.
I would then ask you, How many x86 programs do you have that require 68k libraries :-)
68k programs will still be able to use 68k libraries :-)
-
Hey, all. I downloaded the lastest build last night and it doesn't appear that the new "eye candy" was in it. Does anyone know when the nightly build will inculde the new changes. Also, just curious. Does the default Wanderer Desktop look like the new screen shoots?
-
Any program that uses MUI MCCs for example.
We wouldn't be waiting a native TCP/IP if we had a 68k integrated emu working. We wouldn't had need the native GCC port and a long etcetera.
For example, I could use Poseidon for the USB stuff, I could use Genesis for the TCP/IP, and blah blah blah...
-
Any program that uses MUI MCCs for example.
AROS will get it's own versions of most MUI stuff... but good point :-)
We wouldn't be waiting a native TCP/IP if we had a 68k integrated emu working. We wouldn't had need the native GCC port and a long etcetera.
We need a native TCP/IP stack. since we want a system that is integrated into the system rather than a 3rd party extra.
For example, I could use Poseidon for the USB stuff, I could use Genesis for the TCP/IP, and blah blah blah...
A native USB driver would be needed anyway.
If you really think about it, I'm sure you will realises that the UAE approach is a much better long term solution.
:-)
-
"AROS will get it's own versions of most MUI stuff"
I seriously doubt that most developers will make special AROS versions. Just look at the current situation, creating 68k binaries is just a matter of recompiling most of MOS stuff, but I don't see them recompiling for OS 3.x.
"We need a native TCP/IP stack. since we want a system that is integrated into the system rather than a 3rd party extra."
Yes, but until you have ready your native TCP/IP you could be using AROS for everything instead of using Windows or Linux and you would already have a huge base of AROS users.
"A native USB driver would be needed anyway."
I could use AracAttack right now if AROS supported OpenPCI...
The UAE idea isn't bad, but I would prefer to have also an integrated emu in big-endian systems... in little-endian systems the integrated 68k emulation would be more difficult, but on ppc I can't see why you wouldn't want to have the OPTION of using one method or the other...
-
Poster: bloodline Posted: 2004/3/9 4:37:44
You mean your poor laptop has been denied AROS all this time!!!
Ah, yes, it has :-(
but as it has Linux, windows2000 and winuae, it's not exactly suffering from a lack of OS's!
:lol:
it just that I need to have AROS be completely bootable from CD because I can't monkey with what I already have on it. I need this baby to be 100% working perfectly.
Also, not being a tech nerd, i'm still trying to understand how this works.
I do understand how to download an iso and then burn a cd. I just did that for Mandrake 9.2 this weekend for a friend of mine. that part was easy.
:-D
it's just once I have a bootable AROS CD, then what? what if i want to try out different amiga programs? like, duh! IFX? (who didn't see THAT coming?) :-o
-
Hello, crumb.
I think that everyone has got your point about integrating UAE in AROS as a transparent emulation. (heavy lobbying)
Sure.
But, as TCP/IP or USB, things are to go deeper in the core-OS. That's why there is an "hidd" concept.
Speaking of OpenPCI: It has been discuted a lot of times: It could be made an OpenPCI.library wrapper around the pci.hidd and its pci.library. BUT, OpenPCI isn't that "OPEN". And this is a kludge to work with native Amiga hardware. Then, AROS isn't intended to be targeted to 68k first. No doubts it will in future. But for now, devs are focusing on low-level API and HIDD. just, and you will be pleased, to be compatable (portability) with your concepts.
Devs are waiting for a ppc port that open them the road to an uae transparent layer. For now, this port simply doesn't exist. Same for 68k. So 68k layer isn't the n°1 priority.
Think of TeamAROS bounties for projects priority :-)
Adam Olivier
-
"BUT, OpenPCI isn't that "OPEN". And this is a kludge to work with native Amiga hardware. "
As your PCI HIDD is really open could this be ported easily to real Amigas?
I say this because OpenPCI only has a few drivers and it would be nice to see a real "open" pci solution.
-
Just one question. Are Nic Andrews and Wez Furlong working on the same TCP/IP stack, or two different ones?
-
pci.hidd is open and documented. It's code is open, it's API is open, and OOP.library system is open too. pci.library is open, in code and in API.
OpenPCI.library is not open: it's API is open.
Anyway, it is not only NON free, it is a wrapper through natives (pci addon cards) libraries (as prometheus.library or other), so even if the OpenPCI.library was used in AROS, it must be some sort of lower level system to manage the pci-bus : in AROS case, the pci.hidd...
Now, it only lacks of devs to create sub-drivers, for scsi or usb or ethernet pci cards... (that's come first in mind)
And yes, hidd's and oop.library could be ported (if anyone wanted to do the 68k port...)
OpenPCI has only drivers for AMIGA PCI BUSSES.
That make a little number of machines (think of A1200-pci, A4000-pci... 1000, 2000, 5000 of each? Now, think of MILLIONS pc's out there with the very same pci bus)
But sure, it can be done.
Appart from that, classic Amiga pci cards (catweasel, delfina-pci/flipper...) should have an AROS driver too!
Adam Olivier
-
Hello ncafferkey,
Good question, as there are 2 TCP/IP stacks projected:
-AmiTCP (from 3.02ß sources, as it is open)
-LwIP (lightweight-IP)
For now, LwIP compiles, runs, and open a bsdsocket.library but seems to be not reachable (don't ask me why). I wasn't able to compile "ping" for it.
AmiTCP doesn't compile (ATM), but is a bit more "Amiga-ish".
Sure that those two devs know each other and will not duplicate efforts.
Stay wired!
Adam Olivier
-
"it is a wrapper through natives (pci addon cards) libraries (as prometheus.library or other), so even if the OpenPCI.library was used in AROS, it must be some sort of lower level system to manage the pci-bus : in AROS case, the pci.hidd..."
Why would you want to invent a new incompatible pci.library and later do a wrapper?
Why don't simply make a new library with functions compatible with OpenPCI ones and avoid the need of using a wrapper?
Titan will probably end up making free the stuff that doesn't require signing NDAs...
"OpenPCI has only drivers for AMIGA PCI BUSSES"
That's completely wrong. It also has drivers for millions of pcs because there's an Amithlon version. And there's also a Pegasos version.
"Appart from that, classic Amiga pci cards (catweasel, delfina-pci/flipper...) should have an AROS driver too!"
With an OpenPCI wrapper and an integrated emu they could work directly.
Sorry, but I don't agree with you saying that 68k emulation is not much important... it can save a lot of time until the rest of elements of AROS are finished.
-
Sorry, but I don't agree with you saying that 68k emulation is not much important... it can save a lot of time until the rest of elements of AROS are finished.
Ok, given that you still believe it's possible to have a transparent 68k emulator on little endian machines in AROS, let's put it this way: there are no programmers in the team interested in such a task, specially because everyone believes it's not possible to do it. We've already stated which is the emulation approach we prefer.
If you believe we're wrong, feel free to prove us wrong, no one will stop you: make this emulator work, and be sure that we'll be ready to admit we were wrong all along, and AROS will have one great piece of software.
-
"Why would you want to invent a new incompatible pci.library and later do a wrapper?
Why don't simply make a new library with functions compatible with OpenPCI ones and avoid the need of using a wrapper?"
I wanted to write OpenPCI compatible thing at the beginning. Unfortunatelly the OpenPCI was insufficient for me. To few features, to limited API. Additionally I've found some licence issues (at least in the version I had) - Aros core libs cannot be GPL'ed. Finally, I wanted to have a system which supports more than one PCI bus in one system (man PCI bus and eg. PCI bus over any PCI device). Using OpenPCI would mean we would need separate openpci.library for every single architecture. The PCI classes are hardware independant and the HW driver class needs in simpliest case to overload two methods to get things working.
"Titan will probably end up making free the stuff that doesn't require signing NDAs..."
Yes, probably...
-
"Ok, given that you still believe it's possible to have a transparent 68k emulator on little endian machines in AROS"
You can
reply my post (http://www.amiga.org/forums/showthread.php?t=7256) to explain me (if you want) why it wouldn't work... I would be very interested, really.
BTW, I was talking about PPC and not x86 in this thread :-)
And I remember having read that the guy who was doing the PPC pegasos port was at least slightly interested in making an integrated ppc emu
"make this emulator work"
well, we don't have a MMU.hidd yet, so I should:
1.- do an MMU.hidd
2.- adapt Exec to use virtual addressing
3.- integrate the 68k emu
Points 1 & 2 are need independently of being ppc or x86. And they would allow the use Swap memory and would help to avoid some lock ups. But I don't think that I have experience to do that. With the MMU functions and with Virtual Addressing It could be easier to do point 3...
-
"Additionally I've found some licence issues (at least in the version I had) - Aros core libs cannot be GPL'ed."
Yes, but the author of a GPL product can provide additional licenses, and Titan could give you an OpenPCI and make it AROS PL...
Try to talk with him so we can have a wrapper officially :-)
"man PCI bus and eg. PCI bus over any PCI device" Well, Prometheus library allows you to have various PCI buses... and it also allows you to have various pci devices inside the same PCI card.
I think that you would only require a pci.library for each architecture... Couldn't you use the BIOS for that? When I load an OS on a x86 machine doesn't it use the BIOS to know how to access the PCI bus? Otherwise an older version of the OS wouldn't work in newer motherboards with different chipsets, but it works... So for x86 we would only use one pci.library, for u-boot we would use other, and for smart firmware another one...
But please, talk with Titan, try to ask him a special OpenPCI version with the AROS licence I guess He'll cooperate :-)
Thank you for your effort, I don't want my comments to sound negative, I just have doubts that I'd like to dissapear...
And again, creating a new pci.hidd is not an easy task and we can always use an OpenPCI wrapper, so thank you :-)
-
"1.- do an MMU.hidd"
I haven't looked much Thor's MMU.library, but it may be a good idea to have similar functions
-
It might be an idea to talk to NicJA about mmu.hidds and the like, when I spoke to him about it, he said he had a better idea... I think his idea was abstract it a bit more... probably using his new cpu.resource.
Anyway, I still am not convinced by direct 68k emulation... A much better idea would be to have a special library loader that creates virtual libraries on the side of the system that doesn't have the native library at run time.
I really like the idea of keeping 68k programs running in a UAE context, so that I can run all my old Hardware hitting games (the only things I have left of my Amiga software that I can't get equvilents on my PC), and because it offers crash protection.
The direct 68k emualtion might me a nice (even desirable) short term solution, but in the long run I would prefer the UAE solution for these reasons:
1. Greater compatibility with Amiga software.
2. Greater system stability.
3. Reduced resource overhead.
4. Platform independance.
5. To encourage more native software.
6. Greater User control over the 68k software.
7. To allow the easy bypassing of legacy system components.
8. Externally matintained Emualtion software (less AROS resources required).
:-)
-
"Yes, but the author of a GPL product can provide additional licenses, and Titan could give you an OpenPCI and make it AROS PL..."
Yes, but I didn't meany Titan here. The OpenPCI SDK he sent me has include file which is/was extremly based (I could almost say copy&paste) on one of linux kernel header files. So I should rather ask there ;)
"Well, Prometheus library allows you to have various PCI buses... and it also allows you to have various pci devices inside the same PCI card."
Can I have there a PCI device on PCI bus which contains itself an other PCI bus (accessed only through this device) to which there is connected additional PCI card providing it's own PCI bus? Mine pci classes allow that :)
"Couldn't you use the BIOS for that?"
AROS doesn't use BIOS except loading stage (actually it's GRUB then who does the job).
"When I load an OS on a x86 machine doesn't it use the BIOS to know how to access the PCI bus?"
Doesn't have to. There is a standard way on x86 to talk to PCI bus.
"But please, talk with Titan, try to ask him a special OpenPCI version with the AROS licence I guess He'll cooperate"
We have already chatted few months ago. Then I've decided to write pci drivers myself. :)
-
@Bloodline:
"Anyway, I still am not convinced by direct 68k emulation... A much better idea would be to have a special library loader that creates virtual libraries on the side of the system that doesn't have the native library at run time."
That would be a great idea :-)
@mschulz:
"Can I have there a PCI device on PCI bus which contains itself an other PCI bus (accessed only through this device) to which there is connected additional PCI card providing it's own PCI bus? Mine pci classes allow that :)"
I don't know a real world situation that would require that. Apart from that I haven't investigated too much Prometheus.library and I can't give a definitive answer. Krashan would be the best person to answer that.
-
You can
Sorry you can't, but feel free to prove me wrong...
reply my post to explain me (if you want) why it wouldn't work... I would be very interested, really.
Done.
-
UAE under AROS ... I'm wondering if it performs faster than under Winblows ou Lunix ...
Any facts ?
-
@Fabio:
thank you for the explanation, I found it very interesting, what do you think about the other idea of using memory in reverse order like Executor? I've explained again how would it work (more clearly hopefully)
-
UAE under AROS ... I'm wondering if it performs faster than under Winblows ou Lunix ...
With our integrated emulation system, Operating system opertaions (graphics etc.) should be a lot faster since they will be handled directly by the native AROS :-)
-
With our integrated emulation system, Operating system opertaions (graphics etc.) should be a lot faster since they will be handled directly by the native AROS
Even considering gfx card acceleration under Winblows / DirectX ?
-
Even considering gfx card acceleration under Winblows / DirectX ?
err... when we get hardware acceleration :-)
-
the second screeny, with the png icons and the aa-fonts looks spanktastic. keep it up guys!
-
With our integrated emulation system, Operating system opertaions (graphics etc.) should be a lot faster since they will be handled directly by the native AROS
Hmmm ... does that means AROS ships a special UAE version which take advantage of AROS resources ? Interesting ...
:-)
-
Hmmm ... does that means AROS ships a special UAE version which take advantage of AROS resources ? Interesting ...
No, unfortunately Matt likes to play the "Fleecy" game, sometimes ;-)
What he meant is that, in future, the integrated emulation system that has a bounty set for it, will work like that. Right now the UAE port we have is just a more or less straight port of the mainline UAE.