VanillaMiNT 2 - need some input

[joska]

SYSDIR is incorrect, something has changed it. The kernel will set it to e.g. "c:\mint\1-19-cur\", if it only contains "xaaes" then something is messed up. This is also why modes.prg is not working for you. Fix SYSDIR, and modes.prg will work too.

[joska]

By "fix" I mean "find what messed it up", not "set it to the correct dir in some script".

[Rustynutt]

Hey Jo, when you have time, could you look into changing modes.prg to look for SV.INF in root of C, include a mode table for SV resolutions options, then save a new SV.INF file out?

I wouldn't mind giving a go at editing the source and compiling, if given the programming language and library involved. I need to start somewhere.

It would save having to edit by hand the SV.INF file each time a resolution change is desired.

I usually only change in the SV.INF file the boot resolution or force mode declaration in the file.

The force mode will override any setting in XAaes, if one is set there.

Think it's basically what your doing with the XAaes config file.

Of course, you could get fancy, and include in a menu the other options available in SV.INF

Thanks, know time is precious.

[joska]

It's on my todo-list - when I get a SuperVidel

[Mark_G]

What is the partition scheme for the HD?
Can VanillaMint be installed on a TOS partition with a '8.3' layout for filenames ?

A quick check gives me :
In Vanilla2.zip is a file 'resolv.conf'
In vanilla4.zip you have also 2 files : COPYING.MiNT and COPYING.LGPL
Also in vanilla5.Zip and vanilla6.zip, I found files with long filenames under mint\toswin2 and \mint\tools\mktbl\keyboards

[joska]

No special partitioning required, all you need is enough space on drive C to unpack the archives. Long filenames not required, in fact it's recommended to *not* have this enabled on the boot partition.

The long filenames in vanilla5/6.zip comes from the FreeMiNT repository. Don't worry about these.

[Mark_G]

Thanks for the quick reply. And all the work you've put in this distribution.

[ThorstenOtto]

Don't worry about these.

IIRC that are mostly some text documents, and a few of the keyboard tables. For those, we could maybe fix the repo to avoid problems (teradesk for example refuses to copy such files, if you have unpacked them to a partition with long filenames, then copy it over to your boot partition). But we can't do much about files like /etc/host.conf which are expected to have that long name by a lot of tools.

[joska]

Yes, resolv.conf is kept as is because if VanillaMiNT is unpacked on a partition with long filename support it will not be found by the relevant tools if it was called "resolv.con".

[stormy]

Hi Joska, how close are you with the new version of VM? Do you have a low-memory usage version for a 4mb ST almost ready I might try? (I am currently testing mint stuff with a 4mb st)

[joska]

It has been put on hold, as MiNT/XaAES is currently too slow for standard 8MHz machines.

[Cyprian]

There will "soon" be an update for VanillaMiNT, but if you want to use MiNT on both 030 and 060 on your Falcon you need to upgrade using the official releases.

I just updated (locally, not available for download yet) VanillaMiNT to the current FreeMiNT snapshot and the size of the distribution increased drastically. Partly due to all the "unixy" tools in the sys-root folder, and partly due to the fact that the snapshot has kernels for all possible machines. I will not include the "unix" tools in VanillaMiNT as that's not what VanillaMiNT is about, but there's still six different kernels.

So the question is: One "huge" VanillaMiNT for all machines, or smaller, machine-specific VanillaMiNTs? I.e. one for TT/Falcon (including AB and CT60), one for Milan, one for Milan, one for Hades.

My colleague (Kroll) has Hades and use it very often, and I know he would be more than happy with that target.
When do you plan publish updated ZIPs files?
Thanks

[joska]

For now this project is on hold. My main motivation for working on this was 68000-support, but the CPU requirements is a showstopper.

[GokMasE]

For now this project is on hold. My main motivation for working on this was 68000-support, but the CPU requirements is a showstopper.

Unfortunate, but I certainly understand your dilemma. The development where MiNT kernel is no longer responsive enough (IIRC, the keyboard driver was the worst culprit?) to be somewhat useful on 8mhz machines is a bit worrying. I would assume that the cause for the problems was introduced a while back in time, and that current devs might perhaps be able to shape things up again?

[joska]

