AmigaOS 3.2 and beyond

[nar001]

Wasn't AmigaOS 3.2 already released by Escom for the walker?

[Samurai_Crow]

The Walker was never released.

[OlafSch]

I have a general question...

is 3.1.4 (and 3.2) structural identical to 3.1 or are there changes?

[boemann]

Originally Posted by OlafSch

I have a general question...

is 3.1.4 (and 3.2) structural identical to 3.1 or are there changes?

Then you will also only get a general answer.

Think of it as a house. We have replaced the floor in one room painted everything, repaired the broken windows, moved a wall 30 cm, and built a new garage.

Is the house structurally the same. I'd say yes, as we certainly didn't tear down the old house first.

[OlafSch]

Originally Posted by boemann

Then you will also only get a general answer.

Think of it as a house. We have replaced the floor in one room painted everything, repaired the broken windows, moved a wall 30 cm, and built a new garage.

Is the house structurally the same. I'd say yes, as we certainly didn't tear down the old house first.

I ask it because I want to make something based on structure of 3.1

The question is... would it still work with 3.1.4 (or 3.2)?

Of course datatypes are changed (as example)

but it still would work

I want to make a version of my distribution based on 3.1 that still works on 3.1.4 or 3.2

or generally said... if I do a distribution for 3.1 would it work on 3.1.4 or do I have to test it on 3.1.4 (or 3.2) additionally?

[coldacid]

You should still test anyway, but I believe the general guide is that if you're not writing patches, then what works on 3.1 should work on 3.1.4 more or less the same; it's merely bug fixes and some backported features from 3.5 and 3.9 that don't change anything already existing.

For 3.2, I think we'll probably just have to wait and see.

[OlafSch]

Originally Posted by coldacid

You should still test anyway, but I believe the general guide is that if you're not writing patches, then what works on 3.1 should work on 3.1.4 more or less the same; it's merely bug fixes and some backported features from 3.5 and 3.9 that don't change anything already existing.

For 3.2, I think we'll probably just have to wait and see.

thanx

[Honey Badger]

so looking forward to OS 3.2 - ready to buy in a heartbeat

love supporting on-going Amiga development

[PurpleMelbourne]

IIRC the upper 2GB memory area was reserved for a Motorola idea of memory protection. Lower 2GB being alterable and upper 2GB being read only.

So how about OS support for multi processing. Our physical CPU's are speed limited, so the only way forward is to use more of them at the same time.


How about CPU_0 + CPU_SMP(1-4)

So everything which must run in the usual way does in the lower 2GB. But when possible (newly written and compiled for new system?), programs are passed onto the SMP complex in the upper 2GB.
I'm guessing the master CPU would have to be the one which moves things from lower to upper and back.

For example you could have five 040 processors.
Bottom 040 works as normal, except it gets rid of anything it can onto the co-processor complex. That complex runs a different exec which is perhaps pulled from BSD and tuned for threads instead of tasks. Or maybe a t unable system where you can change how the scheduling is performed.

I'm interested to make such hardware and send it to you. But working in with the OS may affect how the design is done.

I'm thinking about a couple of options including the Renesas TSI109 PPC PCI Host Bridge chip using FPGA glue for 040 or 060. And as mentioned CPU_0 as one, and several processors all as CPU_1 sharing an L3 Cache. The hardware (chips) has been around 15 years to do this, it would just need some FPGA glue.

[gulliver]

Originally Posted by OlafSch

I ask it because I want to make something based on structure of 3.1

The question is... would it still work with 3.1.4 (or 3.2)?

Of course datatypes are changed (as example)

but it still would work

I want to make a version of my distribution based on 3.1 that still works on 3.1.4 or 3.2

or generally said... if I do a distribution for 3.1 would it work on 3.1.4 or do I have to test it on 3.1.4 (or 3.2) additionally?

Hi,

When doing a distro you should always test first.

The directory layout has not changed much in 3.2 but the functionality has.

The change in functionality will mean that many programs you are used to add to overcome some limitations are no longer required. So better see what has changed first and then plug in what you want.

My advice is that you make a list of what you would want to add to 3.1.4.1, so that when the complete feature set of 3.2 is out, you compare and discard what is not needed and maybe even decide to add something else.

[gulliver]

Originally Posted by PurpleMelbourne

IIRC the upper 2GB memory area was reserved for a Motorola idea of memory protection. Lower 2GB being alterable and upper 2GB being read only.

So how about OS support for multi processing. Our physical CPU's are speed limited, so the only way forward is to use more of them at the same time.


How about CPU_0 + CPU_SMP(1-4)

So everything which must run in the usual way does in the lower 2GB. But when possible (newly written and compiled for new system?), programs are passed onto the SMP complex in the upper 2GB.
I'm guessing the master CPU would have to be the one which moves things from lower to upper and back.

For example you could have five 040 processors.
Bottom 040 works as normal, except it gets rid of anything it can onto the co-processor complex. That complex runs a different exec which is perhaps pulled from BSD and tuned for threads instead of tasks. Or maybe a t unable system where you can change how the scheduling is performed.

I'm interested to make such hardware and send it to you. But working in with the OS may affect how the design is done.

I'm thinking about a couple of options including the Renesas TSI109 PPC PCI Host Bridge chip using FPGA glue for 040 or 060. And as mentioned CPU_0 as one, and several processors all as CPU_1 sharing an L3 Cache. The hardware (chips) has been around 15 years to do this, it would just need some FPGA glue.

Hi,

