MiNT --> GEM

Hardware, coding, music, graphic and various applications

Moderators: Mug UK, moondog/.tSCc., [ProToS], lp, Moderator Team

User avatar
jfl
Atari Super Hero
Atari Super Hero
Posts: 784
Joined: Tue Jul 18, 2006 10:55 pm
Location: Liège, Belgium
Contact:

Re: MiNT --> GEM

Postby jfl » Sat Jan 21, 2017 4:01 pm

joska wrote:
helmut wrote:Any process called GEM runs in single-task-mode (that would also affect N.AES, probably myAES, etc.).

Does that mean that multitasking is disabled when GEM=ROM?

Isn't the GEM in ROM incapable of multitasking?
Jean-François
GEMDict – GEMClip

joska
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3227
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: MiNT --> GEM

Postby joska » Sat Jan 21, 2017 4:04 pm

jfl wrote:Isn't the GEM in ROM incapable of multitasking?


Yes, but by using MiniWin or TosWin you can multitask TOS-programs.
Jo Even

Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 4695
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: MiNT --> GEM

Postby simonsunnyboy » Sat Jan 21, 2017 4:08 pm

If still something is needed, better rename it from "noHog" to "TOS Multitask Helper". Then the purpose would be a lot clearer.
Simon Sunnyboy/Paradize - http://paradize.atari.org/ - STOT: http://www.npoi.de/stot/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

Jabber: simonsunnyboy@atari-jabber.org

helmut
Captain Atari
Captain Atari
Posts: 163
Joined: Thu Jan 07, 2010 4:30 pm

Re: MiNT --> GEM

Postby helmut » Sat Jan 21, 2017 4:56 pm

joska wrote:
helmut wrote:Any process called GEM runs in single-task-mode (that would also affect N.AES, probably myAES, etc.).


Does that mean that multitasking is disabled when GEM=ROM?


No.

joska
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3227
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: MiNT --> GEM

Postby joska » Sat Jan 21, 2017 10:30 pm

mikro wrote:Ideally, the ACC could check if the AES is the ROM one and if not, then exit else provide the yield functionality. This would be pretty awesome.


Done. But I was quite disappointed to see that gcc generated a binary that was ten times bigger than the AHCC-compiled one.

Code: Select all

/*

   no_hog2.acc

   Very simple accessory that just calls Syield every
   20ms.

   Purpose: Use it when using the ROM AES with MiNT to
   allow multitasking (and keyboard) to work properly.

   Jo Even Skarstein, 2017

*/

#include <mintbind.h>
#include <gem.h>
#include <mint/cookie.h>

#ifndef false
enum { false, true };
#endif

char alert_running[] = "[1][ NoHog2 ][ Ok ]";
char alert_no_mint[] = "[1][ NoHog2 only needed | with MiNT. ][ Ok ]";
char alert_mtask[]   = "[1][ NoHog2 only needed | with ROM AES. ][ Ok ]";

int main(void)
{
   long c;
   short exit = false, apid, mint, mtask, e_type = MU_MESAG;
   char *alert = alert_running;

   apid = appl_init();
   menu_register(apid, "  NoHog2");

   mtask = (aes_global[1] != 1);
   mint = !Getcookie(C_MiNT, &c);

   if (!mint)
      alert = alert_no_mint;
   
   if (mint && mtask)
      alert = alert_mtask;

   // Enable 20ms timer when running under MiNT without
   // a multitasking AES.
   if (mint && !mtask)
      e_type |= MU_TIMER;

   while (!exit)
   {
      static short msg[8], mx, my, bt, ks, kb, mc;
      short e = evnt_multi( e_type,
               0, 0, 0,
               0, 0, 0, 0, 0,
               0, 0, 0, 0, 0,
               msg,
               20,
               &mx, &my, &bt, &ks, &kb, &mc);
   
      if (e & MU_MESAG)
      {
         switch (msg[0])
         {
            case AC_OPEN:
               form_alert(0, alert);
               break;
            case AP_TERM:
               exit = true;
               break;
            default:
               break;
         }
      }

      if (e & MU_TIMER)
      {
         Syield();
      }
   }

   appl_exit();
   return 0;
}


Now I need to find out what a "pull request is" :D
Jo Even

Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 617
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: MiNT --> GEM

Postby mfro » Sat Jan 21, 2017 11:41 pm

joska wrote:... But I was quite disappointed to see that gcc generated a binary that was ten times bigger than the AHCC-compiled one...


Using libcmini (gcc 4.6.4 -Os), your code compiles into 5030 bytes...

joska
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3227
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: MiNT --> GEM

Postby joska » Sat Jan 21, 2017 11:45 pm

Yeah, I assumed it was a lib-issue. Adding a simple printf for some quick debugging added 60kB... I'm using gcc to create tiny binaries for microcontrollers, so I expected this to be possible for TOS/MiNT too.
Jo Even

Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

BlankVector
Captain Atari
Captain Atari
Posts: 370
Joined: Wed Oct 24, 2007 7:52 pm
Location: Paris, France
Contact:

Re: MiNT --> GEM

Postby BlankVector » Sun Jan 22, 2017 1:07 am

joska wrote:Do you still have this patch? If so, I'd be interested in trying a patched kernel on Milan and Falcon/AB. The Milan kernel is especially interesting because keyboard handling on the Milan is different from the other kernels.

I can't find it, I think I didn't keep it. But I remember. The trick was to call IkbdScan() directly, without addroottimeout().
Look a sys/keyboard.c (GitHub advertisement :wink: ), function ikbd_scan(). It is part of Helmut's WITH_SINGLE_TASK_SUPPORT. IIRC, it was enough to do the trick.

joska wrote:Please note that even with this fix, there is still a need for something like nohog.acc. Without this multitasking will not work correctly when using the ROM AES.

You are right, but preemptive multitasking is not going to work well when the ROM AES is running, in any case. That's because the AES runs in supervisor mode, and FreeMiNT doesn't preempt supervisor programs. For example, it you are in any dialog, the program is stuck in a supervisor loop so the background processes will completely be stopped. I thinnk that nohog.acc just improves things a bit.

Anyway, when using GEM=ROM (I love that mode), I don't care much about preemptive multitasking. I just want to have the benefits of FreeMiNT drivers (i.e ext2 and FAT32 drivers) from the ROM desktop. They work fine even if preemptive multitasking is asleep.

jfl wrote:Isn't the GEM in ROM incapable of multitasking?

The GEM (actually, AES) is really a cooperative multitasking system between the main program and the accessories. To do its work, it runs in supervisor mode. And by design, FreeMiNT's multitasking does not preemt tasks running in supervisor mode. I think it is mainly to avoid reentrency problems with BIOS, VDI, etc.

mikro
Atari Super Hero
Atari Super Hero
Posts: 796
Joined: Sat Sep 10, 2005 11:11 am
Location: Brisbane, Queensland, Australia
Contact:

Re: MiNT --> GEM

Postby mikro » Sun Jan 22, 2017 6:12 am

joska wrote:
mikro wrote:Ideally, the ACC could check if the AES is the ROM one and if not, then exit else provide the yield functionality. This would be pretty awesome.


Done. But I was quite disappointed to see that gcc generated a binary that was ten times bigger than the AHCC-compiled one.

[...]

Now I need to find out what a "pull request is" :D

Thanks Jo, it wasn't that hard, was it. ;-)

Apropo, the size: that size is that big even without using mintlib? When you provide a Makefile (see my github comment) I will know better but to this point I've assumed that you don't need to link it with mintlib at all (only using its startup file).

You can take a look here: https://github.com/freemint/freemint/tr ... s/mintload ... it's basically a copy of xaloader skeleton, it doesn't use mintlib & co at all and its pretty slim.

joska
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3227
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: MiNT --> GEM

Postby joska » Sun Jan 22, 2017 9:01 am

mikro wrote:Thanks Jo, it wasn't that hard, was it. ;-)


I don't know, not really sure what I did...

mikro wrote:Apropo, the size: that size is that big even without using mintlib?


Without testing I can say that it most definitely isn't :)

mikro wrote:You can take a look here: https://github.com/freemint/freemint/tr ... s/mintload ... it's basically a copy of xaloader skeleton, it doesn't use mintlib & co at all and its pretty slim.


MiNTloader is duplicating lots of code - get_cookie, various string-functions, init-code, argument-parsing etc from mintlib. That doesn't look very clean to me. I'd rather see a more capable linker. Or maybe the problem is mintlib itself?
Jo Even

Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

joska
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3227
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: MiNT --> GEM

Postby joska » Sun Jan 22, 2017 9:27 am

mikro wrote:When you provide a Makefile (see my github comment)


Will not happen ;) I just spent an hour of my life trying to figure out the FreeMiNT makefile "system". That's an hour I'll never get back.

Feel free to add this acc to the FreeMiNT repository, but then someone else would have to create the makefile.

nohog2.c
You do not have the required permissions to view the files attached to this post.
Jo Even

Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 4695
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: MiNT --> GEM

Postby simonsunnyboy » Sun Jan 22, 2017 9:31 am

BlankVector wrote:Anyway, when using GEM=ROM (I love that mode), I don't care much about preemptive multitasking. I just want to have the benefits of FreeMiNT drivers (i.e ext2 and FAT32 drivers) from the ROM desktop. They work fine even if preemptive multitasking is asleep.


That is exactly the main use case for GEM=ROM, to run the advanced kernel features in a memory confined, e.q. 4MB environment. Without accelerators, multitasking GEM with XaAES is barely usable on a F030 even with 16MB RAM.

This will make FreeMiNT more usable on 4MB ST class machines aswell.
Simon Sunnyboy/Paradize - http://paradize.atari.org/ - STOT: http://www.npoi.de/stot/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

Jabber: simonsunnyboy@atari-jabber.org

joska
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3227
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: MiNT --> GEM

Postby joska » Sun Jan 22, 2017 9:36 am

simonsunnyboy wrote:Without accelerators, multitasking GEM with XaAES is barely usable on a F030 even with 16MB RAM.


In what way is it "barely usable"?
Jo Even

Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 4695
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: MiNT --> GEM

Postby simonsunnyboy » Sun Jan 22, 2017 9:53 am

It feels sluggish and unresponsive for me. Sorry I'm spoiled having worked with RISC OS in the early 90s. So every other system from the era just doesn't feel usable for me when it comes to multitasking. Sorry, personal bias here.

But I am sure, others will agree that some programs work better in singletasking on a plain Falcon than with XaAES-
Simon Sunnyboy/Paradize - http://paradize.atari.org/ - STOT: http://www.npoi.de/stot/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

Jabber: simonsunnyboy@atari-jabber.org

mikro
Atari Super Hero
Atari Super Hero
Posts: 796
Joined: Sat Sep 10, 2005 11:11 am
Location: Brisbane, Queensland, Australia
Contact:

Re: MiNT --> GEM

Postby mikro » Sun Jan 22, 2017 10:40 am

joska wrote:
mikro wrote:When you provide a Makefile (see my github comment)


Will not happen ;) I just spent an hour of my life trying to figure out the FreeMiNT makefile "system". That's an hour I'll never get back.

Feel free to add this acc to the FreeMiNT repository, but then someone else would have to create the makefile.

nohog2.c

It took me 15 minutes. :) You could have asked, literally it's only about copying some existing project, changing TARGET, COBJS and SRCFILES and there you go. No need to figure stuff out by yourself, others did it for you! :)

joska
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3227
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: MiNT --> GEM

Postby joska » Sun Jan 22, 2017 11:07 am

mikro wrote:It took me 15 minutes. :)


Yes, because you know how it works. Btw those 15 minutes is about twice as long as it took me to create the accessory from scratch using AHCC - because I know how it works ;)

mikro wrote:You could have asked, literally it's only about copying some existing project, changing TARGET, COBJS and SRCFILES and there you go.


I won't even ask why all these files are necessary. One 2kB sourcefile producing a 4kB binary with AHCC has now grown into 9 (?) files producing a 45kB binary. Same program :)

I just accept that it works, but do not intend to learn how.

https://www.youtube.com/watch?v=Q37xJtuQ24w
Jo Even

Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64


Social Media

     

Return to “Professionals”

Who is online

Users browsing this forum: No registered users and 1 guest