@Gunnar

Quote:

Gunnar wrote: @bhabbott Quote: The Amiga didn't have multicore, 64 bits, memory protection etc. because such hardware didn't exist. What's the point of adding features to an OS that cannot be used? Amiga OS was not 'crippled', it was tuned to the available hardware and intended usage. There's nothing wrong with that. What do I like about Amiga? I like a lot about the AMIGA its light weightiness and swiftness. The Amiga boots in few seconds. The OS is slim and light.

If you remove all checks... then yes.

It's like a car where you've removed the ABS, the parking sensors, the instrument cluster, media player, wheel rim, etc., the safety belt and even the brakes: it's more lightweight and go fast, but you can easily crash when turning the curve...

Anyway, nowadays even PCs running Windows boot in a few seconds.
Quote:

The Amiga chipset allows to do many things very efficient. Dragging down screens is done for "free" with the Copper and there is no need to copy mega bytes around for doing this.

Sure, but nowadays we've completely different ways of generating graphics and we've graphics cards embedding tenth of thousands of small cores ("coprocessors") that can do much more work compared to the very simple (and slow) Copper.
Quote:

Programs can be coded on Amiga small and swift too. I can directly ask the mouse button using only 1 instruction. There is no need to go through layer over layers of abstraction.

http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node000A.html

However, as a general rule, it is not permissible to directly
access the hardware in the Amiga unless your software either has full
control of the system, or has arbitrated via the OS for exclusive access
to the particular parts of the hardware you wish to control.
[...]
The following list will help you to find
the appropriate operating system functions or mechanisms which may exist
for arbitrated access to the hardware discussed in this manual.

Hardware component Amiga system module that controls it

Gameport.............input.device, gameport.device, potgo.resource
Quote:

TO ME: these are all good features. And they part of my Amiga feeling.

At the time, yes: it was also mine.
Quote:

Why does AMIGA have this and other OS do not?

Different designs.

Other OSes had the chance to evolve to the current systems thanks to a completely different design.

Whereas the AmigaOS wasn't able to do it (included the rewritings) and will never do it.

Again, different design choices brought to completely different situations.
Quote:

Could programs be so light and fast on Linux for example? No they can never be so slim and light and fast as on AMIGA OS. And this because of the different design of both OS. Linux forbids direct hardware access .. And many things which go fast and direct on Amiga - become slow and complicated on Linux.

Linux is a monster. There are other OSes with fully-fledged memory protection, SMP, resource tracking, etc. etc. etc. which are also very light-weight and fast to boot.

The first time that I've seen QNX I was shocked: a complete, modern, OS which was running from a 1.44MB floppy and which was even embedding a web browser.
Quote:

So yes Amiga is different to Linux .. it has no memory protection ... But this is good in many ways ...

Seriously no: memory protection is a Great, Good Thing.
Quote:

If Amiga would be like Linux, would also be not a lot slower? Think about it.

Well, to be more precise, it depends also on which Linux you're talking about.

Yes, Linux is a monster, because it has A LOT of things which are normally embedded. However you can also fine-tune it in every detail.

On automotive we use it a lot with customized distros (using the Yocto "meta-distro" project). It was needed because we need to control every single aspect of it, included the boot time.

That's because on some countries it's mandatory to have the system "active" (information panel on displays, and the instrument cluster) WITHIN 2 (TWO!) seconds.

Yes, we've Linux which boots and shows the information panel on the displays in at most TWO seconds, once you "turn on the key" of the car.

And that's Linux: the "monster" which I'm talking about.

And no, there isn't a super computer inside: SoCs on automotive are quite old stuff (since projects already started SEVERAL YEARS ago) AND using relatively simple CPU cores (Atoms for Intel SoCs.; NOT the new Atoms, of course: the OLD ones. And Cortex A53 for the new ARM SoCs, if I recall correctly) AND using a few cores AND using some GB or memory AND using relatively old GPUs embedded.

