here is an idea I have been thinking about for some time,


reading Fabio's comments in the OS4 vs MOS vs AROS thread it
sounds like this hasnt been done,


this idea will probably depress people of several other projects


but it could be a sound way to secure the Amiga's future,


step 1. Port AROS to 68k AGA!

why on earth do that?  :read on,

Let me explain, 2 projects bypass all known issues:

1. AROS: this bypasses accusations of stolen source because its
   open source. Hyperion by using AROS also give it their
   stamp of approval,

2. UAE: The A1 itself uses this, thus it is officially endorsed!

Now the problem with UAE is that it requires ROM ownership,
thus fantastic though it is: I have been told that WinUAE
gives disk speeds of 58Meg/second and it has truecolour etc,

it has the problem that its market cannot grow except through ROM piracy,
 at least not without Amiga co.'s approval,


And the problem with AROS according to Fabios comments is it cannot
run 68k binaries, that was never the projects intention,


So my way around all this is that if AROS is ported to 68k AGA,
that will then furnish an opensource Kickstart ROM for UAE!

I dont know much about UAE but it sounds like it emulates AGA custom chips
and 68k CPU but requires a 68k AGA OS ROM binary to be complete:
enter a very specific almost absurd port of AROS to provide
an opensource freely distributable reimplemented 68k AGA OS3.1 ROM binary,


This way 68k AROS AGA will create open source OS3.1 for all systems,
and the market can then grow, very fast because its for free,
and it will run on all known hardware: Mac, PC, Linux, Unix, A1, Pegasos,

and all existing 68k binaries will run on it,

who needs OS4 if you can do this?

68k AGA code can then be used as virtual machine code,
which means you can have closed source cross platform binaries:
so no need for Amiga DE which also tries this but appears to use
an undocumented binary format and requires a license fee or something,


this means that people can create closed source commercial programs,
IMO for a platform to take off you really need to be able to have
closed source commercial programs,


The Amiga co. can also make money by selling eg OS3.9 to run atop this,

AGA? Why AGA? This is hardware dependent and has no future.

AGA has had its day, and that day was some 10 years ago. Its only good for ye hardware banging 2D games of yore.

UAE has to devote considerable CPU resources to emulate AGA at full speed (which is tragic considering how slow that definition full speed is in modern terms), the *sole* benefit of which is running various aga based programs.

All serious amiga software of the last decade or so years has been RTG friendly.

Casting that aside, you have this notion of UAE as an "OS", running unhosted on your PC that gives transparent 680x0 emulation.

I'm afraid it's already been done. Amithlon was pretty much just that.

I could be wrong, but it still needs OS ROMs to work.

A replacememnt ROM for Amithlon (and a general update of the whole thing wouldnt hurt) based on open source code would pretty much do the job you are asking, AGA emulation aside.

As for how useful it would prove to be, I can't say.

by falemagn on 2004/4/4 16:12:33

Quote:



And the problem with AROS according to Fabios comments is it cannot run 68k binaries, that was never the projects intention,




No, wait, that's not what I said, I said that AROS' aim has never been
to run 68k binaries on other CPU's than 68k's, which is quite different...


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


seems I wasnt reading carefully enough,

whats the thinking behind this?

if AROS were to run a 68k binary such as SAS C 6.50 on an Intel machine,
what issue is it that you want to avoid?


Eyetech by using UAE endorse AmigaOS being run on any CPU provided an
official ROM is used,

Hyperion by using AROS code endorse open source reimplementations,

so combining these 2 endorsements we get that
UAE can be used on an open source reimplemented ROM?



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

@KennyR

AGA? Why AGA? This is hardware dependent and has no future.

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

really I meant the entire custom chipset, just for compatibility reasons,

interleaved bitmaps are a slow and obsolete concept,

new programs for a new OS shouldnt reference the chipset at all,
probably a good idea to read + write protect the chipset via MMU
for new programs to prevent the chipset being used,

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

@that_punk_guy


