Sorry for the clickbait-ish title but I really wanted to grab your attention. 
This post is a dump of what’s going on my head regarding the future of the Nextor project, and will be of interest mostly for driver developers. Nothing of what follows is set in stone, and feedback is highly welcome.
The Nextor project has been quite a long and interesting ride so far, and I’m happy to see how well it has been accepted by the MSX community. At this point it’s got most of the features I had planned to implement when I started the project, being the remaining ones:
- Support for loading drivers in RAM, additionally to store them in ROM. To see the usefulness of this keep in mind that a Nextor driver can not only handle storage devices, but also provide interesting capabilities like implementing BASIC CALL commands, providing a timer interrupt hook, or hooking into the extended BIOS; these things require currently manual work like allocating RAM in page 3 and adjusting various system pointers, imagine if Nextor could be able to handle all of this gracefully.
- Support for filesystem drivers. That’s a huge one. So additionally to low-level device drivers having basically a “read and write sectors” function, a filesystem driver would instead have functions like “find files”, “read from file”, “rename file”, etc; of course directly mapped to the equivalent system function calls. That would allow amazing stuff, from leaving advanced hardware to take the burden of dealing with filesystem management, to map Nextor drive letters directly to FTP servers.
- One that I hadn’t considered initially but needs some love is the support for floppy disk drives. There’s no way to implement basic floppy-related features like formatting a disk or providing a phantom drive (the last one can be done, although in an overly complicated way, in Nextor 2.1), and this needs to be fixed - so that you can e.g. use a USB FDD as it’s meant to be used, natively from a Nextor driver.
However, before plunging into those I would like to take a step back and make a couple of changes to the driver structure. These changes are intended to somewhat simplify the code of Nextor (and hopefully the process of writing new drivers too), and are driven by the observation of how existing drivers have been written:
- Get rid of drive-based drivers
Nextor allows to use two kind of drivers: “drive-based”, where the driver itself handles a number of drives much like MSX-DOS does; and “device-based”, where the driver controls a number of devices and Nextor maps drives to partitions on these devices.
To the best of my knowledge, nobody has written a drive-based driver for Nextor; all the existing drivers are device-based.
Removing support for drive-based drivers would allow me to remove some code from the Nextor kernel, and would make the process of writing a new driver (and the associated documentation) less confusing.
- Get rid of LUNs
Nextor drivers can control up to seven devices, each having up to seven logical units. I designed it that way because that’s how SCSI and (more relevantly nowadays) the USB storage class work.
However this has proven to be confusing. I have been asked questions like “My device has two card slots, is that two devices or one device with two LUNs?”; and the truth is that there’s no right answer, both methods would work. I always end up recommending using two devices with a single LUN for simplicity.
Therefore, I think it’s safe to change the “7 devices with 7 LUNs” design to just “255 devices”. If a driver still needs to internally use LUNs, it can do something like supporting 15 devices and mapping device numbers as “main device id + 16 * LUN id” or something like that.
- Unify the info/status routines
Right now Nextor drivers need to implement three routines to get information about devices: DEV_INFO, DEV_STATUS, and LUN_INFO. The idea is to deprecate those and replace them with a single DEV_QUERY routine, where the index of the information to be queried would be passed in a register; this mechanism is less confusing and easily extensible without having to create new routine entry points.
As for getting information about the driver itself, Nextor has three mechanisms: hardcoded information (driver flags and name), a DRV_VERSION routine, and an optional DRV_CONFIG routine. The plan would be to leave only DRV_CONFIG (renamed to DRV_QUERY) making it mandatory; and, similarly to DEV_QUERY, use an input register to indicate the index of the information to be queried.
Although implementing both routines would be mandatory for all drivers, not all the queries would be mandatory to implement; in fact the idea is to have as much of them as possible being optional, with Nextor being able to resort to sensible defaults as appropriate.
“Wait a second”, you’ll say. “But that’s incompatible with the current driver design. Does that mean that drivers would have to be rewritten?”
Well… yes and no.
Please be so kind to drop your torches and pitchforks and allow me to finish the post. Thanks.
If Nextor was a Windows-like sized project, with thousands (millions?) of supported pieces of hardware out there, I wouldn’t be able to afford introducing such breaking changes. But we are the MSX community, which is comparatively very small; and only a handful of drivers have been developed. From the top of my mind:
- Sunrise IDE (and compatibles like Carnivore2)
- MegaFlashROM SCC+ SD
- Flashjacks
- Rookie Drive
- SD Mapper
- GR8NET
...and maybe a few others, but you get the idea: we are in “small committee” and I’m sure we could somehow coordinate to get any required changes done.
“But why don’t you support both types of drivers at the same time?” I had considered that, but that approach would add too much complexity to the Nextor code, especially if LUNs are indeed removed from the equation. And given the constraints I have on the time I can afford to dedicate to the project, I need to simplify stuff as much as I can.
“Then… will I have to rewrite my driver from scratch??” No. Not from scratch. Apart from the mentioned changes, the rest of the driver structure would remain unchanged (most notably the DEV_RW routine, which would only require changes in case of supporting LUNs). The changes would mostly consist of moving some code around (notably, from DEV_INFO/DEV_STATUS/LUN_INFO to DEV_QUERY); I would publish a detailed driver migration guide, and I would migrate the Sunrise IDE driver myself to guide by example.
Going back to the title of the post, I think that such a breaking change well deserves a main version bump, so these changes would be implemented in a future Nextor 3.0.
“And what about Nextor 2? Will you abandon it?” No. Or better said, not yet. Nextor 2 would enter into “maintenance mode”, this means that I would continue fixing any bugs found but I wouldn’t implement any new feature on it (in other words: but fixes would go to Nextor 2 and 3, anything new would go to Nextor 3 only). Of course I can be flexible here: if I get a request for a feature that’s fairly easy to implement I might add it to Nextor 2 as well.
Thus, Nextor 2 would die only after Nextor 3 has a stable release and has drivers for all devices (a device explicitly or blatantly abandoned by its creator might be an exception here, if that ever happens).
So, what would be the next steps if I decide to go ahead with this plan?
- Publish a temptative detailed design of the new driver structure and the driver migration guide, get feedback, adjust if needed.
- Develop and publish a first alpha of Nextor 3.0, having the exact same functionality of Nextor 2.1 but with the new driver system, and two drivers migrated by myself: standalone and Sunrise IDE. That’s when driver developers could start the migrations.
- Start working in the new features of Nextor 3, while helping anyone struggling with driver migration, while fixing bugs in Nextor 2.1.
Uh… now that I re-read it, 3 sounds like too many things at once; but well, you get the idea, that would roughly be the plan.
“And what schedule/time estimation would this plan have?”
Ha ha ha!! That was a very good one! 
So… that’s basically what’s in my mind regarding the future of Nextor. Now, what’s in yours?
. The fact that DOS2 does not do this by itself always seemed strange and risky to me, especially in the case of abnormal program termination. As a programmer it’s also a hassle because I need to store and remember these, and define abort handlers to ensure they are restored. To be honest I also kinda don’t trust all programmers to take sufficient care to do this 
