@amigadave

Pure inteligence if you ask me. Whats common for Amiga fans must be some sort of yet to be discovered special gift.

_________________
A1G3-SE + OS4.1 u1 iso (x2)

@xe54

QNX would have been okay, but today it sucks. I did a development project back in school using it, and today's version (created for the desktop) is far removed from the original concept. The embedded versions may be better, as I have no experience with those.

BeOS was a good concept, some parts were implemented extremely well (latency timing, threading, SMP, etc.) the file system was buggy and sucky. Why have great performance when you aren't sure that your file writes are safe?

Haiku is pretty interesting, but it isn't as tightly coded as BeOS (I looked at the source, it isn't), but that's because you have it open source and a variety of programmers with varying skill sets have done work on it. But for a community project, I would call it successful. It is just ugly and doesn't have any apps

I do believe that a unified vision is necessary, and hopefully, I can be a small part in helping to do that. The Amiga community certainly has the inspiration and community to support it.

Frankly, from an "outsiders" point of view, it seems that some parties thrive on the division within the community, and because it suits their agenda, they keep up the strive and conflict, for their own benefit and not the benefit of the platform.

And thanks for the compliment, I just see it as it is. The legacy of the platform deserves more than being relegated to 2nd class, has been status. The platform was once a leader, it should be a leader again. And it isn't unobtainable, and it surely doesn't have to be expensive.

Creativity can go a long way. Remember, price doesn't make something valuable. But value can make something priceless.

Last edited by Cod3r on 19-Jul-2012 at 12:57 AM.

@wawa

Truth be told, some of those benchmarks are garbage.

For example, when I run the system without the MultiTOS kernel underneath the OS, the Speedometer benchmarks says 1300-1400% of a Atari ST. Almost twice what the video shows.

MultiTOS is a time-slice based Unix-like OS, and the scheduler steals many clock cycles for itself. If I had more time, I would have filmed a comparison.

I would have loved to show Aros (it would have saved me a re-config of my whole system) but the legal department of my company forbade me to use non OSI licensed software on the board. Notice all the legal crap in the video description? Wasn't my idea. I had to get even my description approved before posting it.

Quote:

wawa wrote: @Cod3r Quote: The video is up... http://youtu.be/mrBvJozVpcA looks rather cool, im not very familiar with atari, so cannot make much of those benchmarks, but ~700 speed of atari-st is definitely something! is it too much to demand if you made a video running your fork of aros too? remember there are aros68k nightles online, that might be much more advanced than what you might use if your sources are few months old. aros is making quite a progress, y know;) edit: damn forum formatting, really annoying..

@Cod3r

mmm.. i see. sounds not so good. i assume that way is blocked then, till aros license problem be resolved, which might not be easy if even possible.

@NutsAboutAmiga

I know what you mean, but I mean do it in another way. I have an idea i'll show you guys. It'll take a while, but it's worth demonstrating.

I think people get confused about what Linux truly is. Linux itself is just a kernel. The GNU tools (i.e. bash shell, emacs, etc.) make "Linux" what people think Linux is. The Xserver, window managers and other things are just layers on top of that.

A kernel is really agnostic. It isn't one way or another, and it doesn't even make something compatible or not. You can implement a different API on whatever kernel you like (an over simplification, I know).

In regards to using Freescale designs, ACube is smart by doing that, and their prices basically show the benefits behind doing that.

I won't mind spending a little more than what something is worth, but 600 euros (I think that's about $900 USD) for a ColdFire board with MIDI ports in a blue box is ridiculous. And half the implementation isn't even functional!

I would have used a USB MIDI interface sold for PC's that's costs $20-30 USD, connected to a USB port on the a development board and made a driver for it. Done.

Quote:

NutsAboutAmiga wrote: @Cod3r The problem whit that is we lose the Amiga identity in the process, and up as another Unix or Linux system. MacOSX is a different OS then MacOS9 was, and in some ways, I believe MacOS lost something in the process, MacOSX is absolutely not as clean as it was. I’m for slow and steady improvements, and I see nothing wrong whit reinventing something if it makes it better, it is not just about making money, if it was then it probably not be interested. I agree whit you that using Freescale reference designs, might cut costs a lot, ACube-Systems uses modified Freescale references designs. A-EON gets someone else to do deign and manufacturing and that’s maybe way costs are higher.

Last edited by Cod3r on 19-Jul-2012 at 01:12 AM.
Last edited by Cod3r on 18-Jul-2012 at 11:53 PM.

@amigadave

You said it not me! Atari is quite boring to use. Talk about feeling like you're stuck in 1984...

At least my Amiga 500 doesn't make me feel like it is all that dated. It just is, because I know it is, but Atari makes you see it firsthand.

