MiNT --> GEM

[jury]

I want to start standard GEM so I have read that in mint.cnf INIT line must be replaced with "INIT=gem"
When I did so, all I get during boot is "Launching init: gem ... error -33" and I get MiS, the FreeMiNT internal shell
What to do to start it?

[mikro]

The keyword you're looking for is "GEM=ROM". :) But beware, it has its limitations, since the internal AES is used.

[BlankVector]

I love GEM=ROM, unfortunately there is a big drawback... The keyboard does not work anymore

[simonsunnyboy]

This should be fixed.

I personally don't mind the GEM multitasking missing if other MiNT features do work properly. And it saves RAM on 4MB machines, not to speak of having a small release tailored to work on 4MB STs. It is doable as other have already shown.

[mfro]

I love GEM=ROM, unfortunately there is a big drawback... The keyboard does not work anymore

To my knowledge, this is just because the ROM desktop never leaves supervisor mode, effectively causing MiNT to stop multitasking (since it never does task switching in supervisor mode).

Get NOHOG.ACC (should be available with older MiNT releases or Atari MULTITOS). NOHOG basically does nothing else than just switch itself (and thus, the desktop, since they are both the same task) to user mode.

[mikro]

Damn it, this is ridiculous. Forcing user to install a dumb acc which can be easily simulated within the kernel. The saddest part of this is the fact that the ACC is not even a part of the freemint source tree, not even as a binary.

[joska]

I'm quite sure that NOHOG.ACC was shipped with MultiTOS, so it's not really free software. It would take literally five minutes to create a replacement though - write a tiny acc that just sets up a timer and calls Syield() at regular intervals.

[simonsunnyboy]

Damn it, this is ridiculous. Forcing user to install a dumb acc which can be easily simulated within the kernel. The saddest part of this is the fact that the ACC is not even a part of the freemint source tree, not even as a binary.

I fully agree on this one. At least the kernel could display a message, informing the user. I personally would like to see this fixed in the kernel itself.

[jury]

I love GEM=ROM, unfortunately there is a big drawback... The keyboard does not work anymore

What do you mean "keyboard does not work anymore" ?

I just tried GEM=ROM and all was fine, keyboard worked OK. Even played 2 levels of Jazz Jackrabbit on keyboard.

[BlankVector]

What do you mean "keyboard does not work anymore" ?

I mean that when you press a key, it does not do the expected action. It is actually delayed until the AES allow multitask.
i.e. New Folder does not work, you can't type anything.

[jury]

I see. Tried New Folder and right, typing was really delayed. So seems that only games work fine.

[joska]

Here's a quick workaround. Run this accessory and the keyboard works fine. I could not get GEM=ROM to work on my Milan, but I tested this on my Mega and it worked fine.

nohog2.zip.zip

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.

	Jo Even Skarstein, 2017

*/

#include <tos.h>
#include <mint.h>
#include <aes.h>

void main(void)
{
	short exit = false;
	EVENT event = {	MU_TIMER|MU_MESAG,	// Types
					0, 0, 0,			// Button
					0, 0, 0, 0, 0,		// m1
					0, 0, 0, 0, 0,		// m2
					20, 0,			// Timer
					0, 0, 0, 0, 0, 0, 0,
					{0, 0, 0, 0, 0, 0, 0, 0}
				  };

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

	while (!exit)
	{
		unsigned short e = EvntMulti(&event);

		if (e & MU_MESAG)
		{
			switch (event.mgpbuf[0])
			{
				case AC_OPEN:
					form_alert(0, "[1][ NoHog2 ][ Ok ]");
					break;
				case AC_CLOSE:
					break;
				case AP_TERM:
					exit = true;
					break;
				default:
					break;
			}
		}

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

	appl_exit();
}

Compiled with AHCC. Binary and sources attached.

[mikro]

Hey Jo, what about making a pull request? ;-) (https://github.com/freemint/freemint) Although then it would be perhaps better to make it gcc friendly.

We could include this into the "tools" directory, where it had once resided.

[helmut]

Just in case you didn't know: Keyboard works with GEM=ROM in my kernel since ages.

[joska]

We could include this into the "tools" directory, where it had once resided.

Well, this was just a quick hack. It doesn't even check if MiNT is running so it might cause problems if started under TOS. But if there is a need for it I could fix it up.

Just in case you didn't know: Keyboard works with GEM=ROM in my kernel since ages.

Was this related to the singlemode changes you did years ago? I thought that had already made it into the main branch?

[helmut]

Yes and no.

[jury]

One more thing. Why does all filenames are lowercase? Its looks quite unnatural ( or rather ugly ) when trying to change the name of existing file, old part is lower and new part is upper. After the change is OK'ed whole filename is converted back to lower. Is it a bug or it is on purpose?

Here's a quick workaround. Run this accessory and the keyboard works fine. I could not get GEM=ROM to work on my Milan, but I tested this on my Mega and it worked fine.

Thanks, will try it when I will find out why my network setup stopped working ( as this is the only way I can transfer files to Falcon )

[mikro]

Well, this was just a quick hack. It doesn't even check if MiNT is running so it might cause problems if started under TOS. But if there is a need for it I could fix it up.

As you can see, there certainly is. :-) It's really hard to explain to every new user that yeah, you kind of need this and it's like super simple to do but please, go and grab that 20 years old ACC because we don't have anything else.

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.

Just in case you didn't know: Keyboard works with GEM=ROM in my kernel since ages.

Why have you never provided a patch? What purpose it has to stay in your branch, to amuse yourself? :-)

[BlankVector]

Just in case you didn't know: Keyboard works with GEM=ROM in my kernel since ages.

I also looked at that long ago.

Normally (with TOS), when a key is pressed, the work is done synchronously in the interrupt handler: the key is decoded and put into the appropriate BIOS buffer.

What MiNT does is to eat the keystroke, but put it in the BIOS buffer later, after a task switch. Since the ROM AES runs in supervisor mode, that task switch doesn't happen (or very later), so the keyboard seems to be stuck.

IMHO that delayed keyboard handling is a total nonsense. TOS has always done that synchronously. The only serious reason for that would be stack usage: MiNT advanced keyboard handling (AKP, etc.) may require more stack than TOS. So if the interrupted program runs in supervisor mode and has a small stack (which is the case for the ROM AES), there might be a stack overflow.
And I don't mention the fact that a BIOS feature (low-level keyboard handling) relies on an upper layer feature (MiNT's GEMDOS multitasking) is a complete nonsense.

I made quick test long ago (probably the same as Helmut fix): instead of delaying the keystroke, handle it immediately, like TOS. Then keyboard works like a charm with GEM=ROM. What needs to be proven is if there are really stack issues as I suspect.

[simonsunnyboy]

And I don't mention the fact that a BIOS feature (low-level keyboard handling) relies on an upper layer feature (MiNT's GEMDOS multitasking) is a complete nonsense.

I fully agree on this one. Is the fix too complicated to add to the kernel trunk?

[helmut]

Why have you never provided a patch? What purpose it has to stay in your branch, to amuse yourself?

Any process called GEM runs in single-task-mode (that would also affect N.AES, probably myAES, etc.). I didn't notice any regression, but I''m not a regular user of any of these. Maybe more, I don't remember.
And I don't touch trunk anyway.

[simonsunnyboy]

I have filed an issue on github

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

I'll see what I can do. Unless you want to fix this in the kernel?

[joska]

I made quick test long ago (probably the same as Helmut fix): instead of delaying the keystroke, handle it immediately, like TOS. Then keyboard works like a charm with GEM=ROM. What needs to be proven is if there are really stack issues as I suspect.

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.

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.

[joska]

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?