Quote:

gregthecanuck wrote: This is the kicker. Hardware sold is going to drive the demand from the users. I don't think AmigaOS is attractive enough at this point to drive demand for ports to platforms like the RPi or PCs. There is already UAE.

UAE is more convenient for most users and probably the largest Amiga base at this point. In comparison, the Raspberry Pi lacks performance but has other advantages including, cost, size, energy efficiency, quietness, hardware standardization and well documented hardware. There are Amiga (and many non-Amiga) users already using it for (often personal) embedded systems. This is what lower end Amiga hardware should be like although the Raspberry Pi is subsidized so Amiga hardware could probably not be quite as cheap. I think fairly comparable hardware with a few more features (SATA and FPGA) could be mass produced costing 3 to 5 times as much. The end of Moore's law makes it attractive to create hardware again. Well designed hardware can have a market life of many years as endless die shrinks by the competition are no longer possible. It may even be better to back off from the most expensive die sizes and use much cheaper and more reliable processes. A simpler CPU design is cheaper to design and can have benefits as the Raspberry Pi CPU offers better security and energy efficiency than more aggressive CPUs.

Quote:

Remember why the Amiga was purchased? Bang for the buck, bare-metal performance, etc... Now a lot of demand is coming from nostalgia. The A1222 and Vampire are getting back to that. As far as I can tell quite a few Vampires are being sold (all that can be made) and I expect that once OS4 issues with A1222 are sorted out quite a few of those systems will be sold as well.

IMO, both the Tabor and Vampire miss their marks on features and price/performance.

The Tabor is not retro Amiga compatible and is barely even PPC compatible. The CPU e500v2 cores are a horrible bastard design made for embedded systems. The FPU is removed and there is no Altivec SIMD unit but rather cut down half way similar functionality added into the integer unit all using the same register file with 64 bit wide registers (including the 32 bit GP integer registers). Is there a realization that all those registers and register files that PPC fans are so proud of reduce energy efficiency and slow interrupts? Funny part is that this barely PPC Book E implementation doesn't support the PPC Variable Length Encoding (VLE) to reduce instruction fetch cost (one study found 42% of a typical embedded 32 bit RISC processor’s energy consumption comes from instruction fetching). The Tabor SoC implementation creates many new registers which bring PPC acronym hell to new heights. The MMU is much different and requires much more work to support. I bet the AmigaOS 4 developers are cursing this design endlessly as it wastes more and more or their time. This CPU should go down as one of the worst CPU designs ever created. The quick change to the e500mc core is an indicator of how bad this CPU design is. The e500mc core is an improvement but is still vulnerable to Spectre attacks which will likely never be fixed so probably isn't worth upgrading.

The Vampire gets the retro appeal and compatibility right. It however misses the mark on having a proper upgrade path to a mid-performance CPU. Tying the SIMD unit to the integer unit in the ISA practically limits the SIMD unit to an an antiquated 64 bit wide standard (a modern 256 bit wide SIMD can do 4 times as many operations per instruction). Adding more registers everywhere they can be squeezed into the ISA also reduces the appeal of the 68k for embedded applications, uses up valuable encoding space and makes the 68k more difficult to use while giving little value, especially with compiled code. There is little in the way of 64 bit addressing support necessary for a 64 bit system (64 bit absolute addressing is very wasteful). Gunnar missed his opportunity to mass produce an ASIC in the millions for the very hot IoT embedded market using old underutilized fab technology which could have produced ASICs for a fraction of the cost of Freescale CPUs. The CEO of the IoT embedded hardware cut his teeth on the 68k and "can program assembler in 68k like the wind". Yes, code density is important to him and he knows the 68k has better code density than what he is currently trying to use. If he could have been convinced to use the 68k with it adapted to his requirements, I believe we could have had Amiga boards for 3 to 5 times the cost of the Raspberry Pi.

Quote:

We have the "current generation" Amiga OS running on 68K and PPC. I do not believe OS4/PPC is "next generation". To me "next generation" means a breaking update to AmigaOS (memory protection, SMP, ...).

A breaking "compatibility" update is next generation AmigaOS?

I have no doubts that SMP, partial memory protection and resource tracking are possible with compatibility but may require custom hardware. Security with compatibility is the difficult part. My protection ring idea would likely require the fewest changes to the AmigaOS and least amount of performance loss. It may even result in a performance gain compared to other OSs with security. Think of hardware designed for a microkernel which substantially reduces the Inter-process communication user to/from supervisor overhead which gives microkernels the reputation of being slow. If effective enough, it could spell the end of the monolithic kernel. Most CPUs/SoCs are designed for big monolithic kernels but we need efficient, high security and tiny footprint microkernel OSs in embedded hardware. This is another huge embedded market with billions of devices. If I could make 1 cent off of every microkernel embedded device sold, I could probably buy out every Amiga business in less than a year.

Quote:

On the Vampire side the Apollo core is more powerful per clock than PPC and likely ARM at some point. The core team is continually upgrading the core architecture. PPC is pretty much done once the current generations have been accounted for in possible future OS4 ports.

I would say that the Apollo Core is slower per clock in single core performance than most PPC CPUs still. Some logic in an FPGA is slower like a MUX and the amount of logic in the low end FPGAs used in the Vampires is more along the line of a 1990s CPU. There are some areas where Apollo Core outperforms most RISC CPUs like in memory/caches. RISC needs to be wide issue to fetch enough instructions to keep up with CISC and then needs OoO and long unrolled loops to avoid bubbles. RISC CPUs are simple and easy to design but CISC has better performance traits (fewer instructions, better code density, less memory traffic, etc.). The 68060 beat most RISC CPUs of its time in single core performance using less resources so I expect a modern 68k would have no trouble matching at least in order RISC performance and probably at a lower clock which is lower power consumption, less heat, more reliable, less electromagnetic interference, cheaper to design boards and good for embedded.

Quote:

On the OS side I agree on the money-making potential of simply working on Amiga OS. The user base just isn't there to support it (hence Hyperion's money troubles?) in any major way. That is my reason for suggesting to just open source the thing. Hyperion (of whoever will own it after all the legal foo) has to find some way to make money obviously but perhaps they need to go back to their roots and start porting software/games? License the OS for commercial sales (Apollo, A-EON, Amigakit, ?Cloanto?). I am tired of seeing forked OS. We have OS3.x, OS4,x, AROS, MorphOS, ... I would hope open-sourcing OS 3.x would bring some developers back into the fold. Grab the "good stuff" from AROS. Fork it so somebody can play with an RPi port, or start on a next-generation experiment. Now real bounties can be implemented. Other open-source code could be pulled in (such as Linux device drivers) without fear.

AmigaOS is still treated like it could be sold for gold. Those days are over. AmigaOS would get better development if the source was available even if it wasn't free. I did a fair amount of work on vbcc which would not have happened if the source was not available (it is not free but there are advantages to having sources available). It is even more important and common to have sources available for an embedded OS/RTOS. We need to consolidate some of these many forks of AmigaOS and try to have similar APIs. Way too much Amiga developer effort is wasted.