Nextor and automatic drive mappings
Hi, let me throw in my 0.02€:
However, I only get the first partition
I just want to remind that you can choose which partition is mounted at boot by setting its "active" flag with FDISK. Mounting the first existing partition is the default behavior when no partitions have this flag set.
That’s a nice idea Pencioner, however I would really wish Nextor would go back to how MSX-DOS2 does it. DOS2 just mounts all the partitions on a drive, one after another.
MSX-DOS knows nothing about devices or partitions. It just asks the driver how many drives does it control, maps one drive letter to each of those drives, and that's it. If you have a device that maps all the existing partitions at boot, that's because the device developers implemented it that way, not because "MSX-DOS 2 does it". This ad-hoc behavior is what the Nextor device drivers design aimed to avoid.
This would be less flexible, as with Nextor you can have more than 8 partitions, and mount/unmount by demand. But some option for DOS2 compatibility mode would be nice to have too
Exactly, that's the point. If you have a device with a ton of partitions it would easily eat all the drives at boot, making the other devices (e.g. the internal disk drive) invisible. And for sure, someone would complaint about that as well. 
But again, there's really no "DOS 2 compatibility" to discuss here; DOS 2 doesn't handle partitions at all, the partition related behavior on devices with MSX-DOS kernel is implemented in the driver.
To mount other partitions you have to use AUTOEXEC.BAT which is not ideal solution either because MAPDRV accepts slot-subslot as argument, so if you insert cartridge in another slot, it will fail
Usually you'll use just one controller, then you can specify slot number 0 to MAPDRV, meaning "the primary controller". But may I ask how often do you change the slot where you have your storage controller inserted?
BTW, i always wanted MAPDRV to accept drive letter of already mounted partition instead of slot-subslot-LUN information as reference to mount another partition. Technically it is possible, because you can fetch Nextor related information of already mounted partition with DRVINFO command, so it could be possible to mount another
Now that's a really nice idea and I don't think it would be very complicated to implement. Feel free to create an enhancement request for this in GitHub and I'll take a look.
Still if we could have e.g. a NEXTOR.INI that if it has AUTOMOUNT=Y will mount all partitions that would be much easier for many novice MSX'ers. I would argue AUTOMOUNT should be the default even and people that have special use cases or need more flexibility can set AUTOMOUNT to N.
That's also a really nice idea... but that one would be not so easy to implement. 
The kernel would have to scan the root directory of the main device for that NEXTOR.INI (although it did that already in the past for NEXTOR.DAT), parse and verify the file, then apply it once everything has been properly initialized.
I see more viable to develop an AUTOMAP.COM tool and run it on AUTOEXEC.BAT. All the required function calls for such a tool are already in place.
Finally, a couple of pseudo-random thoughts:
I realize that the partition management behavior and tools in Nextor are far from ideal. With the "map just one partition of each device" approach I tried to find a compromise solution that was at least minimally acceptable to everybody: you see all your devices at boot and you are able to use MAPDRV to map others.
Also, the Nextor repository is open to pull requests in case anyone is willing (and able) to give me a hand. Going back to that AUTOMAP.COM tool, for example, I don't think I'll implement it myself (I prefer to dedicate my always shrinking free time to improving/fixing the kernel), but if someone wants to take the challenge, go for it and of course AMA.
I just want to remind that you can choose which partition is mounted at boot by setting its "active" flag with FDISK. Mounting the first existing partition is the default behavior when no partitions have this flag set.
Selecting which partitions auto-mount by setting the “active” seems like the perfect solution to me to be honest. (I presume you can set this flag on more than one partition.)
Usually you'll use just one controller, then you can specify slot number 0 to MAPDRV, meaning "the primary controller". But may I ask how often do you change the slot where you have your storage controller inserted?
Ah since you ask, I change slots quite often, I swap my MegaFlashROM SCC+ SD between my MSX machines quite a lot and am not paying attention to what slot I insert it in. Also sometimes I change the slot to get some other extension to work. I also share the same SD card between different disk interface extensions, which have different internal slot layouts.
So avoiding the need for the end user to use slot identifiers seems like a good concept to me. I like Pencioner’s idea, and that automap tool idea would achieve something similar as well.
But then again I don’t feel the need to have more than 1 partition. 4 GB is plenty enough for me, and I find dealing with multiple drives a hassle because it makes it harder to find where you put things. And if I had a need for more than one partition, I can use the active partition flag.
That's also a really nice idea... but that one would be not so easy to implement. The kernel would have to scan the root directory of the main device for that NEXTOR.INI (although it did that already in the past for NEXTOR.DAT), parse and verify the file, then apply it once everything has been properly initialized.
In my opinion AUTOEXEC.BAT fulfills exactly the same purpose that such an INI file would, in a more flexible way. You can define environment variables and execute programs.
I just want to remind that you can choose which partition is mounted at boot by setting its "active" flag with FDISK. Mounting the first existing partition is the default behavior when no partitions have this flag set.
Selecting which partitions auto-mount by setting the “active” seems like the perfect solution to me to be honest. (I presume you can set this flag on more than one partition.)
Only one partition can be marked active and only the marked partition is mounted as A: (unless your disk interface is in a lower slot, then it becomes C: unfortunately), in my opinion (although off topic slightly) Nextor should always let any disk ROM initialize first and let it mount its drives, afterwards Nextor can mount the partitions. That way the resulting operating environment will always be the same regardless the location of the disk ROM.
Usually you'll use just one controller, then you can specify slot number 0 to MAPDRV, meaning "the primary controller". But may I ask how often do you change the slot where you have your storage controller inserted?
Ah since you ask, I change slots quite often, I swap my MegaFlashROM SCC+ SD between my MSX machines quite a lot and am not paying attention to what slot I insert it in. Also sometimes I change the slot to get some other extension to work. I also share the same SD card between different disk interface extensions, which have different internal slot layouts.
So avoiding the need for the end user to use slot identifiers seems like a good concept to me. I like Pencioner’s idea, and that automap tool idea would achieve something similar as well.
But then again I don’t feel the need to have more than 1 partition. 4 GB is plenty enough for me, and I find dealing with multiple drives a hassle because it makes it harder to find where you put things. And if I had a need for more than one partition, I can use the active partition flag.
I do this as well (swap SD between OCM, MFR, GR8NET) and computers (some with disk ROM in slot 0). I do have multiple partitions, 1 with the OS, utilities and applications (2GB in size). A second one with ROM and disk images (4GB) and 2 more partitions with VGM packs (both also 4GB).
That's also a really nice idea... but that one would be not so easy to implement. The kernel would have to scan the root directory of the main device for that NEXTOR.INI (although it did that already in the past for NEXTOR.DAT), parse and verify the file, then apply it once everything has been properly initialized.
In my opinion AUTOEXEC.BAT fulfills exactly the same purpose that such an INI file would, in a more flexible way. You can define environment variables and execute programs.
I disagree, AUTOEXEC.BAT is for when the OS has finished booting, a NEXTOR.INI (or CONFIG.SYS if you compare it to MS-DOS) would configure the OS during boot time.