The new SoCs for the new projects are much more powerful (but still small things compared to the CPUs and GPUs which we've on our PCs) but it'll take time to have them on the market.

In short: the situation is very very different even when talking about the monster that it is Linux.

So, pay attention when making comparisons like that: they strictly depend on a specific computer & hardware: no general claims can and should be made.

@cdimauro

Quote:

cdimauro wrote: I know it. But do you know this: http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node0003.html These are the hardware components of the Amiga: * Motorola MC68000 16/32-bit main processor. ?

It's Motorola's product. Commodore's value-added IPs are the Amiga custom chips, Amiga PCB design and the AmigaOS.

A1200 has MC68EC020.

A3000 has MC68030.

68000 DIP chip from another non-Commodore computer works on the A500/A1000/A1500/A2000.

Last edited by Hammer on 12-Mar-2024 at 06:03 AM.
Last edited by Hammer on 12-Mar-2024 at 06:02 AM.
Last edited by Hammer on 12-Mar-2024 at 06:01 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: cdimauro wrote: I know it. But do you know this: http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node0003.html These are the hardware components of the Amiga: * Motorola MC68000 16/32-bit main processor. ? It's Motorola's product. Commodore's value-added IPs are the Amiga custom chips, Amiga PCB design and the AmigaOS. A1200 has MC68EC020. A3000 has MC68030. 68000 DIP chip from another non-Commodore computer works on the A500/A1000/A1500/A2000.

As I've already said: I KNOW IT.

But the Amiga Hardware Manual gives a different definition of what an Amiga is.

Clear now?

@cdimauro

Quote:

I know it. But do you know this: http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node0003.html These are the hardware components of the Amiga: * Motorola MC68000 16/32-bit main processor. ?

https://www.reddit.com/r/amiga/comments/tza5if/my_original_a500_cpu_found_sleeping_in_a_68010/
This user's A500 had SCN68000 before replacing it with MC68010.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@cdimauro

Quote:

cdimauro wrote: As I've already said: I KNOW IT. But the Amiga Hardware Manual gives a different definition of what an Amiga is. Clear now?

http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node0003.html

These are the hardware components of the Amiga:

* Motorola MC68000 16/32-bit main processor. The Amiga also supports the
68010, 68020, and 68030 processors as an option. The A1000, A500 and
A2000 contain the 68000, while the A3000 utilizes the 68030 processor.


Back at you.


https://bigbookofamigahardware.com/bboah/product.aspx?id=1497

The MC68000 was cloned by several manufacturers and these clones can often be found in Amiga's. Processor clones were even installed at the factory. Hitachi and Signetics processors in particular were used instead of Motorola, but Rockwell clones may also have been used.


Commodore has no problems using cloned 68000 CPUs.

For Amiga Hombre, Commodore was preparing for a PA-RISC clone implementation CPU without Motorola/Freescale. Hitachi has cloned PA-RISC 71xx CPU designs and this implementation was selected by Commodore. Hitachi also designed SuperH RISC CPUs.

Commodore was also preparing a licensed 68K clone for A1200 on a chip on certain Amiga Hombre SKUs.

Last edited by Hammer on 12-Mar-2024 at 01:09 PM.
Last edited by Hammer on 12-Mar-2024 at 06:18 AM.
Last edited by Hammer on 12-Mar-2024 at 06:14 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: I know it. But do you know this: http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node0003.html These are the hardware components of the Amiga: * Motorola MC68000 16/32-bit main processor. ? https://www.reddit.com/r/amiga/comments/tza5if/my_original_a500_cpu_found_sleeping_in_a_68010/ This user's A500 had SCN68000 before replacing it with MC68010.

Quote:

Hammer wrote: @cdimauro Quote: cdimauro wrote: As I've already said: I KNOW IT. But the Amiga Hardware Manual gives a different definition of what an Amiga is. Clear now? http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node0003.html These are the hardware components of the Amiga: * Motorola MC68000 16/32-bit main processor. The Amiga also supports the 68010, 68020, and 68030 processors as an option. The A1000, A500 and A2000 contain the 68000, while the A3000 utilizes the 68030 processor. Back at you. https://bigbookofamigahardware.com/bboah/product.aspx?id=1497 The MC68000 was cloned by several manufacturers and these clones can often be found in Amiga's. Processor clones were even installed at the factory. Hitachi and Signetics processors in particular were used instead of Motorola, but Rockwell clones may also have been used. Commodore has no problems using cloned 68000 CPUs. For Amiga Hombre, Commodore was preparing for a PA-RISC clone implementation CPU without Motorola/Freescale. Hitachi has cloned PA-RISC 71xx CPU designs and this implementation was selected by Commodore. Hitachi also designed SuperH RISC CPUs. Commodore was also preparing a licensed 68K clone for A1200 on a chip on certain Amiga Hombre SKUs.

Again, what's not clear to you of what I've said before?

I KNOW IT!

And, on top of that, you should also CAREFULLY read AND understand what people write. When I clarified it, I reported also this:

it's all about who owns the Amiga's IPs & brands. If the owner sells a toaster marketed as Amiga and I buy it, then I can say that I've an Amiga.

This PLUS the definition in the Hardware Manual are, and should be, enough to clarify and classify what's an "Amiga".

Finally clear now?

@cdimauro

Managed to read this article last night. Will post my responses to topics here rather than on blog. But in the meantime...

Quote:

They (Bill?) decided to port the o.s. to PowerPC and a port is what it is: nothing really new, which solves the atavistic problems.

I met him at Ace2k in my local Melbourne. My impression was that Bill [McDaddy] was a business man looking for an opportunity with Amiga and didn't understand the obsession with 68K or the chipset. He came across as an x86 guy to me. As an analogy, Bill was like a driver, surrounded by mechanics. Amiga users are like mechanics, they are interested in what's under the hood.

I was there when he announced OS3.9. It was good for us. But some douche brought his bag and loudly voiced his heckling. I also thought Bill made it happen to give us something, since at that point we were his only market, so far as I know.

Quote:

A new path should have been followed, but probably OS5 required too much effort/investments for what could be done by the IP owners.[

There was a poor mans version: AmigaDE! It only worked on Windows. So Amiga people interested needed a PC and Windows to test it. I bought it, or bought into it rather, but didn't have the hardware to run it on. The box is here somewhere. At Ace2k there were also ideas like using QNX as a base OS.

I thought the DE idea was a bit too close to Java. Generic bytecode that is compiled dynamically for host CPU at load time. And unlike AmigaDE that claimed to support PowerPC, which was still relevant, Java really did support and run on PowerPC! I think it sent the wrong message, as it was claimed to support PowerPC and it didn't even run on Amigas, PowerUP cards weren't even supported.


Now...

The NG label these days tends to be compared with modern systems. But really it is a relative label. Realistically it's relative to 68K Amiga at around 1995 standards. Since NG implies what is after 68K. Given no Amiga designers, engineers nor Commodore were around to ratify what would become NG anything called NG cannot be NG in any official capacity. And for the AmigaOne series this shows from the start since there is at least a decade between that and the last designed Amiga. My comments will be directed at OS4, since I'm familiar with it, and being built off original sources gives it credence to me.


Memory protection:
You mentioned mild protection. While not full protection it is useful. I discovered it first hand when an E program I wrote suddenly started crashing after an OS update. I checked and found eventually I hadn't used DOS API correctly. So for me it was mostly annoying actually when they tightened the nuts lol. But it is useful for catching bad pointers and such a feature would have really helped debug 68K software. That's another stability. AmigaOS trusts pointers and doesn't always check. Said to be for speed but it allowed bugs to fly under the radar on 68K, that break on OS4, leading OS4 to get a reputation of being buggy and unstable. With fallacious claims that the software was fine, because it runs fine on 68K; so if it crashes on OS4, then OS4 is at fault. OS4 isn't perfectly stable either but it helps to know the cause of instability, The binary nature of messages posting data directly was also another method employed for fast speed.

Resource tracking:
OS4 does include some resource tracking. But it "doesn't do it right." Or do it as expected. You can optionally track some resources but you need to manage it manually. So it doesn't free it in an automatic sense on sudden death. After looking into it, I thought it was best to continue my current methods, to keep track of what I open and making sure to free it on exit.


Process and threads:
Without isolated memory spaces conventional process and threads like today cannot work. Though forking is not as popular and copy on write mechanism tends to be preferred now in open sources I've looked at. Given the shared nature of processes in AmigaOS, it's somewhat disappointing there is still no threading support. I mean, with a shared memory space, you've got copy on write support for free. Ok, without MMU tricks it wont copy to parent process, but threads could easily be added to a parent process that can write without any tricks needed. They would need a CPU context and to be executed within the task quantum. A process with child threads as opposed to child process now which are a separate entity. Which can cause problems like below.

The shared memory process model can also make so sense when opening certain libraries, like bsdsocket API, that only work from the opened process. So spawning a child process to perform the work calling API functions will fail. If all processes share all memory how can such an operation fail? It doesn't make sense to enforce a rigid rule when processes can easily write over each others space. Of course, clean code, that isolates open, use and close of an API to one process works fine. But portable code, made to a dynamic threading model, then ported to AmigaOS will break that way. Now, it comes down to a RTFM, but dynamic process based library bases are an Amiga standard. A shared base is more common, but if you program AmigaOS you need to know the quirks. Which are usually in the particular API docs. Even if library opening is a system function, it can't be expected to list any quirks, since they don't always do that. Though the OS is full of quirks you need to know about, that aren't always mentioned, or found in some vague source example.


64 bits:
Obviously a true 64 bit port would need a complete replacement. Since you then need 64 bit pointers. Unless using MMU tricks to map process memory into lower 4GB, which would reduce size while giving greater benefits. But, if a task switch needs a CPU context switch where MMU is remapped per process that adds to overhead. It would be better if all spaces could be mapped without needing to change MMU entries on task switch. The only other problem is IPC, since for that, every task really needs their address spaces reachable all the time. So extended address space, in the 64 bit area may have 33 or 34 bits of physical RAM existent that still need to be reached by 32 bit pointers.

The OS4 kernel developers have even criticised tag lists for being restricted to 32 bits because 64 bit data like FPU register cannot be given directly. It does make sense they used 32 bits. However, tags also have a flags field. I imagine a 64 bit AmigaOS would expand the tags somehow.

You brought up AllocEntry. But in reality how often is it used? Internal OS functions can be changed easily enough. But how many programs make use of it? Despite the limitations, which obviously weren't a problem when 2GB wasn't out yet, I don't see this as a big issue. Simply issue a replacement function. Old software can be stuck at 2GB. The OS has functions that were found to have faults early on and were replaced. Semaphores would be one example.

A related problem is with DOS. I just don't recall what but some DOS functions are sad to be limited to 31 bits. However, the archaic BCPL pointers dragged over, may be of assistance. Since they cut off 2 bits they could in theory support up to 34 bit pointers and break the 32 bit barrier. That might be as useful as the 20 bit extension to x86 many moons ago though so best left as a novelty.

OS4 does have the ExtMem feature now to compensate. But it really just highlights how far it has fallen. The least said about MemMaker the better, we don't need to go back there. The RAM disk is supposed to use it. But in my experience it's faulty. I copied large file to RAM, breaking the 4GB barrier. As it crossed the barrier it froze.


Virtual memory:
I didn't see this mentioned specifically. But OS4 does have some form of virtual memory. At least with mapping virtual to physical. It is used as in the above example of catching illegal memory access. As well as marking an executable address space.

There is also private memory. A process can allocate private memory that is off limits for all other processes. Given the nature of the system design I'm not sure if this is of limited use.


The Stack:
I don't know what happened here but in OS4 an automatic stack enlargement was an intended feature.


Access to OS structures:
I've noticed this for some time. For all the work Carl Sassenrath put into Exec it is unfortunate it has exposed its flaws and the open design is one of them. The most focused upon example would be Forbid and the more dangerous Disable. What makes it worse is being told to avoid Forbid, as if we were getting a slap on the wrist from Mary Whitehouse, when the fact was it was not only the recommended way but for some operations the only way. Now it looks like a bad idea to halt the entire system on a global scale just for one local operation. It does look like a convenient way to lock out data with minimum of overhead, but in hindsight I think it would have been best to include a forbid counter in each data structure. Even in the Node structure itself, an extra UWORD would have fit, that could have been used for an atomic lock locally. Especially given most data needing protecting did include a node.


Windows:
Oh no. When a good example is made of Windows and WIN16 at that, we know it's got real bad. There's just no coming back.

I wonder how it is handled internally. (Excuse the pun.) And if there are specific window handles or generic handles that are overseen by the system. When you have a handle it needs to be reversed into a pointer internally. Treating a handle like an index and traversing a list would be slow. Keeping a preset array is another way within limits. Amiga OFS dealt with a similar problem by using a hash table to reduce a file name into an index of sorts.

The Amiga way of using a direct pointer obviously speed up and simplified this operation. But it affected other parts of the OS. There is a Task ID that identifies that task or or process. An ID, that looks more robust. Of course it is an ID or each task, but each ID is also a pointer to that task. So it's just semantics really. Even DOS where file handles are slightly obfuscated by BCPL pointers expose a file structure when unpacked. Even so, despite exposing memory, if only a generic pointer was shared it wouldn't be as bad. But as you pointed out the objects to these pointers are documented. Not only so but they can contain useful data and sometimes you need to peek to check inside. However, you can tell in an early point in the line that some open doors needed to be shut and made private, as a note about IntuitionBase tell us:

/* I told you this was private.
* The data beyond this point has changed, is changing, and
* will continue to change.
*/

Against this, in the modern age, I see a lot of talk that a new Amiga system including OS should be open source. Perhaps stemming from the original open nature of the OS. But, AmigaOS is not Linux, it's structures may have been public but the code was always private. And it was open enough that helped projects like AROS to launch off the ground. I cast doubt on statements that allege AROS or MorphOS was reverse engineered, since the design is open enough for such a task to be unnecessary. And examples like ReactOS, providing a binary compatible Windows API, show that you only need the public API to recreate a private OS with enough accuracy.


BitMap:
The Screen->BitMap has been an old issue now and so we were told to use Screen->RastPort->BitMap.

As to the BitMap being limited to planar I wondered how this was addressed on RTG. But, this was and needed to be at one point. It's somewhat forward compatible to an extent. For chunky or packed, it only has one plane, so just needs BytesPerRow set for line width. Depth should really be 1 to match, but it leaves no way to set BPP. There is however Flags and an unused pad but I'm not aware of Flags being used for setting packed. The BitMap was also quirky because it didn't include direct line width. An associated structure, Image, is even less expandable and more entrenched in planar.

BitMap as well as DiskObject look like those objects never expanded correctly. Aside from my point about Flags icons has a version. But I didn't see this used to expand or change the structure. Instead there was some kind of other hacking of images in tooltypes or in icon data without any obvious version changes.


BOOPSI:
I didn't see this mentioned but it does address some of the problems. It provides more abstraction than traditional Intuition windows and gadgets. Objects are created from a tag list and their contents are not revealed. Any access for read and write of attributes needs to go through getter and setter functions. Unfortunately, it's based on Smalltalk OOP hacked into C, so looks like a right mess. Before I knew what OOP was I wondered they put this messy API in there needing these dog breakfast looking defines. In addition, it uses Smalltalk terms like messages which is confusing in Amiga parlance, where messages were an Exec message object. But it does hide internals and allow expansion.


Audio and devices:
Despite being an abstract device interface it does expect a few things to be low level such as sample format and frequency. It can also be hard to use for multiple tracks so an associated audio.library providing upper level functions for audio would have helped. Needing IO duplicated or non-standard way of using device doesn't help. AmigaOS is littered with some quirky devices that don't follow the usual device standard. Some need BeginIO which wasn't in Exec. Others like timer.device can clear IO with GetMsg but that is non standard. It wasn't consistent.


Datatypes:
Pretty much built off BOOPSI. Allowing media to be loaded in and displayed. Or played and heard. It needs classes to work and built ins can be limited. But it was a good start to being able to load common images or audio. With a little work it can be used to display a picture or play audio. That can be used as a more abstract way than the Amiga specific devices and libraries, as well as being upward compatible, so working on RTG and RTA at best quality available. I once used it to write a simple sample player.


Workbench:
It's still using most of the old design. Needing to be updated with modern desktop file browsers. And it still doesn't multi-task!

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: A new path should have been followed, but probably OS5 required too much effort/investments for what could be done by the IP owners.[ There was a poor mans version: AmigaDE! It only worked on Windows. So Amiga people interested needed a PC and Windows to test it. I bought it, or bought into it rather, but didn't have the hardware to run it on. The box is here somewhere. At Ace2k there were also ideas like using QNX as a base OS.

Which means that they were aware that the original OS had no future, as it was conceived.
Quote:

I thought the DE idea was a bit too close to Java. Generic bytecode that is compiled dynamically for host CPU at load time.

Well, Java is very well known to be slow at/when loading...
Quote:

The NG label these days tends to be compared with modern systems. But really it is a relative label. Realistically it's relative to 68K Amiga at around 1995 standards. Since NG implies what is after 68K. Given no Amiga designers, engineers nor Commodore were around to ratify what would become NG anything called NG cannot be NG in any official capacity. And for the AmigaOne series this shows from the start since there is at least a decade between that and the last designed Amiga. My comments will be directed at OS4, since I'm familiar with it, and being built off original sources gives it credence to me.

Np. As I've said in the article, all post-Amiga OSes share more or less the same problems.
Quote:

Memory protection: You mentioned mild protection. While not full protection it is useful. I discovered it first hand when an E program I wrote suddenly started crashing after an OS update. I checked and found eventually I hadn't used DOS API correctly. So for me it was mostly annoying actually when they tightened the nuts lol. But it is useful for catching bad pointers and such a feature would have really helped debug 68K software. That's another stability. AmigaOS trusts pointers and doesn't always check. Said to be for speed but it allowed bugs to fly under the radar on 68K, that break on OS4, leading OS4 to get a reputation of being buggy and unstable. With fallacious claims that the software was fine, because it runs fine on 68K; so if it crashes on OS4, then OS4 is at fault. OS4 isn't perfectly stable either but it helps to know the cause of instability, The binary nature of messages posting data directly was also another method employed for fast speed.

Does it mean that OS4's APIs make checks on the data that applications passed? I mean: there should be some difference if such applications work fine on "68k" and don't on OS4...
Quote:

Resource tracking: OS4 does include some resource tracking. But it "doesn't do it right." Or do it as expected. You can optionally track some resources but you need to manage it manually. So it doesn't free it in an automatic sense on sudden death. After looking into it, I thought it was best to continue my current methods, to keep track of what I open and making sure to free it on exit.

This isn't resource tracking. RT is about NOT doing it manually...
Quote:

Process and threads: Without isolated memory spaces conventional process and threads like today cannot work. Though forking is not as popular and copy on write mechanism tends to be preferred now in open sources I've looked at.

Which is a Good Thing! Fork(ing) is the worst thing that Unix has introduced: it's like always using a cannon even when you've to kill a fly...
Quote:

Given the shared nature of processes in AmigaOS, it's somewhat disappointing there is still no threading support. I mean, with a shared memory space, you've got copy on write support for free. Ok, without MMU tricks it wont copy to parent process, but threads could easily be added to a parent process that can write without any tricks needed. They would need a CPU context and to be executed within the task quantum. A process with child threads as opposed to child process now which are a separate entity. Which can cause problems like below.

Actually it's the opposite: AmigaOS has ONLY threads running on a single process. What's missing is the process concept.
Quote:

The shared memory process model can also make so sense when opening certain libraries, like bsdsocket API, that only work from the opened process. So spawning a child process to perform the work calling API functions will fail. If all processes share all memory how can such an operation fail? It doesn't make sense to enforce a rigid rule when processes can easily write over each others space. Of course, clean code, that isolates open, use and close of an API to one process works fine. But portable code, made to a dynamic threading model, then ported to AmigaOS will break that way. Now, it comes down to a RTFM, but dynamic process based library bases are an Amiga standard. A shared base is more common, but if you program AmigaOS you need to know the quirks.

Yes, but we also have some libraries which aren't shared and should be only used on the task that opened them. AFAIR all math libraries work this way.
Quote:

Which are usually in the particular API docs. Even if library opening is a system function, it can't be expected to list any quirks, since they don't always do that. Though the OS is full of quirks you need to know about, that aren't always mentioned, or found in some vague source example.

Do you have examples of such quirks?
Quote:

64 bits: Obviously a true 64 bit port would need a complete replacement. Since you then need 64 bit pointers. Unless using MMU tricks to map process memory into lower 4GB, which would reduce size while giving greater benefits. But, if a task switch needs a CPU context switch where MMU is remapped per process that adds to overhead. It would be better if all spaces could be mapped without needing to change MMU entries on task switch. The only other problem is IPC, since for that, every task really needs their address spaces reachable all the time. So extended address space, in the 64 bit area may have 33 or 34 bits of physical RAM existent that still need to be reached by 32 bit pointers.

You don't need a complete replacement for it neither a MMU is mandatory.

AROS is available in x64 flavor, for example, and it wasn't completely replaced just for this. The MMU is enabled but only because it's mandatory for x64 running in Long Mode (64 bit).
Quote:

The OS4 kernel developers have even criticised tag lists for being restricted to 32 bits because 64 bit data like FPU register cannot be given directly. It does make sense they used 32 bits. However, tags also have a flags field.

In fact, tags are one the most inefficient (and dangerous!) implementation which was introduced on the OS.
Quote:

I imagine a 64 bit AmigaOS would expand the tags somehow.

AROS did it. AFAIR the common base on AROS is that an entry on a tag list has the same size of pointers.
Quote:

You brought up AllocEntry. But in reality how often is it used? Internal OS functions can be changed easily enough. But how many programs make use of it? Despite the limitations, which obviously weren't a problem when 2GB wasn't out yet, I don't see this as a big issue.

Well, you've to consider it anyway because... it exists. I don't know how many programs used it, but if it's there probably some OS code used it.

You know how it works: a developer see a recurring pattern and it asks to the architect if a function/API can be introduced for it...
Quote:

Simply issue a replacement function. Old software can be stuck at 2GB. The OS has functions that were found to have faults early on and were replaced. Semaphores would be one example.

Changing code is not a problem... if you've the code. And developers willing to change it...
Quote:

A related problem is with DOS. I just don't recall what but some DOS functions are sad to be limited to 31 bits. However, the archaic BCPL pointers dragged over, may be of assistance. Since they cut off 2 bits they could in theory support up to 34 bit pointers and break the 32 bit barrier. That might be as useful as the 20 bit extension to x86 many moons ago though so best left as a novelty.

Well, you don't want to bind again yourself to another of the most stupid things that were introduced in the Amiga OS, right?
Quote:

OS4 does have the ExtMem feature now to compensate. But it really just highlights how far it has fallen. The least said about MemMaker the better, we don't need to go back there. The RAM disk is supposed to use it. But in my experience it's faulty. I copied large file to RAM, breaking the 4GB barrier. As it crossed the barrier it froze.

I assume that you've filed a bug report.

However, ExtMem isn't a so complicated stuff to implement & work (it's like the EMS memory on DOS). Maybe it wasn't tested enough.
Quote:

Virtual memory: I didn't see this mentioned specifically. But OS4 does have some form of virtual memory. At least with mapping virtual to physical. It is used as in the above example of catching illegal memory access. As well as marking an executable address space.

That belongs to memory protection part of the article.
Quote:

There is also private memory. A process can allocate private memory that is off limits for all other processes. Given the nature of the system design I'm not sure if this is of limited use.

As I'v said in the article, it depends about what it does with such private memory. If it doesn't share it, then it's ok. But if it does and the OS decides, for example, to swap it... BOOM!
Quote:

The Stack: I don't know what happened here but in OS4 an automatic stack enlargement was an intended feature.

Even if it's implemented, it's severely limited by the memory allocations: you can go down until you find that the memory block which is below is already allocated.

It happens also on OSes where processes have separated address spaces, but since the memory isn't shared with other processes then you've to make a VERY HUGE usage of stack to reach the bottom.
Quote:

Access to OS structures: I've noticed this for some time. For all the work Carl Sassenrath put into Exec it is unfortunate it has exposed its flaws and the open design is one of them. The most focused upon example would be Forbid and the more dangerous Disable. What makes it worse is being told to avoid Forbid, as if we were getting a slap on the wrist from Mary Whitehouse, when the fact was it was not only the recommended way but for some operations the only way. Now it looks like a bad idea to halt the entire system on a global scale just for one local operation. It does look like a convenient way to lock out data with minimum of overhead, but in hindsight I think it would have been best to include a forbid counter in each data structure. Even in the Node structure itself, an extra UWORD would have fit, that could have been used for an atomic lock locally. Especially given most data needing protecting did include a node.

No, the best is to do NOT have such APIs. At all.

And provide proper APIs for accessing controlled data or provide enumerators API when you need to have a list of resources.
Quote:

Windows: Oh no. When a good example is made of Windows and WIN16 at that, we know it's got real bad. There's just no coming back. I wonder how it is handled internally. (Excuse the pun.)

I don't, because, as a developer, I don't need to know such internal details.
Quote:

And if there are specific window handles or generic handles that are overseen by the system. When you have a handle it needs to be reversed into a pointer internally.

Why? It depends. And it's an internal thing, anyway: it's a problem of the OS and not of the developers.
Quote:

Treating a handle like an index and traversing a list would be slow.

Why? It's much faster than traversing a linked list.
Quote:

Keeping a preset array is another way within limits.

Not if you can reallocate the memory for such structures when you need more entries there.
Quote:

Amiga OFS dealt with a similar problem by using a hash table to reduce a file name into an index of sorts.

That's another possibility, but here the problem to solve was another one.
Quote:

The Amiga way of using a direct pointer obviously speed up and simplified this operation. But it affected other parts of the OS. There is a Task ID that identifies that task or or process. An ID, that looks more robust. Of course it is an ID or each task, but each ID is also a pointer to that task. So it's just semantics really. Even DOS where file handles are slightly obfuscated by BCPL pointers expose a file structure when unpacked. Even so, despite exposing memory, if only a generic pointer was shared it wouldn't be as bad.

It is: think about moving from 32 to 64 bit and you'll get a simple example why directly using pointers was a bad thing (since that many times they are also embedded in structures).
Quote:

But as you pointed out the objects to these pointers are documented. Not only so but they can contain useful data and sometimes you need to peek to check inside. However, you can tell in an early point in the line that some open doors needed to be shut and made private, as a note about IntuitionBase tell us: /* I told you this was private. * The data beyond this point has changed, is changing, and * will continue to change. */ Against this, in the modern age, I see a lot of talk that a new Amiga system including OS should be open source. Perhaps stemming from the original open nature of the OS. But, AmigaOS is not Linux, it's structures may have been public but the code was always private. And it was open enough that helped projects like AROS to launch off the ground. I cast doubt on statements that allege AROS or MorphOS was reverse engineered, since the design is open enough for such a task to be unnecessary. And examples like ReactOS, providing a binary compatible Windows API, show that you only need the public API to recreate a private OS with enough accuracy.

In fact the problem is not about the APIs, which should be public by definition for allowing people to develop code using them. Rather, to have published internal details which should have been left private.
Quote:

BitMap: The Screen->BitMap has been an old issue now and so we were told to use Screen->RastPort->BitMap.

But the issue remained even using the latter.
Quote:

BOOPSI: I didn't see this mentioned but it does address some of the problems.

I haven't mentioned it because it wasn't part of the issues that crippled the AmigaOS future.

However the plan is, since long time, to publish an article about it and its quirks. Albeit I've already shared most of them on some posts in the BOOPSI thread.
Quote:

It provides more abstraction than traditional Intuition windows and gadgets. Objects are created from a tag list and their contents are not revealed. Any access for read and write of attributes needs to go through getter and setter functions. Unfortunately, it's based on Smalltalk OOP hacked into C, so looks like a right mess.

Hum. Why do you think that it's like Smalltalk? Only because everything is message passing?
Quote:

Before I knew what OOP was I wondered they put this messy API in there needing these dog breakfast looking defines. In addition, it uses Smalltalk terms like messages which is confusing in Amiga parlance, where messages were an Exec message object. But it does hide internals and allow expansion.

Look at my posts on the other thread.
Quote:

Audio and devices: Despite being an abstract device interface it does expect a few things to be low level such as sample format and frequency.

The problem is how they are defined / specified: too much low-level AKA a direct mapping of Amiga's audio hardware.

@cdimauro

I have read and enjoyed Mauros articles. They are good, knowledgeable and proper analysts.
There is no wrong in proper criticism.

On fast booting - I would love to see OS or its critical parts in EPROM/ROM again. Hope its not too expnsive - that kind of 8-bit/16bit legacy is not that bad. Maybe it can be archived via Amiga style RAD device? Android and iOS devices are coming quite near to it, but still are not there.

I liked complex architectures of Amiga, Jaguar or Falcon, where you could off load the CPU and archive much, but seems its not easy to utilize. I like the way Apollo team has improved both CPU
and chipset - but yet very little software seems to utilize it, even V2s are around almost a decade now. Hope some open sourcing or paid licensing or wider adoption is possible.

Counting boot time until all hard disk activity and background services, Windows certainly does not boot (yet) in few seconds, although boot time seems to be improving, as point of criticism.

_________________
Future Acube and MOS supporter, fi di good, nothing fi di unprofessionals. Learn it harder way!

@vox

Not counting the motherboard UEFI booting, Windows boots in a matter of a few seconds on my AM4 Zen 3 system with PCIe 4 NVMe storage and DDR4 RAM. Not the latest hardware but pretty recent. And it wasn’t much slower on a PCIe 3 NVMe storage.
And lets not forget that on the Windows system one can leverage hibernation/sleep, which a I do. I press the button, and in 1-2 seconds (with Windows Hello) I’m presented with a ready system.

One might say that some fictional Amiga OS port which is capable of leveraging multiple CPU cores/threads, DDR4 RAM and PCIe 4 NVME might boot in 1-2 seconds, but I guess we’ll never know.

_________________
All the way, with 68k

agami Quote:

Not counting the motherboard UEFI booting, Windows boots in a matter of a few seconds on my AM4 Zen 3 system with PCIe 4 NVMe storage and DDR4 RAM. Not the latest hardware but pretty recent. And it wasn’t much slower on a PCIe 3 NVMe storage. And lets not forget that on the Windows system one can leverage hibernation/sleep, which a I do. I press the button, and in 1-2 seconds (with Windows Hello) I’m presented with a ready system.

A fresh Windows install with lots of fast resources boots relatively fast. It's amazing how much the drive slows with use compared to the Amiga which uses few resources and slow drives. A low resource used Windows system can take longer to shutdown before a restart than the Amiga takes to boot, especially with low memory and virtual paging. Heavy virtual paging from a memory leak can take minutes for a restart or never if it bugs out. Virtual memory practically can't be turned off too. Best case Windows performance is good but worst case is much worse than an original 68k Amiga.

agami Quote:

One might say that some fictional Amiga OS port which is capable of leveraging multiple CPU cores/threads, DDR4 RAM and PCIe 4 NVME might boot in 1-2 seconds, but I guess we’ll never know.

Steve Shireman showed me an Amiga 1200 with PCMCIA NVRAM card booting in a few seconds back in the 1990s. It was a lightweight boot but then the Amiga doesn't need to load much to boot off a drive. A 68k Amiga with modern tech could likely be perceived by humans as an instant on computer. This not only saves time for humans but is good for embedded systems.

@agami

Quote:

One might say that some fictional Amiga OS port which is capable of leveraging multiple CPU cores/threads, DDR4 RAM and PCIe 4 NVME might boot in 1-2 seconds,

If you lower delay of the System waiting time - wating for potential slow Drives
and you allow the System to boot immediate as soon a drive shows
then Amiga OS today already boots in 2-3 seconds on Vampire 2 and 4.

This is no problem. We did this for fun already.

This is a complete boot to truecolor WB.

Last edited by Gunnar on 19-Mar-2024 at 03:08 AM.

@Hypex

Quote:

I met him at Ace2k in my local Melbourne. My impression was that Bill [McDaddy] was a business man looking for an opportunity with Amiga and didn't understand the obsession with 68K or the chipset. He came across as an x86 guy to me. As an analogy, Bill was like a driver, surrounded by mechanics. Amiga users are like mechanics, they are interested in what's under the hood.

"X86 guy" has a legacy software mindset e.g. Windows 3.1 running on 13th gen Intel RaptorLake CPU https://www.youtube.com/watch?v=nqyF6ZlT-Pw

Bill McEwen's Tao Group's Virtual Processor initiative is anti-legacy (anti-retro) software.

From this Amiga Anywhere Demo https://www.youtube.com/watch?v=HfHcwpzxSdk
The problem is Windows CE devices are missing a CPU abstraction layer and Amiga Anywhere is attempting to solve MS's Windows CE problem.

Google's Android and Apple iOS appeared and wreaked MS's Windows CE handheld adventure.

Last edited by Hammer on 19-Mar-2024 at 05:36 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@agami

Quote:

agami wrote: @vox Not counting the motherboard UEFI booting, Windows boots in a matter of a few seconds on my AM4 Zen 3 system with PCIe 4 NVMe storage and DDR4 RAM. Not the latest hardware but pretty recent. And it wasn’t much slower on a PCIe 3 NVMe storage. And lets not forget that on the Windows system one can leverage hibernation/sleep, which a I do. I press the button, and in 1-2 seconds (with Windows Hello) I’m presented with a ready system. One might say that some fictional Amiga OS port which is capable of leveraging multiple CPU cores/threads, DDR4 RAM and PCIe 4 NVME might boot in 1-2 seconds, but I guess we’ll never know.

That's also because Windows has services that are run mostly in parallel at the startup (according to the defined priorities and dependencies).

Starting with SSDs this feature was exploited to the maximum, especially with SSDs which allowed to issue multiple I/O requests.

But this is possible because the OS has full control and knowledge of the system, so it can decide how to start services and control that they are loading correctly, and decide if and how many of them can be also started at a certain point in time.

This is completely missing from the Amiga OS, where you've a single script which is executed when the system boots and it's the user that, in case, has to manually execute commands in parallel by using the RUN command. And the same user should know how to do it, because the same startup sequence could fail on another configuration.

Fortunately, the Amiga OS is simple and hasn't so many components, so it loads pretty fast even using the usual startup sequence which is basicaly doing "batch processing".

@cdimauro

Quote:

Again, what's not clear to you of what I've said before? I KNOW IT! And, on top of that, you should also CAREFULLY read AND understand what people write. When I clarified it, I reported also this: it's all about who owns the Amiga's IPs & brands. If the owner sells a toaster marketed as Amiga and I buy it, then I can say that I've an Amiga. This PLUS the definition in the Hardware Manual are, and should be, enough to clarify and classify what's an "Amiga". Finally clear now?

Amiga Anywhere and AmigaDE had Amiga's name and it flopped hard.

I'm NOT into supporting a product that attempts to fix Microsoft's lack of CPU abstraction layer with their Windows CE-based handhelds.

Windows CE on various RISC ISA families flopped like Windows NT non-x86 editions.

Last edited by Hammer on 19-Mar-2024 at 05:48 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@matthey, @Gunnar, @cdimauro

I guess I should've made my statement a little clearer:

As I was kind of staying on topic and talking about a "fictional" Amiga OS which is actually NG, which not only supports modern hardware systems and peripherals, but also has a modern architecture for usability and security; it would no longer be the lightweight Amiga OS 3.x or its facsimile AROS 68k.

No free lunch, guys.

_________________
All the way, with 68k

@agami

Quote:

"fictional" Amiga OS" -- has a modern architecture for usability and security; it would no longer be the lightweight Amiga OS 3.x or its facsimile AROS 68k.

Can you help me understand what the "Amiga" part of it will be?


When I today compare Linux and Amiga OS, then I can very clearly see two very different ideals.

Linux - security with lots of abstractions and forbidding many things by design.
Amiga - the opposite. Less secure but lots of coding freedom and slim by design.

So which one do you want?


Or do you want Linux with Amiga icons?

@Gunnar

In the USA they talk about forcing developer to not code in C/C++ or insecure languages.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@agami

Since the Amiga is now a hobby system and may never again reach millions of sales or sell more than Windows or macOS is abandoning its speed, elegance and lightweight design really necessarily? The Vampire V4 project really shows how relaunching a computer system with realistic goals should be done. Amiga does not have to be like Linux, Windows or macOS to succeed. A few hundred thousand sales would be nice in the Amiga market. Then people could enjoy their hobby more and developers might be able to make a little chicken scratch for a change. And it would be nice if the fighting for little crumbs in this market would end.

Last edited by DiscreetFX on 20-Mar-2024 at 06:40 PM.

_________________
Sent from my Quantum Computer.

DiscreetFX Quote:

Since the Amiga is now a hobby system and may never again reach millions of sales or sell more than Windows or macOS is abandoning its speed, elegance and lightweight design really necessarily? The Vampire V4 project really shows how relaunching a computer system with realistic goals should be done. Amiga does not have to be like Linux, Windows or macOS to succeed. A few hundred thousand sales would be nice in the Amiga market. Then people could enjoy their hobby more and developers might be able to make a little chicken scratch for a change. And it would be nice if the fighting for little crumbs in this market would end.

The Amiga remained the 68k Amiga when Amiga Anywhere failed and became Amiga Nowhere. The Amiga became AmigaOne even though AmigaOne failed and became AmigaNOne. The fat PPC AmigaNOne lives on after 2 decades of failure replacing and blocking the lightweight 68k Amiga and the hot retro Amiga market. How can this be even without ownership of Amiga IP? Possession is nine-tenths of the law (Uti possidetis) and the IP squatters refuse to return what they possess to the owner. Further, they believe what they possess is extremely valuable even after 2 decades of failure. Surely they demand more ransom than they have earned from the Amiga IP in 2 decades and investors will only pay according to how much the IP has earned. It seems we are at an impasse until the squatters die and by that time too many Amiga fans will likely be dead to make a difference. This is the legacy of Trevor and his fixer Ben. Sorry, no crumbs fall from their table.