Quote:

hth313 wrote: That might be because your Amiga cannot run modern software?

I can run some memory demanding applications like vbcc or gcc (compiling), NetSurf, Lightwave, ImageFX, TVPaint, Quake 1 & 2, DOSBox, etc. including with RTG. The application I have run out of memory most in is vbcc compiling large and complex sources with a little over 100MiB free before starting.

Quote:

I cannot even imagine trying to use a (modern) computer with less than 4GB, it would be too limiting.

Modern computers are wasteful but there are ways to save memory.

1) Use 25% less memory by using a 32 bit CPU or using 32 bit applications on a good 64 bit CPU.
2) Code uses 25% less memory on an architecture with better code density than x86_64 like the 68k.
3) A more efficient OS can save hundreds of MiB of memory.

@Fl@sh

I had compared a few of the libraries between 3.1, Aros and AmigaOS

Aros is of course based on 3.1 and includes extensions so there are similarities between all APIs but there are also differences on each platform. Short: Aros is similar but not identical to AmigaOS

@matthey

Software sells hardware (and by that OS)

So you need software to attract users but you only get new software when you already have users (=potential buyers)

The problem is we have only few users and thus no incentive to program new software (including games). Cheap hardware like RPi offers a chance to attract users and that attracts software.

Quote:

matthey wrote: Modern computers are wasteful but there are ways to save memory. 1) Use 25% less memory by using a 32 bit CPU or using 32 bit applications on a good 64 bit CPU. 2) Code uses 25% less memory on an architecture with better code density than x86_64 like the 68k. 3) A more efficient OS can save hundreds of MiB of memory.

Most of the memory consumed is not due to object code, but data. While you can save memory using 32-bit pointers, it does not help when the data needed goes into several GB size, you will risk running out of address space instead.

Linux of today takes like 200GB when up and running (I think). Lots of processes (30+?) and i did not do anything else than turn it on. Compared to NetBSD back in the days, I think it started with 6 processes when I logged in. The latter could (in theory) boot in 4MB. Still, 200MB or a tenth of it (if you consider a less bloated OS might need 20MB) is fairly small amounts when compared to 4GB and beyond.

A web browser takes several GB today, at least the way I use them. Linking Clang library takes 6GB on a 64-bit Linux. I have code building tools that consumes 3GB+.

Then I may want to start a virtual machine, and sadly, I can barely do it on my 16GB MacBook Pro when I have everything else up and running in my work environment.

Today people use in-memory data rather than rely on disk based databases for access, because it is much quicker and easier to have it in memory. The days of batch jobs are long gone. Today we have huge data sets and short response times, often over internet. Large amounts of RAM is the reason we can do it.

Amusing that you talk about that embedded needs to go 64-bit, while desktop should use 32-bit?

The days of 32-bit for general computing is very quickly coming to an end as far I as understand. However, the embedded side has need for resource optimized designs and it will most likely remain that way for the time being.

@hth313

What do we discuss about?

A professional desktop platform needs 64bit, SMP and MP (for security reasons). 64bit needs adapted sources, SMP breaks software (was tested on Aros). Of course it is possible but then we need software developers who write new software for it. I do not see where we could get those realistic. And where would be the advantage of such a modern but incompatible platform compared to Linux, Mac or Windows? I do not see a realistic chance.

Quote:

OlafS25 wrote: Cheap hardware like RPi offers a chance to attract users and that attracts software.

Yes, I am attracted!

I hope AROS and RPi will be my go-to hobby OS of tomorrow. The main reason I got that RPi in the first place was to try RISC-OS. In some way this idea of something different on cheap hardware worked on me at least. In the end I did not stay, but that was mainly due to the situation of RISC-OS software.

Quote:

OlafS25 wrote: What do we discuss about?

Basically that computers of today need a minimum of 4GB, at least if we want to run modern software.

@hth313

4 GB is ok today (as long you do not something heavy like video editing)

But if you have a lightweight OS like Aros and you do not need to start a virus scanner and lots of other services you have on professional platforms then I think 2 GB might be enough

Of course 2 GB might become a problem with heavy professional applications and big data

Nice about Aros is you have different options. But Aros basically still is 32bit up to now

@matthey
Quote:

ARM has replace the Cortex-A53 with the Cortex-A55. Sorry if my post sounded like the Broadcom SoC and Pi4 would receive it (edited for clarification). Yes, it is the logical successor.

