AmigaOS 3.2 and beyond

[OlafSch]

Originally Posted by Fastdruid

Even with an FPGA based accelerator I don't see it. You're better off emulating a faster 68020 or '030/'040 than you are spreading into more cores. Although I grant if you have the ALU spare that just spinning up a second core would be easier.

I see AmigaOS 3.x as the legacy OS, yes it should get new features and updates but not at the extent of breaking everything that came before it. SMP is a problem that has proved tricky on AmigaOS4 with true multi-cored processors let alone on AmigaOS3 with kludged virtual ones while trying to retain compatibility.

https://blog.hyperion-entertainment....nt-and-future/

Finally, it's questionable on 68k if there would be any real performance improvement.

So it would be right at the very very bottom of any list I'd want the devs to spend time on.

if you have no automatic SMP you see no change even with multicore as long the software is not adapted. There is only few software where you would see the difference at all, f.e. adapted Raytracing software or CAD or a big database or a prefessional video software. But then you still have the problem with limited RAM range (32bit) so you need a 64bit system for that.

Of course you could also use SMP for the system but that needs a lot of work to adapt the desktop to it and amiga is so lightweight that I doubt that you experience much difference.

[Gorf]

Originally Posted by OlafSch

on aros smp support was added only at X64 platform. At the moment it is more important that as much software as possible works on aros 68k and that current hardware is supported and parts of aros are optimized. Even that is a demanding task. At the moment I do neither see the need nor the development resources for adding something like smp.

well ... this thread is called "AmigaOS 3.2 and beyond"

I fully agree with you on the priorities, I was only thinking ahead.

SMP is a typical "chicken or egg" problem:
why support it on the OS if there is no hardware?
why build SMP hardware, if the OS does not support it?

at one point someone has to make the first move....

[Gorf]

Originally Posted by Fastdruid

Even with an FPGA based accelerator I don't see it. You're better off emulating a faster 68020 or '030/'040 than you are spreading into more cores. Although I grant if you have the ALU spare that just spinning up a second core would be easier.

The Apollo core already has working SMT aka Hyperthreading (pretending to be dual-core) and AFAIK it is used by bypassing the scheduler for things like cpu-blitting.

Also for other FPGA-68K implementations it is probably much easier to double an existing core instead of making it faster.
On designs like Minimig or FPGA-arcade the memory bandwidth is currently not fully used - so this could be a way to go.

I see AmigaOS 3.x as the legacy OS, yes it should get new features and updates but not at the extent of breaking everything that came before it. SMP is a problem that has proved tricky on AmigaOS4 with true multi-cored processors let alone on AmigaOS3 with kludged virtual ones while trying to retain compatibility.

On AROS for x64 SMP is already reality. Supported by a modified scheduler.
On the Vampire there is hyperthreading.

[amigo1]

Originally Posted by Thomas Richter

Surprise, surprise. You can already do that right now. Actually, since Os 2.0. The libraries go into PROGDIR: and are found there.

Yes, thanks for reminding me! And that's one of the things I like about AmigaOS.

The problem is *not* the operating system, but developers. There is no need to clutter LIBS: with private libraries, or S:User-Startup with assigns.

I am so in line with Your opinion on this!

BTW, if you want to include PROGDIR:Libs as well: BetterOpenLibs exists, and is in Aminet. Its functionality is not included in 3.1.4 since it changes the behaviour of ramlib.

I did not know about BetterOpenLibs. There seem to be to versions on Aminet the latest v1.04.
This is neat, it cleans up the App drawer.
Would it make sense to integrate that in the OS instead of having a patch taking care of it?

[looseether]

Firstly, let me thank and congratulate all you developers on 3.1.4. It is an unbelievable thing to have happened to our humble platform. It's very nice too !
And now there is 3.2 in development with more improvements. I am lost for words to describe my gratitude. Just astounding really.

I have a kind of negative request and something that I haven't seen brought up in this thread (unless I missed it of course), and that is :
in this 3.2 update, please, please resist the urge to describe file and disk sizes the 'modern' way of KiB, MiB, GiB etc and please just leave them as KB, MB, GB etc.

If you really feel the need to change them to KiB etc can you allow a switch/preference/env variable so it can be toggled back to the traditional way of KB etc so the user can choose and make that decision for themselves ?

And this without recalculating the filesize so it is really just a visual label type thing.

If you were to hard-code it as KiB etc, it would most definitely be a complete deal-breaker for me, which would be a pity.

With that caveat in mind, keep up the excellent work folks; this is VERY exciting

[Minuous]

Don't worry, we don't like "kibibytes" and such nonsense :-) 1K = 1024 bytes.

[looseether]

Originally Posted by Minuous

Don't worry, we don't like "kibibytes" and such nonsense :-) 1K = 1024 bytes.

Thank you for that !

[amigo1]

Originally Posted by Minuous

Don't worry, we don't like "kibibytes" and such nonsense :-) 1K = 1024 bytes.

But it's wrong!!

[malko]

Originally Posted by amigo1

But it's wrong!!

Really?
It's the angle of view that's important.

source Wikipedia :

[...]
(Kilobyte)
In some areas of information technology, particularly in reference to digital memory capacity, kilobyte instead denotes 1024 (2^10) bytes. This arises from the powers-of-two sizing common to memory circuit design. In this context, the symbols KB and K are often used.
[...]
(JEDEC)
The specification contains definitions of the commonly used prefixes kilo, mega, and giga usually combined with the units byte and bit to designate multiples of the units.
The specification cites three prefixes as follows:
kilo (K): A multiplier equal to 1024 (2^10).
mega (M): A multiplier equal to 1,048,576 (2^20 or K^2, where K = 1024).
giga (G): A multiplier equal to 1,073,741,824 (2^30 or K^3, where K = 1024).
[...]

