Poll: What KS would you prefer in a Vampire... Aros or KS3.1

[IanP]

Optimising the compiler for Apollo would make a big difference to AROS but optimising the source code would probably make as much difference.

Licensing KS3.1 doesn't solve the problems that the operating system is not under development, is closed source and stuck at supporting the AGA hardware from the early 1990's.

[wawa]

Optimising the compiler for Apollo would make a big difference to AROS but optimising the source code would probably make as much difference.

deadwood has experimented with aros code generated with vbcc instead of gcc 4.6.8 on this very site. the result afair was, that vbcc generated code wasnt noticeably faster. aros has known issues, one simply needs to address them, but since the awareness and recognitionb on part of genuine amiga 68k community is so low, these issues remain open, as long as they are nones priority.

above all, aros is currently being compiled for a plain 68000.

[Samurai_Crow]

@wawa

What makes you think that VBCC has better instruction scheduling for a proposed 3-way superscalar CPU with 2 way opcode fusion possibilities? Besides, the only part of VBCC that is any good right now is VAsm because it has a nice peephole optimizer. The main optimizer of the actual VBCC compiler is only average at best by today's standards. GCC 4.x has good macro-optimization but needs a better peephole optimizer in the backend. In short, neither VBCC nor GCC are optimal solutions for the needs placed before us.

[xArtx]

The same ROM from the machine it goes in.
If you have the media on the card maybe it would be possible for an Amiga program
to initially upload the ROM from the Amiga, even if that meant a one time connection to the serial port.

[wawa]

Originally Posted by Samurai_Crow

@wawa

What makes you think that VBCC has better instruction scheduling for a proposed 3-way superscalar CPU with 2 way opcode fusion possibilities? Besides, the only part of VBCC that is any good right now is VAsm because it has a nice peephole optimizer. The main optimizer of the actual VBCC compiler is only average at best by today's standards. GCC 4.x has good macro-optimization but needs a better peephole optimizer in the backend. In short, neither VBCC nor GCC are optimal solutions for the needs placed before us.

if not vbcc, then what? gcc 2.8.x? some hypothetical non existant apollo backend to gcc, that would break backward compatibility?

[wawa]

i have put here a few minutes of a shaky and blurry video of an amiga a1200/060-50/16mb booting and running aros68k in highres interlace. have not been doing anything particular with it just opening some apps and mui guis to demonstrate overall responsivness and stability of the system under such circumstances. i intend to do a video of my a4k/rtg, which would be much faster, but id like to get rid of bug when booting from intenal ide of an a4000 first as well as correct some glitches when using picasso4 pixelformats. i could swap picasso for cv64 instead, but the work has to be done on p4 either way, sooner or later.

[clebin]

To add my 2p worth, a better aim would be to get AROS 68k optimised and ready for the standalone Apollo machine. Done right, AROS would be a perfect fit for a forward thinking 'classic' machine like that.

[matthey]

Originally Posted by IanP

Optimising the compiler for Apollo would make a big difference to AROS but optimising the source code would probably make as much difference.

Licensing KS3.1 doesn't solve the problems that the operating system is not under development, is closed source and stuck at supporting the AGA hardware from the early 1990's.

So compiler support and developer tools for the 68k are out of date and generally not developed, the 68k AmigaOS is out of date and not developed, all the Amiga copyrights are owned by different entities and it is not clear who owns them, AROS is not optimized and development is at a snails pace but now we have new hardware for a slow CPU using FPGA, no business partners, no publicity, no financing, no standards, no documentation, no recognition and virtually no support outside of a tiny group. Who is leading this chaotic blob to the promised land?

There are many people who do not want a revival of the 68k or Amiga. There are the Microsoft/Intel zealots who want one common computer platform to rule them all and attract all the viruses. Many big software developers don't want to mess with the lowly 68k. The GCC folks don't want to support the 68k and never officially supported the Amiga. Even in our Amiga community there are PPC lovers, hardware manufacturers and possibly intellectual rights holders who see the 68k as competition. Even with finding good business partners who like the 68k, there are too many uncertainties which are evident with questions like: What OS should be used? Why choose the 68k when ARM is so cheap? The funny thing is that the last question was asked by a man in the embedded market who has written papers about the advantages of the 68k. I'm not much of a salesman and few consider me to be charismatic but we didn't have a professional product or business plan to present and this has not changed. It doesn't matter how promising the Apollo core technology is as superior products fail all the time.

Originally Posted by Samurai_Crow

What makes you think that VBCC has better instruction scheduling for a proposed 3-way superscalar CPU with 2 way opcode fusion possibilities?

