Which OS Would Be The Best Amiga Way Forward...

[bloodline]

Bloodline...How is your Aros68K-A1200 experience? Looks like it is OK. In my own Aros68K-UAE poking around, it seems to me that this is the way to go as opposed to a massively patched 3.x original. Would you tend to agree? Question...Aros kickstart' files are softloaded at boot somehow?
 

:lol: AROS 68k on an A1200 is currently slow, painful and bloody good fun

There is a nightly build ADF on the AROS website, write it to a real Amiga disk... Boot your Amiga with the disk, it will softkick the AROS ROM... The fun is then throwing all your Amiga software at it and seeing what crashes and what produces weird results

I am debating on installing this in my A3000. I am assuming that all of the expansion hardware I have wouldn't be an issue and that I would still be able to run RTG video via cybergraphx4. The problem I have in the A3000 is memory. only a 2/16MB config. Maybe it is time to jump onboard the 256MB ZorRam thing. Which would mean I have issues with # of cards installed. I think dumping the X-Surf/Subway USB combo in favor of Deneb/USB/USB Network would do the trick. I need to learn more about this USB network thingy I see people using...
 
So Aros68K very interesting and certainly could solve once and for all the 68K OS availability and politics and do so with improved functionality.
 
Cheers.

Try the nightly build, have a play, you're not going to break anything and te devs welcome all feedback!

[vidarh]

I think you just dont know Amiga software very well. If AmigaOS design was kept easy and simple like it was in Kickstart 1.3 it could even work. In release 2.0 Commodore developers really screwed it up.

My point about scope is that the number of applications that it needs to support is fairly manageable. It doesn't need to support every possible "legal" thing an AmigaOS app can do simply because not every permutation of legal things are actually being done by existing, still useful AmigaOS applications.

So Emumiga will be tailored for each application?

I don't think that's the goal, but if it's *necessary* I don't think anyone would object to it. That's the point.

 My wish list would be very short: Blacks Editor because it is still the best text editor for Amiga. AmiNetRadio and dynAMIte could be nice to have, too. I can not remember any other useful 68k applications/games anymore.

And *this* is the point. While I'm sure there are people who use many, many more m68k apps, the total number that people actually use is still fairly limited.

Hmm? Do you realize how often OO application are going to have context switch between 68k and AROS native code? You can not even figure out when 68k code is calling native AROS code because it is nothing but jsr() to a pointer.

Of course you can. Any AROS code that's made "visible" to the m68k code would need to be "mapped" into the m68k apps address space. It's then absolutely trivial to make the m68k emulator detect when the m68k core tries to access an address that would bring it into AROS code.

 Nothing is going to tell you 68k code is trying to call AROS BOOPSI dispatcher code.

Yes, the m68k emulator would, because it would know that the target address of a JSR etc. is an address that corresponds to a function exported from the host environment, rather than m68k code. This bit is trivial.

But back to data endianess problem. How do you can really know what kind of data structure there is behind Object pointer? Depending on object type its data structure extension is different. Are you going to detect data structure format based on its pointer + allocated space for object?

This only ever matter if it's a data structure "exported" from AROS to m68k. The subset of data structures that are worth exporting *and* that m68k code would legally try to access is limited, because it is limited to only libraries that are used  by m68k code *and* where it makes sense for the m68k code to call the AROS native version of the library rather than a straight m68k version. They don't *need* to be able to call the AROS native versions other than where it impacts integration.

E.g. you don't strictly *need* it to be able to call the host version of Zune, for example (while it might be desirable), since Zune doesn't need to run in a single context for all applications in the system.

There's a tradeoff between how complicated you make it vs. how tight integration is really necessary - the less integration, the closer you get to the Janus-UAE model. The more integration, the more work to translate data structures etc.. It's not either/or.

[Rodomoc]

Bloodline, Thanks for the feedback. I think that I will attempt running Aros 68K from the ADF method you mention on my A3000 in native ECS video to see what happens. The machine does have 040 in it so maybe this will help it run Aros 68K better. I won't worry about any of the expansion hardware I have yet and if it freaks Aros 68K out somehow, I'll unplug the lot of it.

[wawrzon]

Bloodline, Thanks for the feedback. I think that I will attempt running Aros 68K from the ADF method you mention on my A3000 in native ECS video to see what happens. The machine does have 040 in it so maybe this will help it run Aros 68K better. I won't worry about any of the expansion hardware I have yet and if it freaks Aros 68K out somehow, I'll unplug the lot of it.

