AmigaOS 3.2 and beyond

[Olaf Barthel]

Originally Posted by spudje

If taking things from AOS4 is an option, I think I like to AppDir concept and the update support. Would be call to bring that over to AOS3.

The APPDIR: concept works well for AmigaOS4 because the dos.library component was rewritten from the ground up and then some. This was a major accomplishment and one of the many benefits it brought with it was that for the first time in more than 30 years extensions could be added within the existing architecture, instead of getting stacked onto it. We are, unfortunately, a very long way away from dos.library being in a state fit to allow for such changes

AmigaOS4 has an online update server which, however, hinges on the availability of a TCP/IP stack that's integrated into it, and robust drivers which don't hang, crash or cause other kinds of mischief. Sadly, we do have our share of problems with network device drivers and their hardware. Unlike the AmigaOS4 solution, making your Amiga access the Internet is not quite so straightforward for AmigaOS 3.x. You might say that this is not such a big deal, but the thing is, we ought to do better than is possible today. Good enough here is not really good enough when the update server should be the main beneficiary of the networking capabilities. There is still work to be done here.

[Olaf Barthel]

Originally Posted by pipper

My personal wish is: better (remote) debugging facilities provided by the operating system. Bebbo implemented a GDBserver that works, but is rather limited. It would be great if exec could provide hooks and other debugging facilities (potentially utilizing the MMU) that make implementing a debugger much easier. Alternatively, the OS could come with a full gdbserver...

The gdbserver command is helpful indeed, since we seem to lack just about any slightly sophisticated interactive debugger which would complement the 'C' compilers available today.

We are currently working on an NDK for AmigaOS 3.2 and part of the job is figuring out which Amiga development environments exists, native and cross-development included, and whether we can provide a set of header files which would make them more robust and powerful. From what I learned, the commonly-used header files for GCC tend to be about 20 years old and they don't all work well.

Native development is very important. If you cannot even do that, and also use an interactive debugger which accelerates the debugging process, it gives the impression that the Amiga platform is just not up to the task. We've had interactive source level debuggers since 1988, if I remember correctly. If you're forced to go back to the old and tried method sprinkling your source code with printf() calls, you're regressing to a state which should have been left behind for more than 30 years.

We need a new Amiga-native source level debugger, possibly need it more than improved remote debugging tools.

[Olaf Barthel]

Originally Posted by amigang

firstly great work guys keeping the OS updated.

my only issue would be the version name.


I know AmigaOS is a bit of mess as I gather OS 3.5 / 3.9 source code was never shared and it contained a number of third party add-ons that not owned by Haage & Partner or Amiga inc.

You are not wrong, but the full picture is more nuanced. AmigaOS 3.5/3.9 did consist of major operating system changes in components and application software, with every contributor putting something into the pot.

The AmigaOS4 project was lucky enough to license or acquire components which were used in 3.5/3.9, and those which were unavailable were subsequently recreated from scratch over the years.

Where licensing and ownership allowed it, we have been permitted to reuse such AmigaOS4 components as could be adapted for AmigaOS 3.1.x and 3.2.

AmigaOS 3.1.4 is more advance than AmigaOS 3.9 correct?

I would not want to claim that. The whole idea of making AmigaOS 3.1.4 came out of the realization that there was no straightforward path to make a new AmigaOS 68k operating system that could continue along the same lines as AmigaOS 3.9. There would have to be a different path, starting with AmigaOS 3.1 and building up from there. This would involve upgrading the existing components to become more robust first, integrating AmigaOS 3.5/3.9 functionality as such was available and maybe adapting AmigaOS 4.x code if this was an option. That was the "pipe dream" which surprisingly, came to happen.

Our project development in about parallels the development of AmigaOS 3.5/3.9 to some degree, but it deviates from it to a large degree as well. There are features which do not compare well with what AmigaOS 3.5/3.9 offered. But there are also features in AmigaOS 3.1.x and 3.2 which were absent from AmigaOS 3.5/3.9 and arguably could not have been part of these. There is overlap, of course, but how do you judge what is better or more advanced? It's hard to pick criteria and get a general sense of what was achieved or more successful.

I would called it AmigaOS 3.10 or now AmigaOS 3.11 as it does confuse me a least.

It is confusing, has to be confusing because the respective projects moved into very different directions.

[spudje]

Originally Posted by Minuous

3.10 is equal to 3.1 which is an already-used release number.

That's what I also used to think. But you see many software releases with version numbering continuing after the "decimal" point. E.g. Home Assistant went from 0.99.x to 0.10x.x (currently 0.107.7). So 3.10 seems nice to me actually.

@Olaf thanks for the extensive answer!! I understand it's probably too complicated for 3.x then. Nevertheless, I was very much charmed about this in 4.x so see this as a compliment.

Apart from the fact that there is something wrong in the network stack on 4.1 FE update 1 classic, making it fairly impossible to download files bigger than 1MB, Downloads almost always stall and time out. So updating hardly ever works for me

[demon-knight]

You could go the Winamp route and call it version 5, quite dramatic but it would clear up any confusion that exists about which point release is the newest.

[DamienD]

Originally Posted by Jope

Please no. Only fully functional parts of the OS should be included, ones that are developed as a part of the OS development tree. Anything that lives its own development life outside of the OS should continue to live outside.

Guys, I'm totally with Jope on this.

If you want other 3rd party software, just download / add afterwards. You all know where to get it from

[gulliver]

Originally Posted by AlphaAmiga

To further E-Penguins point, would the team consider distributing the release on CD-Rom as well as a floppy version at all? This way it would be possible to include demo versions of the software E-Penguin mentioned on the CD Distribution (plus anything else the team consider as a nice add-on for people who have more powerful systems e.g BestWB etc?) as you would have plenty of space.

