AmigaOS 3.2 and beyond

[Pyromania]

What's the planned release date pretty please?

[hUMUNGUs]

Originally Posted by Pyromania

I’m ready to purchase AmigaOS 3.2 as soon as it’s available.

Ditto

[loonsta]

I'd love to see a more modern default font in Workbench, or at least less chunky

@Thomas Richter what are the chances of allowing them to freely use topaz6?

[Michael]

Originally Posted by loonsta

I'd love to see a more modern default font in Workbench, or at least less chunky

Topaz is rom font and available all the time, it also causes other problems for none Latin users but this is how computers are made, something has to be the default. The good news, unlike many others systems, AmigaOS is more flexible and allows you to choose what ever fonts you like after installation, some like thin Xen fonts, others prefer Helvetica, while Times is considered a classic. Also the limits of 8x8 fonts have been mostly removed now so hi res users can enjoy a much nicer picture,

[Samurai_Crow]

Originally Posted by Michael

Topaz is rom font and available all the time, it also causes other problems for none Latin users but this is how computers are made, something has to be the default. The good news, unlike many others systems, AmigaOS is more flexible and allows you to choose what ever fonts you like after installation, some like thin Xen fonts, others prefer Helvetica, while Times is considered a classic. Also the limits of 8x8 fonts have been mostly removed now so hi res users can enjoy a much nicer picture,

Topaz 8 and 9 are in ROM but WB 3.9 came with a 6-pixel wide version called Topaz 6. It displayed 120 characters per row on 640x200 screens (or 256 y for PAL).

[Michael]

Topaz6/8 is not that much different from XEN/8 and the later is usually installed with MagicWB or MUI plus offers other font sizes and is available in different charsets for support of other languages. So the use case is very limited and only if you prefer some variation of char design style compared to other more popular similar fonts. And you cant draw much variation in such a small square anyways.

[Thomas Richter]

Originally Posted by Michael

Topaz6/8 is not that much different from XEN/8 and the later is usually installed with MagicWB or MUI plus offers other font sizes and is available in different charsets for support of other languages. So the use case is very limited and only if you prefer some variation of char design style compared to other more popular similar fonts. And you cant draw much variation in such a small square anyways.

The problem with XEN is that this font declares that it is a proportional font, even though it is not in reality. This means that it will not be available for some applications which require fixed-size fonts (and it also means that it allowed us to fix a bug in the graphics font size computation...).

I do not quite recall the history of topaz6. Might be that I came up with this font, but this was like 20 years ago. If so, go ahead and share as you like. It is a fixed-size font, and even indicated as such - unlike XEN.

[Daedalus]

Originally Posted by Leandro Jardim

Hmm. I don't know if I believe this. The palette have it's colors 4-7 changed not because they are getting remapped for other image or icon, because if this would be true, they would get locked afterwards specially for the use by the backdrop.

Or, maybe they're not getting locked because the backdrop precision setting isn't high enough? I don't know about the finer details of the picture datatype and its operation in this case, so it's entirely possible that it doesn't lock the pens, just in case something else needs them. Especially if your backdrop precision is set to anything other than "Best". But if those pens weren't needed for anything, then they should stay the same. With just 16 colours in your screenmode, it should be easy to take a screengrab and see if pens 4-7 are used for the backdrop.

Look what I said:

I understand what you're saying, that's not a problem. I haven't checked for pens being locked or unlocked because ultimately that doesn't matter to the end result since pens don't need to be locked to be used. All I can tell you is that the only way I can get the MagicWB colours to be incorrect is to set the icon colour to a lower priority than the backdrop. Otherwise my MagicWB icons are always displayed correctly.

The thing is that before I changed the backdrop, the colors were locked so they were in use by something. If they are not locked, they are not in use by something anymore. This is what I know.

And, aside from all that, have you actually tried using it the way I described? Set your icon precision to the maximum and set the backdrop precision to the lowest setting. Then try changing the backdrop and see if your icons lose their pens. If you're still getting messed up colours, there must be something different on your system - different icon.library, different datatypes or something.