My advice is to always play nice with the Amiga hardware and its OS to ensure proper operation and compatibility.

You can hack things to get them going, but their resulting operation will be compromised at some point. There are lot of Amiga hardware expansion designs, and even some that are currently on sale, that hack their way into the system. The result of this is not optimal. But better than hearing me repeating it, just learn from their mistakes.

Use AutoConfig.

[AC/DC HACKER!]

Originally Posted by digitalMedic

Disappointed that the CyberGfx developer has not been willing to assist in this. I know that Thomas said he could not make a P96 driver for the CybervisionPPC card because he does not have one to work with, so I am willing to lend my card to one of the developers if it would help make a P96 driver for the AmigaOS. This would allow us to move on from CyberGfx.

Originally Posted by loonsta

I’ve also offered loan of my Blizzard PPC and BVision to Thomas so he can develop P96 driver for it. I’ll need to ship it from Australia though. So I think he’s waiting for covid situation to dissipate more..

I don't think so...as I've considered offering my CybervisionPPC as help from the States. I Agree about CGFX. Aside, I didn't offer to move AWAY from CGX4.. I had considered the offer for both ways.

Originally Posted by E-Penguin

I think many of us would love to see the amiga os open sourced, but while hyperion and cloanto can make money off it by selling old versions and new versions build for free by skilled enthusiasts, there's no urgency on their part.

But this is a discussion for elsewhere. I greatly admire those involved in 3.2, licensing issues aside

I've thought Amiga OS should be for many years. Sort of how "Tron" made it understood. When I saw Windows 7 become what it did, I thought Amiga OS should be better. As I read through this Thread once in a while, I notice how the dedicated are still going (even the new people). That's the "theme" of Jay Miner, of "Tron". That's the "Spirit" of the Boing Ball to Check Mark. I'm not old by any means... I don't think that way, I don't relate myself to "old" in any way. Keep going, All!

[Thomas Richter]

Originally Posted by PurpleMelbourne

IIRC the upper 2GB memory area was reserved for a Motorola idea of memory protection. Lower 2GB being alterable and upper 2GB being read only.

How about CPU_0 + CPU_SMP(1-4)

Won't work. The problem is not memory, but synchronization. The AmigaOs synchronization primitives are actually constructed "the wrong way round". While sane operating systems built on top of semaphores or mutexes to synchronize tasks, AmigaOs uses Forbid-style locking to protect its structures to a major degree.

Unfortunately, Forbid() is not even an exec function, it is also a macro that just increments a counter in ExecBase. That is not at all sufficient to stop another CPU from executing any critical code.

Thus, please understand: AmigaOs is a museum piece. It is not a modern operating system, and it cannot be made a modern operating system. If you want something modern and scalable, there are many alternatives.

[PurpleMelbourne]

Originally Posted by Thomas Richter

Won't work. ...Unfortunately, Forbid() is not even an exec function, it is also a macro that just increments a counter in ExecBase. That is not at all sufficient to stop another CPU from executing any critical code.

Thus, please understand: AmigaOs is a museum piece. It is not a modern operating system, and it cannot be made a modern operating system. If you want something modern and scalable, there are many alternatives.

So it sounds like the answer to the chicken or the egg question...
There is a software problem to be solved before a hardware solution can be created. And so no point trying to push the boundaries.

And that you say there is no intention to make that fix this?

Did I get that right?

[PurpleMelbourne]

Are there other ways that multi processing hardware on Amiga can successfully work on the software?

[apex]

Why?

[Liqourice]

I also wonder why. The thing with Amigas and AmigaOS is to make it and software that runs swift in a minimalistic environment. It's a challenge. Adding more processors and so on kind of takes away what Amiga is. Make it possible to create bloated and unoptimised software and you have Windows. What's the point with that?

This is the main reason I don't like emulators and software created that only runs in them. If it can't run on an at least an unaccellerated A1200 then it's useless to the community, in my opinion.

Now, I'm not a programmer, haven't been for 25 years at least, but I enjoy playing around and making things work on my two Amigas. I want an OS that works on them and allows to use old software. Creating something that eventually will demand huge and expensive hardware upgrades will not benefit the community at all, it will only destroy it.

[Thomas Richter]

Originally Posted by PurpleMelbourne

There is a software problem to be solved before a hardware solution can be created. And so no point trying to push the boundaries.

And that you say there is no intention to make that fix this?

That is not a "fix". That is a "ditch it, loose compatibility, and restart from scratch".

[PurpleMelbourne]

Originally Posted by Liqourice

I also wonder why.

KiCad on Amiga for a start.
Compiling FPGA for another.

[Daedalus]

Originally Posted by PurpleMelbourne

KiCad on Amiga for a start.
Compiling FPGA for another.

I'm not aware of ports of either KiCAD or any FPGA compilers to Amiga OS. And whatever about a compiler that might be portable, KiCAD has a massive list of dependencies that would need to be sorted first, before even starting to worry about the lack of multiple CPUs. The lack of multiple CPU support isn't the limiting factor here, not by a long shot.

There are lots of things that benefit from as much CPU power as you can give them, and that's not much different now than it was back in the day. Some of that is of course personal choice, even back in the day I wanted more speed than the A500 or A1200 could give me stock, and to me it's silly to limit myself to such basic hardware unless that a specific aim (e.g. developing a game for a standard spec). Yes, more speed is always good, but there's a limit to what's practical. If you're looking for a modern system with modern features to support modern software, put an Amiga skin on your favourite Linux distro.