OL wrote:I hope realtime moving will be better now, I have found in 0.97 a bug introduced in kernel event manager that perhaps could explain this (as I have no issue like this under Aranym I'm not sure of the result but for sure it's a new bug found). Could perhaps fix some crash but nothing relative to ext2 issue

I just checked time delay after clicking the right mouse button on the application in Yoppla task manager on my two computers on Falcon with Radeon graphics card settings are:"use_videocard_mem = true""CT_60_VIDEOCARD = true"delay is over 1 s.In the case of Hades daley is less than 1 s, the difference is about 0.5 s., The above settings obviously falseThis is a curiosity, I know the difference is insignificant but always What do You think about it ?I checked and there is no difference in version from 13 September and today on Falcon CT60 and Hades

OL wrote:I hope realtime moving will be better now, I have found in 0.97 a bug introduced in kernel event manager that perhaps could explain this (as I have no issue like this under Aranym I'm not sure of the result but for sure it's a new bug found). Could perhaps fix some crash but nothing relative to ext2 issue

I just checked time delay after clicking the right mouse button on the application in Yoppla task manager on my two computers on Falcon with Radeon graphics card settings are:"use_videocard_mem = true""CT_60_VIDEOCARD = true"delay is over 1 s.In the case of Hades daley is less than 1 s, the difference is about 0.5 s., The above settings obviously falseThis is a curiosity, I know the difference is insignificant but always What do You think about it ?I checked and there is no difference in version from 13 September and today on Falcon CT60 and Hades

I don't know why there is delay on CT60, I have not. I suppose even with new masreal.prg moving window in real time is not better?

OL wrote: only TOS with patched xbios can work, when you call an xbios function if this function doesn't exist TOS just return a value different from 0 and so no crash but only for value between 0 to 127 !!!!

My info is that the Milan TOS return the function number, if the function doesn't exist. All number not only betwenn 0 to 127. A problem is when a other program is in the XBIOS trap, then nobody knows what will return.

although I'm french, the forum is in english so this is the langage I use here. Just a suggestion : what is scary coming back to the atari world after 25 years of sleep (more or less) is to see the dispersion between the different mint versions, the same thing for the AES and for the front ends such as jinnee, magic, teradesk etc without mentioning the many incompatibilities between all those softwares. From what I have seen of myAES, my opinion is that it's good basis for a new inclusive OS, together with Emutos (even I think nobody cares at Atari about using a TOS from 1993, and even so it would be a very bad commercial move on their behalf to go against it). Otherwise what's left of the atari world will slowly die with its users...

It also means that, although it's fun to boost a falcon (a bit like tuning a car), it will hardly reach a decent speed for new usages. On the hand, the amiga world, with the vampire board, is making a clear move towards a new generation. Here some walls are still to be destroyed and limitations by-passed (screen resolutions and so on).

patbud wrote:although I'm french, the forum is in english so this is the langage I use here. Just a suggestion : what is scary coming back to the atari world after 25 years of sleep (more or less) is to see the dispersion between the different mint versions, the same thing for the AES and for the front ends such as jinnee, magic, teradesk etc without mentioning the many incompatibilities between all those softwares. From what I have seen of myAES, my opinion is that it's good basis for a new inclusive OS, together with Emutos (even I think nobody cares at Atari about using a TOS from 1993, and even so it would be a very bad commercial move on their behalf to go against it). Otherwise what's left of the atari world will slowly die with its users...

It also means that, although it's fun to boost a falcon (a bit like tuning a car), it will hardly reach a decent speed for new usages. On the hand, the amiga world, with the vampire board, is making a clear move towards a new generation. Here some walls are still to be destroyed and limitations by-passed (screen resolutions and so on).

