68k AGA AROS + UAE => winner!

[bloodline]

whoosh777 has raised a good point, and that point is that the Amiga Port of aROS is seriously lacking.

From what I can see the biggest issue here is bootsrapping the Amiga before the OS comes into play... if any Demos coders out there want to have some fun again.. they could do worse than get AROS booting on the Amiga... We already have the 68k dependant code runnign on the palm... come on guys, we need you :-D

[bloodline]

@bloodline

From what I can see the biggest issue here is bootsrapping the Amiga
before the OS comes into play... if any Demos coders out there want to
have some fun again.. they could do worse than get AROS booting on the Amiga...

--------------------------

if they can get AROS directly booting from an A1 that will be a major
achievement,

will they also need to port gcc to that specific setup?

I would still like the ability to run my 68k programs,

maybe if they can port UAE to run above that version of AROS,

I dont know what the issues are in porting UAE,
 

Booting an A1 with AROS is not that hard, since the A1 has it's own firmware (The UBoot BIOS) to bootstrap the hardware... bootstraping a real Amiga is much harder since AROS would have to do that itself.. the real Amiga's OS and firmware are one and the same.

UAE runs fine on AROS, but some people would like to see it be able to pass OS function calls from the Emulation through to the Main AROS OS thus integrating it.

[bloodline]

IonDeluxe wrote:
UAE still needs kickstart, and I have not seen anyone talk about an open source re-implementation of that, or I am blind.
I cant be opensourced until you getourd the kick rom.

When someone matures the 68k port of AROS it will probably (The is no technical reason why not) be included with UAE as the Default ROM. Obviously the user could use a real ROM if they wish, but it would not be needed.

[bloodline]

to what extent is AROS an API as compared to an OS?

If you want to directly boot an A1 not via Linux,
how is this done?:

lets say you buy an A1,
you switch it on,

do you have to create a CD on another machine which you
then boot the A1 with?

How much facilities does A1 UBoot provide?

The code you would run on the A1, how is this created?

AROS is an OS. It currently is able to boot x86 machines and Openfirmware PPC Machines.

If you were to Flash the A1 BIOS with an Openfirmware rom (written for the Terron), then AROS could boot it.

I would expect UBoot provides similar features to Openfirmware, all it takes is for someone to adapt the AROS Boot code.

A System's firmware initilises the hardware, and brings it to a known state. It then Looks for an operating system Loader on the available storage media). Once a Loader is found it is executed. The AROS Loader will then load the AROS "ROM" code into the memory, THat memory is then protected against writing (Since it must be treated as a ROM).
The Loader then preserves all the hardware info from the BIOS into a "safe" location... The loader then jumps to the AROS ROM code. AROS then takes control of the machine. AROS boots.

The Booting precedure is available for view in the AROS source code, and If you have any questions you can visit www.aros-exec.org where the devs can often be found lurking.

[bloodline]

For the A1000 I believe they cross compiled the OS from Macs,
this is why Lattice C occurs on both platforms, it was originally a Mac
compiler and they used it to cross-compile AmigaOS (I think)

VAX Machines actually. NO Mac of that time would have been powerfull enough (or enough memory/hard disk) to Compile AmigaOS

[bloodline]

2. The issue of 64 bit code, this can be done by extending the
68k Virtual CPU instruction set by inventing our own 64 bit instructions!

But the only reason to stay with the 68k is to maintain compatibility with the old Amigas... if you want to extend the instruction set virtually, you would do much better to use a brand new CPU.

In answer to your question, the 68k was not extened becasue at the time there was a Paradigm shift from CISC to RISC, and since there was not the software inventment in the 68k that there was in the x86, the decision was made to dump the 68k and move to the PPC.
Note that the x86 instruction set is more RISC like than the 68k, so lends itself better to modern optimisations.

History has shown that the RISC/CISC divide was actually qutie an artificial one, and that a balance between the two is the best architecture.

Personally I would like to have seen the 68k extended in the same way the x86 was with the Pentium.