[PeterK]

What Leandro Jardim complained about is correct. There is indeed a small problem with the MWB color setting of the Workbench, but only on an 8 color screen. The Screenmode preferences or maybe also IPrefs seem to set the palette back to the 8 default colors whenever an 8 color screen is activated, so probably even after LoadWB. Then you have to call the Workbench preferences once again and just click onto "USE" in order to re-enable the MWB colors. This issue does not appear on screens with 16 or more colors.

[Olaf Barthel]

Originally Posted by Leandro Jardim

For example when I type in OS 3.5 and OS 3.9 it works:

> CondenseIcon DH0:#? OI

it will batch convert all planar data from the icons in DH0 to OS 3.5 color icons and will remove the planar data replacing it with a tiny dot, so only what remains is the color mapped data. It also converts all the NewIcons data and optimize the color mapped data removing the unused palette entries.

But in OS 3.1.4 the program scan icon by icon but don't do nothing. Unfortunately it don't display any error message too.

Another thing is newiconemu.library. Have you tried to edit NewIcons/ColorIcons with Iconian with that library installed in OS 3.1.4? With it in OS 3.5/3.9 Iconian can load and save these icon types. But in OS 3.1.4, Iconian can't find the color mapped data. Instead, it will load only the planar icon, leaving the color mapped data behind.

Hm... the AmigaOS 3.5/3.9 icon.library both supports NewIcons as well as the quirky IFF icon file format I cooked up at the time. The Amiga icon file format is not intended to be extended, so basically everything one can do to "extend" is a hack.

NewIcons was the most gentle of these extensions because it reused the icon tool types to encode the image data, then made sure that these additional tool types were not visible or accessible to the user. Clever

The AmigaOS 3.5/3.9 icon.library does exactly what NewIcons used to do, without the patches which NewIcons required. Software which tries to access these NewIcon tool type data will not see it, unless it processes the icon files directly (not a good idea, but what can you do?).

Because the tools you mentioned seem to predate AmigaOS 3.5/3.9, it's likely that they will come up short when trying to access the colour icon information. It's not just that the AmigaOS 3.5/3.9 icon.library hides this information, it also interacts with the Workbench through a different set of library functions which did not exist in AmigaOS 3.1. Hence, what older tools will see when they use the older AmigaOS 3.1 icon.library function is not what the Workbench in AmigaOS 3.5/3.9 will see and use.

