What follows is my own opinion, right or wrong.

Some have spoken of updating AHI to do lots of cool modern things.
The more we update AHI, the less compatible it is.

AHI as it is now has a strength that will be hard to beat: It is the accepted standard across all Amiga-inspired platforms. and that is exactly what would serve the community best.

In my opinion, any "new" software would have to run beside AHI without causing trouble. I have considered a couple different things, but then I have FAR more projects than I have time to implement them.

This is not to say that AHI can't have a few features added.. but if it risks compatibility then I think it's probably not worth it.

I have a short list of things that would be very useful to add, but I have one thing preventing me from even trying.. I do all my programming on a native AmigaOS machine, and I have never been able to get any AHI code to compile here.
I will admit freely that I am no compiler guru, and the complexities of writing code that is cross-compatible on many different OSs is not easy to do.. But having said that, if I could compile the AHI sources from OS4 then there would be a very high likelihood that I could add a few of the features that I have been thinking about.
I have even implemented some of these with excessive use of SetFunction(), but I think that's a poor way to try and improve things.

So there's my real request:
If someone knows enough about configuring my compiler to build the AHI sources, or better yet configure the sources to compile in a "standard" AmigaOS dev kit, please contact me here or offlist.

:)

@tonyw

"I can't get Odyssey to save its settings without crashing. So whenever I try to use it, I have to change fonts, window size, screen, all over again."

Odyssey has settings?? :)
I guess I'm just way too basic for all that fancy stuff.

In 99% of the cases I run programs the way it installed.
If I can't trust the programmer to choose the best defaults, then who CAN I trust?

:) :)

@kilaueabart

A couple times I have had it run out of RAM after some exrended browsing. I get a very detailed requester saying that it can not cope with a failed allocation and it must close.. (X1000 with 2 of the 4 gig available to AmigaOS)

And just this evening I got a DSI when a facebook chat window played a short audio clip.. I noticed it was the "Odyssey Audio Player" or something like that.

And maybe I'm just old and paranoid, but I never ignore these things. If it is having troubles of any sort I will reset the machine before proceeding. But that's just me. :)

@ddni

ddni said:
"With regards to moving in the direction of being able to help. I am a user and accepted long ago that my ability to code will never get beyond BASIC."

I am sorry if that sounded rude.
I know we are not all developers, for whatever reason.

I _am_ guilty of saying "Go download a compiler", but I usually reserve that for people who tell me "I can't write any code, My contribution is to tell the programmers what they should be doing.".. as far as I know that's not you.

What I should have said, if I were taking more time as I should have.. We all care a LOT about AmigaOS.. Many of us wish something or other was different. We can focus that desire in either direction.. either promoting positive things, or complaining about the things we don't like.

I'll make a few examples, hopefully without pissing anyone off.
Have you heard of Epsilon? As far as I know, he's not a programmer. And I believe it's safe to say he is an "enthusiastic member of the community".. I don't know how much time he spends putting his blogs together, but there is little doubt that he is promoting the entire community in a positive way.
In truth I have never met him. I am making guesses based purely on what he adds to "us", the Amiga community. We are damn lucky to have him.
There are other ways to help as well. Any time a programmer is working on something that will not be part of the OS, he needs to find his own Beta testers. I put together a short list of folks that play with MIDI gear when I was working on CAMD things.. they were all really helpful.
Another example.. Many programmers write great code, but are loathe to document anything. If there is a program you are familiar with that has sucky or no documents, ask the author if you can write some. If there's no place to keep those documents, ask Steve if you can keep them on the Doc Wiki. He just might grant you editing rights.

Maybe my whole point is poorly made. I am not really trying to push anyone into servitude.. I was really just pointing out that the actions we each take can promote the greater good, or not. If you're going to expend lots of energy, you might want to check which direction you're pointing towards at the time. That's all I am saying.

I never intended this to become a soapbox speech, and it's NOT aimed at anyone in particular. I have no axe to grind with anyone posting in this thread... I'm just talking too much.


:)

Hoping I pulled my foot out of my mouth instead of sticking it in deeper,
LyleHaze

@ddni

I'll risk a comment of my own here, uninvited and unprovoked:

Many would like to hear more regular news about project development. We must be a passionate group to have survived this long.

But there is a flip side. If a project is announced, and any sort of delay comes along, there is a long line of people who would jump at the chance to scream and moan and prophesize the end of the world.

For myself, as a developer, I would NEVER release ANY information about someone elses project. This is a very sensitive subject for many, and the events that have brought it on are too numerous to list.