But the 68k would have to have lost a lot of adressing modes in order to allow high performance operation. This rearchitecturing would have removed the neat orthogonal design of the 68k and rendered it quite incompatibile with the original 68k chips... Defeating the point...

[bloodline]

>UAE runs fine on AROS, but some people would like to see it be able to pass
>OS function calls from the Emulation through to the
>Main AROS OS thus integrating it.

if UAE runs on AROS then that is one way around the problem,
just run the 68k binaries on UAE on AROS,

redirecting UAE through AROS sounds quite a tricky problem,

I think this requires a lot of thought just to understand
the problem properly,

you are attempting to transplant one implementation by a totally
different one,

also some 68k programs may hit the h/w directly which the
redirection wouldnt understand,

Ok, the UAE idea, is just that. Run a 68k version AROS on UAE, and run UAE on AROS.

All 68k programs will run in UAE, and they will make OS calls to the 68k version of AROS Running in UAE... That 68k version of AROS will be specially designed to allow it to call AROS functions through UAE. So whe the 68k program calls the 68k AROS in UAE to open a window... the 68k version of AROS calls the x86 version of AROS and that Opens a window.

when the user clicks on a window that is owned by the 68k version of AROS running in UAE, the event gets passed through to the 68k verison of AROS which passes to the 68k program.

If the 68k program tried to hit the hardware, it will have no problems since the Hardware is emulated in UAE.

[bloodline]

Karlos wrote:
@bloodline

Well regarding the addressing modes, I could have done without the memory indirect addressing modes added since the 020. There as good as worthless anyway - the time it takes to fully decode one is simply ludicrous.

Does any amiga software even use them?

The only indirect addressing modes I use for 020+ (and see used elsewhere are)

(d16, aN), (aN)+, -(aN), (d8, aN, xN.w|.l * scale)

and occasionally pc based ones, eg I use (d8, pc, xN.w|.l * scale) for some duffs device style jumps into expanded loops.

When I was using 68k, I would tend to use a Memory to Register move, then work in the regs (register to register), then a Register to Memory move.

I really could not be bothered learning all those addressing modes :-( though pre/post incriment/decrement was very handy :-)

[bloodline]

>AROS is an OS. It currently is able to boot x86 machines and
>Openfirmware PPC Machines.

>If you were to Flash the A1 BIOS with an Openfirmware rom (written for the Terron),
> then AROS could boot it.

so you appear to be saying it can already be done!

and you also seem to be saying that the only dependencies are that its
Openfirmware, ie the fact its an A1 is irrelevant,

Has this actually been tried out?

What is involved in this flashing of the A1 BIOS?:

lets say someone orders an A1, how do they get the BIOS flashed?

will this clash with running OS4? : what flash does that require, UBoot?

can you switch back and forth between Openfirmware and UBoot?

Have I understood you correctly: you buy an A1, flash the BIOS, download AROS,
boot AROS?

Yes, the fact that it's an A1 is irrelevant. The hardware is a *standard* PPC machine.

First you would have to get an Openfirmware BIOS image from someone. I don't know if these exist, if they do, then One of the other users of the MAI chipset might have one. Check out the Terron.

I assume the A1 BIOS can be flashed by software... most BIOS's can be.

OS4 needs UBoot to boot, for the same reason AROS needs Openfirmware. THat's what they have been written to use. I don't think it's healthy to keep reflashing the BIOS. If one wants to use an Openfirmware PPC machine I would suggest they get an old Mac or a Pegasos2.

On the PC one can use the MMU to load a BIOS image into memory and then use that instead of the ROM BIOS... I assume the same is true of the PPC machines.

The solution to this problem is to get someone with UBoot experience to adapt AROS to use UBoot instead of Openfirmware, That's the simplest solution all round.

>The Loader then preserves all the hardware info from the BIOS into a "safe"
>location... The loader then jumps to the AROS ROM code.
>AROS then takes control of the machine. AROS boots.

does the firmware tell you where all the system memory is located?


are any memory allocation facilities provided or you have to construct these
yourself?