If you combine these effects, it becomes more plausible why the tools no longer produce the effects you expected them to have. What remains accessible is the planar image data which does not carry colour information and for which palette changes have direct consequences (the 3.5/3.9 icons, as well as the NewIcons are dynamically remapped for the display, so they don't suffer so much).

[Daedalus]

@PeterK

Hmmm... That is interesting, and I can reproduce it here when switching from a 16-colour screenmode to an 8-colour screenmode, but *only* when I have a backdrop image already set. Without the backdrop image, MWB colours are set as expected when switching to an 8-colour screen. OS 3.9 acts in the same way, except that clicking Use in Workbench prefs doesn't restore the MWB colours. So 3.1.4's behaviour is slightly better at least, if not perfect in this situation. It would never cross my mind to use a backdrop that requires non-MWB colours on an 8-colour screen in the first place, since clearly something's not going to match.

It still doesn't explain Leandro's issue, as he's been talking about 16+ colour screens all the way along, and I still haven't seen it on 16 or 32 colour screens.

[Thomas Richter]

For the records: The difference between 8 and >8 color screens is that intuition locks the first four and last four pens for itself. In other words, all of them for an 8 color screen. The reason is that some old-school gadgets perform gadget activation by complementation, such that the first four pens become the last four pens. To keep the visual impression consistent, intuition keeps these pens for itself.

What IPrefs learned in 3.1.4 is not to allocate pens 4-7 for MagicWB on an 8-color screen, but to run into a hard-override of the intuition pens, well knowing that the MagicWB pens are consistent with the visual impression.

For deeper screens, this trick is not required and IPrefs just uses shared pen allocation. Whether it gets usable pens depends on the priority of the pens of the background, which depends on the "quality" setting of the background pattern or picture.

[PeterK]

Originally Posted by Daedalus

@PeterK
It still doesn't explain Leandro's issue, as he's been talking about 16+ colour screens all the way along, and I still haven't seen it on 16 or 32 colour screens.

Sorry, I was too lazy to read all the discussion about Leandro's issues and I couldn't reproduce it yet on screens with 16 colors or more, but I think Olaf Barthel and Thomas Richter have already given some good explanations too about what happens.

In the meantime, I've tried to reproduce the other problems with CondenseIcon and Iconian, but I never had any issues on WB 3.1.4, no matter which icon.library I used for the tests. Both still work.

@Leandro
Please don't use on old installer script from OS 3.0/3.1 on a newer system like 3.1.4+ as it is coming with Iconian. Install old apps always manually. Iconian needs the "emulated" newicon.library of OS 3.9 or from Stephan Rupprecht's homepage, but don't install the NewIcons patch, which would only work with an original newicon.library. Iconian also needs guigfx.library and render.library and some classes and gadgets installed. Then it works on 3.1.4+ and you can read and write all types of icons with it, although I think Iconian has a lot of bugs. So be careful and work with copies of your icons only. - CondenseIcon didn't have any problems to convert NewIcons into ColorIcons here with both icon.libraries.

[kamelito]

@AmigaOS Team
I was reading this https://wiki.amigaos.net/wiki/Exec_Memory_Allocation and This http://aminet.net/package/util/boot/TLSFMem and was wondering if a new memory allocation algorithm was also planned for 3.2.
Was Executive (see Aminet) better than Exec? Is there work ongoing about making Exec more efficient and faster? Are we far from a real-time OS and is it possible to make AmigaOS a real-time one?

[daxb]

I think the biggest problem with such main changes is that you introduce incompatibility. I tried both in the past and theoretical it sounds good but in practise I needed to remove them because of problems.

[Thomas Richter]

The exec memory allocation is prone to fragmentation, true. However, there are applications that depend on is specific implementation, that walk the exec memory list itself as its structures are public. There are also applications that play certain tricks with the memory list, such as to fetch memory aligned to certain boundaries.

As far as fragmentation is concerned, the two biggest causes of fragmentation are the layer cliprect allocation, which re-allocated clip rects on every window re-arrangement, and the graphics region management, which reallocates regions on every damage done to a simple refresh window.

The first cause has been addressed in 3.1.4, as layers pools now cliprects and recycles them, avoiding to go through the exec memory list. There is one cliprect pool per LayerInfo, the layer counterpart of an intuition screen.

The second cause has been addressed in 3.1.4 as well, where graphics now pools all regions and regionrectangles, also helping to speed up damage operations.

What may help is an exec "scratch list" of small memory fragments. PoolMem keeps such a list. But the implementation is touchy as it needs to address the above tricks for aligned allocation or precise return codes some applications (illegally) depend upon.

[kamelito]

I guess it is too late to remove private datas structures from the NDK?

[Thomas Richter]

Isn't that contradiction in terms? Data structures that are documented in the NDK are by definition not private. The problem is the construction of the Os which made many structures public to begin with, but you won't stop a single program from using them by removing their documentation.

Graphics is a prime example of how not to do it in this respect.

Later versions (2.0 and above) are in that sense better because the interfaces changed to easily extensible mechanisms such as taglists, and structures that did not require documentation remained undocumented and private.

[Minuous]

If there are any entirely private structures, they could be removed; however structures in the NDK are usually there for a reason, eg. there are some that are allowed to be read but not written, etc.

[kamelito]

Since there is C in the OS why not compile each C parts for every CPU? I guess it would be a nightmare to test thought.