AmigaOS 3.2 and beyond

[Minuous]

@coldacid:

All depths are supported. It has all the features of the OS4 version plus support for marquee selections and move/cut/copy/paste on these.

[Yulquen74]

Is everyting compiled for 68000, or are there 020/030 compiles for Amigas with
such processors or accelerator boards?

[Rotzloeffel]

68000 only. There are no Special CPU-Version... I have no idea for what this could be good for

[Warty]

@Boemann, about the textedit.gadget, can you share any more information?
- any built in 'save'/'load' functionality? if so, what does that look like?
- any provision for user-supplied markup? not the syntax highlighting that an app might provide, but bold, italic, etc.
- curious about performance. Running on bare 68000 is mentioned a few times, but I think of the old 1.x notepad app, and you could actually see the characters get drawn as you typed them. In general, Amiga editors and word processors always seemed slow to render characters, compared to same-generation Macs. I never knew if that was because every Amiga programmer had to write their own low level rendering (the mac toolbox (or whatever the ROM was called) provided a decent chunk of fast asm routines that could be used for stuff like that), or if it was more related to how intuition/KS worked overall.

Anyway, excited for the new text gadget, sounds great.

[bubbob42]

The textedit.gadget is being tested on 7MHz+FastRam config regularly. It performs surprisingly well, better than expected from such a slow machine.

We‘re still evaluating, but it is already apparent that Reaction has a lot less overhead compared to MUI on the same machine.

[Michael]

Originally Posted by ancalimon

When the refresh rate of the resolution is not 50hz for pal timings and 60hz for ntsc timings, there is screen tearing when moving objects on screen.

This is especially a problem with CGX screens on CVisionPPC where 50hz refresh rates disturb your eye too much. (and even with a 50hz screen mode there is visible line that looks like it is tearing the screen slowly in one direction depending on whether your precise 50.xxxxhz mode is higher or lower than the PAL precise timing). Also the mouse pointer will not move smoothly when refresh rate is different from 50hz. (I overcame this problem by creating 100hz screenmodes. This way the mouse moves semi-smoothly alas with a bit of flickering as if there is a double of the mouse pointer.)

Is there a way to fix this? Maybe create a new timer for screenmodes?

Can you elaborate a bit more on the problem and where it happens ?
I am running a CVPPC and have no problems that you are trying to describe. My screens are 75, 85, 100, 120Hz on CRT. With 100 you can experience some shimmering effect from some games running via rtgmaster library and the cause of this is yet unknown.

[tom256]

Originally Posted by Rotzloeffel

68000 only. There are no Special CPU-Version... I have no idea for what this could be good for

Lot's of people are claiming that compile for MC68020+ bringing speed benefits. Some applications are MC68020+ not without the reason I guess.

[Minuous]

The fact that 68020 code runs faster than 68000 code can be objectively demonstrated.

[Thomas Richter]

Originally Posted by Michael

Can you elaborate a bit more on the problem and where it happens ?
I am running a CVPPC and have no problems that you are trying to describe. My screens are 75, 85, 100, 120Hz on CRT. With 100 you can experience some shimmering effect from some games running via rtgmaster library and the cause of this is yet unknown.

Wrong thread? Tearing is the result of lack of synchronization. Unfortunately, the means by which you can synchronize RTG output are limited by the graphics card interface, for example its ability to create a vertical blank interrupt or to query the beam counter. There is typically not much service in this direction available, and multiple graphics cards do not provide sufficient services to allow synchronization. While P96 makes a best attempt to emulate WaitTOF() (synchronization to the top of frame), the corresponding counterpart WaitBOVP() is not emulated at all as there is no abstraction to read the beam counter from a board, and hence any attempt to gain synchronization with this call will fail.

[Thomas Richter]

Originally Posted by tom256

Lot's of people are claiming that compile for MC68020+ bringing speed benefits. Some applications are MC68020+ not without the reason I guess.

Mostly without reason. There are certainly some heavy-duty data operations where 68020+ code would be beneficial, e.g. rendering of images or video, or changing to the color format of a picture. However, the overall impact of 68020+ code for the usual desktop operations is too small to justify potential incompatibilities and work on customer complaints.