If you didn't know better, the modern Amiganoid systems look and feel as modern as Windows or Mac OS X. The modern Atari? I think they are just now in the early 90's, along with Windows 3.1

I think Amiga is close enough to modern to be groundbreaking, with a little help.

Quote:

amigadave wrote: @cod3r, We might not be groundbreaking compared to mainstream computing, but the fact that there are so many of us "old sentimental" users still working on Amiga inspired platforms is truly amazing. What other platform that has had it's parent company cease to exist has done as much as the Amiga community? You are justified in being interested in the Amiga above and beyond the Atari, as it surely is and was a far superior platform than the Atari and I dare say that there are far more remaining Amiga users than Atari users, and for good reason. The Amiga is far more interesting and capable. There may not be many non-Amiga users who find the few Amiga inspired "Next Gen" platforms interesting, but there are a few current Amiga Next Gen users who have zero previous Amiga experience.

@Cod3r
Okidoki.. the best is via email (see on bottom: www.aeros-os.org, or Impressum)

_________________
AROS Broadway - AEROS - Aminux - AmiCloud - indieGO! Appstore - AmiWallet - VAN lossless video codec - AMC Amiga media Center -KrypUnite - LibertyNet - MinX - amigaNX

@pavlor

Some of those benchmarks are truly bogus. I'll explain...

I was using MultiTOS, a Atari Unix-like kernel while doing the benchmarks. I had forgot that I had it active when I left off working on it.

MultiTOS steals cycles while scheduling. Quite a few.

So the Dhryston is off. Without MultiTOS active, with just the EmuTOS desktop it is ~19000 Dhrystones. You read correctly, that is the same value it always gets under MultiTOS. I suspect that Atari didn't write that kernel in asm. It may even be interpreter or p-code. It is that slow.

Kronos? The scores are skewed based on the system you are comparing them to. You have to load up some presets to compare the different systems. Again, MultiTOS is to blame here, but that score even shocked me when I ran it. Notice in the video that the app bombs and crashes. Again, I blame MultiTOS.

Gembench, hmm... i'm not sure where it get it's numbers. I noticed that some Atari benchmarks calculate speed by checking the system clock signal. It would be accurate if I actually did have the system at 8mhz or whatever Atari's original clock speed was. My system, since emulated, is clocked at a psuedo bus speed of 24mhz clocks. The real native system bus is at 33mhz, but because it is emulated (the processor), I synchronized the virtual CPU clock and everything to multiples of 8, or a 1600hz system timer as a source clock. That way, no instructions would ever take longer than they should or less, as in a computer-based emulator.

On a computer software style emulator, the system emulated would have to me much slower to even consider accurate instruction-to-cycle execution. For example, with a 2.4 ghz Intel CPU, you may be able to have clock accurate emulation of a Commodore 64 at 1mhz. And you'd better not try to watch a DVD while doing it LOL.

It is hard to explain, but my timing and the real Atari's timing is WAY different by source clock, but through wait-states and division, I end up with enough of the correct timing that allows the software to run. Most of it, at least.

Atari was easy to do, because most of its GUI software never touches the hardware-it is all GEMDOS API calls. So it is very emulator friendly, in that regard. That's why it was easy to emulate.

And regarding compatibility, thanks but, did you see all those system resets? LOL! I was so embarrassed that it locked up like that, it never did that before!

Quote:

pavlor wrote: @Cod3r Quote: The video is up... Looks fast and compatible. Benchmark results are little bit strange (maybe I read it wrong): Dhryston scores 8368 Dhrystones (4.76 DMIPS - roughly 68030 25 MHz performance or 68000 60 MHz) Kronos scores 3.4? (68000 8 MHz performance) Gembench scores 2167x ST performance. Difference between these results is interesting.

@Cod3r