>Speculation on my part, since I'm no hardware/HAL guru, but no matter
>how fast you run the emulation,
>it's going to be held back by the architecture - addressing modes, registers, etc
> - that the emulated processor offers. And you can't change them, or you'n
>l break compatibility.

yes, but JIT emulation is pretty fast: Morphos people say theirs is 75% of
native speed,

really its only when you reach a slowdown of 400% that you should start worrying,

if you upgrade your computer to one which is 2 x as fast its quite a disappointment,
when its 8 x as fast then its impressive, IMO 4 x is the cut off point to be
impressed,


also you dont need that many registers, good compilers convert local variables
to registers on a many-to-many basis, you only need maybe 8 or even 4
general purpose registers,

in fact you could get very fast code without any registers due to the
fact that the currently executing functions stack slot will usually
entirely be in the cache, probably in the L1-cache,


the preoccupation with having lots of registers is a hangover from
the days when everyone coded in assembler,


also 3-address code eg "add d0,d1,d2"  (d2 = d0 + d1 ) is also
of dubious merit, Motorola 68k uses 2-address code "add d0,d1" (d1=d1 + d0),

in fact 1-address code "add d0" (accumulator = accumulator + d0) is probably
just as good,

probably even 0-address code "add" (pop pop add push) is also just as fast,

one problem with 3-address code is that you end up with huge instructions
(eg 1 instruction = 32 bits: twice as big as typical 68k instructions),
with 0-address code you could fit 8 instructions in that space,

anyway the point I am making is that 68k's 2-address code with 8 to 16
registers is probably just as good and twice as small as PPC's 3-address code
with 32 registers: most of those 32 registers will be asleep most of the time,

example:

x = y * z + t ;

in 3 address code:

lea y,d2
load 0(d2),d0
lea z,d2
load 0(d2),d1
mul d0,d1,d1
lea t,d2
load 0(d2),d0
add d0,d1,d1
lea x,d2
store d1,0(d2)

(RISC code is like wearing a strait-jacket),

1 address version:

load  y    ; to accumulator
move d0  ; from accumulator
load z   ; to accumulator
mul d0  ; accumulator = accumulator * d0
move d0
load t
add d0
store x

1 address code is actually much more in the spirit of the RISC concept,


Motorola 68k version:

move.l  z,d1
muls.l  y,d1
add.l   t,d1
move.l  d1,x

0 address code version:

push y
push z
mul
push t
add
pop x

:clean + simple,


the 1-address version certainly outdoes the 3-address version on all
counts: smaller + shorter + fewer instructions, fewer overall memory references,


the real gain of having eg 1-address code with eg 4 registers is
you end up with a huge reduction in chip circuitry
=> much smaller => much faster,


>Using AGA emulation in the way you describe is also... well, insane,
> quite frankly. Why toss the Amiga's established RTG system out of the window?

I agree, I'm not stopping you using the RTG system,
I am just thinking of the classic AGA machine as a bootstrap OS,

you can have all the modern stuff you want atop that bootstrap OS,
so eg you can and should have the RTG system,


doing everything via 68k means you eliminate the need for
open source + recompilation,

:it will save centuries of effort and eliminate truckloads of bloat!

open source always becomes very bloated

eg the general trend is for source code that exceeds 9meg compressed,
regardless of what it does, IMO a lot of it is
"tactical" bloat

manufacturing industry is totally closed source,

visit http://ftp.gnu.org/gnu to see what open source really looks like,

now visit http://www.aminet.net to see what closed source looks like,

which do you prefer?

I dont know about you but I only use open source stuff out of necessity,
I much prefer eg SAS C 650 to gcc, but some things can only be done via gcc,

gcc also has some really neat features eg it will convert c to assembler,

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

@Karlos

>UAE has to devote considerable CPU resources to emulate AGA at full speed
>(which is tragic considering how slow that definition full
>speed is in modern terms), the *sole* benefit of which is running
>various aga based programs.