If there is a project that _I_ am working on at the request of someone else, I STILL make no public announcements, unless first getting explicit permission from whoever I am coding for.

Neither of the above are actual "rules" told me by anyone else, but they seem perfectly reasonable and sane given the way things work.

Finally, on projects I am doing just for my self, I might, MIGHT make an early announcement if I feel like it. But I am still quite careful about that anyway. Why? It's all posted above.

I currently have at least a half-dozen "open" projects in some state between started and finished. Some I have discussed openly, some only with one or two trusted friends. Actually, a dozen might be a closer count.

Some will certainly be finished, some may never be. Even if I wanted to I could not predict a hard release date for any of them. It's not unusual for a project to be 97% complete and stumble on some detail that prevents it from being released.. Maybe for a few weeks, maybe to be shelved until some later date.

All dates after "today" are speculation. Pure guesses.
As long as a fair percentage of the community continues to complain about "broken promises".. No, wait, let me be more clear:

As long as developers still remember being the subject of complaints about "broken promises and missed deadlines", you can expect most of them to release little or no information until they are damn good and ready to. And if that is not an option they might well stop developing entirely.

This entire post is my opinion only. it is not the opinion of Steve, it is not sanctioned by Hyperion, it is not the position of A_EON, it's all purely Lyle Hazelwood, May 15 2014.

If I have offended anyone, ask yourself what you can do to improve the situation and then move in that direction.

Now I'll go back to one of my super-secret, highly classified, AmigaOS projects.

Thanks all for the help.
I never thought to download pthreads.lha to get threads.library, especially since I already had a pthreads.library installed.

The new MPlayer runs now with a much lower CPU load than the previous version. Good Job!

Sorry about the library troubles, I just couldn't figure out why I was the only one without it.

:)

@broadblues

I checked twice.. even checked snoopy to make sure it was not a mis-spelled error message.

I don't have a threads.library, and I don't know where to find one.
Apparently the rest of the people here have it already.

Ah well.. Progress is good. And if I don't get it working here it's really all the same, I have too much work to do, really no time to go off playing videos and such.

:)

Please pardon if it's already listed here.. 22 pages is a lot of posts to catch up on.

I have installed
MPlayer for AmigaOS4 SVN-rSVN-r32634-4.2.4

on a Nemo X1000

And any attempt to run it gets only:
Can't open threads.library

There is no reference to threads.library in the documentation, on OS4Depot, or at Aminet.

Thanks!

@eliyahu

After spending 20 minutes writing and then deleting my own thoughts about this project, I will simply say that your comments regarding this are, in my opinion, generous beyond compare.

:)

@kilaueabart

amigaboot.of is the first step in loading up AmigaOS. CFE must be able to load amigaboot.of from somewhere it can read. The common way is to have the first partition on your hard drive as a very small FFS partition, and to load amigaboot.of from there. (CFE can read FFS!) In truth it can be on ANY device that CFE can read from, including the compact flash card.

@Atheist

I am one of the few that never tried to accellerate my X1000 startup, but there are a few tricks that can help. I don't think putting amigaboot.of on a compact flash would make much of a difference, as the file is barely 50K in size.

Depending on how your system is set up, there may be one or two separate menus to select your boot device from. the fewer the menus, and the faster the menus time out, the quicker your boot time will be.

Another method is to adjust the CPU clock as part of your startup.. without adjustment it will start at a very conservative(slow) rate, and will speed up later after the OS loads up. There is a CFE command to get the speedup sooner if desired.

Running the network-startup script asynchronously is a big speedup, as long as anything that requires a network connection comes later in that same script. Past those things, all the tricks that are common to all versions of AmigaOS also apply here. And there may be more that I have forgotten.

If you have an X1000 you'll find lots of details in Sys:Documentation/X1000_CFE.pdf. The menu systems and even the clock speedup are described clearly in that document.

Troubleshooting guide:

http://wiki.amigaos.net/index.php/AmigaOne_X1000

Getting the serial debug set up can be a bit tricky.
The "normal" connection has a male 9 pin at each serial port, that part is easy, but the cable between them must be a "Null Modem Cable", which has some pin pairs swapped.
The tricky part is that you can not tell if a cable is straight or null without having a meter on hand. The two cable types look identical otherwise.(both ends female)

Without a meter the best test is to connect two known-good serial ports to verify your cable and connections first, and only after proving those out should you move on to the machine in question.
There is a detailed article on setting up for serial debug at the AmigaOS Documentation Wiki. Link is provided below.
http://wiki.amigaos.net/index.php/Advanced_Serial_Debugging_Guide