I share your opinion about the diversity of operating systems for TOS computers. But the faults were made in the past. If you take a look at today than there's only MiNT that's still in development as a multitasking system. Concerning the AES there's only XaAES as a part of MiNT that is still developed. As an alternative there's MyAES. MyAES is pretty cool but still it doesn't reach the stability and compatibility of XaAES. XaAES is much faster concerning all the realtime stuff but MyAES has a nicer look.

The atari developers often didn't unite and a lot of them did their own stuff because they didn't share their opinions. So we 've got a lot of different software for TOS today. I don't think that's bad but for the future it would be nice if more developers could join each other, I think. Looking at the current hardware we' ve got the Firebee that's a really nice computer. It's supporting TOS and MiNT. You can't compare it to a current PC. It's much to slow but for a lot of GEM applications it's a very fast computer. But the community isn't that enthusiastic about the Firebee due to its coldfire cpu and some incompatibilities with old 68k software. I think the Firebee is the right step into the future made for future gem applications. MyAES is such an application and it supports the Firebee. Looking at our Amiga friends you may recognize that they 've got current state of the art powerpc computers and a lot of software delevopment for their computers. We are far far away from that. So I'm glad that there are guys like Olivier Landemarre who does a really good work by supporting users and trying to fix bugs that are reported by the users.

I'm not sure which way our TOS platform will go. Is the Firebee some kind of a fight of one's last stand? Will it be a pure retro platform in the future with no further developments anymore? MyAES does support old ST computers and the newest clones as well. On one hand that's very good on the other hand it would be better for some new applications not to try to reach a compatibility with every TOS computer that was build.

For compatibility issue, most are link to the use of form_do function, I not plane to fix this, MyAES goal is to not lock at any time the screen and this function is clearly uncompatible with such function, it is used on old software, there is a function include in MyAES some software are able to work with it some other no, such software generally are designed for single TOS not for nultitask system. For other bugs I try to fix it when there is request. 0.97 looks not mature I have done so many changes this 2 last years, but I'm not far to have finished it.

For compatibility issue, most are link to the use of form_do function, I not plane to fix this, MyAES goal is to not lock at any time the screen and this function is clearly uncompatible with such function, it is used on old software, there is a function include in MyAES some software are able to work with it some other no, such software generally are designed for single TOS not for nultitask system. For other bugs I try to fix it when there is request. 0.97 looks not mature I have done so many changes this 2 last years, but I'm not far to have finished it.

Let me some weeks to fix all

Olivier

In the first video the realtime stuff of MyAES is as fast as the realtime stuff when using XaAES on my Milan. The second video represents the situation on my Milan when using MyAES and turning on the realtime stuff. I don't know why XaAES is much faster on my Milan concerning the realtime stuff?

I won't agree with you about MyAES 0.97. I've only got the problem with the realtime stuff but I think it's due to my hardware that's not supported by MyAES? I think MyAES 0.97 is a finished version. It's works very well on my Milan. Much better then version 0.96. There were many redraw issues in version 0.96. So MyAES 0.96 wasn't useable on my Milan due to the redraw issues. Despite the redraw issues in MyAES 0.96 the realtime stuff was as slow as in version 0.97 on my Milan. MyAES 0.97 works very well for me and a lot of problems I had with the predecessor are gone. No redraw issues anymore. I only had a problem when using Atari Works. All the other stuff is working very well with MyAES 0.97. Anyway you did a great work, I think!

OL wrote:For compatibility issue, most are link to the use of form_do function, I not plane to fix this, MyAES goal is to not lock at any time the screen and this function is clearly uncompatible with such function,

In XaAES form_do does not block any other AES clients. The dialog is placed within a window and can be freely moved around like any other window. Of course, the application that calls form_co won't receive messages while the dialog is open, just like in TOS. XaAES copes with this by redrawing any dirty windows in grey. It works remarkably well.

OL wrote: it is used on old software, there is a function include in MyAES some software are able to work with it some other no, such software generally are designed for single TOS not for nultitask system.

form_do is the only way AES can do dialogs, thus it's used in tons of applications. True, most of these were written before multitasking was available, but this does not mean that the applications are useless. Even more "recent" stuff (like Atari Works) used them. To be honest I use this function even nowadays. Simple, one-dialog applications (like the setup-tools I've created for the Firebee and VanillaMiNT) are *very* easy to make using form_do, without the need for any supporting libraries.

OL wrote:For compatibility issue, most are link to the use of form_do function, I not plane to fix this, MyAES goal is to not lock at any time the screen and this function is clearly uncompatible with such function,

In XaAES form_do does not block any other AES clients. The dialog is placed within a window and can be freely moved around like any other window. Of course, the application that calls form_co won't receive messages while the dialog is open, just like in TOS. XaAES copes with this by redrawing any dirty windows in grey. It works remarkably well.

This is what do MyAES too except looks not so good, perhaps because I don't like at all this call because it is blocking application that call the form_do so impossible to redraw in theory the content of other windows of this application. It's more than 10 years I have not look at this function, perhaps I should rewrite it for 0.98 version!

joska wrote:

OL wrote: it is used on old software, there is a function include in MyAES some software are able to work with it some other no, such software generally are designed for single TOS not for nultitask system.

form_do is the only way AES can do dialogs, thus it's used in tons of applications. True, most of these were written before multitasking was available, but this does not mean that the applications are useless. Even more "recent" stuff (like Atari Works) used them. To be honest I use this function even nowadays. Simple, one-dialog applications (like the setup-tools I've created for the Firebee and VanillaMiNT) are *very* easy to make using form_do, without the need for any supporting libraries.

No it is not the only way to do dialog since TOS4 (even if in this case the implementation is not enough) I want to speak to toolbar, just add toolbar in window and you have your dialog box, managed by system. This is simple.

For compatibility issue, most are link to the use of form_do function, I not plane to fix this, MyAES goal is to not lock at any time the screen and this function is clearly uncompatible with such function, it is used on old software, there is a function include in MyAES some software are able to work with it some other no, such software generally are designed for single TOS not for nultitask system. For other bugs I try to fix it when there is request. 0.97 looks not mature I have done so many changes this 2 last years, but I'm not far to have finished it.

Let me some weeks to fix all

Olivier

In the first video the realtime stuff of MyAES is as fast as the realtime stuff when using XaAES on my Milan. The second video represents the situation on my Milan when using MyAES and turning on the realtime stuff. I don't know why XaAES is much faster on my Milan concerning the realtime stuff?

I won't agree with you about MyAES 0.97. I've only got the problem with the realtime stuff but I think it's due to my hardware that's not supported by MyAES? I think MyAES 0.97 is a finished version. It's works very well on my Milan. Much better then version 0.96. There were many redraw issues in version 0.96. So MyAES 0.96 wasn't useable on my Milan due to the redraw issues. Despite the redraw issues in MyAES 0.96 the realtime stuff was as slow as in version 0.97 on my Milan. MyAES 0.97 works very well for me and a lot of problems I had with the predecessor are gone. No redraw issues anymore. I only had a problem when using Atari Works. All the other stuff is working very well with MyAES 0.97. Anyway you did a great work, I think!

Oh no it is not link to your hardware, this is MyAES issue, perhaps in your case because in all case I copy the content of the window in a buffer before do the copy on screen at new position, this is not always need but I have prefer the most simple solution, but I don't think it is this.I'm just surprised because under Hatari even in 16Mhz emulation it is not so bad, not like on this bad demonstration

OL wrote:No it is not the only way to do dialog since TOS4 (even if in this case the implementation is not enough) I want to speak to toolbar, just add toolbar in window and you have your dialog box, managed by system. This is simple.

Almost no application use toolbars. The reason is obvious - toolbars are very limited compared to even form_do, not to mention most windowed dialog libraries. XaAES has had extended toolbar functionality for 15 years or so but yet no-one has used it to my knowledge.