Besides, it is really bad practise to provide multiple versions specialized to a specific CPU each. A much better approach is to have an internal dispatcher that selects the ideal algorithm for the target platform and is otherwise ignorant on the CPU type.

The math libraries are a prime example of how to do this. They contain code for 68000,68020,68882,68040 and 68060 all under a single library, and select the right one for the CPU they find.

[ancalimon]

I was wondering if all the gurus of Amiga that makes life much easier are working with OS3.1.4 and 3.2?

I mean like PeterK's icon.library, or Thomas Richter above.

[PeterK]

Myself, I'm not "working" with AmigaOS anymore since the start of the Millennium, just using OS 3.9+3.1.4 for asm coding and tests, but no 3.2 yet. In the 90th I still used my A2000 for online banking, email, ftp, BBS etc, but now PCs are doing that and WinUAE emulates the Amiga.

And the Gurus coming from my icon.library never wanted to work together with the AmigaOS, at least the red ones always refused to do that!

[Thomas Richter]

Originally Posted by ancalimon

I was wondering if all the gurus of Amiga that makes life much easier are working with OS3.1.4 and 3.2?

Yes. A beta of 3.2 is the current basis for operation on the A2000, 3.1.4 on the A1200. Another tool is vamos which uses the 3.2 command set for its job. Compilation and development is mostly on vamos these days.

[DarrenHD]

Originally Posted by gulliver

Greetings fellow Amigans,

I believe we need to establish a two way communication channel between
us, AmigaOS 68k developers, and you, the user.

For us, developers, it is important to get your ideas and opinions
regarding AmigaOS right. We don't want to lose the feedback loop that
is required for the constant improvement we aim for our beloved OS.

My idea is to simply invite you to this talk, since we have a lot to
tell you, but more importantly, there is a lot we need to learn and
understand from you as a user.

We are amiga fans too, and much like you, we also had enough of these
toxic repetitive rants polluting threads about my option is better
than yours, lawsuit wars, companies and source model. We haven't got
the power to change any of the above. If you want to cover these
topics, please go somewhere else and create your own thread, do not
attempt to hijack this one.

Lets have a civil conversation on technical, and perhaps much more
mundane things about our hobby and passion.

Thanks in advance.

Can you add DSP support to the OS for the AA3000+? I understand Randall Jesup from C= had written code for it, perhaps it's in the OS source somewhere, or you could contact Randall for it. Finish it up and include it with 3.2.

[samo79]

Originally Posted by Minuous

@coldacid:

All depths are supported. It has all the features of the OS4 version plus support for marquee selections and move/cut/copy/paste on these.

I wonder if these new os 3.2 features will be available also to amigaos4 developers, so to share & use the same components bringing both system at the same level

[gulliver]

Originally Posted by samo79

I wonder if these new os 3.2 features will be available also to amigaos4 developers, so to share & use the same components bringing both system at the same level

Yes, OS4 developers are more than welcomed to reuse components.

Any OS4 dev can let us know and we can arrange that quickly. Cooperation makes us all stronger!


FYI: we have a few devs that develop on both camps at the same time.

[gulliver]

Originally Posted by DarrenHD

Can you add DSP support to the OS for the AA3000+? I understand Randall Jesup from C= had written code for it, perhaps it's in the OS source somewhere, or you could contact Randall for it. Finish it up and include it with 3.2.

I am sorry Darren, but we have more than enough features already. We are just debugging and polishing AmigaOS 3.2.

I don't know of any of us that has contact with Randall anyway.

Sounds something interesting to explore for a future OS release.

[DarrenHD]

Originally Posted by gulliver

I am sorry Darren, but we have more than enough features already. We are just debugging and polishing AmigaOS 3.2.

I don't know of any of us that has contact with Randall anyway.

Sounds something interesting to explore for a future OS release.

Ok, future release I believe Dave Haynie has contact info for Randall.

Darren

[lmimmfn]

Any chance of restoring "Guru Meditation"?

[Thomas Richter]

Originally Posted by lmimmfn

Any chance of restoring "Guru Meditation"?

Hopefully not. If you want to crash your machine, I suggest Kick 1.3 or before.