Correct, keyboard input is the problem, with both XaAES and MyAES. Memory usage is actually not bad, and speed in general is OK too. But lost keypresses when typing normally is unacceptable. Mega STE with cache enabled is the minimum requirement now.

[mikro]

Yeah, I would also like to see some user reports whether 1.16 / 1.18 is really that *much* more responsive. If so, we can certainly take a look. It's easier to investigate a regression than a generic report like "it's slow!" :)

[ThorstenOtto]

I don't think that there really is a regression in keyboard handling, it has always been a bit slow. Generally i think that there are several things that affect this:
- USB driver cannot use interrupts, and must poll the device. On plain 68k, that alone takes way too much CPU time, making those devices almost unusable.
- The keyboard driver in Mint could certainly be enhanced and speed up, but this has always been the case.
- Typing in toswin2 is a bit slow, even on fast computers. Again, i don't think that this is regression, its just because toswin2 tries to be system friendly, using GEMDOS calls most of the time. I don't think that this can easily be changed without breaking toswin2, but when considering whether keyboard input is acceptable, you should find some other way to test that.

If the problem persists in both MyAES and XaAES, i think the only option is to take a look at mint itself.

[stormy]

I don't think that there really is a regression in keyboard handling, it has always been a bit slow. Generally i think that there are several things that affect this:
- USB driver cannot use interrupts, and must poll the device. On plain 68k, that alone takes way too much CPU time, making those devices almost unusable.
- The keyboard driver in Mint could certainly be enhanced and speed up, but this has always been the case.
- Typing in toswin2 is a bit slow, even on fast computers. Again, i don't think that this is regression, its just because toswin2 tries to be system friendly, using GEMDOS calls most of the time. I don't think that this can easily be changed without breaking toswin2, but when considering whether keyboard input is acceptable, you should find some other way to test that.

If the problem persists in both MyAES and XaAES, i think the only option is to take a look at mint itself.

I think Joska is probably talking about just the standard Atari keyboard and not the USB. I also think he means 'all typing in general' rather than just toswin2? So perhaps Joska could clarify these points, then perhaps it could get looked at? It would be a shame if nothing happens.

[joska]

It has already been explained here: https://sourceforge.net/p/freemint/mail ... sg37254315

[GokMasE]

It has already been explained here: https://sourceforge.net/p/freemint/mail ... sg37254315

I kind of consider it odd that key strokes are skipped entirely though, I would have expected sluggish response rate but not key strokes being entirely left out.

But having possibility to use similar behaviour to how TOS handles key strokes as a "default mode" sounds like a good plan to me, especially if leaving the field open to anyone who'd like to utilize the asyncronous keyboard driver of later date.

Vincents idea thus sounds quite appealing but as with anything else in life, there is always that "someone" who has to do it

[stormy]

It looks to me like Vincent Riviere has a good solution. I wonder how difficult it would be to implement.

[joska]

I may completely misunderstand this code, but to me it looks like this was added by Helmut Karlowski (?) several years ago in his own FreeMiNT branch, as a part of this work on the "singlemode" support.

Screenshot from 2022-01-19 09-53-12.png

Here the code that evaluates the keypresses and puts characters into the iorec buffer is called directly by the keyboard interrupt handler when the application runs in single-mode. Wouldn't this work in all cases?

[mfro]

did you touch KERN_SLICES during your tests by any chance? The addroottimeout() call gets executed next task switch earliest - KERN_SLICES setting would affect that. I wonder what effect changes to it might have (don't have a plain ST to do my own tests).

[mikro]

I may completely misunderstand this code, but to me it looks like this was added by Helmut Karlowski (?) several years ago in his own FreeMiNT branch, as a part of this work on the "singlemode" support.

Screenshot from 2022-01-19 09-53-12.png

Here the code that evaluates the keypresses and puts characters into the iorec buffer is called directly by the keyboard interrupt handler when the application runs in single-mode. Wouldn't this work in all cases?

Related message from Helmut: https://mikro.naprvyraz.sk/mint/201009/msg00410.html and the whole thread started by Vincent: https://mikro.naprvyraz.sk/mint/201009/msg00193.html

[joska]

did you touch KERN_SLICES during your tests by any chance?

I did not, default settings are used. Very good point, I will test this ASAP.