AmigaOS 3.2 released!

[Swe_Kryten2x4b]

Originally Posted by Swe_Kryten2x4b

Well, I guess I need to think of something else...trying to run it from a script in wbstartup will be my next attempt.

Quoting myself...that seems to work. Fingers crossed.

[samplist]

There's seems to be a bug in the help system when the OS partition name contains spaces.

[Heiroglyph]

Originally Posted by samplist

There's seems to be a bug in the help system when the OS partition name contains spaces.

In your startup-sequence, what is Locale assigned to?

I normally change all mine to reference SYS: rather than disk name because I've ran into issues like this in the past.

I'm not sure that's the issue, but it's possible.

[samplist]

Thanks @Heiroglyph, LOCALE is assigned to SYS:Locale

[jPV]

Originally Posted by samplist

There's seems to be a bug in the help system when the OS partition name contains spaces.

The documentation tries to access the GUIDEDIR: assign, but hrmh... where does it assign that? Quickly looking I can't see it as a generic assign... is this some new non-standard trick somewhere?

In any case, whereever it assigns that, it doesn't seem to use quotation marks for the path... if you copy the documentation to "Ram Disk:" and try to view it from there, it also fails with the same way.

EDIT: it seems to be a new feature, so probably a bug that users can't fix themselves:
"GUIDEDIR: is now a fake assign usable when specifying paths. Its purpose is to make those links work as expected no matter who opened the guide and from where. It very much resembles the PROGDIR: concept."

[jostberg]

Just got my CD. Must say the upgrade process from 3.1.4.1 was very easy and fast. Most, if not all, of my previous settings were unchanged. As I have an Apollo 4060 in my A3000 I'm still on 3.1 ROM but the machine with 3.2 seems more responsive than before.

A very pleasant experience so far!

[samplist]

Originally Posted by jPV

EDIT: it seems to be a new feature, so probably a bug that users can't fix themselves:"

Thanks @jPV, good to know!

[Michael]

Originally Posted by jPV

T
EDIT: it seems to be a new feature, so probably a bug that users can't fix themselves:
"GUIDEDIR: is now a fake assign usable when specifying paths. Its purpose is to make those links work as expected no matter who opened the guide and from where. It very much resembles the PROGDIR: concept."

Yes, it's a new feature similar to PROGDIR:, and the good news it's user fixable, all you have to do is add quotes " " in all links inside the help guide so that path resolving does not fail on spaces, this is being addressed for the update.

[Michael]

Originally Posted by Jope

Exchange 47.7 crashes if you remove Viewfonts 2 from the commodities list and then hide the Exchange window by using the close gadget.

Does not crash with the older Exchange 40.1 running under 3.2 nor 45.2 running under 3.9.

https://aminet.net/package/text/font/viewfont

Can confirm that something is going wrong, under investigation.

[nogginthenog]

Originally Posted by rutra80

To be more precise:

KS 3.1.4 + AmigaOS 3.2 = no guru when dir >>nil:
KS 3.2 + AmigaOS 3.2 = guru when dir >>nil:

Originally Posted by nogginthenog

I can reproduce this on my fresh 3.2 install.
I'll do some more testing tomorrow.

Kickstart 47.96, A4000 ROM here.
I don't have any issue running dir >> ram:test

Maybe it is a nil: issue?

Running MuForce I get these hits. Same results with no SS and just running setpatch.

LONG READ from 0000001C                        PC: 00F82664
USP : 089F6984 SR: 0010  (U0)(-)(D)  TCB: 089F5A78
Data: 00000005 00000000 00000404 00000001 021D68DB FFFFFFFF 021D68DB 000003EC
Addr: 00000018 089F698C 089F5AD4 00000000 089F6B70 089F69D0 080008D4 08002340
Stck: 00F969A0 00F9CF0E 00000000 021D68DB 0500089F 69A0D525 00000000 089F698C
Stck: 089F5AD4 00000404 00000000 085FD524 00000001 021D68DB FFFFFFFF 021D68DB
Name: "Shell Process"  CLI: "dir"  


LONG WRITE to  0000001C        data=089F698C   PC: 00F82668
USP : 089F6984 SR: 0010  (U0)(-)(D)  TCB: 089F5A78
Data: 00000000 00000000 00000404 00000001 021D68DB FFFFFFFF 021D68DB 000003EC
Addr: 00000018 089F698C 089F5AD4 00000000 089F6B70 089F69D0 080008D4 08002344
Stck: 00F969A0 00F9CF0E 00000000 021D68DB 0500089F 69A0D525 00000000 089F698C
Stck: 089F5AD4 00000404 00000000 085FD524 00000001 021D68DB FFFFFFFF 021D68DB
Name: "Shell Process"  CLI: "dir"  


LONG WRITE to  00000000        data=089F698C   PC: 00F82672
USP : 089F6984 SR: 0010  (U0)(-)(D)  TCB: 089F5A78
Data: 00000018 00000000 00000404 00000001 021D68DB FFFFFFFF 021D68DB 000003EC
Addr: 00000000 089F698C 089F5AD4 00000000 089F6B70 089F69D0 080008D4 08002344
Stck: 00F969A0 00F9CF0E 00000018 00000000 0500089F 69A0D525 00000000 089F698C
Stck: 089F5AD4 00000404 00000000 085FD524 00000001 021D68DB FFFFFFFF 021D68DB
Name: "Shell Process"  CLI: "dir"  


LONG READ from 00000010                        PC: 00F82678
USP : 089F6984 SR: 0010  (U0)(-)(D)  TCB: 089F5A78
Data: 00000003 00000000 00000404 00000001 021D68DB FFFFFFFF 021D68DB 000003EC
Addr: 00000000 00000000 089F5AD4 00000000 089F6B70 089F69D0 080008D4 08002340
Stck: 00F969A0 00F9CF0E 00000018 00000000 0500089F 69A0D525 00000000 089F698C
Stck: 089F5AD4 00000404 00000000 085FD524 00000001 021D68DB FFFFFFFF 021D68DB
Name: "Shell Process"  CLI: "dir"

[Futaura]

Originally Posted by Rotzloeffel

The warp Datatypes working only with the picture.datatype of CybergraphX and not with the picture.datatype of 3.9 3.1.4 or 3.2..... they use a "hack" to ignore the API of picture.datatype V43.... this is NOT working anymore with picture.datatype V47.

Of course, you can use this Datatypes, but there is no benefit anymore.... or never was

What ever are you talking about? The Warp Datatypes do not use any hacks. Why would I restrict them to only use the CGX picture.datatype or ignore the V43 API, which the datatypes rely on?

The Warp Datatypes have been carefully written to support all known picture.datatypes V43 and above on OS3, OS4 and MorphOS, even third party ones (e.g. from AfaOS). They certainly work perfectly well on the 3.9 and 3.1.4 picture.datatype and should work fine with 3.2 also, unless some required features of picture.datatype were removed in V47.

[Michael]

Originally Posted by Rotzloeffel

The warp Datatypes working only with the picture.datatype of CybergraphX and not with the picture.datatype of 3.9 3.1.4 or 3.2..... they use a "hack" to ignore the API of picture.datatype V43.... this is NOT working anymore with picture.datatype V47.

Of course, you can use this Datatypes, but there is no benefit anymore.... or never was

What benefit ? What changed ? What is not working as expected ?
Which of the datatypes in question ? Example please.

[boemann]

Originally Posted by Futaura

What ever are you talking about? The Warp Datatypes do not use any hacks. Why would I restrict them to only use the CGX picture.datatype or ignore the V43 API, which the datatypes rely on?

The Warp Datatypes have been carefully written to support all known picture.datatypes V43 and above on OS3, OS4 and MorphOS, even third party ones (e.g. from AfaOS). They certainly work perfectly well on the 3.9 and 3.1.4 picture.datatype and should work fine with 3.2 also, unless some required features of picture.datatype were removed in V47.

There have been a bit of confusion here. The Warp Datatypes "warp" only with cgx picture.datatype but function fine without. There are no incompatibilities wrt. warpDTs known at the moment. They fall back to the standard V43 API with OS-supplied variants of picture.datatype and work as intended on 3.2.

As to benefit: We did some performance test and the 3.2 jpeg datatype is at least as fast as the warp jpeg, We have not compared the other picturetypes.

[Rotzloeffel]

Originally Posted by Michael

What benefit ? What changed ? What is not working as expected ?
Which of the datatypes in question ? Example please.

As Camilla said! The warp-effect is only with cgx picture.datatype... i caled it benefit i never said it would not work without... but slower

[Futaura]

Originally Posted by boemann

There have been a bit of confusion here. The Warp Datatypes "warp" only with cgx picture.datatype but function fine without. There are no incompatibilities wrt. warpDTs known at the moment. They fall back to the standard V43 API with OS-supplied variants of picture.datatype and work as intended on 3.2.

Thanks for clearing this up. However, I should emphasize there are no hacks involved - the "they fall back to the standard V43" comment is incorrect. There is only one V43 API method used by the Warp Datatypes - there is no fall back to different versions (or were you referring to the new V47 PDTA_ObtainPixelBuffer feature?). Nothing different, in terms of speed, is done in the Warp Datatypes if the CGX picture.datatype is not used or not. It is the OS picture.datatype itself that is slower than the CGX one.

As I understand it, the OS picture.datatype does a lot of extra copying between memory buffers, which is what slows it down. I don't know how the CGX picture.datatype works internally, but maybe it copies the chunky data from a subclass directly into a bitmap, perhaps even using the graphics card via CGX to do this. Of course, this may not be compatible with V44 things like dithering, but there is perhaps room for optimization in the OS picture.datatype.

As soon as my 3.2 CD arrives, I shall look at supporting PDTA_ObtainPixelBuffer in the Warp Datatypes

[Michael]

I wonder why anyone would like to use cgx version of the picture datatype that is old, not updated, and has many compatibility issues and bugs, and I doubt that it's dithering functions are faster. If warp cut corners somewhere, good for it, but for general purpose use, the OS supplied picture datatype has been the only choice since 20 years now, even for CGX users (me included).

[Futaura]

Originally Posted by Michael

I wonder why anyone would like to use cgx version of the picture datatype that is old, not updated, and has many compatibility issues and bugs, and I doubt that it's dithering functions are faster. If warp cut corners somewhere, good for it, but for general purpose use, the OS supplied picture datatype has been the only choice since 20 years now, even for CGX users (me included).

The main reason for me is that the CGX picture.datatype is simply much faster than the suboptimal OS picture.datatype. I guess it depends if you use any applications that rely on the V44+ new features, such as scaling.

[Romanujan]

There is probably also a room for size optimization in several small Kickstart modules, like potgo.resource or wbtask - unofficial versions by DonAdan (http://wt.exotica.org.uk/test.html - WT31.lzx artchive) are visibly smaller (just don't use his ramlib, it's buggy).

[Phantasm]

Maybe obvious (and not a defect per se) but due to the new icon.datatype which allows icons to be displayed as images when you click on an .info file in directory opus 5 it now defaults to displaying it in multiview rather than using the built in .info viewer. This is quite annoying if you want to edit the tooltypes


I ended up disabling this by updating the filetypes configuration for pictures and excluding info files by requiring a match for ~(#?.info) as well as a hit from the datatypes.

[daxb]

Maybe you use the wrong icon identifier? My DOpus5 installation has a filetype "picture, icon" for icons that does a byte compare to $e310. So no datatype group match.