AmigaOS 3.2 and beyond

[phx]

Originally Posted by Olaf Barthel

Would be lovely if it were portable, but this seems to be geared towards the PowerPC platform which means that the entire toolchain to support GCC will be involved.

Indeed, that would be useless. We need a source level debugger which supports SAS/C's LINE-debug hunks, which was widely used by many native Amiga compilers.

The best existing native debugger, with 68060 and source level debugging support, is Ralph Schmidt's BDebug, from the Barfly Assembler package. But as we know him I doubt that he will grant access to the source text.

The only AmigaOS 2.x/3.x native debugger which also comes with full source code is the one which shipped as part DICE 1.15.

There is also the full source code of PowerVisor on Aminet:
http://aminet.net/package/dev/debug/PowerVisor-src

As the name implies, it is quite powerful, but unfortunately only up to 68030. Decades ago I adapted the source locally to add 040 and 060 support, but never completely finished that.

[kamelito]

Did you knew about this ? That is great!
https://archive.org/details/1988-04-30_Amiga_DevCon

[Samurai_Crow]

Originally Posted by kamelito

Did you knew about this ? That is great!

https://archive.org/details/1988-04-30_Amiga_DevCon

No, but I was at the St. Louis one in 1998. Were there notes for that one?

[boemann]

Originally Posted by phx

There is also the full source code of PowerVisor on Aminet:
http://aminet.net/package/dev/debug/PowerVisor-src

As the name implies, it is quite powerful, but unfortunately only up to 68030. Decades ago I adapted the source locally to add 040 and 060 support, but never completely finished that.

Thanks I think this one looks interesting. Would you be willing to polish off those old adaptations or possibly redo them if they are lost. I would be interested in making a texteditor.gadget based gui for it.

[kamelito]

Originally Posted by Samurai_Crow

No, but I was at the St. Louis one in 1998. Were there notes for that one?

http://www.retro-commodore.eu/downlo...Washington.pdf

[gulliver]

Originally Posted by kamelito

http://www.retro-commodore.eu/downlo...Washington.pdf

The link seems to be dead. Do you have another one?

Thanks.

[Zack]

http://www.retro-commodore.eu/amiga-development/

[Samurai_Crow]

Originally Posted by gulliver

The link seems to be dead. Do you have another one?



Thanks.

His first link is to 1988 also. (Archive)

[kamelito]

https://commodore.bombjack.org/amiga...rence_1990.pdf

https://commodore.bombjack.org/amiga...enver_1991.pdf

https://commodore.bombjack.org/amiga...ilano_1991.pdf

https://commodore.bombjack.org/amiga...lando_1993.pdf

https://commodore.bombjack.org/amiga...s_Embeded).pdf

There is also disks posted by Thellier from Paris Devcon.

[Samurai_Crow]

I guess the Gateway vintage notes are lost to the time bandits. 1998 wasn't listed.

[boemann]

Originally Posted by gulliver

The link seems to be dead. Do you have another one?

Thanks.

retro-commodore doesn't support deep linking, but go to the site and search for yourself. The documents on that site is often of superior quality

[gulliver]

Originally Posted by boemann

retro-commodore doesn't support deep linking, but go to the site and search for yourself. The documents on that site is often of superior quality

Thanks will do that.

[kamelito]

Bombjack do have a lot more thought!

[Leandro Jardim]

Sorry for taking so much time to respond. I am was thinking about what to say, among other things.

Originally Posted by Daedalus

In what way? The setting works as expected here - MagicWB icons have the correct colours when that setting is enabled, and behaviour is the same as it is in 3.9. If there aren't enough colours available, and something requires higher precision than the icons, then those pens will be taken.

Are you sure? The icons I use are not color mapped icons like that of OS 3.9 and NewIcons, they are much like the planar icons used by OS 1.x and MagicWB.

From what I know, they have no color mapped data, so they get the palette from palette static entries, usually colors 4-7 from a minimum 8 color Workbench screen.

I always thought that for MagicWB data show properly in such icons they need a MagicWB daemon justly to lock the contents of those palette entries, so not allowing other programs and the OS to modify them. Correct me if I am wrong.

Strange as I always thought that the first function of the MagicWB daemon was to lock the MagicWB colors to not allow they to change, and to not move, and to not get removed from the palette.

I tried to launch one program to look visually if the colors 4-7 are staying locked after I change the backdrop while the option "MagicWB colors" of the Workbench preferences editor is ON. And I should say, before I change the backdrop the colors 4-7 are locked by the OS for use by the MagicWB planar icons, and cannot the changed, but after that, the colors are unlocked.

The most visible change of this is that the MagicWB planar icons I have on my system change their colors 4-7 when I open a drawer full of color mapped icons, for example. The color mapped icons work perfectly, per se.

Try it yourself to see if it also happens to you. With an *16 colors or more* AGA screenmode and that Workbench option enabled, firstly open a drawer full of *3-bitplane* MagicWB icons, then change the backdrop and afterwards open a drawer full of NewIcons/ColorIcons. Do you see it now?