any API provided for reading the drives?

The Firmware tells you how much memory is present (Thoguh it's good practice to check while the OS is booting).

The Memory is always located in it's address space... your question doesn't make much sense :-(. Maybe you mean other memory like PCI space and stuff, yes that sort of information is usually gathered by the BIOS, and AROS uses that information.

AROS provides the Memory allocating functions. The Firmware does not need to know about stuff like that.

Most BIOS firmware does provide a simple API for accessing physical sotrage media... how else are you going to load the OS :-)

if I can get an A1 to directly boot AROS and then run UAE above this,
then I think I will go down this path and find out what AROS are doing,


IMO AROS are 10 x as competent as Hyperion,


my interest in this is my own projects that I could run in the AROS
environment so eg I very strictly only use the OS3.0 API and cybergraphics.library,


my interests tend to be nongraphical so eg exec.library interests me
much more than graphics + intuition etc.
Exec really is a masterpiece,

If you want to work on the PPC version of AROS why not help the PPC guys get it running on UBoot?

I think Hyperion are perfectly competant, it's hard work writing an OS from Scratch.

You project should run fine in AROS, if you have a PC there, then you could compile your Apps for AROS right now and use them on your PC with AROS :-)

Exec is a masterpeice! And getting to look at the Exec sources in AROS is really nice :-)

[bloodline]

>OS4 needs UBoot to boot, for the same reason AROS needs Openfirmware.
>THat's what they have been written to use. I don't think it's healthy to keep
>reflashing the BIOS. If one wants to use an Openfirmware PPC machine I
>would suggest they get an old Mac or o Pegasos2.

ok, was there any thinking behind their decision to use UBoot?
 

I think they choose it because it was different from the other PPC machines which all went Openfirmware, That way they could lminit the machine which OS4 runs on, and that it was suitable for thier needs.

> The solution to this problem is to get someone with UBoot experience to adapt
>AROS to use UBoot instead of Openfirmware, That's the simplest solution all round.

>The Firmware tells you how much memory is present
>(Thoguh it's good practice to check while the OS is booting).

>The Memory is always located in it's address space... your question doesn't make
>much sense.

I was thinking in terms of the classic machine where the memory may be
in several noncontiguous segments,

it sounds like you are saying its all remapped into 1 contiguous slot,

System Ram (Which AROS calls Fast Mem) is. Note AROS calls the first 16meg of System Ram Chips Mem, as this is DMA able ram.

>If you want to work on the PPC version of AROS why not help the PPC guys get it
>running on UBoot?

quite possibly, maybe a good approach would be the more general problem of
layering Openfirmware above Uboot,

if Uboot and Openfirmware are both quite simple then this layering may not
be a big deal,

and then layer the reverse way round,

what I may do is buy an A1, and then fool around with the UBoot to try
and understand it and then look into what the AROS people are doing,

AROS is really modular. One would not layer OF (Openfirmware) on top of UBoot, one would take out the OF boot code and replace it with UBoot Boot code. The advntage of AROS being opensource is that it can be hacked to suit the needs of the user (ie you) :-)

>You project should run fine in AROS, if you have a PC there, then you could
>compile your Apps for AROS right now and use them on your PC with AROS

I only have 68k machines, 2 68000 A500s and a 68030 A1200,
I will try and get some stuff onto AROS though this will probably wait till I am
on PPC or PC, I have lots of useful utilities that I have written to manage
my own system,

If you find a PC in the trash/skip/bin then dig it out and run AROS on it, I have several junk machines found that run AROS fine.

>Exec is a masterpeice! And getting to look at the Exec sources in AROS is
>really nice

it could help me understand the original exec,

The AROS code does the same as the original code... so it's a great place to really admire the design.

[bloodline]

whoosh777 wrote

I think you need to chat to Crumb...

But Keeping 68k Apps away from x86 apps will be better in the long term... espeacially when adding features like Memory Protection, which 68k apps simply cannot work under.

Basicly keep 68k in the emulator and only let certain OS calls out to the Main AROS, so that the 68k programs can function in the same windowing environment as the x86 apps (without actually going near them).

