AmigaOS 3.2 released!

[Pyromania]

@Steril707

What game did you spend 1000 hours coding. I want to buy this gem!

[alancfrancis]

Originally Posted by Pyromania

@Steril707

What game did you spend 1000 hours coding. I want to buy this gem!

I assume it’s this: https://tigerskunk.itch.io/inviyya

Which I’m just about to buy

[coldacid]

Originally Posted by BigD

And yet A-EON pays it so it is possible! A coder like yourself should use the shareware model.

A-EON pays because Trevor's got more money than he knows what to do with.

[Heiroglyph]

What is a mouse adapter that is known to work with the scroll wheel support?

My (probably first generation) Cocolino doesn't work, but it has always been a bit hit or miss.

Preferably one that isn't a bare board just waiting to be shorted out and is still easily available. USB or PS2, it doesn't matter to me.

Thanks!

[boemann]

Well I've only tested scrollwheel with uae. but I'd assume cocolino to work too. The scrollwheel support relies on newmouse events which is the de-facto 68k standard. You still need to install it's driver software though. The thing the os does is replace the freewheel program

[Tigerskunk]

Originally Posted by BigD

And yet A-EON pays it so it is possible!

That's because Trevor has a lot of money and is a good person and does this for the Amiga
Not because he earns any money with this.

[jPV]

I have some problems with the Shell usage on OS3.2:

1) Redirecting both stdout and stderr on the same line doesn't work. For example, "lha >RAM:test.txt *>>RAM:test.txt" gives an error "unable to open redirection file". The same happens with other (internal) commands too, not just with lha. This works just fine with OS3.1, OS4, and MorphOS, so it looks like a bug in newer 68k AmigaOS version(s).

2) The FailAt command seems to do some weird things when combined with the previous line in a script file. The redirection line will be looped forever when you add the FailAt before it and the script never exits. This also doesn't happen on older/other operating systems and looks like a new bug.

Here's an example script to reproduce both issues in the same script:

failat 21 ; this causes an eternal loop for the next line
lha >RAM:test.txt *>>RAM:test.txt ; combining both stdout and stderr on the same line doesn't work

It would be nice to hear comments from developers that is there any work-around for these, because they currently cripple my own project where I'm creating a GUI for shell programs. I'd need to get everything redirected in one line with big enough fail limit to avoid any shell windows popping up in any situation.

I'll also attach two screenshots, one showing how everything works as expected on OS3.1 and then another showing them failing on OS3.2.

[Amiga68k]

Originally Posted by jPV

I have some problems with the Shell usage on OS3.2:

1) Redirecting both stdout and stderr on the same line doesn't work. For example, "lha >RAM:test.txt *>>RAM:test.txt" gives an error "unable to open redirection file". The same happens with other (internal) commands too, not just with lha. This works just fine with OS3.1, OS4, and MorphOS, so it looks like a bug in newer 68k AmigaOS version(s).

Specifically for lha, I'm also seeing different behavior with just "lha >RAM:test.txt"

OS3.1 returns to the shell
OS3.2 doesn't return to the shell, file is locked

For specifically lha there is this "Paused. Press any key to continue..." you get when just typing "lha" that might play a role...? Probably not related to the issue you are seeing though, but for instance "cd >RAM:test.txt" returns to the shell correctly.

[Olaf Barthel]

Originally Posted by Amiga68k

Specifically for lha, I'm also seeing different behavior with just "lha >RAM:test.txt"

OS3.1 returns to the shell
OS3.2 doesn't return to the shell, file is locked

For specifically lha there is this "Paused. Press any key to continue..." you get when just typing "lha" that might play a role...? Probably not related to the issue you are seeing though, but for instance "cd >RAM:test.txt" returns to the shell correctly.

This still bears closer examination for sure.

