Official update to OS 3.1 from Hyperion

[Olaf Barthel]

Originally Posted by wawa

olaf, if you dont know for sure, who of us is supposed to know?

Speaking for myself: there I things which I chose not to learn more about. Too much knowledge inevitably leads to worrying. So far, I believe that what I wrote here can be surmised by anyone who avoids the conspiracy theories and looks at the results of what the players in this market produce.

[wawa]

Originally Posted by Olaf Barthel

there I things which I chose not to learn more about.

same as me. the whole drama is kindof entertaining, might even make up for a nice plot draft of a court intrigue movie, but too much is too much.
i prefer to try to contirbute to something constructive, where i can both find my place and the outcome of which promisses something that may be actualy handy for me in one or another manner.

i dont think i act out of hatred, i might dislike attitudes but in the end i try to make convenient choices. if i even criticized os4 and the policies accompanying it, they were actually for practical purposes i consider constructive. for instance i coulndt understand timberwolf hype in prospect of lack of future maintainability, while leaving much more reasonable project, which was odyssey, to be postponed. time has proven me right..

[Kalamatee]

Originally Posted by Olaf Barthel

You make this sound like a bad thing

Its a big factor in why the Amiga community is now a very small niche, if that - and why it will remain to be so. And probably why it seems to attract mainly people with that mentality.

Seriously, this is in my opinion a side-effect of very few players remaining in this field who can to a certain degree control what products may be made and sold. How much control they actually have is limited by budget constraints, personnel involved, time available, actual sales and legal restrictions.

Few players being involved means that any decision made by them can instantly have far reaching effects on the market, the business and the hobbyists, both for better and for worse.

The limitations which the players have to work under always dictate how much risk they may be able to take, also for better and worse.

Finally, there is also competition between the players, among and against each other, which adds another level of risk and uncertainty on top.

If this were any other kind of business, would you reasonably want to be involved in it?

I lost interest in anything commercial involving Amiga/AmigaOS in the late 90s when it had already started to become a farce. Companies exploiting legal uncertainty/dubious claims put the nail in the coffin for me.

You mentioned milking. I believe that the term may not apply here. The constraints are not created by the players, they just have very little room to conduct their businesses. This in turn leads to the sometimes baffling decisions as to what kind of product can be released, and at which price.

I don't entirely agree - they have a massive amount of freedom and choice compared to say the 90's. But instead they focus on selling poor performing hardware (with some features not even partially supported in cases) for extortionate sums.

The operating system has become a façade for nothing more than an easy route to port Linux code, not even embellishing the AmigaOS way of doing things.

Other small companies and start-ups seem to be able to achieve in a few years, what it takes a quarter of a century for AmigaOS to not even get close to...

[Olaf Barthel]

Originally Posted by Kalamatee

I don't entirely agree - they have a massive amount of freedom and choice compared to say the 90's. But instead they focus on selling poor performing hardware (with some features not even partially supported in cases) for extortionate sums.

The operating system has become a façade for nothing more than an easy route to port Linux code, not even embellishing the AmigaOS way of doing things.

Other small companies and start-ups seem to be able to achieve in a few years, what it takes a quarter of a century for AmigaOS to not even get close to...

I disagree with the companies having more freedom - the constraints include (again) available funds, the age of the operating system architecture and the workload which can be shared between the hardware manufacturer and the software developer.

