Quote:

I would help, and I did offer to donate towards getting AROS a board.

I assume you already have an A1 board... Is the A1 running Linux? if you are a developer, why not download the AROS CVS and try and compile it

@bloodline

Yes I already have a board, however your stated need
was for a board and I merely tried to satisfy that

AROS on LinuxPPC ? Way ahead of you

Dave.

Quote:

Yes I already have a board, however your stated need was for a board and I merely tried to satisfy that AROS on LinuxPPC ? Way ahead of you

As much as I (or any of the AROS team) would love an A1 board, The expertise to develop for it would be far greater an asset.

AROS on LinuxPPC...

Join the AROS dev mailing list and some of the others working on LinuxPPC will be able to work with you.

Once the LinuxPPC hosted version of AROS is working fine, then we can see about letting AROS boot itself

Quote:

What is the next step ? gdb & The Grim Reaper

When using AROS hosted under LInux you probably already have something even better then this Grim Reaper thingy. Because you can run whole AROS with Linux gdb and then the whole OS is under control of the debugger, not just single AROS apps. You can have breakpoints in OS functions. And on a crash (which of course just crashes the Linux app "AROS" not the whole computer. You can "reboot" in 1 to 2 seconds) a gdb backtrace can give you informations like this:

#0 0x405c78ab in mNL_Set (cl=0x404d3d28, obj=0x405bd880, msg=0x405bc7ec)
at NList_mcc1.c:657
#1 0x405bd9d8 in ?? ()
#2 0x405c49a4 in _Dispatcher (cl=0x404d3d28, obj=0x405bd880, msg=0x405bc7ec)
at NList_mcc0.c:471
#3 0x404ee89a in metaDispatcher (cl=0x404d3d28, obj=0x405bd880, msg=0x405bc7ec)
at support.c:164
#4 0x08052a43 in DoMethodA (obj=0x405bd880, message=0x405bc7ec) at domethod.c:66
#5 0x40059dda in Intuition_SetAttrsA (object=0x405bd880, tagList=0x405bc834,
IntuitionBase=0x403653ac) at setattrsa.c:72
#6 0x405663ef in SetAttrs (object=0x405bd880, tag1=1) at setattrs.c:68
#7 0x405398d7 in mNotifySet (cl=0x404a5b38, obj=0x405bd880, msg=0x40609a7c)
at classes/notify.c:535
#8 0x40539edc in MyDispatcher (cl=0x404a5b38, obj=0x405bd880, msg=0x40609a7c)
at classes/notify.c:675
#9 0x404ee89a in metaDispatcher (cl=0x404a5b38, obj=0x405bd880, msg=0x40609a7c)
at support.c:164
#10 0x4050b3a5 in Area_Dispatcher (cl=0x404e5d28, obj=0x405bd880, msg=0x40609a7c)
at classes/area.c:1805
#11 0x404ee89a in metaDispatcher (cl=0x404e5d28, obj=0x405bd880, msg=0x40609a7c)
at support.c:164
#12 0x405244b5 in Group_Dispatcher (cl=0x404e64b8, obj=0x405bd880, msg=0x40609a7c)
at classes/group.c:2160
#13 0x404ee89a in metaDispatcher (cl=0x404e64b8, obj=0x405bd880, msg=0x40609a7c)
at support.c:164
---Type to continue, or q to quit---
#14 0x405f7e45 in DoSuperMethodA (cl=0x404d3d28, obj=0x405bd880, message=0x40609a7c)
at dosupermethod.c:61
#15 0x405c547c in _Dispatcher (cl=0x404d3d28, obj=0x405bd880, msg=0x40609a7c)
at NList_mcc0.c:556
#16 0x404ee89a in metaDispatcher (cl=0x404d3d28, obj=0x405bd880, msg=0x40609a7c)
at support.c:164
#17 0x40538fd1 in check_notify (nnode=0x40609a0c, obj=0x40604760, tag=0x405bccf4)
at classes/notify.c:247
#18 0x4053915c in mSet (cl=0x404a5b38, obj=0x40604760, msg=0x405bccac)
at classes/notify.c:309
#19 0x40539d7c in MyDispatcher (cl=0x404a5b38, obj=0x40604760, msg=0x405bccac)
at classes/notify.c:651
#20 0x404ee89a in metaDispatcher (cl=0x404a5b38, obj=0x40604760, msg=0x405bccac)
at support.c:164
#21 0x40504895 in Area_Set (cl=0x404e5d28, obj=0x40604760, msg=0x405bccac)
at classes/area.c:583
#22 0x4050aebf in Area_Dispatcher (cl=0x404e5d28, obj=0x40604760, msg=0x405bccac)
at classes/area.c:1772
#23 0x404ee89a in metaDispatcher (cl=0x404e5d28, obj=0x40604760, msg=0x405bccac)
at support.c:164
#24 0x40552de5 in Text_Set (cl=0x404e5da8, obj=0x40604760, msg=0x405bccac)
at classes/text.c:242
#25 0x4055653e in Text_Dispatcher (cl=0x404e5da8, obj=0x40604760, msg=0x405bccac)
at classes/text.c:984
#26 0x404ee89a in metaDispatcher (cl=0x404e5da8, obj=0x40604760, msg=0x405bccac)
---Type to continue, or q to quit---
at support.c:164
#27 0x08052a43 in DoMethodA (obj=0x40604760, message=0x405bccac) at domethod.c:66
#28 0x40059dda in Intuition_SetAttrsA (object=0x40604760, tagList=0x405bccf4,
IntuitionBase=0x403653ac) at setattrsa.c:72
#29 0x405663ef in SetAttrs (object=0x40604760, tag1=2151822645) at setattrs.c:68
#30 0x4050786a in handle_release (cl=0x404e5d28, obj=0x40604760, cancel=0)
at classes/area.c:1334
#31 0x40508146 in event_button (cl=0x404e5d28, obj=0x40604760, imsg=0x4061aa88)
at classes/area.c:1381
#32 0x4050980f in Area_HandleEvent (cl=0x404e5d28, obj=0x40604760, msg=0x405bcea0)
at classes/area.c:1514
#33 0x4050b08c in Area_Dispatcher (cl=0x404e5d28, obj=0x40604760, msg=0x405bcea0)
at classes/area.c:1787
#34 0x404ee89a in metaDispatcher (cl=0x404e5d28, obj=0x40604760, msg=0x405bcea0)
at support.c:164
#35 0x4055b6c8 in invoke_event_handler (ehn=0x406047c8, event=0x4061aa88,
muikey=4294967295) at classes/window.c:943
#36 0x4055bd5f in handle_event (win=0x406072a0, event=0x4061aa88) at classes/window.c:1084
#37 0x4055b18d in _zune_window_message (imsg=0x4061aa88) at classes/window.c:889
#38 0x4050120a in Application_NewInput (cl=0x404e5bb8, obj=0x406074d0, msg=0x405bd174)
at classes/application.c:661
#39 0x4050223c in Application_Dispatcher (cl=0x404e5bb8, obj=0x406074d0, msg=0x405bd174)
at classes/application.c:887
#40 0x404ee89a in metaDispatcher (cl=0x404e5bb8, obj=0x406074d0, msg=0x405bd174)
at support.c:164
---Type to continue, or q to quit---
#41 0x404d6c63 in DoMethod (obj=0x406074d0, MethodID=2151824294) at domethod.c:82
#42 0x404d567f in main (argc=1, argv=0x403d8c28) at NList-Demo.c:735
#43 0x404d3f54 in __startup_entry (argstr=0x403d890c " \n", argsize=2, sysbase=0x4030e24c)
at startup.c:102
#44 0x4009bdd1 in Dos_RunProcess (proc=0x403c8c90, sss=0x4039cbf0,
argptr=0x403d890c " \n", argsize=2, entry=0x404d3e18 <__startup_entry+4>,
DOSBase=0x4037d0c0) at runprocess.c:125
#45 0x400ad865 in Dos_RunCommand (segList=0x404d3e14, stacksize=40960,
argptr=0x403d890c " \n", argsize=2, DOSBase=0x4037d0c0) at runcommand.c:111
#46 0x403cb5f6 in executeLine (command=0x403d82ce "Demos/NList-Demo",
commandArgs=0x403d890c " \n", rd=0x4039ccf0) at Shell.c:1192
#47 0x403ca388 in checkLine (rd=0x4039ccf0, cl=0x4039cd14) at Shell.c:607
#48 0x403c9ee9 in interact () at Shell.c:475
#49 0x403c9d0b in Shell_main (__shargs=0x4039cdc8, __argstr=0x403bbd94 "",
SysBase=0x4030e24c, DOSBase=0x4037d0c0) at Shell.c:416
#50 0x403c9b29 in entry (argstr=0x403bbd94 "", argsize=1, sysBase=0x4030e24c)
at Shell.c:379
#51 0x4009bdd1 in Dos_RunProcess (proc=0x403c8c90, sss=0x403d62f0, argptr=0x403bbd94 "",
argsize=1, entry=0x403c99a0 , DOSBase=0x4037d0c0) at runprocess.c:125
#52 0x400ad865 in Dos_RunCommand (segList=0x403c999c, stacksize=40960,
argptr=0x403bbd94 "", argsize=1, DOSBase=0x4037d0c0) at runcommand.c:111
#53 0x4009c959 in NewCliProc (argstr=0x403bbd94 "", argsize=1, SysBase=0x4030e24c)
at newcliproc.c:87
#54 0x400a1c5b in DosEntry (argPtr=0x403bbd94 "", argSize=1, initialPC=0x4009c6d0,
SysBase=0x4030e24c) at addprocess.c:23