Hi,

AmigaOS 3.2 has more than 50 new features, and these require more space. This resulted in a substancial increment on the amount of disks that 3.2 will require. And we have not finished yet!

While we currently still have a disk based installation, the most likely scenario is that 3.2 will be primarily offered in some other type of media, which most likely be cd-rom. Still nothing is set as a defintive matter in this regard.

If we are going to use cd-roms for physical distribution, there will be enough place left to put optional software like the one you mention. But that will need to be analyzed when the time comes.

BTW, I am currently working on BestWB 2.0 which is targetted exclusively at AmigaOS 3.2, and will bring new features too.

[Tigerskunk]

I am really really looking forward to OS 3.2
Seems like you guys are aiming for the sky..

[AlphaAmiga]

Hi gulliver,

Thank you for the response, its great to hear of the OS moving forward and that more will be going into the system and that a CD release may be a possibility.

Do you see BestWB evolving into something that could be part of the install scheme for the OS - i.e. you get upto a certain point and the installer asks if you want to install this (and any other packages)?

I put an earlier post in regards space in the ROM chips - post #50 - does anyone in the team think this is possible?

Thanks very much.

[boemann]

Originally Posted by AlphaAmiga

I put an earlier post in regards space in the ROM chips - post #50 - does anyone in the team think this is possible?

Thanks very much.

We have about 6kb of ROM left and we'd like to have space for other improvements too, so I don't see how we can add diagnostics. We do have the option of moving things like audio.device to disk etc but we are really on a tight budget.

[AlphaAmiga]

Originally Posted by boemann

We have about 6kb of ROM left and we'd like to have space for other improvements too, so I don't see how we can add diagnostics. We do have the option of moving things like audio.device to disk etc but we are really on a tight budget.

Thank you for the reply, I did think it would be a long shot, but would never be a deal breaker :-)

[Leandro Jardim]

I would like to give two suggestions and one bug report.

First, the two suggestions:

* Multiview works as an ANIM player, albeit it is slow (I have not tested it with graphics cards), and reads the entire ANIM to RAM. Do you think in the possibility to update Multiview and the datatypes to play animations from the hard-disk, at the real speed, now with the new OS 3.2?

* For users that run Workbench on a color mapped OCS/AGA screen, would be best if Multiview for OS 3.2 had a menu item to select the color and the dithering precision for pictures and animations displayed on the Workbench screen.

And now the bug report:

* I am using the old MagicMenu 1.29 (very similar to the version used by Bloodwych in ClassicWB LITE). But it have some incompatibilities with Intuition, which hopefully are fixed when I install ObtainGIRPort.lha. Unfortunately this patch is incompatible with the external Intuition library that lets the user drag windows out of screen. With the new library, AmigaOS crash when I drag the horizontal slider of any Workbench window to any direction.

I understand that MagicMenu 1.29 is a too old program to support in the new OS, and the bugged program here is MagicMenu, not OS 3.1.4, but then I thought, I will at least try to ask for a kludge in the new OS to fix MagicMenu, since MagicMenu is a much used program by everyone, and the crash did not happen on the old OS 3.0/3.1.

[utri007]

I would suggest that if you could offer 1mb rom, at least for those machines wich has proven to work with it. It is easy to end up to problems is all the modules are not in rom.

[Pyromania]

@gulliver

Don’t forget to offer the official OS 3.2 flash drive.

[Lord Aga]

Originally Posted by boemann

- cursor is an I beam and it blinks to make it easier to spot

Could you make it beep with every blink? Like in every retarded movie ever

[boemann]

Originally Posted by Lord Aga

Could you make it beep with every blink? Like in every retarded movie ever

Brilliant idea, but it is already implemented, in fact we are also playing a little jingle every 8th blink

[gulliver]

Originally Posted by Leandro Jardim

And now the bug report:

* I am using the old MagicMenu 1.29 (very similar to the version used by Bloodwych in ClassicWB LITE). But it have some incompatibilities with Intuition, which hopefully are fixed when I install ObtainGIRPort.lha. Unfortunately this patch is incompatible with the external Intuition library that lets the user drag windows out of screen. With the new library, AmigaOS crash when I drag the horizontal slider of any Workbench window to any direction.

I understand that MagicMenu 1.29 is a too old program to support in the new OS, and the bugged program here is MagicMenu, not OS 3.1.4, but then I thought, I will at least try to ask for a kludge in the new OS to fix MagicMenu, since MagicMenu is a much used program by everyone, and the crash did not happen on the old OS 3.0/3.1.

Why are you using version 1.29?
That is an extremely outdated and bugged version. Is there any good reason to use that?

Use v2.30 if you only have a 68000 or 2.35 if you have a 020+

I use both of the above with no issues on both AmigaOS 3.1.4 and 3.2 beta.

[Lord Aga]

Originally Posted by boemann

Brilliant idea, but it is already implemented, in fact we are also playing a little jingle every 8th blink

Much obliged

[Leandro Jardim]

Originally Posted by gulliver

Why are you using version 1.29?
That is an extremely outdated and bugged version. Is there any good reason to use that?

Use v2.30 if you only have a 68000 or 2.35 if you have a 020+

I use both of the above with no issues on both AmigaOS 3.1.4 and 3.2 beta.

Only "aesthetic" reasons. I prefer the visual of the version 1.29 over the version 2.0+. On plain hires it looks more classy.

[gulliver]

Originally Posted by Leandro Jardim

Only "aesthetic" reasons. I prefer the visual of the version 1.29 over the version 2.0+. On plain hires it looks more classy.

Then if you want to keep that old version you would need to use the intuition.library with limited functionality we provided for CGX RTG systems.

Be warned that in AmigaOS 3.2 we added even more cool features to Intuition.