If you build and sell a PowerPC-based desktop system you are boxed in by the choices you are allowed to make with regard to the hardware you can buy ready-made, and which source you can use for it (the PowerPC platform is in about the same situation as the MC68000 family was in the late 1990'ies). You do not always have a choice between several different sources, and you do not necessarily have a potential manufacturing contact in, say, China, who could customize a design for you.

So, what gives? You are left with a small set of choices to make anything at all in the first place, especially considering how much risk you can take up, financially, and market-wise (who's going to buy that? how many boxes can you expect to sell?). Whatever you pick, it will be part of a package which hooks up the CPU to peripheral hardware and memory. Again, you may have to make choices, based upon cost and availability, or there may be not a lot of choice at all, because the package already combines CPU, peripheral hardware and memory.

This covers the hardware manufacturing side. Things get interesting in the next step: does the operating system already provide drivers for that hardware, and why should you care as the hardware provider? You're going to pay for the software developer to figure out how to make that box jump through hoops, aren't you? Problem solved. Or is it?

The hardware which lands in the hands of the software developer may not be supported by drivers which already exist and which are well-tested. So new drivers will have to be written, and (this from somebody who's had a mostly miserable time for each such gig) this is always a struggle. Hardware documentation is mostly lacking in context, and manufacturers tend to close the gap by shipping code samples or point to Linux kernel code. Never mind that the code's intended home architecture is far removed from what the Amiga operating system wants to see, or that it looks like it's been encrypted (no, it's just one single developer doing his best, learning on the job, still in need of learning to write robust and readable code). So you do what you can, but it takes its toll...

You mentioned hardware not performing well, and hardware features not being supported. This is a side-effect of the package the hardware manufacturer picked containing complex components which are not a good match for the Amiga operating system architecture.

The typical example for that is that the main board contains a network interface, but there is no driver for it (there's a driver for the network interface plugged into the PCI slot, which works, though). The "AmigaOne" shipped with a fairly common type of 3com NIC whose precursors existed already existed in the 1990'ies. You won't find these in the current packages any more. Some of the NIC designs are off-the-shelf and that improves your odds to make a driver that works. But there are also in-house NIC designs which tie into the overall architecture of the package: at this point it's you against the "alien invasion", and unlike the movie heroes of the past, you can side-step the problem by not spending a truly awful amount of time to teach the alien puppy to walk and bark (or look into the wrong end of a flamethrower). You opt for the cost-effective approach of sticking a well-supported NIC into one of the expansion slots. Problem solved. Really, done and done.

...except for that little problem with the network driver architecture we use on the Amiga. It was designed for the kind of hardware which existed at the cusp of the late 1980'ies and 1990'ies: 10BASE2 and 10BASE5 Ethernet. These NICs work in a particular way, and today's NICs work nothing like that any more. This has consequences for the performance you can realistically coax out of the hardware and the TCP/IP stack. On the Amiga a Fast Ethernet NIC (100 Megabits/second) or a Gigabit Ethernet NIC will typically peak around 20-30 Megabits/second while the CPU load is close to 100%. We cannot currently do any better than that.

So, I've written too much already, I suppose As I am not entirely fond to mention, things are complicated, especially on the Amiga

[Kalamatee]

Originally Posted by Olaf Barthel

I disagree with the companies having more freedom - the constraints include (again) available funds, the age of the operating system architecture and the workload which can be shared between the hardware manufacturer and the software developer.

If you build and sell a PowerPC-based desktop system you are boxed in by the choices you are allowed to make with regard to the hardware you can buy ready-made, and which source you can use for it (the PowerPC platform is in about the same situation as the MC68000 family was in the late 1990'ies). You do not always have a choice between several different sources, and you do not necessarily have a potential manufacturing contact in, say, China, who could customize a design for you.

So, what gives? You are left with a small set of choices to make anything at all in the first place, especially considering how much risk you can take up, financially, and market-wise (who's going to buy that? how many boxes can you expect to sell?). Whatever you pick, it will be part of a package which hooks up the CPU to peripheral hardware and memory. Again, you may have to make choices, based upon cost and availability, or there may be not a lot of choice at all, because the package already combines CPU, peripheral hardware and memory.

I don't entirely disagree with what you are saying, but it is masking over the fact bad decisions where made in the late 90s and have been vehemently clung to, to the platforms detriment.

It was known PPC wasn't going anywhere 20 years ago, ARM custom "SoC"'s with more power/performance/features/choice have been available for 15 years or so.

And yes - for over 15 years there's been an unbelievable amount of choice/off the shelf hardware/peripherals that could've been leveraged - choosing to ignore it doesn't mean it wasn't an option.

This covers the hardware manufacturing side. Things get interesting in the next step: does the operating system already provide drivers for that hardware, and why should you care as the hardware provider? You're going to pay for the software developer to figure out how to make that box jump through hoops, aren't you? Problem solved. Or is it?

The hardware which lands in the hands of the software developer may not be supported by drivers which already exist and which are well-tested. So new drivers will have to be written, and (this from somebody who's had a mostly miserable time for each such gig) this is always a struggle. Hardware documentation is mostly lacking in context, and manufacturers tend to close the gap by shipping code samples or point to Linux kernel code. Never mind that the code's intended home architecture is far removed from what the Amiga operating system wants to see, or that it looks like it's been encrypted (no, it's just one single developer doing his best, learning on the job, still in need of learning to write robust and readable code). So you do what you can, but it takes its toll...

You mentioned hardware not performing well, and hardware features not being supported. This is a side-effect of the package the hardware manufacturer picked containing complex components which are not a good match for the Amiga operating system architecture.

The typical example for that is that the main board contains a network interface, but there is no driver for it (there's a driver for the network interface plugged into the PCI slot, which works, though). The "AmigaOne" shipped with a fairly common type of 3com NIC whose precursors existed already existed in the 1990'ies. You won't find these in the current packages any more. Some of the NIC designs are off-the-shelf and that improves your odds to make a driver that works. But there are also in-house NIC designs which tie into the overall architecture of the package: at this point it's you against the "alien invasion", and unlike the movie heroes of the past, you can side-step the problem by not spending a truly awful amount of time to teach the alien puppy to walk and bark (or look into the wrong end of a flamethrower). You opt for the cost-effective approach of sticking a well-supported NIC into one of the expansion slots. Problem solved. Really, done and done.

...except for that little problem with the network driver architecture we use on the Amiga. It was designed for the kind of hardware which existed at the cusp of the late 1980'ies and 1990'ies: 10BASE2 and 10BASE5 Ethernet. These NICs work in a particular way, and today's NICs work nothing like that any more. This has consequences for the performance you can realistically coax out of the hardware and the TCP/IP stack. On the Amiga a Fast Ethernet NIC (100 Megabits/second) or a Gigabit Ethernet NIC will typically peak around 20-30 Megabits/second while the CPU load is close to 100%. We cannot currently do any better than that.

So, I've written too much already, I suppose As I am not entirely fond to mention, things are complicated, especially on the Amiga

Yes indeed - but thanks for sharing your perspective ( I have much respect for the things you have achieved over the years).

[wawa]

Originally Posted by Olaf Barthel

If you build and sell a PowerPC-based desktop system you are boxed in by the choices you are allowed to make with regard to the hardware you can buy ready-made, and which source you can use for it (the PowerPC platform is in about the same situation as the MC68000 family was in the late 1990'ies). You do not always have a choice between several different sources, and you do not necessarily have a potential manufacturing contact in, say, China, who could customize a design for you.

which sounds kinda fatalist, as it it was undavoidable to repeat the failures of the past and this time let the followers be walked into an abvious trap along with their pension savings.

[Olaf Barthel]

Originally Posted by Kalamatee

I don't entirely disagree with what you are saying, but it is masking over the fact bad decisions where made in the late 90s and have been vehemently clung to, to the platforms detriment.

It was known PPC wasn't going anywhere 20 years ago, ARM custom "SoC"'s with more power/performance/features/choice have been available for 15 years or so.

The developer tool chains (optimizing compiler, linker, binary format, etc.) for the ARM platform have improved drastically only over the last few years. The PPC tool chains, by comparison, were sufficiently mature for quite a while longer. I would say that a realistic perspective for integrating ARM support has not been an option until 5-6 years ago.

And yes - for over 15 years there's been an unbelievable amount of choice/off the shelf hardware/peripherals that could've been leveraged - choosing to ignore it doesn't mean it wasn't an option.

The choice is no choice, and the option is not an option if the cost sunk into making the PowerPC platform the focus makes itself felt.

Moving to a different system architecture requires that all the necessary pieces (hardware, development tools, developers porting their applications) are in place and even then the risk never stops reminding everyone what they are getting themselves into. Few platforms successfully made this journey without running themselves into the ground.

If one were to pick a nice, affordable, powerful platform not unlike the RaspberryPi 3, you would still have to find a way for existing users to make the migration with you. There would have to be backwards compatibility for data and programs, which is difficult to begin with: do you both support 68k software and PowerPC programs? What about hardware drivers, are they going to make the migration, too?

I reckon that this part of a hypothetical migration to a new hardware platform were essentially doable, if it were not for the lack of financial resources, the number of potential customers to follow you, and the lack of interest in the hardware makers to support your migration. This used to be easier in the early 2000's when Motorola had a vested interest in helping the 68k platform users to find a good home in the PowerPC domain.

Again, I would like to stress that the choice of the options, the alternatives, has been contracting quickly, maybe even accelerating in the past few years. Due to constraints on capital, constraints on availability of qualified developers (combined with the lack of capital this implies qualified developers willing to work for very little money) and the risk of doing business in such a small market, this is where we wound up with little chance to reverse the overall trend.

One can criticize the decisions that were made which led to this state of affairs. Beyond that it won't help to keep criticizing them, what's done is done. The question which I keep coming around to again and again is: what exactly can we do right now? I am no longer interested in discussing questions pertaining the "tragedy of the Amiga", who would be at fault, how could it have been done right. That's like discussing football after the match, when you haven't even been a player, and no amount of post-game discussion can change how the game played out.

[Olaf Barthel]

Originally Posted by wawa

which sounds kinda fatalist, as it it was undavoidable to repeat the failures of the past and this time let the followers be walked into an abvious trap along with their pension savings.

I only looks inevitable in retrospect. Which doesn't make the road traveled any better, of course. The steps taken after Commodore had collapsed, with the various ownership transitions of the assets, suffered from lack of vision, or at least an overall strategy. Nobody was in charge for long enough for such a strategy to come together.

As the results of the decisions made, and the roads not taken, materialized, fewer and fewer degrees of freedom to make further choices remained.

[wawa]

i think about the present and the future rather than about the past, that naturally cannot be replaced. shouldnt we lern from it rater than traditionally repeat failures? i understand that you are caught in a net of relationships and try to make the best out of it. nevertheless i would be rather disppointed in your place. even though i dont know any better.

[bubbob42]

Originally Posted by Olaf Barthel

Moving to a different system architecture requires that all the necessary pieces (hardware, development tools, developers porting their applications) are in place and even then the risk never stops reminding everyone what they are getting themselves into. Few platforms successfully made this journey without running themselves into the ground.

So, if we draw some conclusion from the picture of the last decades - moving to a new cpu architecture might be next to impossible.

Which leaves us with a) emulation or b) going back to 68k, which lately has promising (hobby) platform and performance perspectives because of the Apollo core. And users of classic systems won't be left behind, as they may either upgrade their machines with Apollo-cards or at least benefit from OS bugfixes and small improvements. It also has got at least some of the prerequisites you laid out.

However, OS3.1 also has the most legal problems, whether it's "companies" kicking each others shins or developers (who feel like they cannot contribute to e.g. AROS, because they have knowledge of original AOS sources) or else. I'm afraid it's still a mess, but at least it gained some "momentum" compared to the situation two years ago...

How do you judge the possibility to backport (parts) of OS4.1 to 68k/Apollo systems from a pure technical point of view? There has been an OS4 68k beta back in the day...

[wawa]

Originally Posted by bubbob42

How do you judge the possibility to backport (parts) of OS4.1 to 68k/Apollo systems from a pure technical point of view? There has been an OS4 68k beta back in the day...

here we go again.. as i said in the other thread:
http://eab.abime.net/showthread.php?...95#post1158295

have you even looked at the quite high ram requirement figures? without even having os4 run on 68k architecture and being able to figure out what speed figures we would have to do with..

im though curious about olafs comment about this as well.

[bubbob42]

Originally Posted by wawa

have you even looked at the quite high ram requirement figures?

Well, switch off the eyecandy-stuff and we'll see. AFAIR PPC binaries are also a bit larger than their exact 68k counterparts (at least my programs are).

[wawa]

Originally Posted by bubbob42

Well, switch off the eyecandy-stuff and we'll see. AFAIR PPC binaries are also a bit larger than their exact 68k counterparts (at least my programs are).

i know. ppc binaries and general ram requirement may be up to two times higher, but have you followed our discussion with flathamster on a1k?

os4 with eyecandy and stuff (ppc) >50mb (usually people claim you cant boot workbench to less than 70mb requires)
aros with eyecandy and stuff (68k) ~7mb

os4 early startup (ppc) >7mb (other users claim 30mb)
aros early startup/boot without the s-s ~1mb

and aros is by no means optimized yet afaik. so i wonder where that ram gets wasted.

[grelbfarlk]

Originally Posted by wawa

i know. ppc binaries and general ram requirement may be up to two times higher, but have you followed our discussion with flathamster on a1k?

os4 with eyecandy and stuff (ppc) >50mb (usually people claim you cant boot workbench to less than 70mb requires)
aros with eyecandy and stuff (68k) ~7mb

os4 early startup (ppc) >7mb (other users claim 30mb)
aros early startup/boot without the s-s ~1mb

and aros is by no means optimized yet afaik. so i wonder where that ram gets wasted.

I'm not defending the RAM requirements for AROS or OS4, but in the case of OS4 or AROS x86(x64) what does that really matter? It's not like on either of these platforms adding a whopping GIGABYTE of RAM is a problem.

The RAM requirement for OS4 on CSPPC is a shame since there's no way to upgrade it cheaply, yes yes you can buy relatively expensive and slow Zorrams/Bigrams. And for that reason OS4 on CSPPC is somewhat of a novelty, not enough RAM to not be hamstrung by it, and not fast enough to run NG level applications.

On AROS, the Vampire team mentioned 512MB of RAM which could possibly increase for the next board whether that's the standalone or otherwise.

[wawa]

apparently it mattes for many people, who argue 1mb is too much for early startup. in fact ram isnt really cheap on amiga. a4000 cpu slot is being mapped to 128mb space in hardware. gunnar considers this possible to overcome, but i doubt it upon what i have been told by others. on apollo-forum there has been a lot of talk about present and future ram requirements. vampires are currently delivered with 128mb which already is an upgrade in comparison to previous models. i think we need to respect and work along these constraints, and while obviously features cost ressourses, they shouldnt cost more than necessary. thats been amiga philosophy all along, wasnt it?

btw, for tests purposes im downgrading what i have here and running some aros and amiga demos and programs on an 4000/040/16mb motherboard ram/no rtg. working fine and stable. wanderer is a bit sluggish with png icons on aga, but apps like dopus4, snoopdos, editor are responsive as ever.

[matthey]

Originally Posted by bubbob42

So, if we draw some conclusion from the picture of the last decades - moving to a new cpu architecture might be next to impossible.

Which leaves us with a) emulation or b) going back to 68k, which lately has promising (hobby) platform and performance perspectives because of the Apollo core. And users of classic systems won't be left behind, as they may either upgrade their machines with Apollo-cards or at least benefit from OS bugfixes and small improvements. It also has got at least some of the prerequisites you laid out.

Staying with the 68k retains the most users and is easier than migrating to another platform. I believe it is necessary to attract outside users though and that will be limited with an FPGA only CPU. Gunnar has made horrible choices with the Apollo Core (design and ISA) hyper-optimizing it for an FPGA while making a transition to an ASIC undesirable. It's too bad as the performance is amazing and works well with all the complexity (he has skills). Of course his mistakes could be undone but he would have to give up control. I wanted to get Dave Alsup (InnovASIC's Fido designer) to review his work and I was asked by an investor who lives near Joe Circello (68060 and ColdFire architect) if we should contact him but I was hesitant at that time.

ARMv8 is also tempting with its big endian support. The ISA is more standardized and the designs are highly optimized but now there is less customizability and a license fee is necessary. If you use ARMv8 commodity hardware then it is difficult to differentiate from the crowd which you are competing against (how do you become the number one OS for the Raspberry Pi 3 for example?). I still think it would be better to become vertically integrated producing unique hardware as working with synthesizable HDL code for an FPGA is common today and chip fab/foundry services are common and like a commodity themselves. Why not choose the 68k then you have a unique product with retro appeal, there is no license fee to pay to ARM and there would be unlimited customizability without threats from ARM. It would take time to develop the technology and talent but then it may be possible to build a strong position not unlike ARM Holdings.

Originally Posted by bubbob42

How do you judge the possibility to backport (parts) of OS4.1 to 68k/Apollo systems from a pure technical point of view? There has been an OS4 68k beta back in the day...

IMO, there are many modules which could be back ported from AmigaOS 4 to AmigaOS 3 with minimal changes. There are some modules which may be better to stay with the AmigaOS 3 version and pull parts from the AmigaOS 4 version. Some of the AmigaOS 4 modules may be too heavy for AmigaOS 3 and would probably be left out, at least for now. I would probably maintain separate sources and teams (less disruptive of AmigaOS 4 development) but give them access to all sources and bug fix information. The primary focus for an AmigaOS 3 team would probably be bug fixes, integrating and improving API compatibility with AmigaOS 4 and large disk support. I expect the changes due to AmigaOS 4 would be substantial enough that a new kickstart/ROM would be practically necessary or at least highly desirable. I talked to Matthew@A-Eon some time ago and it sounded like he would like to backport more software (not clear on what was possible for A-Eon) but it is not as easy as just recompiling code in most cases.

Originally Posted by bubbob42

Well, switch off the eyecandy-stuff and we'll see. AFAIR PPC binaries are also a bit larger than their exact 68k counterparts (at least my programs are).

A bit larger? The 68k is something like 40% better code density on average.

Originally Posted by wawa

i know. ppc binaries and general ram requirement may be up to two times higher, but have you followed our discussion with flathamster on a1k?

os4 with eyecandy and stuff (ppc) >50mb (usually people claim you cant boot workbench to less than 70mb requires)
aros with eyecandy and stuff (68k) ~7mb

os4 early startup (ppc) >7mb (other users claim 30mb)
aros early startup/boot without the s-s ~1mb

and aros is by no means optimized yet afaik. so i wonder where that ram gets wasted.

I believe the disks use caches even when booting without the startup-sequence and PPC users probably have larger caches. The PPC MMU tables probably take some memory and all the enhanced OS code (the OS is mostly code) could easily use twice as much memory as the 68k.

[wawa]

Originally Posted by matthey

I believe the disks use caches even when booting without the startup-sequence and PPC users probably have larger caches. The PPC MMU tables probably take some memory and all the enhanced OS code (the OS is mostly code) could easily use twice as much memory as the 68k.

ten times ram requirement because of disk caches and code density? perhaps..

[Olaf Barthel]

Originally Posted by bubbob42

So, if we draw some conclusion from the picture of the last decades - moving to a new cpu architecture might be next to impossible.

In my opinion it's just hard, not next to impossible. Ten years ago the PowerPC platform was arguably a sound choice. Now ARM is challenging that, and the next few years will show how far it can make it into server and desktop markets. Some of the problems which surround a hypothetical migration might just go away, such as hardware cost in general, and specific hardware cost for custom designs.

Which leaves us with a) emulation or b) going back to 68k, which lately has promising (hobby) platform and performance perspectives because of the Apollo core. And users of classic systems won't be left behind, as they may either upgrade their machines with Apollo-cards or at least benefit from OS bugfixes and small improvements. It also has got at least some of the prerequisites you laid out.