[bloodline]

@whoosh777

who is Crumb?

An A.orger who wants inline 68k emulation in x86 AROS :-)

>If you find a PC in the trash/skip/bin then dig it out and run AROS on it,
>I have several junk machines found that run AROS fine.

I am trying to decide which path to take, PC or A1?

if I buy an A1 I think I can sell it back to Eyetech,
this reduces the risk of making this purchase,

re: reflashing ROMs, could you also run Mac's OS on Pegasos + A1
as well as Morphos + OS4 + AROS on Macs?

I'm not sure Eyetech would want to buy your A1 back... not with out a massive loss (more than the Price of a PC!).

I suggest you talk to people and look around for the machine that best suits your needs for the lowest cost.
(click the link for BlackTroll for great prices on AROS PCs)

Yes you can run MacOS on both the A1 and the Pegasos, by using a special program called "Mac-on-Linux", but then you need to run Linux too.
MOS and OS4 don't run on the Mac. AROS should though.

Some AROS questions:

1. what compiler(s) are used for recompiling AROS programs?

 

The Default Compiler is gcc. One AROS dev works in SAS/C on a real Amiga though. But to compile for the x86 you need to use gcc. We also have an x86 Assember program, as well as BASIC, False and Python all included with AROS.

2. are commercial AROS programs allowed, eg could they sell an AROS version of IBrowse?

Of course you can run commercial apps on AROS. That fits with my personal computer paradigm:

1. You pay for the harware.
2. You pay for the drivers.
3. You pay for the software.
4. But the OS is free and open source.

In fact the AROS licence even allows you to sell AROS, with certain conditions applying, this is how the MorphOS team are able to use the AROS sources (they bug fix the code they use).

I hope to see comercial software appearing for AROS once it gets better established.

[bloodline]

Getting AROS to boot directly on an A1 sounds a very high priority project, so if it hasnt been completed I may join that project, it also sounds very interesting,


I understand AROS already runs above Linux on A1 so AROS is there already but not the way many people want,

It would certainly be a great thing to have AROS running Nativly on the A1.

The PPC Linux hosted version of AROS is coming on rather quickly thanks to Markus, who is resolving some stack issues, and attempting to get the Graphics drivers to work.

if you compile AROS with big endian Intel gcc then you can have seamless 68k + x86 AROS integration using some variant of my suggestion,

read + execute exceptions would toggle between emulated and nonemulated instructions,

That's true, if we treated all memory access in AROS as Big Endien we could have the same 68k emulation method as OS4 and MorphOS use. But it has been decided that the performance penalty of running a little Endien CPU with Big Endian data was to significant (something like 30% penalty) that it was not worth it.
Besides if we use an integrated UAE we also get Hardware compatibility and improved stability so it's a benefit all round.

Would there be any point in creating your own AROS PPC platform?

AROS IS the platform, what hardware you choose to run it on is up to you. :-)
Be that a Mac, a PC, a Pegasos, an A1 or a washing machine... it's up to you.

>The Default Compiler is gcc.

this is the deciding factor,

which versions?

I hope you have gcc2.95.3-4 even though its not the most current,

is it a specifically AROS gcc or do you reuse generic ones?

Have you got 68k hosted cross compiler gcc's (PPC , Intel) for AROS?

To compile AROS you have to use the latest gcc (3.x.x). The AROS native version of gcc is the latest.

gcc supports the x86, the PPC and the 68k. this was a deciding factor in choosing it. Since AROS can be compiled for all of those CPUs.

you realise that gcc is also an assembler, the moment a platform has gcc
it automatically has an assembler:

Of course, other wise gcc wouldn't be able to output executable code. But the AROS distribution also includes the x86 assembler NASM, for those that want to just ply with x86 asm in AROS.
It should be noted however, that due to the cross platform nature of AROS, the use of ASM is actively discouraged. One should use C at all times.
The only exception is in some low level systems (noteably the exec.library) which need to access CPU specific features.

