@Hans

But those same die hard 68k fans run their true Amigaos3.x on Fpga reimplementation of 68K ISA with alien extensions like AMMX and Saga. Or even 68k emulation on ARM cpu's. At a price/performance ratio which is even worse then NG hardware. It looks to me that the only thing that matters is the old machine.

Which makes me wonder if a PowerPC accelerator which could either run OS3.x on top of petunia or OS4.1 would be accepted.

@Hans

Quote:

Yes, there are some reversed engineered drivers available but they are slow and not really stable for obvious reasons. And some drivers seem open source but still need a binary component. Like the ARM MALI drivers for example.

In any case, switching ISA again will be at least as painful as it was for the 68k->PPC switch. Although a lot of code is written in C nowadays. There are simply less developers available to do the job then there were 15 years ago.

@Hans

Quote:
I agree that most negative comments in your survey are made by people who will never buy real hardware. And probably don't even use OS4 on an emulator. However it would still be nice to get a better view on the wishes of those who are genuinly interested to buy new hardware.

Quote:
Not sure if ARM will be of any help for the future of AmigaOS4.
You can forget about those mobile phone CPUs. GFX drivers are closed source. And they are obsolete within 3 years. If they offer PCIe at all then it is limited to one or two controllers with a low amount of lanes. Memory is stacked on top of the CPU package. Lack ethernet MACs. And they only sell the CPU platform (CPU+modem+PMIC) to a handfull of top tier manufacturers. Both Qualcomm and Samsung tried to enter the industrial market with some offering. The SD410 was for sale. The SD600 required approval before you could design with it. The SD820 was only available for selected SOM partners. And similar to the T10x2, the SD820 chipset price tag was about EUR 130 (@10k annual qty).
Those small form factor devices like RPI are a couple of steps backwards compared to the X5000 when it comes to GFX solutions. I doubt if the experience will be better compared to QEMU on a fast PC.
And ATX/ITX form factor boards are niche. Some manufacturers tried some server ARM boards (eg Gigabyte MP30-AR0) but they are not on sale anymore or ridiculously expensive.
So if we want a step up from the the X5000 with ARM then we are back at custom hardware again. With for example a NXP Layerscape CPU. Which again means a CPU which is tailored toward networking Alternatively, we could use a nVidia Jetson like module and forget about the embedded GPU. But do not expect much price difference compared to a SAM460.

And the most important questions are: Who will port OS4 on it? And how many decades will it take? How many users are left by then?

So in my opinion, the only "short term" solution would be a lower cost T10x2 based platform. Even if its only meant to bridge the gap.
The T10x2 uses has the same e5500 core as the X5000. Uses almost the same peripherals as the X5000. This means a minimum software effort to get OS4 running on it. The only issue is. Are all parties involved (OS4, ExecSG) also willing to support it and at what cost.

PS. A e6500 core option would be a step up from the X5000. And I would buy it of course at a sensible price. But this will not sell below E1000 because the CPU itself is already >EUR300.

@Templario

I don't think that you'd to pay for OS4 updates. At least the latest one was for free. Afaik, only 4.0 and 4.1 were paid releases. Enhancer is a seperate commercial product.

And obviously Hyperion wanted to see money for 3.2 as well. And as long as people are happy to pay for them, why not?

I cannot comment on the business model for MorphOS. I don't use MorphOS. But my persional view on the MorphOS team is that it consists of a bunch of friends who like to create an OS in the spirit of AmigaOS. And that the money they make of it is more related to bounties and license cost of third party components. There seems to be less of a commercial drive behind it.

@Hans

There are some nice anwers in there:

Quote:
If he want everything for free then he must be running his linux in "the cloud"

Quote:
There are different definitions of "pointless"

Quote:
Which of course cannot be broken by leaking batteries and short circuits.

But jokes aside. It would be nice to have a follow-up survey where you could ask the emulation users to elaborate more on price and price/performance ratio. So what would be an acceptable price for entry level PowerPC hardware and what performance level would be acceptable compared to eg. a SAM460. what features would you rate important (1-5) where 1 is least and 5 is most:
- Processor speed compared to SAM460
- Memory speed compared to SAM460
- All-in-one (as opposed to bare minimum with expansion slots)
- On-board 2D only gfx output
- USB speed (2.0 vs 3.2)
- amount of USB ports
- USB-C connector
- amount of PCIe slots
- SATA connectors
- NVME slot
- Audio quality
- Audio channels
- Smallest form factor (eg miniITX)

And a multiple choice or open question for an acceptable sales price for the filled out answers above.

@Rolar

Quote: Then it definitly seems timing related. What you can do is remove nvme.device from the kicklayout and mount the partitions with sys:System/Mounter instead. Make sure that you change the device in the tooltype to nvme.device.

Quote:

No idea. I don't mount myself but hand it over to the mounter.library. However, there might be a configuration file somewhere.

@Rolar

Did you activate the debug kernel in your kicklayout?
You can also try to increase the debug level.

But be prepared to have your debug terminal flooded with info

@Rolar

No, I do not know how hiding icons affect amigaos. Maybe @Joerg knows what could be the issue.

This doesn't happen for amiga filesystems. So one thing I could think of is that the NTFS-3G/Filesysbox combo might not have been implemented with fixed storage in mind. And removable storage like USB drives might be loaded and mounted after all dependancies of NTFS-3G/Filesysbox are available.