For any modern AES to be successful it has to support legacy software in the best possible way. E.g. there hasn't been a new editor or word processor since the 90's, and most likely there won't be any more either. So it's better to improve the experience with existing software than inventing new features that unfortunately won't be exploited.

But then again, we do this for fun so in the end the best features are the ones the author enjoys making

OL wrote:No it is not the only way to do dialog since TOS4 (even if in this case the implementation is not enough) I want to speak to toolbar, just add toolbar in window and you have your dialog box, managed by system. This is simple.

Almost no application use toolbars. The reason is obvious - toolbars are very limited compared to even form_do, not to mention most windowed dialog libraries. XaAES has had extended toolbar functionality for 15 years or so but yet no-one has used it to my knowledge.

For any modern AES to be successful it has to support legacy software in the best possible way. E.g. there hasn't been a new editor or word processor since the 90's, and most likely there won't be any more either. So it's better to improve the experience with existing software than inventing new features that unfortunately won't be exploited.

But then again, we do this for fun so in the end the best features are the ones the author enjoys making

In 1993 so 24 years ago (!!!) I was writing my first gem library, already there was not locking dialog box and I was not the first one to do it, there was several library available already (big (perhaps not a good example!), windom, cflib...), I never use form_do, this is so strange, so far from windows idea

Just my point of view. But I agree if it is possible to do something why not but I'm not in the past but more in futur. Up to version 1.0 it is focus on new feature and compatibility. After if I continue it will more focus on new capacity only.

OL wrote:No it is not the only way to do dialog since TOS4 (even if in this case the implementation is not enough) I want to speak to toolbar, just add toolbar in window and you have your dialog box, managed by system. This is simple.

Almost no application use toolbars. The reason is obvious - toolbars are very limited compared to even form_do, not to mention most windowed dialog libraries. XaAES has had extended toolbar functionality for 15 years or so but yet no-one has used it to my knowledge.

For any modern AES to be successful it has to support legacy software in the best possible way. E.g. there hasn't been a new editor or word processor since the 90's, and most likely there won't be any more either. So it's better to improve the experience with existing software than inventing new features that unfortunately won't be exploited.

But then again, we do this for fun so in the end the best features are the ones the author enjoys making

In 1993 so 24 years ago (!!!) I was writing my first gem library, already there was not locking dialog box and I was not the first one to do it, there was several library available already (big (perhaps not a good example!), windom, cflib...), I never use form_do, this is so strange, so far from windows idea

Just my point of view. But I agree if it is possible to do something why not but I'm not in the past but more in futur. Up to version 1.0 it is focus on new feature and compatibility. After if I continue it will more focus on new capacity only.

I think you just said it quite well. This is for compatibility mostly with older apps instead of future apps. I think any AES should take those legacy apps into consideration even recognizing the deficiency. Maybe a rewrite of that section code could treat the form_do like XaAES does. That has a very elegant solution which would be nice in MyAES.

OL wrote:In 1993 so 24 years ago (!!!) I was writing my first gem library, already there was not locking dialog box and I was not the first one to do it, there was several library available already (big (perhaps not a good example!), windom, cflib...),

Correct, in the early 90's the germans started to make som high quality applications with windowed dialogs using libraries like E-Gem, libsys and whatnot. Since then there has been very little new software using form_do, except for some small utilities where this doesn't matter (especially not with an AES with non-blocking form_do). However, the majority of applications were made before this. There is a huge number of applications out there from the "plain GEM applications" era.

OL wrote:but I'm not in the past but more in futur.

The fact that we hang around here and use 90's computers confirms that we're all living in the past

For compatibility issue, most are link to the use of form_do function, I not plane to fix this, MyAES goal is to not lock at any time the screen and this function is clearly uncompatible with such function, it is used on old software, there is a function include in MyAES some software are able to work with it some other no, such software generally are designed for single TOS not for nultitask system. For other bugs I try to fix it when there is request. 0.97 looks not mature I have done so many changes this 2 last years, but I'm not far to have finished it.

Let me some weeks to fix all

Olivier

In the first video the realtime stuff of MyAES is as fast as the realtime stuff when using XaAES on my Milan. The second video represents the situation on my Milan when using MyAES and turning on the realtime stuff. I don't know why XaAES is much faster on my Milan concerning the realtime stuff?

I won't agree with you about MyAES 0.97. I've only got the problem with the realtime stuff but I think it's due to my hardware that's not supported by MyAES? I think MyAES 0.97 is a finished version. It's works very well on my Milan. Much better then version 0.96. There were many redraw issues in version 0.96. So MyAES 0.96 wasn't useable on my Milan due to the redraw issues. Despite the redraw issues in MyAES 0.96 the realtime stuff was as slow as in version 0.97 on my Milan. MyAES 0.97 works very well for me and a lot of problems I had with the predecessor are gone. No redraw issues anymore. I only had a problem when using Atari Works. All the other stuff is working very well with MyAES 0.97. Anyway you did a great work, I think!

For a bright new future of the TOS platform it needs new applications. A contempory desktop like zDesk. An office application supporting all common standards and formats. An internet browser that also supports all common standards. An email client and much more. It was very nice if the TOS platform could reach the look and feel and quality of Mac OS 9 and its applications. That would be a great step into the right direction. Afer the release of the Firebee I thougt that this might happen and a dream could come true. But it just didn't. There is Netsurf, we've got MyAES and a few other nice new applications but no great breakthrough. So I think the compatibility with old applications is necessary even for a new AES. However I think that MyAES is a right Step into the future. It might become a very good looking and very useable AES even for a computer that might be nearly 30 years old. So younger people may take a look at it and they might be astonished what such an old machine could do. We also might use all our old applications like Calamus, Papyrus, Texel etc.. I think that's the future of the TOS platform.

The download link is a little bit wrong. I think you've forgotten something. But I managed it to download the new version and I tested it. It's a little bit better when moving and resizing windows on the desktop. In an application it's still a big problem especially when resizing windows. It's still far away from your good video and very close to your bad video. But don't think to much about the realtime stuff. I think it's nice to have but it's not essential for me. Instead of the realtime stuff a resizeable file selector and a working mouse wheel within the file selector would be great. I like the MyAES file selector much more than the one of XaAES.

The download link is a little bit wrong. I think you've forgotten something. But I managed it to download the new version and I tested it. It's a little bit better when moving and resizing windows on the desktop. In an application it's still a big problem especially when resizing windows. It's still far away from your good video and very close to your bad video. But don't think to much about the realtime stuff. I think it's nice to have but it's not essential for me. Instead of the realtime stuff a resizeable file selector and a working mouse wheel within the file selector would be great. I like the MyAES file selector much more than the one of XaAES.

Neurotoxic wrote:For a bright new future of the TOS platform it needs new applications. A contempory desktop like zDesk. An office application supporting all common standards and formats. An internet browser that also supports all common standards. An email client and much more. It was very nice if the TOS platform could reach the look and feel and quality of Mac OS 9 and its applications. That would be a great step into the right direction. Afer the release of the Firebee I thougt that this might happen and a dream could come true. But it just didn't. There is Netsurf, we've got MyAES and a few other nice new applications but no great breakthrough. So I think the compatibility with old applications is necessary even for a new AES. However I think that MyAES is a right Step into the future. It might become a very good looking and very useable AES even for a computer that might be nearly 30 years old. So younger people may take a look at it and they might be astonished what such an old machine could do. We also might use all our old applications like Calamus, Papyrus, Texel etc.. I think that's the future of the TOS platform.

Of course Mdesk is not yet mature but do you try it? You can find it in folder gemsys/myaes/mdeskit is not nice as zdesk but not need a lot of memory to run, it's just to see not for use yet.

Papyrus is strange looks able to run correctly only under Magic and TOS