What seems odd to me is the combination of using the same destination file for redirecting the output and then also appending the console output to it in sequence (we don't really have a good stderr on AmigaDOS).

Redirecting the output will create or overwrite an existing file which can then no longer be opened in read-only or read/write mode, even by the same process which created/overwrote that file just now. Appending console output to the same output redirection-created file will likely fail. It does not have to fail, though, because the file system you are redirecting all that output to has the final say on whether this combination of creating and appending is OK or not.

Could be that this worked differently for the shell or the file system in the past which you are using (redirection or appending to NIL: should not have such side-effects because no file system is involved). For consistency, I would have expected that the shell stops when it fails to open the console redirection file.

Is just the LhA command tripped up by this or would any command do, e.g. "Echo" or "Dir"?

[Thomas Richter]

Originally Posted by jPV

I'll also attach two screenshots, one showing how everything works as expected on OS3.1 and then another showing them failing on OS3.2.

Not reproducable here, but then again, I'm not using 3.2, but the shell 47.36, which was the latest version I made before I left. So apparently, something broke later in the history.

[Lisko]

I was wondering if the copymemquick patch still gives an advantage on 3.2 or has been integrated in?

[Amiga68k]

Originally Posted by Thomas Richter

Not reproducable here, but then again, I'm not using 3.2, but the shell 47.36, which was the latest version I made before I left. So apparently, something broke later in the history.

Does "lha >RAM:test.txt" return to the shell immediately with 47.36? On the version shipped with 3.2 the shell keeps waiting for input.

Edit: nevermind, this seems to be related to the version of lha in use:
v1.38, shell keeps waiting for input, also on 3.1, workaround: use -Qa
v2.15, shell returns at once, both on 3.1 and 3.2

[Thomas Richter]

Originally Posted by Lisko

I was wondering if the copymemquick patch still gives an advantage on 3.2 or has been integrated in?

No, and frankly: Where do you see a measureable advantage of this except in synthetic benchmarks?

[jPV]

"lha >NIL: *>>NIL:" or "dir >NIL: *>>NIL:" crashes the whole machine under 3.2, but doesn't crash on 3.1...

Also just "dir >>NIL:" takes the machine down on 3.2... so something with the appending?

[rutra80]

On clean 3.2 gurus indeed, but on 3.1.4 upgraded to 3.2 doesn't...

[Heiroglyph]

Originally Posted by boemann

Well I've only tested scrollwheel with uae. but I'd assume cocolino to work too. The scrollwheel support relies on newmouse events which is the de-facto 68k standard. You still need to install it's driver software though. The thing the os does is replace the freewheel program

I'm having no luck with it. I've even tried using the OS4 command line argument just in case. Yes, it is enabled in IControl.

If anyone else gets it working with a Cocolino, I'd love to hear how.

Otherwise I'd sure like to find a replacement that is known to work.

[boemann]

Originally Posted by Heiroglyph

I'm having no luck with it. I've even tried using the OS4 command line argument just in case. Yes, it is enabled in IControl.

If anyone else gets it working with a Cocolino, I'd love to hear how.

Otherwise I'd sure like to find a replacement that is known to work.

what does cocolinotest say ?

Also not all mouse work with cocolino - are you sure it is a ps/2 based mouse

[Heiroglyph]

Originally Posted by boemann

what does cocolinotest say ?

Also not all mouse work with cocolino - are you sure it is a ps/2 based mouse

With just the default driver options, when I scroll forward it says Fiveth Down, scroll back it says Fourth Down.

It's a PS2 mouse, no USB to PS2 adapter although I won't guarantee what the IC is in it.

Edit: I just tried an ancient MS Intellimouse with the ball and it has the same result.

[ExiE]

Originally Posted by Thomas Richter

Not reproducable here, but then again, I'm not using 3.2, but the shell 47.36, which was the latest version I made before I left. So apparently, something broke later in the history.

Does that mean you're no longer part of the OS3.x dev team?

[Swe_Kryten2x4b]

Originally Posted by Heiroglyph

I'm having no luck with it. I've even tried using the OS4 command line argument just in case. Yes, it is enabled in IControl.

If anyone else gets it working with a Cocolino, I'd love to hear how.

Otherwise I'd sure like to find a replacement that is known to work.

I can't find it on their website anymore (well, I can see it on their startpage but once I click on it I just get "No product matches the search criteria") but I bought a scroll-wheel equipped mouse from amigakit quite some time ago that works fine with 3.2. Some custom-made one to be sure but it came with just the standard connector already in place. For use without wheel, just plug it in. If you want the wheel enabled, one line in user-startup to start the driver.

According to scout's tasklist it uses cocolino to do the job.