Do not look this as an offense, please. Even I am in doubt if I was right, now...

Originally Posted by Olaf Barthel

What exactly do these programs accomplish, and what is not working as intended? I can see that these predate the AmigaOS 3.9 release, so that might explain why the icon.library from that release onward seems not to account for that functionality.

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.

EDIT: Interesting that I found this issue when I was trying to batch-convert my MagicWB icons because of the earlier issue with them.

EDIT2: These same things also happen with the IconLib by Peter.

[Daedalus]

Originally Posted by Leandro Jardim

Are you sure? The icons I use are not color mapped icons like that of OS 3.9 and NewIcons, they are much like the planar icons used by OS 1.x and MagicWB.

Yep, I'm sure.

From what I know, they have no color mapped data, so they get the palette from palette static entries, usually colors 4-7 from a minimum 8 color Workbench screen.

What you say is true, but you're forgetting that by their very nature of being MagicWB icons, they do use a colour-mapped palette, it's just that that palette information is fixed and stored elsewhere.

I always thought that for MagicWB data show properly in such icons they need a MagicWB daemon justly to lock the contents of those palette entries, so not allowing other programs and the OS to modify them. Correct me if I am wrong.

That's prior to 3.5, yes, because the OS doesn't know anything about colour-mapped icons. But from 3.5 on, that functionality was added to the OS and MagicWB's icon colours are treated with the same consideration as colours from other icon types. If you're using the MagicWB option, of course.

Strange as I always thought that the first function of the MagicWB daemon was to lock the MagicWB colors to not allow they to change, and to not move, and to not get removed from the palette.

It is, but that's because 3.1 and below don't have any concept of icon colour palette locking at all. 3.5+ adds it, though it's not as rigid as MagicWB's daemon in that the pens are prioritised, so should they be needed for something more important, they'll be reallocated.

I tried to launch one program to look if the colors 4-7 are staying locked after I change the backdrop while the option "MagicWB colors" of the Workbench preferences editor is ON. And I should say, before I change the backdrop the colors 4-7 are locked by the OS for use by the MagicWB planar icons, and cannot the changed, but after that, the colors are unlocked.

So it looks like pens 4-7 were required for the backdrop then?

The most visible change of this is that the MagicWB planar icons I have on my system change their colors 4-7 when I open a drawer full of color mapped icons, for example. The color mapped icons work perfectly, per se.

Because they can be remapped to colours that are close to what they use and are also needed for the backdrop. But if you set a backdrop that uses colours that don't exist in your colour icons, you'll see they'll look pretty bad too.

Try it yourself to see if it also happens to you. With an *16 colors* AGA screenmode and that Workbench option enabled, firstly open a drawer full of *3-bitplane* MagicWB icons, then change the backdrop and afterwards open a drawer full of NewIcons/ColorIcons. Do you see it now?

No, I don't. But I expect that's because I have my icon colours set to a higher priority than the backdrop colours. As a result, the backdrop is forced to use the icon colours, including MagicWB colours, so that looks terrible instead of the icons.

Do not look this as an offense, please.

Not at all

[Leandro Jardim]

Originally Posted by Daedalus

Because they can be remapped to colours that are close to what they use and are also needed for the backdrop. But if you set a backdrop that uses colours that don't exist in your colour icons, you'll see they'll look pretty bad too.

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.

Look what I said:

I tried to launch one program to look visually if the colors 4-7 are staying locked after I change the backdrop while the option "MagicWB colors" of the Workbench preferences editor is ON. And I should say, before I change the backdrop the colors 4-7 are locked by the OS for use by the MagicWB planar icons, and cannot the changed, but after that, the colors are unlocked.

The program I used was the FullPalette preferences editor, obviously with it's daemon commented out of startup-sequence. When you click on any color with the SHIFT key pressed at the same time, it beeps if the color is locked by the OS or by FullPalette itself. Anyway the preferences editor works the same without it.

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.

[Pyromania]

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

[coldacid]

Originally Posted by Pyromania

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

Ditto.

[Tigerskunk]

Originally Posted by Pyromania

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

Dito

[Thomas Richter]

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.

Since the icon library of 3.1.4 is pretty close to the 3.9 one, this is maybe due to a change in your settings and not due to changes in the library. What the 3.1.4 icon.library changed was the handling of long file names, but not the general handling of icons.


Note well that that this "newicons" patch does not really work anymore with 3.9 and 3.1.4 either unless you explicitly turn its support off. The reason is that the above programs most likely expect to find the newicons "junk" in the tooltypes of the icon, but as soon as 3.9 or 3.1.4 icon.library is in, it will read this junk itself, interpret it as icon data, and deliver the right icon by itself, leaving the tooltypes the above programs want to work with unavailable.


In other words: This cannot possibly work. The icon.library does now the work of the patch, and for that reason, the patch itself has no data done to work with.

Originally Posted by Leandro Jardim

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.

See above, same problem. Turn the support for new icons *off*, then these programs will get their data. But you won't see the icons then on the workbench.