Hi all Nextor fans. After publishing the beautified MSX2 Technical Handbook, I think that it's time to give some love to Nextor. I have some plans/ideas on how to continue with the project, but instead of Just Doing It (TM) as usual, this time I thought it would be a good idea to tell the community (that's you all who are reading this) a bit about it, which hopefully will result on me getting some useful feedback (and perhaps even some help).
First of all, I'm going to start working on v2.1.0 beta 1. This will be the same as v2.1.0 alpha 2, but will all the fixes and features introduced in v2.0.5-beta1.
After that it'll be time to do some bug hunting. Since I openly published the Nextor sources in GitHub a pretty nice list of bugs has flourished, which is a fantastic thing - by the way most of these have been reported by sd-snatcher, for which I love and hate him at the same time ;) Any help for obliterating these bugs will be highly welcome, even simple hints of what can be causing it or where the offending code can be. And of course, don't hesitate to report any other bug that you find.
Bugs aside, these are the areas that I plan to improve in Nextor 2.1:
1. Drive/partition assignment at boot time
Right now the default behavior of the Nextor kernel at boot time (which can be overriden by drivers by implementeing the DRV_CONFIG routine introduced in v2.0.5) is to assign one drive to each available device, drive A: being assigned to the first device that has a partition with a file named NEXTOR.DAT in the root directory. sd-snatcher points out that the proper thing to do would be to rely on the bootable flag that is defined for partition tables instead, and I think that it makes perfect sense (that would require to develop some tool to change the bootable status of partitions, but that's not a big deal).
Therefore the procedure at boot time would be:
- Scan all the existing devices in device-LUN ascending number order in search for a FAT12 or FAT16 partition with a bootable flag (only FAT12 when booting in DOS 1 mode), and assign the first one found to A:.
- If no such partition is found, then scan again in search for simply a valid FAT12 or FAT16 partition, and assign it to A:
- Once A: is assigned, search for other devices having at least one FAT12 or FAT16 partition, and assign one drive to each.
If no partitions exist on any device having the bootable flag, then this procedure is identical to the one currently followed by Nextor, except that NEXTOR.DATs are ignored.
Another improvement that I was thinking about for the drive assignment at boot time is to assign drives to removable devices, even when no volumen is inserted. Then when the user inserts a volume (e.g. a SD card), a partition will be assigned automatically on first access. This is however impossible with the current driver structure - see next point.
2. Device/LUN driver routines unification
Right now Nextor drivers must implement three different routines that allow the Nextor kernel to obtain device information and status (DEV_INFO, DEV_STATUS and LUN_INFO). These routines show some inconsistencies (e.g. why descriptive strings can be returned for devices but not for LUNs?), aren't easily escalable (how to return more information in future versions without breaking old drivers?) and have (at least) one important flaw: it's not possible to know if a device is removable if there's no volume inserted (LUN_INFO returns "device not available" in this case, but also when the device really doesn't exist).
To solve this I plan to replace these three routines with a single one, DEV_QUERY, that would serve as a central point for gathering device information and status in a more granular way. This routine would accept a query index, a device index and a LUN index, and would return the appropriate information depending on the query. Example queries would be "What's your device name?", "Are you a removable device?", "What's your volume change status?" or "What's your size in sectors?". This is easile escalably - just define new queries in the future and as long as they are optional, everything remains compatible.
The "replacement" would be done in two steps:
- - In Nextor 2.1 DEV_QUERY would be optional, the Nextor kernel would still use DEV_INFO, DEV_STATUS and LUN_INFO for drivers that don't implement it.
- - In Nextor 2.2 (whenever that will be) DEV_QUERY would be mandatory, and support for the replaced routines would be removed (which would simplify the Nextor kernel code).
3. The CTRL key
As mentioned before, at boot time Nextor assigns one drive for each existing device that has a valid partition (unless DRV_CONFIG says something different). But if CTRL is pressed then one single drive will be assigned per driver.
Again, sd-snatcher makes a useful suggestion: pass the status of the CTRL to the DRV_INIT and DRV_CONFIG at boot time (he also suggests passing SHIFT, but this key is used to disable MSX-DOS drivers), and let the driver decide what to do. This is a good idea, the question would be what to do when DRV_CONFIG is not implemented or doesn't report the initial drive count for the driver - should CTRL keep its current behavior of assgning one single drive for the driver? Is this really useful?
4. Floppy emulation mode
The floppy emulation mode is implemented by creating a file with a special name in the boot partition: if the file exists then Nextor boots in emulation mode, unless a special key is pressed. Then the file needs to be renamed or deleted if the user wants to disable booting in emulation mode.
I would like to improve this mechanism (if only because after removing the search for NEXTOR.DAT, removing also the code that searches for the emulation data file would greatly simplify the Nextor code), but I can't think of anything short of requiring the drivers to somehow provide non-volatile ad-hoc storage. Any ideas?
And that's all I have for now. Let the fight debate begin!
. Additionally, compile hex2bin, Sjasm and the mknexrom tool, and translate the batch files to a bash script. Would I need to do anything else? 
