68k AGA AROS + UAE => winner!

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

[that_punk_guy]

whoosh777 wrote:
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!

And at that point your code no longer runs natively even on the lowest common denominator machine: the 68k Amiga.

:-?

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

[Karlos]

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

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

[Karlos]

The register indexed scale mode (d8, aN, xN.w|.l * scale) is incredibly handy and is still fast.

Imagine an array of 32-bit integers, pointed to by a0, and a 16-bit index in d0, you want to move that entry to say d1

move.l (a0, d0.w*4), d1

It's much faster than any pointer arithmetic you can do by manually calculating the address and doesnt trash any registers.

How handy is that?

[whoosh777]

by bloodline on 2004/4/7 9:54:16


--------------------------------------
my questions were:

Quote:



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?

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

your answer to this is very interesting, it explains several things
I was wondering about,

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

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

And now can UAE be run just like that on this AROS?

I may go down this path then,

sorry if some of these questions sound ignorant, but I only know in depth
about 68k Amiga,

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

are you referring to booting AROS from UBoot??

So are UBoot and Openfirmware the only contenders or are there others?

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

this answers several questions,

now can the MMU be used instead of ROM flashing? ie can UBoot eg remap the
ROM address space to RAM and then copy Openfirmware there and then
metamorphose into Openfirmware or is it more complicated?

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

I have to look into this, I feel scared to even look though,
there is something daunting about this, I am afraid to click the link even,
I will click that link, just give me some time!


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,

[whoosh777]

by that_punk_guy on 2004/4/7 10:12:07
----------------------------------------------
Quote:


whoosh777 wrote:
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!

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


>And at that point your code no longer runs natively even on the
>lowest common denominator machine: the 68k Amiga.

the 68k architecture anticipates this though:

if you tried executing eg 1010000000000000

which was say at memory location $123400

you would get a "Line 1010 Emulator" exception specifically for
this situation,

I havent done this myself but what I think happens is the
CPU jumps to the trap vector for this exception stored at address $028,
the CPU is in Supervisor mode,

the supervisor stack is in a7 which points indirectly to
the instruction thus:

movea.l 2(a7),a0  ; will move $123400 to a0 (I think),

movea.w (a0),a1 ; will move 1010000000000000 into a1,

which you can now emulate via a subroutine,
my_emulator( a0 = instruction address , a1 = first 16 bits of instruction )

if the extended instructions are thoughtfully designed this emulation
could be ultra fast eg a few machine code instructions,

ie you can patch the 68k CPU to understand the extended instruction set,

[whoosh777]

@bloodline

>Note that the x86 instruction set is more RISC like than the 68k,

how many registers?

0 , 1 , 2 or 3 address code? (max no. of CPU registers per instruction)

can you give some simple examples of x86 assembler?

eg how would you do x = y * z + t   where x,y,z,t are all in memory


how does it do floating point maths?

[BigBenAussie]

You know what I think would be a winner. And I know this is flame bait.

AROS should sit on top of Linux and be able to utilise Linux apps. Sun has just released its Java Desktop System(JDS) which has its StarOffice suite and sits on top of Linux. Its on the cover of a few mags at the moment and it appears to me that it is being hailed merely for being a different distribution and looking like windows.

AROS could get some quick publicity if it offered its own distribution perhaps with some converted Amiga utils or existing Apps running through UAE. At the very least, sitting on top of linux it could call up some of the standard Linux apps and call itself a distribution. It could run Linux based browsers and openoffice. And it should run off the CD like JDS does. You could also include some of the decent free Amiga games and apps on the CD. And you would need a very decent startup theme.

Ok...There's a problem, most likely in that it doesn't support the same GUI library. Doah...

But still, if it could be done, you get points on the board and some interest that could perhaps be diverted into more people being interested in developing AROS further. You could include your linux based development environment on the CD too and see if some Linux people want to go to the trouble of converting some apps to native Amiga.

There I said it.
I know it sounds like prostituting AROS but it might take it to the next level. And you could still work on your native version.

[whoosh777]

>if you tried executing eg 1010000000000000

>which was say at memory location $123400

>you would get a "Line 1010 Emulator" exception specifically for
>this situation,

>I havent done this myself but what I think happens is the
>CPU jumps to the trap vector for this exception stored at address $028,
>the CPU is in Supervisor mode,

if you want to see the default trap handler for the above exception
in action on your system,
download this binary: http://www.whoosh777.pwp.blueyonder.co.uk/crash1010

it is the program:

THE ORIGINAL VERSION OF THIS WAS WRONG AND DIDNT CRASH CORRECTLY!
SO I HAVE EDITTED THIS POSTING WITH A DEBUGGED VERSION THAT CRASHES CORRECTLY!


unsigned int x ;

void (*y)(void);

int main( int argc , char **argv )
{
x = 0xa0000000 ;
y = (void (*)(void))&x ;

y() ;
return( 0 ) ;
}

I got a crash requester:

crash1010
Program failed (error #8000000A).
Wait for disk activity to finish.

Suspend                    Reboot

exec/alerts.h says that 8000000A is "Line 1010 Emulator error":

#define ACPU_Trace      0x80000009      /* Trace error */
#define ACPU_LineA      0x8000000A      /* Line 1010 Emulator error */
#define ACPU_LineF      0x8000000B      /* Line 1111 Emulator error */
#define ACPU_Format     0x8000000E      /* Stack frame format error */


"Line 1111" is the exception you get if you run a FPU instruction without an
FPU present,

:in theory someone could write an FPU emulator for 68k CPUs lacking FPUs,
(all FPU instructions begin with the binary digits 1111),
that way you could run FPU binaries on non FPU machines,

[whoosh777]

this is embarrassing, but several hours after uploading
crash1010 I was reading a comic about a guy flying an
aeroplane into the future when I suddenly realised
the bug in crash1010, thats why it wasnt crashing correctly!

I've fixed the bug and editted that post with the correct
version that causes the 1010 line emulator trap handler
crash requester,

it now crashes correctly with no. #8000000A,

and I blamed AmigaOS!

anyway I can laugh now,

BTW how do you get the smileys into postings,
I cannot see how to do it, I tried clicking on them
but it doesnt seem to have any effect?

[Hammer]

how many registers?

AMD64(X86-64) exposes 16 GPRs 64bit registers, while Pentium IV** (with hyper-treading) has 8 + 8 GPRs configuration.

how does it do floating point maths?

About X86-64/AMD64
"Instruction set is designed to offer all advantages of CISC and RISC.
- Code Density of CISC
- Register usage and ABI models of RISC"

Reference document