[E-Penguin]

It makes a difference when dealing with large data volumes (where 1k = 1024) and low data transfer rates (where 1k = 1000). Those 24 bytes start to add up and be significant.

[Minuous]

Originally Posted by amigo1

But it's wrong!!

It's not. See eg. the glossary in the official Style Guide.

[Fastdruid]

Originally Posted by OlafSch

SMP on 68k? For what hardware?

I'd like to take my previous statements back.

Turns out that the B2000 was designed as a full co-processor system and can (in theory) use both the original *and* CPU in the add-on board. It is entirely possible to have upgraded the original CPU in and added a brand new CPU.

Also see Gemini.

[amigo1]

Originally Posted by Minuous

It's not. See eg. the glossary in the official Style Guide.

I think I'll open a new thread for this!

[amigo1]

I found one little cosmetic issue, I don't know if it has already been reported. It is not so important anyway, as the contents remains intact.

When creating a new drawer from Workbench, no error message comes up if a drawer with the same name already exists in the same location.

and another thing in the next post.

[amigo1]

Besides the above, "dir" and "list" behave differently when they encounter directory names with forbidden characters. Like in the "Remus/modules" directory for example.
Why is the Author of Remus using the paranthesis in the naming scheme I ask!

If it's not too much of an hassle, maybe "list" can be made to at least behave as well as "dir"?

Here an example, assuming some dirs in "RAM:Test" named as in the table below when following the Dropbox link, the command

dir RAM:Test/ all

correctly list the dirs and their contents, while

list RAM:Test/ all

goes into a loop because of
- "Rename_Me_?"

If "Rename_Me_?" is removed from the directory,
"List all" stops for a "bad template" error because of
- "Rename_Me_("
- "Rename_Me_)"
- "Rename_Me_["
- "Rename_Me_]"
- "Rename_Me_#"

"List all" ignores the Directories
- "Rename_Me_()"
- "Rename_Me_[]"

"List all" stops for a "object not found" error because of
- "Rename_Me_%"

If it helps, the table (again, pls follow the dropbox link) displays what happens if "dir" or "list" are used with an apostrophe before one or both characters wich are offending the naming conventions. A little more consistency would be
helpful.
The most bothersome situation is when the "List" command just refuses to execute because there are some offending characters. e.g.

1.>"list work: lformat "setdate %p%n 2020-04-31" to ram:setdate-list

LIST: object not found

or

1.work:>list all files since sunday

LIST: object not found

https://www.dropbox.com/s/vtx0pmk8kg...06.47.png?dl=0

[Bruce Abbott]

Originally Posted by Minuous

7MHz is going to be slow no matter what you do. Better to optimize for a more modern CPU. Users with 32-bit CPUs like the 68020 do not want to run 16-bit operating systems.

68020 is in no way a 'modern' CPU, and Amiga OS has always been 32 bit.

Most upgraded their CPU 20 years ago or more when OS3.5 made it a requirement, no sense going backwards now.

No they didn't. OS3.5 was a boondoggle - the Amiga equivalent of Windows ME. Which is why to forward we had to go 'back' to 3.1.4.

The OS should be optimized for slower CPUs because that's what most Amiga owners have, and will continue to have while retro computing is a thing. If this isn't done, I guarantee that faster machines will also suffer, just like PCs did (and still do). First it will be that you need a 14MHz 68020 to get 'acceptable' performance, then an 040 or 060, a Vampire or even even higher. This goes against the spirit of Amiga OS, which was always designed to work efficiently on stock 68k machines. Once developers lose sight of that, the sky is the limit on bloat.

I have a Vampire equipped A600 which is blindingly fast, but I also have an A1200 and an A500. I want an OS that works better on all of them, not one that needs an 080 or better.

[coder76]

Bruce is right here. But I'm not sure if it makes sense to target a 7 MHz 68000 here, as OS 3.x was designed for AGA chipset. And that means 68020 is the minimum here. Does AmigaOS 3.0-3.1 even run on an A500 with 1 MB of memory? In any case no AGA features can be used on OCS/ECS machines.

[Thomas Richter]

Originally Posted by amigo1

Besides the above, "dir" and "list" behave differently when they encounter directory names with forbidden characters.

There are no forbidden characters. There are just characters that work differently than you may believe they work. Hint:


list #?


does not list the file with the name #?. Other wild cards are (,),~,[,],|,% and '.

[Thomas Richter]

Originally Posted by coder76

Bruce is right here. But I'm not sure if it makes sense to target a 7 MHz 68000 here, as OS 3.x was designed for AGA chipset. And that means 68020 is the minimum here. Does AmigaOS 3.0-3.1 even run on an A500 with 1 MB of memory? In any case no AGA features can be used on OCS/ECS machines.

As of 3.1.4, there is no relation between CPU model and chipset version anymore. An A2000 Kickstart would work with an AGA chipset, and a A1200 Kickstart would work with a 68000 CPU.

[lmimmfn]

Originally Posted by Thomas Richter

As of 3.1.4, there is no relation between CPU model and chipset version anymore. An A2000 Kickstart would work with an AGA chipset, and a A1200 Kickstart would work with a 68000 CPU.

The way it should be