if you think about 68k system atop of linux kernel it has been done few times. amithlon comes to mind and also there was i think another sloution, i dont remember the name. amithlon has been prohibited for licencing reasons (there was no aros68k in perspective. beats me why the other thing isnt much used. also there was initiative called anubis, amiga api on to of linux kernel, being a split freaction of aros. nothing ever came out of it except some hot air.

please dont take it as dis encouragement again. it is plain for ur info.

@Cod3r

Thanks for explanation.

Quote:

And regarding compatibility, thanks but, did you see all those system resets? LOL! I was so embarrassed that it locked up like that, it never did that before!

My ST is doing the same, charm of old OSs?

@pavlor

Since you have a real ST, can you tell me how your system compares to the benchmarks on the video? Just for my own knowledge, maybe I can optimize it a bit better.

Do you have MultiTOS? If so, can you tell me your experience with it? Is it really slow and buggy? I just want to know if it is my work or theirs (Atari's) that makes it crash like that.

Quote:

pavlor wrote: @Cod3r Thanks for explanation. Quote: And regarding compatibility, thanks but, did you see all those system resets? LOL! I was so embarrassed that it locked up like that, it never did that before! My ST is doing the same, charm of old OSs?

@wawa

I'm talking something REALLY different... it may take a while, but I just may be able to pull a rabbit out my hat

Quote:

wawa wrote: @Cod3r if you think about 68k system atop of linux kernel it has been done few times. amithlon comes to mind and also there was i think another sloution, i dont remember the name. amithlon has been prohibited for licencing reasons (there was no aros68k in perspective. beats me why the other thing isnt much used. also there was initiative called anubis, amiga api on to of linux kernel, being a split freaction of aros. nothing ever came out of it except some hot air. please dont take it as dis encouragement again. it is plain for ur info.

@Cod3r

Quote:

Since you have a real ST, can you tell me how your system compares to the benchmarks on the video? Just for my own knowledge, maybe I can optimize it a bit better.

I have unexpanded 520ST, I don´t think I can help you there.

Quote:

Do you have MultiTOS?

I used MultiTOS (released by Atari) only in emulation. However, there are newer MiNT releases (FreeMINT with XaAES, Thing desktop etc.), which should be better suited for your needs.

And yes, stability wasn´t its strong point.

@pavlor

I figured as much about MultiTOS. The board never crashed or locked up until I loaded that thing on it. That was the worst $30 I spent in a long, long time. It did nothing to improve anything. No wonder Atari stopped making computers...

Maybe MiNT would be better, but I could not find a "load and go" solution anywhere on the net. I don't have time to try to understand some cryptic writing on how to load the OS i.e. "First, you format the boot disk with a low-level formatter based on Unix/Mint, then you edit the boot script, then you copy the loader to the hard drive, then you reset, then you type "Super Atari" then you..." I couldn't deal with all that.

Other than the RAM, there probably isn't much difference between a 520ST and the 1040ST, right?

Quote:

pavlor wrote: @Cod3r Quote: Since you have a real ST, can you tell me how your system compares to the benchmarks on the video? Just for my own knowledge, maybe I can optimize it a bit better. I have unexpanded 520ST, I don´t think I can help you there. Quote: Do you have MultiTOS? I used MultiTOS (released by Atari) only in emulation. However, there are newer MiNT releases (FreeMINT with XaAES, Thing desktop etc.), which should be better suited for your needs. And yes, stability wasn´t its strong point.

@NutsAboutAmiga

You cant. Consider having written code as follows:

void foo()
{
   TEXT buf[300];

   stccpy(buf, "PROGDIR:", sizeof(buf));
   AddPart(buf, "Image.png", sizeof(buf));
   BPTR fh = Open(buf, MODE_OLDFILE);
   Close(fh);
}

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@itix

Yes but does Open() keep the string pointer in a global list or something like that?

local variables whit in Open() is added to stack of the instance, Open() probably depends on lock(), and so either lock() or open() can deal whit that problem internally.

There are probably 1000 of functions that have to be reviewed, to make shore they ether fail on the use of local address space, or duplicate the memory when it’s possible or when you should be allowed to do so, and do nothing where it safe whit in the instance.

You will always run into applications that think it’s safe to poke around in system structures; the problem is to detect this, and provided a proper feedback, when a parts of a system structure was not intended for public use.
It might be smart move the stack of libraries and devices in to a kernel address space, so that a MMU hit can provide a proper feedback, in these cases.

Already we can write protect strings by adding “const” in front, I’m shore the compiler and the ELF loader can do a lot to aid in solving the problem, after all other operating systems does it.

const TEXT buf[]=”BLA BLA BLA”;

The concept of stack enlargement depends on haveing a large amount of free virtual address space that can’t be fragmented, when you hit the end a MMU hit triggers and more physical memory is allocated and added to the end.

It only makes sense if full vitalization is inn did implemented, current memory vitalization only deals whit memory fragmentation, and is not limited by the fact that most memory is shard or public.

I’m shore it’s going to be painful to implement but worth it in the end.

Note that code is most likely perfectly legal in Linux.

Last edited by NutsAboutAmiga on 19-Jul-2012 at 02:18 PM.
Last edited by NutsAboutAmiga on 19-Jul-2012 at 01:39 PM.
Last edited by NutsAboutAmiga on 19-Jul-2012 at 11:24 AM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Cod3r

"Frankly, from an "outsiders" point of view, it seems that some parties thrive on the division within the community, and because it suits their agenda, they keep up the strive and conflict, for their own benefit and not the benefit of the platform."

I agree fully!

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@Cod3r

Quote:

Cod3r wrote: Creativity can go a long way. Remember, price doesn't make something valuable. But value can make something priceless.

Beautiful!

The world needs reminding of how fast computers used to be ;)

Personally, I would love to see AROS come on in leaps and bounds - shaped by the ideas, vision and creativity of all of the active community.

As it stands it is a good basis for development but IMHO is trying it's hardest to be AmigaOS4 - whereas it could really carve out any path for its future development. So long as the development tries to maintain the Amiga ethos of speed and simplicity, I believe people will be interested in it.

I believe integration of software, globally accessible abstractions of system APIs and strong networking capabilities would set a good baseline on which to hang new developments.

By this I mean that for a system to be useful, it must come set up in a way to handle all the media formats that computers users store - from viewing PDFs to Movie files, and have this neatly tied into the UI - traditionally via the double click (though I personally prefer KDE style single click ;). The strong datatypes API is a great way for this to be advanced - especially with the introduction of Reggae style streaming datatypes for drip-fed data such as MP4 and internet radio.

The abstraction of the system APIs was another strong point with the original OS, with handlers for almost all file operations and a fancy Rexx based script based metalanguage for accessing this underlying framework! In newer versions of OS4, they now have python as well as Arexx, which automatically increases the value of the system exponentially - especially to those in the embedded / kiosk markets.
It would be great to be able to use python on Aros to control devices and systems, but I would be happy with any of the open source scripting languages - perhaps even something entirely different that would allow deep level access to the video display along with hardware controlling - similar to Processing perhaps?

This would allow the machine to be crafted into very specific needs with very little overhead - from controlling the realtime visuals and lights at a gig, all in time to music - to developing video games with innovative controllers.

Augmenting the home and hackers market seems to be the next big thing with devices such as the PI and Arduino becoming incredibly popular. Low cost - high creativity. My belief is that these systems are a blank canvas on which to create whatever you so wish. This creativity angle is lacking from modern Apple devices for example.

One of the greatest strengths of the Amiga was that it was always sold as a tool to achieve creativity - and not just because of software - crazy hardware was ripe - from digitisers, samplers and MIDI ports to 3D renderfarms, scalable live TV output and genlocks. Hardware for the new breed of PPC amigas is not causing the same level of excitement and creativity.

I mentioned networking before but I do believe that is one of the most important areas to ensure perfection first. A small footprint, network capable OS would definitely interest a community outside of the Amiga, especially if it could be deployed as a low weight server.

Finally, I admire that you are helping the community to create a specification, a target, a dream that is tangible, a roadmap, a path, a direction ...

That would be a great step in the right direction towards unity.

It frustrates me watching slow development, with no clues as to progress, no ideas on time scales, no discussion about future plans, unfinished software and hardware being sold at top prices, in-fighting over the market share, devs replicating work for multiple platforms, lack of dedicated documentation and most of all, the politics!

Amiga INC have made it practically impossible to follow that legacy, but there aint no reason that we can't take the initiative and make a platform we always dreamed of :)

The great Trevor Dick stepped up the plate where no one else could and I am so happy that the team managed to put together a great computer with relatively modern software.
In my opinion the AmigaOneX1000 is the machine that should have been released by ESCOM in the late 1990s! Politics kept it delayed!

For the Classic Amiga fan, nothing can touch it. Dedicated hardware and software.

The future beyond OS4 is of course open for discussion :)

I believe that future to be based around shared source code, openness and mission based team work.

Most probably based upon the decade of work started by the AROS teams ;)

