AmigaOS 3.2 and beyond

[boemann]

Originally Posted by tero

Does this include a fix for the issue that the gadgetless chooser gadget can only be controlled by keyboard?

Those things are not really related, but yes there is a fix for that

[boemann]

Originally Posted by ppeter

A W E S O M E !!!!! :-) :-)


Such pity they had not thought about that 40 years ago!

Would an optional KEYWORD for Setdate be something feasible?

Setdate ram:test.txt ISO8601 2024-07-22 21:41:52

The format could handle it 40 years ago - they just didn't make the ui to do it

And yes a keyword is feasible - not sure we will find time to do it though - many other things we want to spend our time on too

[tero]

Originally Posted by boemann

Those things are not really related, but yes there is a fix for that

I thought you would use that for the floating menus. Anyway glad to hear there is a fix. Thx in advance.

[Tpod]

Originally Posted by Daedalus

I've found the RAD: device is excellent for booting from as a virtual floppy drive, and is already included. Just mount RAD: and the ADF, diskcopy the ADF to RAD: and reboot. An ARexx script could probably combine those steps into a single menu entry without too much trouble.

Thanks for reminding me about RAD: sadly it's useless for Non Standard bootblock ADF's but a good option for other ADF's sometimes. I may move it out of Storage otherwise I'll forget about it again.

I guess I was being too optimistic (probably not feasible as paraj pointed out) that something could be done about those Non Standard bootblock ADF's. I was thinking there may be some clever trick possible to avoid the direct hardware access of the real floppy interface especially via the Early Startup Control.

[kamelito]

@boemann why not also build a set of roms for 68000/68020/68030/68040/68060 with max optimized settings and let user judge if it’s worthwhile or not?

[boemann]

Originally Posted by kamelito

@boemann why not also build a set of roms for 68000/68020/68030/68040/68060 with max optimized settings and let user judge if it’s worthwhile or not?

Because we have better things to do than doing pointless work

[ppeter]

Originally Posted by boemann

The format could handle it 40 years ago - they just didn't make the ui to do it

And yes a keyword is feasible - not sure we will find time to do it though - many other things we want to spend our time on too

Of course! You set the priorities.

Thanks for the answers and thanks a lot for taking it into consideration! :-))

[kamelito]

Originally Posted by boemann

Because we have better things to do than doing pointless work

I suppose that you don’t have the knowledge to write optimized code that works but this is fine. Better wait for faster cpu solutions that will solve performance like they do for ages on PC.
Your work and those of the team is appreciated nonetheless.

[boemann]

Originally Posted by kamelito

I suppose that you don’t have the knowledge to write optimized code that works but this is fine. Better wait for faster cpu solutions that will solve performance like they do for ages on PC.
Your work and those of the team is appreciated nonetheless.

I think you got something wrong here. We are fully aware of how to optimize and that is exactly what we are doing. But we will not build for different CPU as that gives almost nothing in return.

Our focus is on better algorithms and on writing code that takes advantage of cache. But those things have nothing to do with making special builds for different CPUs.

When optimizing you always start where there is most to be gained. And you base that on measurements.

[kamelito]

I recall that Chris Green former AmigaOS graphics.library programmer did optimize some area with 68020 code so I suppose that it is not for nothing. I wonder how many users use 3.2.x on a bare 68000 so I guess that 68020 should be the minimum.

[Thomas Richter]

Originally Posted by kamelito

I recall that Chris Green former AmigaOS graphics.library programmer did optimize some area with 68020 code so I suppose that it is not for nothing. I wonder how many users use 3.2.x on a bare 68000 so I guess that 68020 should be the minimum.

Frankly, there isn't really too much to optimze there. What was optimized (but already in 3.1.4) was the WriteChunkyPixels() area, providing a better algorithm, but even there, the code is generic. Not by conincidence, it is the same algorithm as in P96, though there it is optimized for the 68020 and up. I remember some very tiny code portions that where specific for the AGA machines and thus expected a 68020, but that doesn't really help - something particularly harmless as writing the extended color registers. That's now 68000 code (again) without really much impact on speed.

Please also remember that there is very limited manpower to look after the code, in particular code as messy as that of graphics. Having one common code (AGA, ECS, OCS) helps already quite a bit in maintaining it and testing it as there is only one code branch, and not multiple built options.

[Tpod]

A lot of people own & use more than one Amiga. Despite V4, PiStorm & 060 Accelerators being the talk of the town these days, most haven't installed them in every system they use. Plenty of Amigas out there just with extra ram & some form of mass storage & then there's all the plain 68000 based accelerators. The fact that OS3.2 simply works on everything is one of its best features.

[kamelito]

I suppose that one user of 3.2.x on a plain 68000 is enough then.

[Tpod]

Well Amiga is Retro & there will always be those who want to use the system close to its original spec. Plenty of people on this forum enjoy using their 7MHz 1MB RAM Gotek equipped Amigas; there are others who enjoy the challenge of producing games for these low spec machines. Thankfully some end up getting mass storage & upgrading their RAM or get an accelerator.

The OS having such a low system requirement enables far more new customers which then grows the user base … this is good for everyone. One of my spare A500's has a 68010 installed, this give a 10-12% speed boost over 68000, a very modest but noticeable real world improvement (68000 it's so slow in the first place your far more likely to notice it than say 12% on an 68020). Going 020+ specific in the OS from what I gather gives a 0-6% speed boost depending on the specific bit of code your talking about. This is just too small to notice in real world use.

Is there some piece of the OS code you particularly want to speed up?

[Pyromania]

I'm looking forward to buying the next version of AmigaOS!

[Steady]

@kamelito

Don't forget that users of "plain 68000" doesn't always mean 7MHz, I have an ACA500 which contains a 14MHz 68000 and some solutions are faster. They would be excluded where they might run just fine if the OS is targeted at 68020+

[thyslo]

Can I ask about a feature for upcoming AmiagOS3.3?

I often wanted Multiview to allow search in AmigaGuide documents. I mean something like a 'full text search'. Like if the wanted keyword is not on the currently displayed page/section, MultiView should display the section where it found the keyword and highlight it in there.

But maybe this would be a lot of work, 'though..

[ppeter]

Originally Posted by thyslo

Can I ask about a feature for upcoming AmiagOS3.3?

I often wanted Multiview to allow search in AmigaGuide documents. I mean something like a 'full text search'. Like if the wanted keyword is not on the currently displayed page/section, MultiView should display the section where it found the keyword and highlight it in there.

But maybe this would be a lot of work, 'though..

I'd love that too! I hoped for that since I first used AmigaGuide!