Good Luck!
LyleHaze

[edit] spelling errors.

@Dirk-B
Batteries on a PCI card will not help the CMOS chip on the motherboard.

The connection between the battery and CMOS has no common connections with anything going to a PCI slot.

to make a crossover cable:

There are two "normal" ways to make a cable,
labeled 568A and 568B. If both ends of the cable use the same
pattern (either one, I usually use B) then it is a normal cable.

If you use A at one end and B at the other, it becomes a crossover cable.

one of many references:
http://pinouts.ru/NetworkCables/Ether ... StraightThru_pinout.shtml

endless detail:
The description given above is OK for 10/100, but there is some debate as to it's proper use for Gigabit ethernet. However, Gig Ethernet ports are almost universally auto-sensing, so a normal straight cable should work fine.

:)

Have you tried changing the battery?
;)

@kas1e

"But indeed, if CF slot will be used for boot, then boot speed can be faster in compare with nemo (imho)"

The CF slot on Nemo IS used for boot. it holds amigaboot.of, which can also be loaded from the first partition of the HD.

The Cyrus shown at AmiWest had a SD slot, but it's exact purpose has not yet been confirmed.


As with most of the differences discussed, the two appear very close, but final details are not yet available.

Since this thread seems to be detailing the differences between X1000 and Cyrus boards, one other thought just occurred to me.

I believe (I am never sure of anything) that Nemo is the only NG Amiga that uses CFE instead of UBOOT.

Not that big of a difference, but CFE does make choosing from multiple Workbench and Linux partitions really easy. I have not had much experience with multibooting my micro with UBOOT.


I also want to make clear, it's not my intent to claim either board is better than the other, just pointing out the differences as far as we can tell.

I am truly impressed with the current state of the market.

I bought one of the last micro-AOnes, and that was followed by a fairly long dry spell, when it was hard to tell if there would ever be ANY new NG hardware coming. Today we are absolutely spoiled.

The current offerings from ACube and A-EON define a wide range of price/performance choices. Now we may even see more choices from their combined effort.

Not bad at all, in my opinion.

@Kimmok

Even in an ideal case (gfx driver hooks provided, audio driver written, missing documents found etc) then the sound would only work for end-users who are connected by HDMI, as the DVI and XVGA connections have no audio terminals.

That's all that SOME people would need, but certainly not a solution for everyone.

All points well made.
I wonder how the expansion differences will stack up?

We know the Nemo has 1@X16 or 2@X8 PCIe, which
makes dual graphics cards an option..
Nemo adds 2@X1 PCIe, 2PCI, a Xorro slot, and 4 SATA.

How does that compare to the current estimates for Cyrus?
(Yes, I'll call everything an estimate until product is released!)
The press release I am reading now states that Cyrus+ may have
1@X16 PCIe, with the next one down being an X4, so the Nemo
may be the better choice for dual graphics cards.
Most of the rest looks very similar, except Cyrus has 2 SATA
instead of 4, and I see no mention of IDE/PATA interface.

According to the flyer I am reading, the Cyrus+ will have
a dual core 64 bit e550. I do believe there may be other options
in the future. Nemo/X1000 is definitely dual core.

It's all speculation so far, but I look forward to seeing how it
all works out. I have an X1000 and I know how it runs. I have
no doubt that Cyrus+ will also be a very capable machine.

I'll take a stab at this one..
First, the usual disclaimer:
I am not an employee of A-EON nor AmigaKit, nor am I a spokesperson for either company.
What follows is not an official statement, but just the opinion of one Amigan.

Now, with the details covered, here we go.

Cyrus+ looks great, the specifications we have seen so far appear that it's performance may be similar to the Nemo/X1000.

But there are small differences that could tip the scales either way depending on your specific application.

Most importantly, the Cyrus+ has not yet begun full production, and all specifications are subject to change anytime between now and then.

Also, while we are all optimistic, there is no set release date for the Cyrus+.

So to answer your question properly, we don't know, and we won't know until Cyrus+ has been released. Even then, it may be application specific.. for instance, I don't think the Cyrus supports AltiVec, and I believe the X1000 does.. (I could be mistaken on either count) Whether or not that matters depends on whether your application of choice can recognize and make good use of that part of the processor.

There is also the multicore factor, which we can not yet fully evaluate until the OS support for multicore has been released

So we can guess all day long, but the most accurate answer I can offer is we just don't know yet.

Since the release date for Cyrus is unknown, I'd suggest taking the plunge for an X1000. I have never regretted it for a second.

I invite corrections to anything I may have misstated.