AmigaOS 3.2 released!

[ifrit05]

Originally Posted by wiser3

Could someone explain the procedure to see it in English and show a screen shot?

Here ya go, recorded on WinUAE.



https://drive.google.com/file/d/1H-v...ew?usp=sharing


(Might still be processing)



The quote after the asterisk changes every time the scrolling text finishes, there are a couple of good ones so keep an eye out when you do it yourself.

[bubbob42]

Originally Posted by jbenam

Well, it looks like I was right (a file on one of the floppies), I just never bothered to check the update disk as I thought the Easter Egg was present in the base OS3.2

An older version can be found on the original 3.2 floppies as well.

[jbenam]

Originally Posted by bubbob42

An older version can be found on the original 3.2 floppies as well.

Dang, looks like I had the right idea but I must have somehow skimmed over it, then

[enigma776]

Originally Posted by tomcat666

You are right, it is working, for some reason after I did reinstall it was not in the startup sequence. Working perfectly. Thank you.

How did you get this working? I have PatchControl and MCP in my startup-sequence but for some reason its not being triggered, If I manually start MCP then it works but will not load from startup.

Got it working.

[Channel-Z]

Originally Posted by Paulthetall

I have the Amiga OS 3.2 (and upgrade to 3.2.1) on my Amiga 1200. I was hoping to have the scroll wheel function, but unfortunately it doesn't work. Also selected scroll wheel select box in the input settings in Workbench. I have a Mouse of Amikit with the mouse connector with scroll wheel. I have 2 of them and both have the same issue.

How can I fix it? Is it a known issue?

To get the AmigaKit mouse scroll wheel working in OS32x

1. Go to Prefs>IControl and enable "Scroll Wheel Enabled"
2. DL the driver from here
https://web.archive.org/web/20160307...0v1.0fw2.2.lha

3. UnARC the .lha file
4. Copy MX1000.driver to C:
5. Add this to your user-startup

;MX1000 Mouse Scroll Wheel Driver for AmigaKIT mouse
If Exists C:MX1000.driver
C:MX1000.driver
Endif

6. Reboot and it should be working
(**Commented out if using with WINUAE causes issues with mouse movement, uncomment to use on real hardware)

[AC/DC HACKER!]

You could place it in WBStartup as well. Note: It will cause control problems with some 3D games if you play those (Payback WOS, example..). Once you exit the game, you lose full control of the mouse.

[wiser3]

Any hints on when the next Amiga OS release will be released? Yeah, i know, when it's ready.

I'm bringing an Amiga 1200 back to life. Given how long it's been since the last AOS release i'll fall into the usual trap of buy new ROM's and the next day a new release is announced.

[boemann]

Originally Posted by wiser3

Any hints on when the next Amiga OS release will be released? Yeah, i know, when it's ready.

I'm bringing an Amiga 1200 back to life. Given how long it's been since the last AOS release i'll fall into the usual trap of buy new ROM's and the next day a new release is announced.

If you are asking about a potential future 3.3 then I wouldn't worry. Our focus is very much still on making 3.2 as stable as possible. We believe 3.2 is a very good release and we are here to support it.

That brings me to 3.2.2 update, which is maybe what you asked since it sounded like your worry was more about burning a new ROM. We certainly intend to bring out a 3.2.2 update as well as 3.2.3 and 3.2.4 if the need arises. Updates can always happen very fast or after a long time. I could tell you that 3.2.2 will be out in say january, but it could just a well be march, but even if it is out january who is to say we will not have to make a 3.2.3 a fmonth after that. The nature of updates is that they are unpredictable. The good thing is that an update doesn't cost you anything and there is not even an urgent need to burn a new ROM unless you choose to do so.

Right now we don't have any bugfixes where we feel it has to be out asap, but that can change tomorrow. We do want 3.2.2 update out sooner rather than later, as it has been almost a year now since 3.2.1. Even if an urgency came up, I don't see us releasing it this year as we will have to go through testing and that takes time.

So to sum it up: I can never promise anything more than a month, but right now it will not happen the next month.

[boemann]

Originally Posted by Ras Voja

Snoopy,

Is there a more universal USB mouse solution included in my legal OS 3.2?

No, 3.2 does not contain any drivers for specific mice (apart from standard amiga mice). What 3.2 gives is a way to make use of scrollwheel events that such a driver could offer.

The driver is tightly coupled to the way your mouse is coupled to the amiga. If you have an usb mouse then that would have to plug into a usb port which the amiga doesn't have natively. So such a driver would be related to the usb hardware you have

[wiser3]

Originally Posted by boemann

So to sum it up: I can never promise anything more than a month, but right now it will not happen the next month.

Thank you for that full answer! It was much more of a complete explanation of what's going on then i expected.

[mfilos]

Ok... had some strange issue yesterday in case someone can elaborate!

Since I use Vampire V2 on an A600, Vampire V4-SA and also WinUAE and some other Amiga with 030 I wanted to be able to get my CF and share it for test purposes among the systems.
That's why I made a Monitor-Startup file (that replaces the line C:LoadMonDrvs >NIL: of startup-sequence) that checks the following:

• If WinUAE is active then. If not...
• Check the presence of a V2 or V4-SA board. If not then probably Amiga
• If WinUAE is active then it check whether it has RTG disabled or enabled