so eg commercial AROS IBrowse can be closed source?

Yes of course software can be closed source. But it would then be up to the software vendor to provide support for the different CPU versions of their software (ie 68k, PPC and x86). This can lead to the situation where x86 AROS users get a program that PPC AROS users don't get, and Vice Versa.

iospirit announced they have abandoned OS4 development,
there was a link to this from AmigaWorld.net at the time of the
KMOS takeover,


ask iospirit if they will recompile + sell IBrowse to AROS,


they have nothing to lose by doing this,
they already have an up and running website for selling IBrowse,

If there is demand for it, it will happen. Remember that AROS does not at this time have a fully functional TCP/IP stack. So general networking software is not a priority.

[bloodline]

>>It would certainly be a great thing to have AROS running Nativly on the A1.

>The PPC Linux hosted version of AROS is coming on rather quickly thanks to Markus,
>who is resolving some stack issues, and attempting to get the Graphics drivers
>to work.

for me the word Linux is underlined here,

can this Linux work be reused in a directly A1 booting AROS?

Yes, when you think of AROS Hosted, think of Linux as a Hardware abstraction layer. Running AROS on Linux can be thought of as the same as running AOS3.1 in UAE.

While AROS is running on Linux one can work out all the bugs and issues. Then you can add the Firmware boot code and boot AROS on it's own.

It should be noteed at 99.9% of the AROS source code is cross platform, it's just the CPU specific/ASM stuff that needs reworking.

I feel if I buy a PC I am a turncoat or traitor, however if AROS directly
boots ie no Windows and its not Intel then maybe thats better than
using IBM PPC on the A1?

Its strange that IBM are now "good" and Intel are "bad",

Having read the book "Big Blue" IMO IBM are anything but good,

and there is no basis for thinking Intel are "bad": Intel never
did anything "bad",

MS OTOH IMO are bad,

To be honest, the "good"/"bad" lables are a redundant conceptual model. Nothing is good or bad, things fall into two categories, "Usefull" and "Useless" with respect to your requirements.
Windows for example is "Useless" if I want to use an OS that looks and feels the way I want an OS to look and feel, but it is "Useful" is I want to run a certain peice of software.
When choosing hardware you must first consider what your requirements are, then choose what is useful and at the cheapest price. Ignore religious/political issues like "brand" and "make", these things are unimportant when it comes to technology.

How clean is PC AROS boot?

(the cleanness of the PPC AROS boot appeals to me),


Re PC AROS if I have understood you:

1. I buy a PC,
2. I download AROS,
3. I directly boot AROS?
4. I run UAE above AROS for full 68k compatibilty?

Is this correct?

Yes, just download the AROS CD image, burn that to a CD-ROM, then put that in the CD drive, turn the PC on... AROS will boot and run by itself.
You will presented with an early startup menu allowing you to select certain hardware options (good news if you have a Nvidia gfx card), or you can ignore them and it will boot after 5 seconds.

In the UK have you any tips about buying a new PC?

Are the places like PCWorld, Comet, Staples, Dixons a good place to try
or should I go to specialist shops eg from computer mag adverts?

I would build the machine myself. There are plenty of shorps that sell PC parts for good prices. http://www.dabs.com is a great UK website selling top quality parts for a low price.
Don't forget that Black Troll sell complete PC's with AROS already installed for around £160 or so (depending upon the exchange rate).
High Street stores will rip you off.

>That's true, if we treated all memory access in AROS as Big Endien
>we could have the same 68k emulation method as OS4 and MorphOS use.
>But it has been decided that the performance penalty of running
>a little Endien CPU with Big Endian data was to significant
>(something like 30% penalty) that it was not worth it.

30% is nothing,

if a car goes by at 70mph and 10 minutes later another car goes by at 100mph
would you know the difference (I am talking about perceptions here),
(70mph being 30% slower than 100mph)

can you go both ways: ie have Big endian PC AROS and Little endian PC AROS,

30% is far too much. When running AROS on a 3.066Ghz CPU, are you really happy to write off nearly a whole 1Ghz (919.8Mhz) of performance?