@xe54

Quote:

In my opinion the AmigaOneX1000 is the machine that should have been released by ESCOM in the late 1990s! Politics kept it delayed!

in 1995/96 is was 50-90Mhz Pentiums, by the end of 1999 is was around 200 to 300Mhz Pentium II, the X1000 is way faster 1.8Ghz dual core, at start of 2000 is was around 800mhz, I think the specifications was pretty common around 2004, so if it was released in 1995 just imagine the impact.

If Commodore did not make some of the mistakes like AGA chipset and the ZorroIII bus, back in 1992 and instead gone for S3 Virge and PCI, they might have been on level whit the first power mac’s around 1994, instead of going bankrupt.

Last edited by NutsAboutAmiga on 19-Jul-2012 at 02:39 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

I never meant comparable hardware...

Simply that the 10 year gap delayed the development and innovation of the platform.

In 1999 I had a 600Mhz P3 for the record (this was not top of the range).

Ignore the hardware - it is the comparable experience that I am referring to.
AmigaOS on my 25Mhz 68030 still feels faster than on that P3.

We can speculate forever why Commodore failed but let us just agree that it was bad management.

I do not personally believe AGA was a mistake! The AAA probably was however.

The reluctance to use IBM compatible hardware surely didn't help, but ZorroIII had many advantages over PCI at the time (autoconfig for one) and the future seemed much more "up for grabs" back then. Nobody expected the sheer dominance of IBM compatible hardware until it was too late. So lets chalk it up to bad management (at least till the Amiga film come out!)