I do prefer a "hardware native" platform with documented, predictable behaviour. It's hard to use the debugging and QA tools of old on an emulator, which keeps annoying me to no end. Nothing beats an operating system running on the bare metal, especially an operating system like AmigaOS which adds so few and such thin layers between the hardware and the operating system software.

However, OS3.1 also has the most legal problems, whether it's "companies" kicking each others shins or developers (who feel like they cannot contribute to e.g. AROS, because they have knowledge of original AOS sources) or else. I'm afraid it's still a mess, but at least it gained some "momentum" compared to the situation two years ago...

I am cautiously optimistic that the legal trouble will be resolved one way or another in the short or medium term. The longer this drags out, with resources going to legal counsel which would be better spent on product development, the more value will drain out of the platform. Who wants a Pyrrhic victory, really?

How do you judge the possibility to backport (parts) of OS4.1 to 68k/Apollo systems from a pure technical point of view? There has been an OS4 68k beta back in the day...

Development of AmigaOS 4 was "bootstrapped" on 68k because PowerPC hardware was not available for everyone early on, and also (more importantly) because the AmigaOS 3.1 code first had to be made fit for porting. All of that began about 15 years ago and concluded by 2006, if I remember correctly.

The early 68k material, possibly up to the mark around 2004/2005, could port with a little effort, and even then you would be limited to Workbench software, not Kickstart components. However, in the 10+ years since then, the overall integration of the code kept increasing, with new APIs replacing old functionality and workarounds.