There is no point to cripple a CPU, AROS runs using the Native byte order of the CPU, thus it is big endien on 68k and PPC and little Endien on the x86.

You could build a Big Endien AROS for the x86 but that would be incompatible with the faster Little Endian one.

Besides if we use an integrated UAE we also get Hardware compatibility
>and improved stability so it's a benefit all round.

can you integrate UAE at the RAM level with little endian RAM?

if a 68k program accesses OS data structures ints and words at the byte level
or bytes at the word level the OS will get mangled

most programs wont do this so maybe you dont lose too much,

The Idea for the integrated UAE is so that the 68k and the x86 do not share Data structures. But instead allow the two system to synchronise their data. This will allow 68k programs to run in the same environment as the x86 programs. The only down side is that 68k programs will not be able to call x86 functions and vice versa. This could be possible, but probably not worth it. The UAE Emulator will be running a 68k version of AROS (specially designed to synchronise with the x86 version).

everyone says its not a big deal that Eyetech created the A1, I wondered whether they could prove this by doing their own one,

Anyone is able to sell Terrons. I could put a little sticker on it if you like and sell it to you.

people on all Amiga variants could then start generating AROS native progs,

Since AROS is source code compatible with AmigaOS, it is easy to write your program on your A1200 in C... and then take that source code to An AROS machine and recompile for whatever CPU that is running.

gcc has a cross compiler, there is no probelm generating code for any CPU from any CPU, providing you have the includes of course.

computer 3D always sucks because you can literally see the computer slow down
and wince whenever something computationally complex happens,

I've guess you've not used a new 3D card then. I have yet to write a program that causes my Radeon 9000 to slow down even with over 10000 objects (using the DX7 interface).

Amiga.org is closed source isnt it?

No. Both Amiga.org and Amigaworld.net use xoops which is a great example of opensource software. Aros-Exec.org also uses xoops.

Note that if a 68k version is also done then it reaches all platforms via UAE,
so its just the native compile that would be lacking,

:this is a good reason for having a fully implemented 68k AROS,

We need the 68k AROS for the integrated UAE Emulator idea. I also want to run AROS on my A1200. We do have a working 68k AROS, but it needs to be adapted to boot the Amgia Hardwre. At the moment it only boots the Palm PDA.

If AROS has fully integrated 68k compatibility you could use a
3rd party 68k TCP/IP stack until you have your own open source one written,

That would require a Big endien AROS, something that we have already decided is a bad idea on the x86.

AROS will not use a 3rd party TCP/IP stack. When AROS gets a TCP/IP stack it will be fully integrated and designed as part of AROS, rather than an add-on.

you may need to target some publicity at potential commercial developers
about AROS allowing closed source + commercial programs,


AROS publicity tends to tell us that AROS is an open source reimplementation
of OS3.1, the phrase "closed source" is never mentioned,

AROS is a word of mouth effort, there's no budget for promotion :-)

Well AROS is an Open source reimplementation of OS3.1 :-)

to this day I dont even know if closed source commercial binaries are allowed on Linux,

It depends. If you link to a GPL library or use any GPL code, then your software automatically becomes GPL.

If you link to an LGPL library then you program is not GPL or LGPL.

If you use any BSD code then that does does not cause your code to be BSD.

Simply check the licence of any software you are using to find out what you can and can't do.

AROS is covered by the APL, which is similar to LGPL. IF you use AROS source only the code that you use must remain Opensource. The rest of your program is yours.

Licence issues are very complex.

[bloodline]

Crumb wrote:
@Bloodline:

hi!
"An A.orger who wants inline 68k emulation in x86 AROS "

that's me! :-)

Bernd Meyer replied some of my posts in ANN, and he thinks that using the memory as I described (using the memory in reverse order for the 68k memory allocated areas like in the Mac emu Executor) may work to a certain degree but may cause problems like reversed screens etc... so a better approach should be found

Then have a go and get a test program up and running, and we can test it and see if we can work out any bugs.