Vbcc does not have an instruction scheduler for the 68k. Most compilers do not as even the 68040 would get minimal benefits and the 68060 was not well supported. A good backend which generates quality code is more important than the instruction scheduler as scheduling extra instructions is a waste. Vbcc does a lot of things in a smarter and simpler way than GCC but it has areas which have not been improved or optimized. Good support requires good backers, good standards and good documentation.

Originally Posted by Samurai_Crow

Besides, the only part of VBCC that is any good right now is VAsm because it has a nice peephole optimizer. The main optimizer of the actual VBCC compiler is only average at best by today's standards. GCC 4.x has good macro-optimization but needs a better peephole optimizer in the backend. In short, neither VBCC nor GCC are optimal solutions for the needs placed before us.

Vbcc has many high level optimizations but tries to leave low level optimizations to the peephole assembler. This has not been completely successful but only needs minor optimizations in the backend added. The biggest problem is that the 68k backend or instruction scheduler is the lowest priority for enhancements because it is going nowhere. Developers don't like to waste their time.

[wawa]

Originally Posted by matthey

AROS is not optimized and development is at a snails pace

you can always compile a version for 020 .
what concerns snail pace, its as much snail pace as everything else in amiga land, considering how much people are regilarly involved it is pretty complete and feature rich software, at least for our standards. it needs some involvement on amiga backend, thats true..

[kolla]

Originally Posted by Akira

Putting AROS into a device like the Vampire would just hinder its usability and would be detrimental for the Vampire.

You can't just ask the team to "jump together in the river", I rather leave AROS behind in limbo than kill Vampire by sporting an incomplete OS. Vampire team cannot put out there a device that doesn't fully work.

I do wish AROS was worked on as well, but I don't believe this is the right kind of motivation. I wonder if money could make things better, because I sure as hell would contribute to a crowdfunding campaign to push AROS forward.

Would you? Please do!

https://power2people.org/projects/overview/

[kolla]

Originally Posted by Zetr0

[*]SAGA Graphics Card (with the ability to play AGA games on non AGA Amiga)

Oh, you also thought Super AGA means AGA compatibility?

[kolla]

The "snail pace" of AROS outmatches that of AmigaOS, both 3.x and 4.x, that much is certain. MorphOS.. who knows.

I wonder what "A week in OS4.x" would look like, compared to "A week in AROS", lol.

[kipper2k]

K,

off topic a little but nice to show...

[ Show youtube player ]

[ Show youtube player ]

[Amiga1992]

Originally Posted by kolla

Would you? Please do!
[/url]

Both of the Kickstart ROM bounties are complete, there's nothing for me to show my love for there for the ROM completion or optimization for 68k, at least not that I have seen. I am not interested in AROS being used on any other platform.

[TuKo]

Originally Posted by kipper2k

K,

off topic a little but nice to show...

[ Show youtube player ]

[ Show youtube player ]

Best offtopic ever ;-)

My vote?

Short-term: OS3.x

Why? Because it is a known entity. The Apollo crew is busy bringing the core up to their goal configuration. It must have a stable and debugged operating system base.

To attempt to bring up new hardware and start working on an operating system in parallel is a recipe for trouble. Other companies have failed trying to do this.

Longer-term: MorphOS? AROS? OS3.XX?

I know this may sound crazy but for next-gen systems that have been debugged and have an existing user base OS4 is out for known reasons. But what about MorphOS? Perhaps a contender to port to 68K/64 since they are already talking about porting to X86/ARM. No guarantees but hey it's worth a shot. Yes it isn't open source.

AROS is an option but it doesn't sound very robust/mature. How close is it to usable? Time will tell. Is AROS binary compatible with 3.x code?

OS3.XX? An evolving patched OS 3.1. Perhaps in time the patches end up being larger than the original distribution?

Be kind this is my first posting on eab.

[wawa]

Originally Posted by gregthecanuck

Is AROS binary compatible with 3.x code?

always the same questions.. is ist too hard to inform yourself? and why would we even mention it in this context? yes, aros68k is binary compatible with amiga software.

@kipper:
very good bandwidth to rtg, as it seems, not that it was unexpected, but its looking really good.

[dirkies]

if you can softkick an older/newer kickstart on the Vampire 3.1 KS as you can do on classic hardware (assuming the Vampire builtin KS adapts the softkicked KS to the FPGA) , isn't this discussion moot?

[gonzo]

Kick 3.9 if possible :-)

[Romanujan]

3.1 (factory) + ability to flash custom Kickstart (1 MB ROMs should also be supported)

1. All the ROM patches for the Vampire (as far as I understand, currently the Vampire uses patched 3.1 ROM) should be available in a Remus compatible format for anyone wanting to create own custom ROM

2. There should be an easy way (for example - switch on the board) to revert to factory Kickstart, even if the user flashed the Vampire with a non-booting ROM.