The situation is not unlike the transition from Kickstart/Workbench 1.3 to 2.x. For a brief time you had both backwards and forwards compatibility (e.g. asl13.library, gadtools13.library), but the effort of backporting code written for 2.x to 1.3 at some point was just no longer making sense.

So, long lead-up to a short answer: unless the conditions for a back-port were favourable (funds available, every AmigaOS 4 developer in agreement, target hardware specs clear, etc.) I do not see it happening. It's just too hard under the current circumstances, and the current circumstances do not suggest it might even be a good idea to try.

[Olaf Barthel]

Originally Posted by wawa

nevertheless i would be rather disppointed in your place.

I am not really disappointed.

It has been almost exactly 30 years now since I began using the Amiga, and eventually writing software for it. The Amiga shaped my life, my choice of profession, enabled me to conclude my professional education and to set up my own company. It has been a gift which kept on giving, and in turn, I tried to give back some of that gift in the work which I did for the Amiga.

From that long perspective, with all the ups and downs and the very low, low downs, it's hard for me not to feel "blessed" in some way

[wawa]

Originally Posted by Olaf Barthel

Ten years ago the PowerPC platform was arguably a sound choice.

you probably know better than me, but though, from my perspective, i beg to differ. ppc was a curse for (already cursed) amiga platform as soon as it came in question. most amiga users and developers left by then, including me (except keeping an amiga for certain appropriate tasks), and not even seeing ppc in action. the implementation was too clumsy and too expecsive to bother. it was prohibitive already then. i have checked it out in aftermath and i still consider ppc a mistake.

Nothing beats an operating system running on the bare metal

according to what i had to do with, fs- and winuae is a convenient tool for debugging. real hardware is more demanding but it also needs more time to do it proper. both platforms have their place in the process.

Who wants a Pyrrhic victory, really?

its been dragged out for ages. im simply not ready to wait another decade for someone to wake up in their office.

I do not see it happening. It's just too hard under the current circumstances

thanks for confirmation, again. maybe now we can finally resort of pipe dreams and move along with practically viable options.