but the AGA emulation will only happen if you make AGA calls,
so if you run a modern 68k program that makes no use of the custom chips
then that overhead vanishes,

>All serious amiga software of the last decade or so years has been RTG friendly.

I am not stopping you having RTG,

I am all for modern ways of doing things,

but whichever way you do it I think you need OS3.1 68k compatibility,
and you also want the market to grow. Probably also the Amiga OS has to
tear itself away from the central company and become a 3rd party OS,

all the really interesting developements have come from the 3rd party,

as far as I can see there is no disciplic continuity from the original
Amiga OS creators to Hyperion and they have delivered *nothing*,

ie I think they have no mandate


>Casting that aside, you have this notion of UAE as an "OS", running
>unhosted on your PC that gives transparent 680x0 emulation.
>
>I'm afraid it's already been done. Amithlon was pretty much just that.
>
>I could be wrong, but it still needs OS ROMs to work.

but Amithlon has been derailed by legal issues, also doesnt it need a
ROM to function?

I'm not against AROS reimplemented ROM to use with Amithlon,
same idea,
someone told me Amithlon itself makes use of UAE,

it would also be sensible to try and bring Amithlon to other CPUs such as PPC,


>A replacememnt ROM for Amithlon (and a general update of the whole thing
>wouldnt hurt) based on open source code would pretty much do the job
> you are asking, AGA emulation aside.

I am equally happy with this pathway, I dont know what is the issue
thats stopping Amithlon

>As for how useful it would prove to be, I can't say.

an emulator + a reimplemented ROM may be the only way for the
platform to continue,

IMO the only sensible path for OS4 would be to
use a 68k emulator + OS3.1 ROM binary for backwards compatibility,

you should be able to directly boot OS3.1 on an A1
after about 1 year since the OS4 project begun,

if reimplementing OS3.1 native is nowhere near complete after 1 year,
the project should be shelved and an emulated version worked on,

once a directly booting OS3.1 is available and for sale then
they can work on reimplementing it properly,

but you need to have some product out there and on the shelves,
and on peoples desks,


OS4 shouldnt even be thought about till OS3.1 is complete and
 for sale: either emulated or "ported",


people complain about H & P but at least they delivered OS3.9
which I use every day,


Hyperion havent delivered anything at all,

they know how to grab the OS contract and never ever let go
but not how to deliver the product, not even a bad product,

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

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

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

Karlos wrote:
Casting that aside, you have this notion of UAE as an "OS", running unhosted on your PC that gives transparent 680x0 emulation.

I'm afraid it's already been done. Amithlon was pretty much just that.

I could be wrong, but it still needs OS ROMs to work.

A replacememnt ROM for Amithlon (and a general update of the whole thing wouldnt hurt) based on open source code would pretty much do the job you are asking, AGA emulation aside.

As for how useful it would prove to be, I can't say.

I think that's exactly what he was asking:) (As I read it).

Amithlon doesn't already do this, since it also requires the official AmigaOS, but by making use of a 68k AROS, UAE (and Amithlon if one so wished) could replace the ROM (and possibly the entire OS) with a free open source version.

Talking of which - would it be possible to have a ROM based on AROS, with the original AmigaOS running on it? I don't know much about AROS, so I've no idea what level of compatibility there is..

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

@bloodline

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

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?

is there a cross compiler eg gcc or a cross assembler available
for doing this or do you have to create this first?

I suppose you could go through A1's Linux, but that is cheating,
also cheating would be to borrow Hyperions A1-gcc,

how did the Linux people get Linux on the A1?

A similar problem is creating a game that directly boots up on the A1
bypassing the OS and hitting the hardware directly perhaps through the
UBoot,


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

you then inserted a kickstart disk which loads the ROM to RAM,
and then you booted up with a workbench: floppy,

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

it may be more trouble than its worth,


the only neat way I can see to integrate AROS with 68k compatibility is
my initial posting,

that way you completely remove the recompile factor:

both for you: just compile a reimplemented ROM once,
and for programmers: just compile a standard 68k binary just once,

same ROM + same programs then run on all platforms,

and all of www.aminet and geekgadgets and all commercial programs
eg SAS C 650 become available,

once OS3.1 is fully and totally reimplemented you can then
move forwards from this point using emulated 68k but in a
carefully thought through retargettable manner,

ie you would drive arbitrary h/w but through 68k as a virtual CPU,

so eg dos.library can be replaced by newdos.library,

Berndt said in some forum that one problem with dos.library is that
a program can do the following:

f()
{
char x[100] ;
BPTR fh ;

sprintf( x , "filename" ) ;
fh = Open( x , MODE_READWRITE ) ;
.........
}

x is a pointer to a string on the stack, however x can get passed to
another task by Open(), namely one of those filesystem tasks you see
when you run Sysinfo,

this causes a problem that it makes it tricky to have "infinite" stacks,

a popular concept is for all stacks to start at top of memory and grow downwards
via the MMU. This means that the stack is not public memory, ie it cannot
be accessed by other tasks,

dos.library needs to be redesigned so that memory supplied by a task
never gets transmitted to another task,

OS tasks should only receive memory allocated by the OS,
user tasks should be forbidden from allocating OS data structures,
:forbidden by careful API design which makes it impossible,


with exec its quite ok for a program to allocate a struct Semaphore
in fact thats the only way to do it: exec does *not* allocate struct Semaphores
for you,

the user even has to supply the name string which isnt copied by the OS
(see comment in second code fragment on p511 of RKM Libraries 3rd edition),

and these are OS data structures, intuitions API wisely prevents the user
allocating struct Window's,

now if the program does AllocVec( sizeof(struct Semaphore),MEMF_PUBLIC | MEMF_CLEAR);
thats fine,

really it should be the other way round: the only way to create an
OS struct Semaphore should be via some API call eg

struct Semaphore *OpenSemaphore( char *name ) ;

with the OS copying "name" to a properly allocated string and not trusting
the user supplied string
exec's AddSemaphore() shouldnt exist, or at least it should be an internal
private exec call,


these are design subtleties but IMO all the amiga libraries should be
gone through with this subtlety fixed,

OS3.1 has to be reimplemented AS-IS as specified in the RKMs because of
the continuity factor: programmers can then recompile all their programs
to AROS unchanged. via the 68k AGA AROS idea even assembler routines
can remain unchanged in fact recompiling is unecessary just reuse the
existing binary!

However once OS3.1 is reimplemented new improved versions of all the
libraries should be done to run in parallel to the original versions,

another problem to fix with newdos.library is to remove the restriction
on filename length, just replace the inbuilt array by a pointer,
similarly arbitrary length shell command lines should be done,

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

@IonDeluxe

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.

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

there is a blurred line between kickstart and AmigaOS,

apart from the bootstrapping I think most of the kickstart ROM
is just AmigaOS libraries,

if you have reimplemented AmigaOS you may be able to bootstrap
from this:

create by hand the initial minimal interlinked OS datastructures,

so they are self consistent and meaningful,
including execs jump vectors,

create an initial tasks data structures as if it were about
to execute its first instruction,
correctly linked into struct ExecBase,

all interrupt handlers in place,

:kind of AmigaOS in suspended animation,

you need to have total mastery and understanding of your reimplementation to do this,

enable interrupts and now jump
to the first instruction of that task: the breath of life,

that tasks program could be to open dos.library and intuition.library

(DOSBase = OpenLibrary( "dos.library", 0 ) ; etc in machine code)

and then using dos.library it would execute s:startup-sequence,
dos has an API call for executing script files:
SystemTagList( d1 = "s:startup-sequence" , d2 = empty taglist ) ;


dos.library needs to be up and running before you can even think
about s:startup-sequence,


I'm just second guessing here and there's probably many different
ways to do it, bootstrapping is a tricky nightmare!

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.