As can be seen there's "stuff" displayed from Shell (where the application was started from), from libraries used by the application (muimaster.library), from OS Routines (DoMethodA()) called by the application and/or libraries the application uses, etc, etc.

And debug output which in a native/non-hosted OS goes to slow serial port, in AROS hosted simply appears as output in Linux shell which is very fast and usually does not cause any real slowdown to AROS itself.

@Fabio:
good job!

@Bloodline:
"We don't really need Snap, as we can use VESA2.0 (The PPC can't use VESA2.0 AFAIK)... "

You could use VESA with the right drivers. Both AmigaOne and Pegasos include a x86 emu so the card can be initialized.

Don't take it as a offense, but VESA is quite slow compared to native drivers...

Anyway VESA is a good way to have basic support for many cards. BTW SNAP supports all the chipsets using native code, so a cheap card with snap will be faster than a high-end one with vesa.

_________________
The only spanish amiga news web page/club: CUAZ

Quote:

(Lite aren't until late 2004).

Wrong. They'll be available much sooner.

If you are refering to the "later in 2004" thing, that was the Micro ATX. Don't confuse that with Mini ITX. MiniITX = AmigaOneLite. MicroATX == Same form factor as Pegasos.

Quote:

Add SciTech's SNAP technology

You are aware of the fact that SNAP is licensed technology ? Licensed, like in "Give us money, get a license" ? The key phrase is "money".

Quote:

And you'll get more Amigans then what Genesi and Amiga Inc will ever get.

Ah, the same old (stupid!) discussion of x86 vs PPC. Can we please, once and for all, drop this rather stupid, nonsensical discussion ? This thread was about "AROS now has a native gcc C/C++ compiler", not "x86 vs PPC". We all had our share of throwing arguments around (yes, me too), and in the end, we all agreed that nobody can predict the future, thus the discussion is completely senseless.


On topic:
Congratulations to Fabio, we know how hard it is to get gcc to work on AmigaOS, we had to go through the same for OS4.

_________________
Thomas, the kernel guy

"I don't have a frigging clue. I'm norwegian" -- Ole-Egil

All opinions expressed are my own and do not necessarily represent those of Hyperion Entertainment

Quote:

this Grim Reaper thingy

This "Grim Reaper thingy" is only the replacement for the old crash requester. If you press "connect to debugger", it will get you into gdb as well.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

Quote:

@Bloodline: "We don't really need Snap, as we can use VESA2.0 (The PPC can't use VESA2.0 AFAIK)... " You could use VESA with the right drivers. Both AmigaOne and Pegasos include a x86 emu so the card can be initialized. Don't take it as a offense, but VESA is quite slow compared to native drivers... Anyway VESA is a good way to have basic support for many cards. BTW SNAP supports all the chipsets using native code, so a cheap card with snap will be faster than a high-end one with vesa.

Well AFAIK it is the SNAP driver that provides the x86 emulation init on the Graphics cards. So that is why SNAP is really good on the PPC platform.

But For AROS x86 it offers no real advantages over VESA2.0

Of course accelerated, native drivers would be the best, and we would hope to get them some day...

But, and you can correct me here, SNAP does not offer gfx accelleration or at least no more than VESA3.0

-Edit- oh yeah and SNAP costs money, which has no context in a Free OS... I suppose you get what you pay for

Quote:

Edit- oh yeah and SNAP costs money, which has no context in a Free OS... I suppose you get what you pay for

Hmm ... not sure:

http://www.scitechsoft.com/licenses/license_home.html
http://www.scitechsoft.com/licenses/faq_lgpl_questions.html

Quote:

This "Grim Reaper thingy" is only the replacement for the old crash requester. If you press "connect to debugger", it will get you into gdb as well.

And can you then do post-mortem analysis? Within linux you can do that on the AROS core file.

_________________
“It is well enough that people of the nation do not understand our banking and monetary
system, for if they did, I believe there would be a revolution before tomorrow morning.”
~~ Henry Ford

Quote:

You are aware of the fact that SNAP is licensed technology ? Licensed, like in "Give us money, get a license" ? The key phrase is "money".

Actually, it's also licensed as in "licensed under the LGPL terms". The open source available drivers, though, last I checked were only the VESA and VGA drivers, which we already have. When more open source drivers are available (if they ever will), then I'm sure we'll have a look at it.

_________________
“It is well enough that people of the nation do not understand our banking and monetary
system, for if they did, I believe there would be a revolution before tomorrow morning.”
~~ Henry Ford

Quote:

And can you then do post-mortem analysis? Within linux you can do that on the AROS core file.

I don't see the connection. I didn't say anything about post-mortem analysis, I just commented that Grim Reaper can get you into gdb as well.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

Quote:

The open source available drivers

You mean as in "drivers whose source is included/available"?

Or as in "drivers available for an open source
licensed SNAP"?

Isn't the point of SNAP that you use binary drivers,
ie. don't need any source code access to the drivers
itself.

Quote:

I don't see the connection. I didn't say anything about post-mortem analysis, I just commented that Grim Reaper can get you into gdb as well.

I just asked a question, and was hoping in a simple answer. The connection, if you want to find any, is just that we were talking about debugging facilities and gdb. You do post mortem analysis with gdb, under linux, and since you mentioned the debugger, which is gdb, there is your connection.

But if you don't want to answer, it's ok.

_________________
“It is well enough that people of the nation do not understand our banking and monetary
system, for if they did, I believe there would be a revolution before tomorrow morning.”
~~ Henry Ford

Quote:

You mean as in "drivers whose source is included/available"?

I meant that, yes.

Quote:

Or as in "drivers available for an open source licensed SNAP"?

But that is also relevant. I think - I'm not sure - you can use the commercial drivers with the open source framework, but the problem is that you cannot ship those drivers with the OS unless you acquire a license. You agree that we can't afford a license, right?

_________________
“It is well enough that people of the nation do not understand our banking and monetary
system, for if they did, I believe there would be a revolution before tomorrow morning.”
~~ Henry Ford

But who (users/OS coders) would ever want a SNAP which only supports VGA/VESA. That doesn't make sense to me. Why make available SNAP both with a commercial and different open source license if the open source license is completely useless (if it really only allows to use VGA/VESA) .

Quote:

I just asked a question, and was hoping in a simple answer.

I mistook it for a rhethorical question, since you seemed to give the answer yourself.

Quote:

But if you don't want to answer, it's ok.

Like I said, I wasn't aware that you where actually asking a question. To answer it, AmigaOS doesn't write core files. You usually would connect the debugger to the recently crashed process. A crashed task is frozen as long as the no one has removed it (which would be Grim Reaper if you press "Kill"), so all its resources are still there and can be examined in the debugger.

It could be possible to write a core file, since there is memory ownership information available for all resources that are allocated under a task's control (i.e. as long as it wasn't another task that did allocate it).

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

Quote:

Well AFAIK it is the SNAP driver that provides the x86 emulation init on the Graphics cards. So that is why SNAP is really good on the PPC platform.

Are we talking about the same SNAP here? x86 emulation init is performed by the Scitech X86 emulator, which is already integrated into U-Boot. Yes, it can run VESA, but it doesn't need SNAP for that.

SNAP *does* offer accelerated, native drivers.

Quote:

But, and you can correct me here, SNAP does not offer gfx accelleration or at least no more than VESA3.0

Oh yes, it does. See here

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

@Georg

You bring up a good point. I don't think they are giving away the specifics source code of the video drivers on their perforce server.

So basically, SNAP is useless for this project.