I could be wrong, but I strongly suspect that the Raspberry Pi 4 will be using a Broadcom SoC with a VideoCore 5 GPU, as this would be a decent upgrade from the VideoCore 4 GPU that all other Raspberry Pi devices have used to date, as well as making use of the open-source V3D driver that Eric Anholt has been working on ( https://anholt.github.io/twivc4/ ).

With that in mind, I would make an educated guess that the Raspberry Pi 4 will be based on a Broadcom BCM7xxx series SoC, and may be close in specs to something like this:

https://www.cnx-software.com/2018/04/13/com-hem-tv-hub-is-an-hybrid-tv-box-powered-by-broadcom-bcm7271-soc-with-videocore-v-gpu/

@OlafS25

2GB is fairly okay. I mean my MorphOS setup plays in a similar league (G4@1667MHz) and the RAM is not too few. The most RAM demandig usage is of course web browsing.
On a RPi with AROS this wouldn't be any different.
If we are honest more RAM demanding applications are rather unrealistic for an Amigaish system (over the next few years at least).

_________________
My programs: via.bckrs.de
MorphOS user since V0.4 (2001)

Quote:

hth313 wrote: Most of the memory consumed is not due to object code, but data. While you can save memory using 32-bit pointers, it does not help when the data needed goes into several GB size, you will risk running out of address space instead. Linux of today takes like 200GB when up and running (I think). Lots of processes (30+?) and i did not do anything else than turn it on. Compared to NetBSD back in the days, I think it started with 6 processes when I logged in. The latter could (in theory) boot in 4MB. Still, 200MB or a tenth of it (if you consider a less bloated OS might need 20MB) is fairly small amounts when compared to 4GB and beyond.

Large amounts of data is the problem but it all helps and more than a little. Use of 32 bit pointers and reduced alignment restrictions can reduce the data usage by more than half in some cases. Reducing the code size doesn't sound like much but most of the OS is code too. Expect a noticeable difference when moving from an architecture with a fat ISA like PPC to one with good code density like the 68k which can be 40-50% better (easy to see on the Amiga between PPC and 68k). It is conceivable to save 0.25 to 0.5 GiB of memory with a combination of good code density and an efficient OS (which have reduction synergies since the OS is mostly code). It is likely that 2 GiB of memory in an efficient computer could be roughly equivalent to a fat computer with 3 GiB and this "might be enough" for most modern computer users.

Quote:

A web browser takes several GB today, at least the way I use them. Linking Clang library takes 6GB on a 64-bit Linux. I have code building tools that consumes 3GB+. Then I may want to start a virtual machine, and sadly, I can barely do it on my 16GB MacBook Pro when I have everything else up and running in my work environment.

So C++ is the problem (joke but partially true). You are a power user with high performance hardware.

Quote:

Today people use in-memory data rather than rely on disk based databases for access, because it is much quicker and easier to have it in memory. The days of batch jobs are long gone. Today we have huge data sets and short response times, often over internet. Large amounts of RAM is the reason we can do it.

I'm aware of modern programs which load everything into memory and mmap large files. The big advantage is convenience but there can be advantages in performance and energy efficiency as well.

Quote:

Amusing that you talk about that embedded needs to go 64-bit, while desktop should use 32-bit? The days of 32-bit for general computing is very quickly coming to an end as far I as understand. However, the embedded side has need for resource optimized designs and it will most likely remain that way for the time being.

We were talking about entry level computing and the Raspberry Pi has shown that price is important. The embedded world recognizes the advantages of 32 bit CPUs while the cheapest entry level desktop computer went 64 bit without a need for the larger address space. Also, the Raspberry Pi is embedded hardware mostly targeted at the desktop. I did not say that embedded needed to go 64 bit either but rather that there should be a 64 bit upgrade path even for embedded. I expect 32 bit CPUs to continue to be the most popular in embedded for a very long time. C instead of C++ is the most popular language for embedded due to better performance and less bloat too.

Quote:

HenryCase wrote: I could be wrong, but I strongly suspect that the Raspberry Pi 4 will be using a Broadcom SoC with a VideoCore 5 GPU, as this would be a decent upgrade from the VideoCore 4 GPU that all other Raspberry Pi devices have used to date, as well as making use of the open-source V3D driver that Eric Anholt has been working on ( https://anholt.github.io/twivc4/ ). With that in mind, I would make an educated guess that the Raspberry Pi 4 will be based on a Broadcom BCM7xxx series SoC, and may be close in specs to something like this: https://www.cnx-software.com/2018/04/13/com-hem-tv-hub-is-an-hybrid-tv-box-powered-by-broadcom-bcm7271-soc-with-videocore-v-gpu/

So still the Cortex-A53 (with maybe a little faster clock speed?) but a better GPU. The Raspberry Pi Foundation must not want the upgraded Cortex-A55 or maybe they don't have a choice. Broadcom is the top of the food chain and decides what is best for all their customers. It's no different than the Tabor ending up with the e500v2 cores as leftovers from Freescale/NXP embedded customers.

@Zylesea

I think so too

when you have a professional system running as a database server or work professional with big data like video editing and similar then of course not but anything amiga related will be private use, the OS itself is very lightweight too so the 32bit barrier is not a problem in my view

@thread

it was often critisized that Aros has nothing like Petunia. Michal is now creating something like that on RPi so 68k software that not hits hardware will hopefully directly work without UAE. When people ask for modern features like 64bit then this will not be possible anymore. Also SMP breaks amiga software and for sure MP. A modern system in todays terms will be different and software has not just to be recompiled but adapted. Who will do that? And what happens with old software without sources? People sometimes seem not to be aware of what they ask for.

Last edited by OlafS25 on 14-Feb-2019 at 09:43 AM.

@Signal

Quote:

There should be room for both. I do like the idea of AmigaOS on the RPi. I would also like to see a path forward for those that would want more powerful, expandable systems.

I never said "let the high end systems out of the market", I'm simply convinced that, at least in the current state of the Amiga market, a (successful!) low-end platform is a priority.

After all, we know what happens when your only choice is a high-end hardware: A1000 did relatively fine if you want, but the true success story was the A500.

To me, it makes more sense to build a low-end market first, and then trying to expand it with more powerful configurations. Not the other way round.

We must keep realistic expectations.
Nobody is going to write a decent amount of software for a userbase amounting to what, 2-3 thousands people? On the other hand, a cheap box MIGHT be able (nothing is a given, mind you) to reach far bigger numbers, and from there you can start building a healthy software ecosystem.

@Turrican3

I totally agree with you.
Amiga needs to restart from bottom, like A500 did.
RPi could be an optimal choice but, if someone is able to build a ppc mobo at really low price, it could be ok too.
There is no technical reason to discard ppc cpu in favour of arm, x86 or something else.
If Tabor will cost no more than 150$, with an OS4 licence included, it could be another good possibility.
Sadly we know the cost will be much higher, if ever released, so I don’t think it will be able to raise Amiga users base.
So to avoid dipendece from exotic, not common and high cost cpu and mobo projects the best solution is to make amigaos cpu agnostic and port it to a wide spreaded low cost hw just like RPi.

_________________
Pegasos II G4@1GHz 2GB Radeon 9250 256MB
AmigaOS4.1 fe - MorphOS - Debian 9 Jessie

@OlafS25

Quote:

it was often critisized that Aros has nothing like Petunia. Michal is now creating something like that on RPi so 68k software that not hits hardware will hopefully directly work without UAE. When people ask for modern features like 64bit then this will not be possible anymore. Also SMP breaks amiga software and for sure MP. A modern system in todays terms will be different and software has not just to be recompiled but adapted. Who will do that? And what happens with old software without sources? People sometimes seem not to be aware of what they ask for.

AROS@Petunia could be a nice project to gain compatibility with many old closed source amigaos 3.1 software.

The best solution should be a native recompile of most used and usefull packages for AmigaOS 2.x/3.x
So I hope many developers will publish on Aminet their source code.
As example I used do it for every program released.
Too many times I read about loosing of sources due to hard disk failure or something similar..

_________________
Pegasos II G4@1GHz 2GB Radeon 9250 256MB
AmigaOS4.1 fe - MorphOS - Debian 9 Jessie

@matthey
Quote:

So still the Cortex-A53 (with maybe a little faster clock speed?) but a better GPU. The Raspberry Pi Foundation must not want the upgraded Cortex-A55 or maybe they don't have a choice. Broadcom is the top of the food chain and decides what is best for all their customers. It's no different than the Tabor ending up with the e500v2 cores as leftovers from Freescale/NXP embedded customers.

To be clear, nothing about the Raspberry Pi specs has been officially announced as of yet (as far as I know), but my guesswork is based on three assumptions:

1. The Raspberry Pi 4 SoC is highly likely to be based on a SoC from Broadcom, due to the close working relationship that the Raspberry Pi Foundation has with Broadcom.

2. It's highly likely that this SoC will use the VideoCore 5 GPU, as this is the next logical step up for the GPU.

3. If the Raspberry Pi 4 is due to be released in 2020, the SoC that is used is either likely to be one that already exists on the market or heavily based on one that already exists on the market, in order to help keep the costs down.

Based on these assumptions, I would say that the best way to guess at the power of the Raspberry Pi 4 is to look at the existing Broadcom SoCs with VideoCore 5 GPUs and either consider if that SoC would be a good choice, or consider if it would be a good choice with a few tweaks. For all I know, one of those SoC tweaks may end up being the inclusion of Cortex-A55 CPUs, but overall I'd say the specs will be similar to one of the group of SoCs I referenced above.

Quote:

Fl@sh wrote: I totally agree with you. Amiga needs to restart from bottom, like A500 did.

+2

Quote:

RPi could be an optimal choice but, if someone is able to build a ppc mobo at really low price, it could be ok too.

I have read that the PPC Efika dropped to $99 U.S. back when there was a lot less competition in the SBC market. It was severely handicapped by lack of memory and the performance was poor. The Efika MX CPU was changed to a 32 bit ARM Cortex-A8 with Thumb2 (code density similar to the 68k) which is better performance and the memory increased. There was even an Efika MX Smartbook which sold for as little as $199 U.S. Low end PPC CPUs have historically had awful performance because they are cache and memory hungry. Remember the PPC 603 where the engineers thought they could get away with the same size caches as the 68060? It did severe damage to the reputation of Apple and PPC. The 68060 had better single core integer performance while using only 32 bit data paths to the memory allowing for cheaper memory (the Pentium couldn't outperform either with a more aggressive performance design and more expensive memory like the PPC).

Quote:

There is no technical reason to discard ppc cpu in favour of arm, x86 or something else. If Tabor will cost no more than 150$, with an OS4 licence included, it could be another good possibility. Sadly we know the cost will be much higher, if ever released, so I don’t think it will be able to raise Amiga users base.

ARMv8 is closer to PPC but looks like an improvement to me. It is still giving up the ability to scale down to where Thumb2 and the 68k were able to go. There is a technical difference in low performance hardware.

There is no way the Tabor could be sold for a profit anywhere near the $150 price range. The CPU alone had a suggested resale price of $42.41 U.S. in quantities of 10k.

https://www.eetimes.com/document.asp?doc_id=1254555#

The Tabor board is *not* cheap with lots of expansion too.

Quote:

So to avoid dependence from exotic, not common and high cost cpu and mobo projects the best solution is to make amigaos cpu agnostic and port it to a wide spread low cost hw just like RPi.

The dependence is on hardware providers who limit choices and have high profit margins which inflate prices. Each Tabor CPU (SoC) likely cost more than a Raspberry Pi. In order to come close to competing, we need mass production, an SoC at a fraction of the cost of the Tabor CPU and a small footprint. This is not going to happen with a PPC CPU but I outlined how it may be possible with a 68k SoC.

@Fl@sh

Quote:

The best solution should be a native recompile of most used and usefull packages for AmigaOS 2.x/3.x So I hope many developers will publish on Aminet their source code. As example I used do it for every program released.  Too many times I read about loosing of sources due to hard disk failure or something similar..

Doubt you would be able to get the sources to do this and that's assuming you could contact the authors even. Then is there really enough comparability between AmigaOS and AROS for them to work?

On a side note I wouldn't be interested in a RPi 'Amiga', had a RPi and found it sluggish as a Linux desktop, would rather pay more for a better experience.

@Fl@sh

Quote:

Fl@sh wrote: RPi could be an optimal choice but, if someone is able to build a ppc mobo at really low price, it could be ok too. There is no technical reason to discard ppc cpu in favour of arm, x86 or something else.

Been there, done that. Well, kind of. I mean more than 10 years ago Genesi pursued such an approach with the Efika. I evaluated the Efika 5200B, it was nice and competetive to some regard but eventually had too many limitations (no inbuild gfx, no usb2.0). Same was true for the 5200B Board by TQ systems (Munich) I evaluated at about the same time.Then Genesi announced the Efika5121 - a real small and cheap board. As the core of the 512x was a bit incompatible (no hardware cache coherence) to the 5200B the board was not continued.
A bit later I put some work into designing a ultra low cost mini board again. Eventually I came to conclusion that the ship had sailed. The ppcs can't compete with the RAM offerings and - outside the Amiga sphere - have no advantage (except maybe for networking). You need real high volume if you want to provide a competetive price tag. But you will not meet the ARM price regions. PPC is dead, unfortunately.

Here's the very little I publically wrote about that project back then: https://via.i-networx.de/eframe/eframe.htm

If you are really interested in evaluating the options of a raspberry pi like device but ppc based and think - after your own research - this could be a vialbe option then consult the guys from bplan or TQ or nxp directly. I have my serious doubts though.

_________________
My programs: via.bckrs.de
MorphOS user since V0.4 (2001)