Rethinking Nextor a bit (help appreciated!)

Page 1/2
| 2

By konamiman

Paragon (1044)

konamiman's picture

14-01-2019, 17:00

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!

Login or register to post comments

By Grauw

Ascended (8457)

Grauw's picture

14-01-2019, 17:28

For me long filename (LFN) support would be very welcome. I wrote earlier:

Grauw wrote:

For translation from long to short filename I think it should be possible to integrate seamlessly in most DOS2 calls. Even _PARSE (to my surprise) does not stop at spaces, so that too could just support it without breaking backwards compatibility.

For translation from wildcard / short filename to long filename I think a LFN-version of _FFIRST and _FNEXT (and _FNEW?) would be needed, adding a parameter pointing to a 255-byte buffer where they can fill in the long filename. Because of the way LFNs are stored, doing it via these calls seems the most efficient / logical to me (as it needs to scan the directory entries preceding the short filename to determine the long one).

And possibly also FAT32 support.

By Grauw

Ascended (8457)

Grauw's picture

14-01-2019, 19:08

Also, do you have some information how I could compile a binary from latest sources that I could put on the MegaFlashROM SCC+ SD?

I'm using MacOS, it looks like I at least need to get a CP/M emulator going, but looks like our very own TomH has made one for MacOS Smile. Additionally, compile hex2bin, Sjasm and the mknexrom tool, and translate the batch files to a bash script. Would I need to do anything else?

By ToriHino

Champion (371)

ToriHino's picture

14-01-2019, 19:21

Grauw wrote:

For me long filename (LFN) support would be very welcome.

That would also be one of my favorite extensions for Nextor. Since we have the tool DI.COM from Victor, I more and more miss the native support for this.

By Spider

Resident (45)

Spider's picture

14-01-2019, 19:50

that might sound extreme and silly at the same time: my proposal is to provide full featured gui Nextor configuration editor embedded into OS. similar to what PC does; but PC keeps the configuration in motherboard flash memory; yet Nextor can keep it on disk.
Scenario is: user holds a key [ALT-STOP] or whatever on boot; Nextor identifies that, shows up UI where you can set various settings, then if user wants to exit-and-save -- Nextor saves that on some file or disk area and uses that info for load.
BTW, that disk area could be a Nextor.sys file itself. and modification could go as static self-patch which would be easy to implement on both floppy disks and hard disk partition locations for Nextor OS.

if user does not hold that key combination -- UI does not pop-up, may be 2-3 sec delay will be provided as in old PC BIOSes, then Nextor.sys is loaded and static encoded parameters are taken from its code [as it was self-patched or defaulted] and load moves on.

Some runtime command/executable may also be provided to start up Nextor configuration UI [as in startup] and reboot on save-and-exit.

If you decide to use a file to store startup configuration configuration -- you may have several files and select the one to take configurations from; or have one file which has several boot configurations: like if you use flash disk on several systems -- you can have one configuration per system or different variants of configurations for one system.
in that case -- you hold key combination on boot -- all possible configurations are shown [or configurations applicable to current hardware is shown]; user selects preferred configuration, and boot with preferred configuration is happening.

Cheers:-)

By Grauw

Ascended (8457)

Grauw's picture

14-01-2019, 23:36

Grauw wrote:

I'm using MacOS, it looks like I at least need to get a CP/M emulator going, but looks like our very own TomH has made one for MacOS Smile.

Hm, ok, TomH’s emulator doesn’t work as I hoped, it’s more of a stand-alone emulator than one which runs on the command line. I found this one, which works fine for m80, but when invoking l80 it fails to run it, instead returning to the command prompt… Some length limit of sorts on the command line it seems. For the b6 segment where I did get it to work the hex file it generates isn’t liked by hex2bin (there seem to be additional characters written from memory after the end of file marker).

By Giangiacomo Zaffini 2

Master (165)

Giangiacomo Zaffini 2's picture

16-01-2019, 13:57

If Nextor could support other filesystem types, filesystem oriented to serial SPI, such as SPIFFS or littleFS, there could be cartridges with cheap memories banks.
If Nextor could have a Dynamic tracing like DTrace or something in that direction, It should be of help.
That's my little trying. :)

By konamiman

Paragon (1044)

konamiman's picture

16-01-2019, 15:28

Giangiacomo Zaffini 2 wrote:

If Nextor could support other filesystem types

That's actually planned for v2.2. Some day, I guess (damn real life...)

By zett

Hero (574)

zett's picture

16-01-2019, 15:40

i hope sir nextor that there will be a way to set disks under dos1 and a map. so like paint 4 and a map as drive b:

By gdx

Prophet (3046)

gdx's picture

17-01-2019, 15:05

Nextor uses too many keys for various functions at startup. It would be better to reduce this to the maximum to avoid confits. For example gather a maximum of functions on a setting screen.

By QBee Sam

Master (206)

QBee Sam's picture

17-01-2019, 21:37

Grauw wrote:

For me long filename (LFN) support would be very welcome. I wrote earlier:

Grauw wrote:

For translation from long to short filename I think it should be possible to integrate seamlessly in most DOS2 calls. Even _PARSE (to my surprise) does not stop at spaces, so that too could just support it without breaking backwards compatibility.

For translation from wildcard / short filename to long filename I think a LFN-version of _FFIRST and _FNEXT (and _FNEW?) would be needed, adding a parameter pointing to a 255-byte buffer where they can fill in the long filename. Because of the way LFNs are stored, doing it via these calls seems the most efficient / logical to me (as it needs to scan the directory entries preceding the short filename to determine the long one).

And possibly also FAT32 support.

+1
Yes, FAT32 support should be fantastic.

Page 1/2
| 2