AROS Status Update

[Crumb]

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...

[Crumb]

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

[Crumb]

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...

[Crumb]

"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...

[Crumb]

"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.

[Crumb]

"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.

[Crumb]

"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 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...

[Crumb]

"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 :-)

[Crumb]

"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

[Crumb]

@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.

[Crumb]

@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)