the current stage of aros 68k is trying to support maximum configurations. whoever is familiar with serial debugging could hook up (sub 25->9 pin adapter + null-modem cable + eventually serial->usb adapter between their amiga and a pc. using tera term on pc (adjusting the port and baudrate to 115200) you can catch the boot log and supply it to aros dev list. feedback welcome.

[itix]

And *this* is the point. While I'm sure there are people who use many, many more m68k apps, the total number that people actually use is still fairly limited.

But seems you can only run simple clock application nobody really need...

I really like Emumiga approach because it tries to bring something new, explore and research. But seeing even very simple data structure like MsgPort (only 40 bytes) has limited support I dont feel confident it is feasible for large applications.

Yes, the m68k emulator would, because it would know that the target address of a JSR etc. is an address that corresponds to a function exported from the host environment, rather than m68k code. This bit is trivial.

It would know when 68k code is calling AROS native code but it would not know how to map 68k params to AROS native code. If you look at hook definition you will find out it is (almost) always standard. However, with DoMethod() call it is more complex because it is a vararg call. You know, DoMethod(obj, method_id, param1, param2, ....) where parameters are pushed to stack and pointer to params is placed in register A1. You can map 68k register to native AROS but what to do with parameters in the stack?

In theory you could always swap endianess of parameters... but how many parameters there will be? You can check method_id but it is not unique. There is no terminator nor there is any number in front of parameters indicating count. Keep track of AROS native objects so you could actually match method_id? Maybe... could work if you dont include Zune.

You could also subclass BOOPSI classes so neither 68k or AROS code would never call directly real dispatcher but go through emulation dispatcher first. However, you have to support large number of methods and tags here...

Btw similar problems will appear with CallHookPkt() (nice vararg call) but you are left without subclassing option.

This only ever matter if it's a data structure "exported" from AROS to m68k. The subset of data structures that are worth exporting *and* that m68k code would legally try to access is limited, because it is limited to only libraries that are used  by m68k code *and* where it makes sense for the m68k code to call the AROS native version of the library rather than a straight m68k version. They don't *need* to be able to call the AROS native versions other than where it impacts integration.

Library wrappers are easy. Call AROS, done. Call AROS, done. Call AROS, done.

E.g. you don't strictly *need* it to be able to call the host version of Zune, for example (while it might be desirable), since Zune doesn't need to run in a single context for all applications in the system.

If you run another instance of Zune in 68k context then things get easier indeed. The same probably should be done to datatypes.

There's a tradeoff between how complicated you make it vs. how tight integration is really necessary - the less integration, the closer you get to the Janus-UAE model. The more integration, the more work to translate data structures etc.. It's not either/or.

More or less Emumiga is stripped down UAE. In other words there is 68k CPU emulation and modified Kickstart image. It does not matter how library call are processed as long as parameters and results are kept in big endian mode.

[jakov]

About Emumiga. From now on, read "x86" as "host". (Emumiga would work on ARM too for instance.)

Emumiga runs EVERYTHING except the program itself in an x86 context. Every loaded library is an x86 library. It works by a pretty deep and convoluted set of "layers" of memory mappings, which it uses to keep track of pointers within structs within pointers.

Moggen is one of the very few coders I know which could implement something like this. This is actually research level stuff and he could write a paper about it.

[MonkeySpandex]

I think AROS stands the better chance of survival what with it being Open Source and running on a lot of commodity PCs.  The 68K port sound interesting.  I still have my old A1200 though it hasn't been used in years.  I've downloaded and had a quick look at AROS on x86 using VirtualBox and it seems at first glance to be very good.

I've never used OS4 or MorphOS.  Both of them look fantastic but I cant help but feel that PowerPC is a dead end.  The hardware is just too expensive for OS4.  I like the fact that MorphOS can work on an old PowerPC Mac but I feel this is too limited for them.  New inexpensive hardware is what is required along with a good base of software.  The lack of software is the real killer of each of the OSes in my humble opinion.

[Franko]

AROS gets compiled during nights and new versions are released to the public for every supported platform every day on www.aros.org. Since 68k is a supported platform, this means that there is a new version for that every day, too.

Follow Wawas instructions if you want to try it on real hardware, although the planar gfx support is not very good yet, so it wont be as fun as emulating with the uaegfx chunky modes for now.

Ok I went to the site and downloaded the following file :-

AROS-20110524-amiga-m68k-system.tar.bz2

Problem number 1:- As seems to be typical these days for things that folk have written or archived using a PC, the filename is TOO LONG for it to be recognised on a REAL Amiga...

Easily solved though (but still ruddy annoying) I renamed it to AROS.tar using my iMac...

Problem number 2: - Unfortunately I can't unarchive it on my Amiga as all un-archiving programs I've just tried just throw up error messages along the lines of "unrecognised" or "this is not a proper xyz archive"...

(I tried UnARJ, UnRAR, UnTGZ etc... that I have on my Amiga but with no luck)...

So have I downloaded the wrong file or do you need too find someone called Gandalf to stand in front of it and mumble some hocus pocus and bang his staff to open the archive...

PS: Who is "Wawa" is he a hobbit that didn't make it into the films... :confused:

[Forcie]

Problem number 2: - Unfortunately I can't unarchive it on my Amiga as  all un-archiving programs I've just tried just throw up error messages  along the lines of "unrecognised" or "this is not a proper xyz  archive"...

(I tried UnARJ, UnRAR, UnTGZ etc... that I have on my Amiga but with no luck)...

The filename does indeed exceed the FFS 30 char limit, but this is not a problem for most classic users who are running on SFS or PFS3 partitions.

Like the filename suggests, this is a standard UNIX-style tarball archive compressed with the bzip2 algorithm. Tools for unpacking this on Amiga have been available since the bzip2 compression algorithm was created in the mid 90's. This is consistent with the standard GNU toolchain that most people developing for the Amiga platform are using nowadays.

[commodorejohn]

Might want to try renaming it to .tar.bz2 there, Franko - some archivers (including at least the implementation of tar on my system) won't understand that it's a zipped tarball otherwise.

[Franko]

Like the filename suggests, this is a standard UNIX-style tarball archive compressed with the bzip2 algorithm. Tools for unpacking this on Amiga have been available since the bzip2 compression algorithm was created in the mid 90's. This is consistent with the standard GNU toolchain that most people developing for the Amiga platform are using nowadays.

Ok even though that's total gobbeldygook to me, I spotted the word ZIP in there so perhaps one of the ZIP unarchivers I have on my miggy will be able to open this mysterious box of tricks, I'll give it a go...

Still pretty dumb though (and just plain lazy) archiving things for a real Amiga and not bothering to make sure the filename is 30 chars or less so that it can be recognised on a real Amiga...

It's like a DVD I once bought on eBAY with some 16,000 C64 games on it, they all had filenames of incredible lengths and I had to write my own program that could handle these long filenames and convert them to 30 chars or less as they were copied across to the Amigas HD...

Why do folk who do stuff on PC's that they hope to be used on a real Amiga forget the very simple fact that the Amiga can't handle these silly long filenames they give them... :rolleyes:

[Franko]

@ Commodorejohn

Thanks, I'll give that a try too...

@ Forcie

I do use SFS but when your transferring something between a MAC and the Amiga it doesn't help as utilities like DirWork (which I use) or DOpus still don't allow for the recognition of these long filenames to be able to read them from the the SD card (in this case) or CD/DVD etc...

It would be much simpler if someone intends their program to be used on a REAL Amiga to remember the 30 Char limitation...

[Forcie]

Still pretty dumb though (and just plain lazy) archiving things for a real Amiga and not bothering to make sure the filename is 30 chars or less so that it can be recognised on a real Amiga...

It's like a DVD I once bought on eBAY with some 16,000 C64 games on it, they all had filenames of incredible lengths and I had to write my own program that could handle these long filenames and convert them to 30 chars or less as they were copied across to the Amigas HD...

Why do folk who do stuff on PC's that they hope to be used on a real Amiga forget the very simple fact that the Amiga can't handle these silly long filenames they give them... :rolleyes:

"Real Amigas" did not come with the lha unarchiver either. So technically uploading Amiga software to the net in this format is inconsiderate of people using "Real Amigas"

No, but seriously. This is still adapted to the logic of the more tech-savvy, developer kind of Amiga user. A guy who upgraded his filesystem 15 years ago and got rid of the filename limitation, and is familiar with common industry-standard UNIX tools. It is all bound to be a little cryptic for anyone not familiar with it. Eventually there will be a full, user-oriented distribution of AROS-68k with pre-installed third party software which is easier to install for the run-of-the-mill user.

[Franko]

"Real Amigas" did not come with the lha unarchiver either. So technically uploading Amiga software to the net in this format is inconsiderate of people using "Real Amigas"

No, but seriously. This is still adapted to the logic of the more tech-savvy, developer kind of Amiga user. A guy who upgraded his filesystem 15 years ago and got rid of the filename limitation, and is familiar with common industry-standard UNIX tools. It is all bound to be a little cryptic for anyone not familiar with it. Eventually there will be a full distribution of AROS-68k which is easier to install for the run-of-the-mill user.

I hope so cos even as I type here my UnZip utils on my Amiga right beside me are having a hairy fit trying to recognise this thing... :crazy:

[Forcie]

I hope so cos even as I type here my UnZip utils on my Amiga right beside me are having a hairy fit trying to recognise this thing... :crazy:

Here are the proper decompressors if you are interested in trying:
http://aminet.net/package/util/arc/AmiGNUtar
http://aminet.net/package/util/arc/bzip2_68k

bzip2 might require ixemul.library, I am not sure since I have had it installed on all my AmigaOS installations since the 90s.

[commodorejohn]

Hmm...oddly, it looks like there aren't very many tools for classic Amiga that handle both tarball and bzip - you might have to decompress it with bunzip first and then use untar to unpack it. That's a bit frustrating...

Oh, beaten. Eh, what the hell, I'll leave it for posterity.