Having different Picasso96Settings file assigned to each monitor's tooltypes is easy. Having different ScreenMode.prefs is easy as well if you copy or rename after system gets discovered. What I wanted though is being able to save EVERY's sessions changes.
That's why I thought of using SYMBOLIC LINK (via MakeLink command).

You can see from the image bellow that I use a symbolic link of the file ScreenMode.prefs for example to file ScreenMode.prefs.UAE. That way if you change a mode and hit SAVE it should change the actual file! Brilliant isn't it?




Well... under OS3.9 and MakeLink v45 that I use it works just fine.
Under OS3.2.1 and MakeLink v47.1, hit SAVE or USE doesn't do ANYTHING (like Intuition didn't realized anything). If you hit SAVE though and make a reboot, the mode you chose works just fine!!!

Is there anything I'm missing here?

[boemann]

Originally Posted by mfilos

Well... under OS3.9 and MakeLink v45 that I use it works just fine.
Under OS3.2.1 and MakeLink v47.1, hit SAVE or USE doesn't do ANYTHING (like Intuition didn't realized anything). If you hit SAVE though and make a reboot, the mode you chose works just fine!!!

Is there anything I'm missing here?

Yes. The way ENV: works on 3.2 is a bit different from 3.9. it is a link of ENVARC:

But not just any kind of link. It is a lazy copy kind of thing, meaning nothing is copied until it is read. If you then overwrite or delete what is in ENV: the you effectively break the link for that file.

Also intuition always only monitors ENV: for changes. When you hit use the prefs files in ENV: is changed and if you press SAVE both ENV: and ENVARC: is updated. So that is why in your case SAVE works as it changes your persistent stuff in ENVARC:

Now since you have links in ENVARC: and we link from ENV:to ENVARC: I can totally see how this very special usecase may break down.

If you could try changing the make link of ENV into a copy of ENVARC: and see if this makes a difference. It will mean you end up using more ram but I guess that is not a big problem.

Also please tell me which comes first: your monitor script or the ENVARC: to ENV: linking

[Thomas Richter]

The "link to external devices" aka "lazy copy" the RAM disk supports works well if the external object is a hardlink. It does not work for soft links. Thus, make sure that the above external link is a hard link (which is resolved by the file system) and not a soft link (which the RAM disk cannot resolve).

[boemann]

Originally Posted by Thomas Richter

The "link to external devices" aka "lazy copy" the RAM disk supports works well if the external object is a hardlink. It does not work for soft links. Thus, make sure that the above external link is a hard link (which is resolved by the file system) and not a soft link (which the RAM disk cannot resolve).

Yes a softlink would explain the issue for sure, but looking at his script he uses hardlinks, so it must be something else.

[mfilos]

Originally Posted by boemann

Also please tell me which comes first: your monitor script or the ENVARC: to ENV: linking

My monitor script runs where the line of C:LoadMonDrvs >NIL: is so it's definitely after the ENV/ENVARC force link.

Originally Posted by boemann

If you could try changing the make link of ENV into a copy of ENVARC: and see if this makes a difference. It will mean you end up using more ram but I guess that is not a big problem.

Can you please elaborate more on that. I haven't understood it correctly.

Also yes, the links are NOT soft links as you said.
With Soft link it didn't work anyway (ENV issues).

[boemann]

Originally Posted by mfilos

My monitor script runs where the line of C:LoadMonDrvs >NIL: is so it's definitely after the ENV/ENVARC force link.


Can you please elaborate more on that. I haven't understood it correctly.

I would try and split it then. Do your links before the env/ENVARC force link, and keep the loadmondrvs where it was originally



As for elaborating on what i meant (but now you should try the above first):
I was suggesting to replace:

MakeLink RAM:ENV to ENVARC: FORCE

with

Copy ENVARC: RAM:ENV ALL

[mfilos]

Originally Posted by boemann

I would try and split it then. Do your links before the env/ENVARC force link, and keep the loadmondrvs where it was originally

Ok this works just fine!!!
Only problem is that the first declaration of C:ShowBoards gives me a pop-up window "Please insert volume ENV in any drive" (apparently because it tries to write to ENV which isn't there yet). If I hit CANCEL everything works just fine. So... what I can do to solve this?

Originally Posted by boemann

As for elaborating on what i meant (but now you should try the above first):
I was suggesting to replace:
MakeLink RAM:ENV to ENVARC: FORCE
with
Copy ENVARC: RAM:ENV ALL

Tried that as well, but apart from the part that it is a lot slower (as it copies everything), it didn't work as intended and generally I don't like that approach.

Thanks again for your time helping me out man. Means a lot

[boemann]

Originally Posted by mfilos

Ok this works just fine!!!
Only problem is that the first declaration of C:ShowBoards gives me a pop-up window "Please insert volume ENV in any drive" (apparently because it tries to write to ENV which isn't there yet). If I hit CANCEL everything works just fine. So... what I can do to solve this?

Well if really want to go with showboards, then maybe briefly assign ENV: to ENVARC: when you run your script

[mfilos]

Originally Posted by boemann

Well if really want to go with showboards, then maybe briefly assign ENV: to ENVARC: when you run your script

Ok that did the trick!

...BUT...

USE still doesn't work, and SAVE works only after the reboot... SO BACK TO SQUARE ONE
I was wrong on saying it did work changing the position of my script in the first place.

[boemann]

I'm starting to question if this has anything to do with your links at all. To me it sounds more like iprefs not running

Can you please test a setup where you don't have links but just actual files and then try to click "use"

When you do click save, can you then see the pref files you changed in ENV: