MiNT --> GEM

[jfl]

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?

[joska]

Isn't the GEM in ROM incapable of multitasking?

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

[simonsunnyboy]

If still something is needed, better rename it from "noHog" to "TOS Multitask Helper". Then the purpose would be a lot clearer.

[helmut]

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]

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"

[mfro]

... 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]

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.

[BlankVector]

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 ), function ikbd_scan(). It is part of Helmut's WITH_SINGLE_TASK_SUPPORT. IIRC, it was enough to do the trick.

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.

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]

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]

Thanks Jo, it wasn't that hard, was it.

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

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

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

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?

[joska]

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

[simonsunnyboy]

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.

[joska]

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

In what way is it "barely usable"?

[simonsunnyboy]

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-

[mikro]

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]

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

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

[Gaiyan]

Can someone give me a hint on why my keyboard won't work when booting to N.AES2? It works fine in XaAES. Is it related to what has been discussed here?

[wongck]

Can someone give me a hint on why my keyboard won't work when booting to N.AES2? It works fine in XaAES. Is it related to what has been discussed here?

Go back to XaAES.
Edit the file called NAES.CNF and put gemcon to false.
Reboot back to NAES.
See if that works.

[Faucon2001]

-> wongck : Personally, I would stopped at the first sentence

Otherwise I have discovered in this thread the use of Gem on top of Mint for Fat32. Thanks guys for this interesting tip.

[Gaiyan]

Can someone give me a hint on why my keyboard won't work when booting to N.AES2? It works fine in XaAES. Is it related to what has been discussed here?

Go back to XaAES.
Edit the file called NAES.CNF and put gemcon to false.
Reboot back to NAES.
See if that works.

That fixed it. Thanks!

[wongck]

-> wongck : Personally, I would stopped at the first sentence

Agreed.
The reason why it is big and bold.

[wongck]

Can someone give me a hint on why my keyboard won't work when booting to N.AES2? It works fine in XaAES. Is it related to what has been discussed here?

Go back to XaAES.
Edit the file called NAES.CNF and put gemcon to false.
Reboot back to NAES.
See if that works.

That fixed it. Thanks!

Glad that you got it working.
Other stuff not working is not so easy to fix....
Have fun with it.

[tyk]

deleted

[tyk]

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.

I just think opposite direction: Why not Ext2 or FAT32 support to single tasking TOS with MetaDOS/BetaDOS/ExtenDOS? Is there any documentation how to make MetaDOS drivers? I know it isn't easy make even read only capital letter 8.3-filename support for Ext2 in TOS 4.04. But it has to be possible.

[mikro]

Is there any documentation how to make MetaDOS drivers?

Sure it is: http://dev-docs.atariforge.org/files/Me ... 3-1989.pdf (official by Atari), http://patrice.mandin.pagesperso-orange ... os-bos.txt (by Patrice Mandin)

You can get an example of a file system driver here: https://github.com/aranym/aranym/tree/m ... fs/metados