@joerg

Never mind, my stupid mistake. Forgot to handle the upper 32bit of the address. ( iotd_Req.io_Actual ) in my Benchmark tool.

@Rolar

https://wiki.amigaos.net/wiki/Advanced_Serial_Debugging_Guide

@joerg

In my driver there is no difference in how I handle both commands. It always handles the address as 64bit. I just additionally zero the upper address for CMD_READ to make sure that there's no garbage which could Lead to a wrong address. I also see no difference in execution time within my driver. This looks OS4 related.

@Rolar

For now it is a tool to profile my code and see how I can ootimese the speed. But I do intent to release it as a standalone tool some day.

One of the things that I've learned is that a DoIO() with CMD_READ (32bit) is executed much faster is than NSCMD_TD_READ64 (64bit). No idea why this would make such a difference for OS4.

@joerg

A nice. Thanks for the effort.


In the meantime I have created my own benchmark. It's rudimentary for now but I intend to expand it with a graphical printout like those nice PC tools.

Anyways, here's the result:

Samsung SSD Connected to the X5000 internal SATA port. At 32MByte and onwards it starts to divide the transfer in chunks according to the output on the debug terminal


Samsung NVMe SSD:
Starting at 16kb I have to get the physical page addresses of the read buffer to create a " Physical Region Page" list and feed it to the NVMe controller. Getting the physical address of a page in supervisor mode creates a lot of overhead as can be seen from the transfer speed. That's why pipelining of commands is so important as can be seen for the larger transfers.
In the future I want to rewrite that part of the driver to use Scatter Gather lists. If the buffer isn't fragmented then this should reduce overhead severely.

@Georg

You are right. It's indeed using UNIT_VBLANK.

I use UNIT_MICROHZ to request the current system time. But I could also use the eclock. I don't know if this makes much difference for timing in the miliseconds range.


I could also do two calls to ReadEClock. Substract the results and divide by the countrate. Maybe this is even faster and more accurate.

@joerg

Something looks seriously broken with scsispeed.

I've used the following command:

(Yes, I know, 4 times 16MB. But it was for diagnostics purposes)

I've tested the same command on my latest driver both with and without debug printouts to the debug shell.

The debug driver prints a string with the following information for each read action:
- The timing of the IO command
- The timing of the NVME read handler
- Time between issued IO commands
- Lenght of read size in bytes

So that's a debug terminal full of data

Then scsispeed reports 220MB/s for all four tests. This low speed is understandable due to the additional time it takes for the debug strings.

Debug printout show that the readspeed is actually happening at close to maximum PCIe speed. This was expected given the small overhead at these ind of transfers. Also the time between commands about 8 us.

But when I run the same benchmark while the debug printouts are disabled then the reported speed drops to just 50MB/s

So something is clearly off here.
A quick scan through the scsispeed source shows that there's some timer trickery happening. According to the source because of a low timer resolution. But a microseconds resolution is sufficient to time these kind of transfers. So apparently this trickery is not working properly or some overflow occurs.

Anyways, the benchmark is just a low level timed CMD_READ loop. I will create one myself without the trickery and up to date Exec calls against the latest SDK.

A simple ITimer->GetSysTime() before and after the DoIO() and then a ITimer->SubTime() should do the trick.

@Maijestro

The SM502 data manual says that the chip supports 32bpp for the main and video layers.

The sam460ex manual says the following:



It doesn't elaborate on "Some operating systems" or why there's this limitation.

@virgola

0:08 on my X5000 with Lame 3.100

The high performance core in your I7-1265u itself is about 10x faster than the e5500 core. The memory performance is even better (compared to the poor P5020 single core DDR memory performance). Yet the result is 8 times slower under winuae and almost 10 times for QEMU. This means an emulation efficiency of 1-1.25%. I would expect an emulation efficiency of about 10% so something is definitly wrong here. Maybe no JIT like Hans is suggesting?

@Rolar

Quote:
I actually just did the performance analysis

My result is ~85MB/s with NTFS. This is way slower than SFS2.
The net write speed isn't that all bad at ~500MB/s. But still only 1/3th of SFS2.
The 1024MB file is split in 20x ~50MB transfers when I use BUF=65536.
But for some reason, there's a small read (64kb each) before and after such a ~50MB write with a total command delay of ~500ms. So in total 20 * ~500ms = ~10 seconds. That's why the write actions doesn't take 2 but ~12 seconds to complete. Hence the very slow performance.

As I understand it, AmigaOS4 includes a port of NTFS-3G which has to go through an additional library called FUSE/FileSysBox. The sources are available in the download section of Hyperion (login required). So if anyone has some spare time and motivation to find out where the 100ms+400ms command delay for those two reads comes from then feel free to do so

EDIT: I suppose that Linux on your X5040 will use all 4 cores when performing that benchmark. Unlike SFS2, NTFS-3G gives a 100% CPU load. So this is also a factor to consider when comparing NTFS results.

@Raziel

Yes, I don't see a reason why it isn't possible. It's a matter creating a vitual device driver with the total size of the BOD and redirecting IO to the right drive. Adding sodtware RAID 0 and 1 is also fairly easy.

There's actually already a software RAID driver on os4depot (swraid_device).

@Rolar
This command will make the shell print the execution speed of a shell command:

prompt "%N.%S [%E s] >"