konamiman/nextor

A disk operating system for MSX computers, forked from MSX-DOS 2.31

nextor's Issues

DEV_STATUS should be called to detect removable disk changes

Currently, Nextor tries to find out if a removable media has changed by checking the FAT header itself.

But this results in unnecessary reads of the media. There are interfaces that provide a hardware disk-change function that can considerably speed up this. Some examples are the Panasonic MSX2+/TR and Sanyo MSX2+ floppy disk interfaces, and the FB-Labs SDHC interface.

The best approach would be for Nextor to call DEV_STATUS, before accessing a removable media, and only if DEV_STATUS returned A=3 (*1) it would try to figure itself by checking the FAT header.

*1: Means that the media is present, but this device can't determine whether it has been changed

Disk change detection bug on 2.0.5-beta1

Nextor 2.0.5-beta1 introduced the much awaited DRV_CONFIG config feature.

But there seems to be a bug on how the disk-change detection is done for removable media.

The routine MEDIA_CHECK on bank2/val.mac will only ask for the driver for a disk-change detection if the UF_PAP flag of the UD_DFLAGS isn't set. When the UF_PAP is set, MEDIA_CHECK doesn't ask for the driver and does a blind return of NC;NZ (Disk has changed).

But, when the system is booted without any media on the drive, the MAP_DEF_DEVB of the bank4/partit.mac file will set the UF_PAP flag to 1.

This behaviour causes a problem, because some drivers will have to rely that its DEV_STATUS will be always called for media change checks, so it can perform its necessary house keeping in case a media has changed, like the update of its Work Area data about the new media that is necessary for other functions like DEV_RW to perform correctly.

Since DEV_STATUS isn't being called, after the system was booted without any media in the drive, DEV_RW will fail because it doesn't know how to handle the new media yet. Nextor will then be unable to read such media and this will result in a deadlock between:

1. Nextor calling a not-yet-functional DEV_RW that to try read partition data and finally clear the UF_PAP flag, and
2. The driver waiting for Nextor to call its DEV_STATUS function to be able to update its WorkArea and make DEV_RW functional for the new media type.

For example, this is the case of SD/SDHC cards, since v1 cards and v2 cards have differences in their protocols. But there are other cases where this can happen, like USB interfaces (a completely different device might have been plugged), or even LS-120 IDE drives.

Suggestion: Pass the status of the CTRL and SHIFT keys to the driver DRV_CONFIG and DRV_INIT

The diskROM reads the status of the CTRL and SHIFT keys at the moment it issues a BEEP in the boot sequence.

Please pass the status that the CTRL and SHIFT keys had at the moment of the boot beep to the driver DRV_CONFIG and DRV_INIT functions, so the driver can take decisions accordingly, like adjusting DEV/LUNs, reduce the allocated workRAM, etc.

MAPDRV "Invalid drive" error if do not supply parameters after the partition number

I get an error Invalid drive if I do not explicitly indicate the device index and driver slot/subslot
mapdrv c: 2

this command work fine:
mapdrv c: 2 1 2-1

Tested on Carnivore2 / Nextor 2.1.0-beta2

Formatting a floppy in Nextor fails with sector not found

System: FS-A1ST, GR8NET

If I try to format a floppy disk from Nextor (FORMAT B:) I get an error. If I boot the machine into basic (GR8NET removed) the floppy formats fine.

If more info (if not reproducible) is needed let me know.

_FDISK freezes if DEV_RW returns an error on its first call

As the title says, CALL FDISK freezes just after the device selection screen if DEV_RW returns an error on the first time it is called.

DRV_CONFIG is called 2 times when going to be in DOS1 mode

If pressing and holding "1" key (boot into DOS1 mode) this routine, DRV_CONFIG, is first called in DOS2 mode (B=0), with A=1 and then with A=2 (with call count equal to number of drives requested). If, during first call (when input A=1) driver returns no error, kernel calls DRV_CONFIG again with A=1, but now in DOS1 mode (B=1), and performs another round of query of devices/LUNs. This problem will not be noticed by the drivers not supporting DRV_CONFIG or boot-time drives.
If driver displays messages (e.g. configuration summary) then the message will appear twice.
If driver must perform configuration only once after the hardware initialization (DRV_INIT), it will be confused by the second call.

M80 include not working

Hi guys i wanted to report a problem of M80 assembler with Nextor.

If i use INCLUDE directive in source code, the assembler reports error (V) not finding the file.
While using legacy MSXDOS 2 all works without problems.

I tested all with Nextor 2.1.0 Beta 2 (openmsx) and M80 version 2.0

_FDISK: partitions can not be added

I created one 4096M partition on the 149 GB disk, saved changes. Used the partition for some time, and then decided to add another partition. But there's no option to add another partition, the only way to create new partition is to delete all the partitions, and then recreate everything from scratch -> data loss.
Why it is not possible to add partitions into the free space after initial configuration is created? Is it possible to change this?

NEXTOR 2.1 Alpha-2 for Sunrise not working on Toshiba HX-10DP

NEXTOR 2.1 Alpha-2 for Sunrise ATA/IDE/CF doesn't work on a Toshiba HX-10DP. Slot management seems buggy. Original MSX-DOS2 v2.30 patched for MSX1 works perfectly. Even the version for ESE-RAM SCC of 512K (see link below works fine).
https://msx.org/downloads/esedos4m

With original Sunrise firmware the interface works on Toshiba HX-10DP (not perfectly but it's usable).

In addition, the second CF card is unusable on all my MSXs. When I use both cards at the same time, it corrupts the FAT. (Tested in FAT16 only)

Kernel does not check for validity of the boot sector

I have made a mistake in test DEV_RW routine, and, when boot sector is being read first time, instead of moving data from ROM location to required RAM location perform reverse action, moving data from RAM to ROM (which has not effect and ROM contents are not changed). However in this case invalid data remains in the RAM sector buffer, and driver returns that it has read 1 sector successfully.
Next action of the kernel is to read sector 0xffffffff. Here's the screenshot of that is being provided as a boot sector on the first read:

This means that if boot sector is obviously corrupt, there may be an invalid request to the storage device (e.g. out of LBA). If connected device is floppy drive (or FDC) without checking track number there will be a risk damaging the stepper motor and its mechanism.

Possible fix could be checking for AA55 signature at the end of the boot sector if Nextor is going to treat boot sector as an MBR (Nextor must write it when initializing the volume). Alternatively, there must be some keywords in the MBR generated by Nextor wilch must be used to identify if sector read can be treated as valid MBR or not.

Long filename (LFN) support

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).

Finally the deletion and renaming of long filenames should be handled, I think currently the directory gets polluted because only the 8.3 entry is removed and the preceding LFN-entries are not.

---

An example of how LFN in Nextor would be useful in VGMPlay is for M3U VGM playlist support. These are distributed with packs you download from VGMRips. However currently users can’t really use these playlists as-is on MSX because they contain long filenames.

To support this in VGMPlay I will _FOPEN the filename on each line of the playlist. People will need to create M3U files especially for MSX with only short filenames in them. However when Nextor supports LFNs, the M3U files distributed with the packs can be used as-is.

Impossible to implement phantom drive properly

The problem starts just at the system start: after DRV_CONFIG is finished, kernel tries to identify the contents of the media in the drives reading boot sectors, however as there's only one diskette drive and another one is phantom, this action causes messages

as kernel has no idea that these drive letters are the same physical drive. It is not possible to overcome at the driver level, and requires changes in the kernel.

Second issue, where to obtain current the letter of the current device to display the prompt: YF33F seems to contain invalid information when device enumeration is being performed (see prompt strings above - for all the devices enumerated YF33F has value of 0). However it seems to contain correct drive letter reference when booting is started.

Third issue, at some point in time (when booting is attempted) the PROMPT hook XF24F is set with jump to somewhere, and machine crashes. When device enumeration is performed before this event, the hook properly contains the RET.

On the pictures -Dx means calling the prompt checking routine for the device x. If prompt is going to be displayed, routine also displays contents of 3 bytes starting XF24F. The first pictures show C9C9C9, while second at the top shows jump to some address EAC6. The jump to this EAC6 ends at some Nextor kernel location displaying arbitrary strings from built-in FDISK application.

Also you can see as soon as booting process started and DOS2 is loaded, YF33F contains correct reference to device current number (as it starts displaying A: and B: in the prompt).

DEV_BASSTAT and register changed

Documentation must explicitly state that code in DEV_BASSTAT must not change HL register, If HL is changed then the _SYSTEM gives Syntax error if HL happens not to point to byte with value of 0.

Nextor ROM should boot MSXDOS2.SYS when NEXTOR.SYS isn't found

For backward compatibility reasons, the Nextor ROM should boot the MSXDOS2.SYS file when the NEXTOR.SYS file isn't found.

Only this way it's possible to use a standalone Nextor cartridge to fully replace a MSX-DOS2 standalone cartridge, for example. Otherwise disk games based on the MSX-DOS2 won't boot.

If a driver implements the new DRV_CONFIG function, Nextor will panic with "No enough memory" if booted with CTRL+1

If, for the configuration index=0 the driver reports B=2 (requiring two drives) and the system is booted with CTRL+1 pressed, Nextor will panic with "No enough memory".

Tested with: Nextor 2.0.5-beta-1 on:

• Sanyo PHC-70FD with 512KB of internal Memory-Mapper
• Panasonic FS-A1ST with 1MB of internal Memory-Mapper
• Panasonic FS-A1ST with 256KB of internal Memory-Mapper

Steps to reproduce:

1. Modify an existing device-based driver so it reports B=2 when DRV_CONFIG is called with A=1
2. Boot your machine holding CTRL+1. According to the documentation, this should force the DOS1-mode with a limit of 1 drive per interface

Result: Nextor will panic with a "No enough memory" message.

Suggested solution: As a measure of software robustness, when CTRL is hold on boot, Nextor should limit the number of requested drives to at most 1, even if the driver asks for more drives on its DRV_CONFIG.

DOS1 mode DRV_CONFIG bug

This bug is probably related to the #12.

If the driver requests 2 drives on DRV_CONFIG with inputs A=1,B=0 (DOS2 mode), and requests only 1 drive for DRV_CONFIG with inputs A=1,B=1 (DOS1 mode), the DOS1 mode will allocate the drive letters to incorrect DEV/LUNs, as described ahead.

Tested on a Sanyo PHC-70FD.

Steps to reproduce:

1. Code a DRV_CONFIG to request 2 drive letters for the DOS2 mode, and only 1 drive letter to the DOS1 mode (to save memory in this mode)
2. Use an MSX that has an internal drive, and connect a Nextor cartridge that has 2 drives (like an IDE with 2 CF cards). All drives must have FAT12-formated medias inside.
3. Boot the MSX and keep the "1" key pressed to force the DOS1 mode
4. On the BASIC prompt, type FILES"B:"
   Result-1: The files from the CF card-2 will be shown. But this DEV/LUN should have been canceled, and the files from the floppy drive should have been listed.
5. On the BASIC prompt, type FILES"C:"
   Result-2: A "Disk I/O error" will occur. But the drive "C:" should have been mapped to the ghost drive of the floppy interface.

Nextor shouldn't block sector I/O to MAPDRV drives when FAT12 disk images are used

Nowadays, Nextor blocks sector I/O to FAT16 partitions, as a safety measure.
But, weirdly enough, it's also blocking sector I/O to MAPDRV drives of FAT12 disk images. This causes DOS2 programs that rely on sector I/O to fail.

For example: These are the results when you try to run the demo of the game F-Nano2' on Nextor 2.1.0RC1:

• Copy the files to a folder on a FAT12 partition: Runs fine
• Copy the files to a folder on a FAT16 partition: Fails because sector I/O is blocked
• Use EMUFILE: fails because the game requires DiskBIOS2
• Use MAPDRV: fails because sector I/O is blocked

You can download the demo of F-Nano2' here.

DOS1 mode reports "Disk I/O error" instead of "Disk offline" before any media is inserted

Tested on Nextor 2.0.5-beta1

Before any media is inserted, DOS1 on BASIC will report "Disk I/O error" instead of "Disk offline".

Steps to reproduce:

1. Boot the MSX without any media on the drive while holding the "1" key, to force the DOS1 mode
2. Type the command FILES on the BASIC prompt

• LUN_INFO will be called 3 times. (*1)
  Result-1: The error "Disk I/O error" will be reported instead of "Disk offline" like a normal floppy drive interface does.
  Note: You might repeat step-2 as much as you want

3. Insert a media in the drive and type FILES

• LUN_INFO will be called, and DEV_DW will be called to read the directory. The files will be shown.

4. Remove the media from the drive and type FILES

• Result-2: Now The "Disk offline" will be shown whenever needed
  Note: LUN_INFO won't be called ever again, even after media changes

*1: It doesn't make any difference if LUN_INFO reports a missing media by returning A=1 (LUN not available), or A=0 with the unknown fields set to zero (meaning not available).

DiskROM should only boot the partition marked as bootable, when more than one partition is present

When there's more than one partition in the media, the Nextor diskROM shouldn't boot a partition that isn't marked as bootable. This could lead to problems if multiple operating systems are installed. (I.e.: Nextor and Uzix) There will be no way to use a boot loader like UZLO.

Information about DOS1 or DOS2 mode is required at the DRV_INIT stage

Because hardware configuration may depend on the the mode system started in - e.g. different storage subsystem configuration settings read from EEPROM.
From the source code I see that Nextor just assigns B directly, and it is not possible to properly know what kernel code has called the DRV_INIT (DOS1 or DOS2), not flag is available in the RAM.
As a workaround it is possible to perform hardware initialization in DRV_CONFIG, but then I need confirmation and guarantee that this routine will always be called in any DOS1 or DOS2 configurations only once.

Add a way to mark the active partition on CALL FDISK

CALL FDISK doesn't allow the user to mark a partition as active. And none of the partitions it creates is marked as active.

Please add to the partition list function a way to mark which partition will be used to boot.

DEV_STATUS is never called on DOS1 mode

DEV_STATUS doesn't seem to ever be called for device-based drivers on DOS1 mode.

This means that the disk-change is only being handled by software, instead of hardware as it was recommended by the MSX standard, even if the interface supports hardware disk-change detection.

HDDEMU v.1.02~1.04

Hi,

These versions don't work on disk with partitions created with the Nextor driver.

http://msx.org/forum/msx-talk/software/question-about-hddemu

VIEW.COM crashes under Nextor

The system crashes when I use VIEW.COM under Nextor 2.10 beta. Tested on emulator and real FS-A1ST and Sunrise with driver v0.17.
https://www.msx.org/downloads/viewcom

Nextor fails in DOS1 mode

The driver is device-based, and returns 2 drives to the system to initialize at the boot time. These drives have 0 sectors in size reported to LUN_INFO (Nextor must identify them on the fly as they are floppy drives).

I am in the process of troubleshooting, and have the following strange things to report:

Problem 1.

When I boot system into DOS2 mode with "Nextor BASIC version 2.10" with 2 drives reported to the system at boot time, BASIC reports 25044 bytes free.
When I boot system into DOS2 mode with "Nextor BASIC version 2.10" with zero drives reported to the system at boot time, BASIC reports same 25044 bytes free.
When I boot system into DOS1 mode pressing and holding '1' key on Nextor initialization going to "Disk BASIC version 1.0" with 2 drives at boot time, BASIC reports 24960 bytes free. FILES command seems to work.
When I boot system into DOS1 mode pressing and holding '1' key on Nextor initialization going to "Disk BASIC version 1.0" with zero drives at boot time, system says "No enough memory" and halts.

Two things I do not understand:
a) why BASIC reports same free space with and without drives when in DOS1 mode as two drives must have space allocated for them in CPU bank 3 - at least for FATs which account for 23512=3072 bytes, thus clearly with two drives free space must be less for at least 3K.
b) Why kernel says "No enough memory" when I report no drives to the system at boot time?

Problem 2.

DOS1 kernel of the Nextor tries to flush sector contents it thinks needs to be flushed when MSXDOS.SYS is being loaded during booting.

In the image above:
++ is start og DEV_RW routine
A is input parameter in register A, device number
F is input parameter in flags
S is LBA requested
B is number of sectors requested
HL is transfer address
X is DEV_RW completion code
B after X is DEV_RW number of sectors processed

You can see that after reading 4 sectors from LBA 0x4A kernel tries to write sector 0xf9c3. I tracked this problem to the flag set in location YF242 (0F242H).

Here's another picture where I artificially disabled writing in the driver:

You can see that after "flushing" this sector 0xf9c3 kernel proceeds with reading remainder of the MSXDOS.SYS from sector 0x4e, and starts it. Then it reads COMMAND.COM, and hangs after it is loaded. Thus the problem is bigger than just buffer durty flag being set.

Note that I simulated the same behaviour in the GR8NET Nextor implementation. I did not catch this problem before simply because I never booted GR8NET from its SD-card or GR8cloud into DOS1 mode.

The problem is NOT present if Nextor kernel is in effect, but driver is located within another kernel (e.g. built-in floppy Disk ROM).

Clear screen before showing boot messages on MSX1

Nextor should clear the screen before showing the version number and searching for devices because on certain MSX1 machines these messages end up in the middle of the screen.

Proposal for alternative image changing trigger

According to the documentation an alternative way to change the mounted DSK image is: "Alternatively, you can also press the GRAPH key when the computer is trying to read the file. The caps led will lit and the computer will freeze until you release GRAPH and press the appropriate file key."

I believe it would be better to detect the GRAPH key being pressed for more than 3 seconds to enable the disk changing mode because catching the file's access while pressing GRAPH may not be an easy task in all situations. In the disk changing mode if GRAPH is pressed again, the mode should be deactivated (in case a user changed his mind).

Partitions created by FDISK mustn't be the same name

All partitions created by FDISK tool there are the same name "NEXTOR 2.0 " (source/kernel/bank5/fdisk2.c) and it is a bit confuse to identify each one on UNIX like operating systems.

Nextor as Master and IDE250.DAT as slave freeze on IDE drive access

When an interface with Nextor is used together with an IDE that still has the IDE250.DAT BIOS, the System boots fine.

But Nextor will freeze on the first access done to a drive of the IDE. It might even be just a DIR command.

DRVINFO shows the correct information, but "DEVINFO 0" shows only the Nextor devices. In my case, not even the TR floppy drive was shown in the list in this case

Tested with Nextor 2.1.0a2 on a FS-A1ST.

Nextor should mount all non-hidden partitions automatically

I've tested the Maxiol CF-IDE controller and there every non-hidden partition is mounted to a drive on bootup. Nextor doesn't do this automatically - a user has to manually mount partitions after bootup. IMO this causes confusion and extra actions while it should be done by default. So I propose that all non-hidden partitions should be auto-mounted on bootup.

The may be, however, a key to press in order to disable this feature and only mount the bootable partition instead (like it's done in Alpha).

The name of the DSK emulation configuration file should be changed

The name of the emulation settings file NEXT_DSK.DAT should be changed to avoid accidental deletion of NEXTOR.SYS file after disabling the emulated DSK image and booting back to MSX-DOS2. When typing "del next" and pressing TAB the first 2 files to be found may be NEXTOR.SYS and NEXTORJP.SYS.

The name of the DSK emulation settings file should not contain any sequence of letters that Nextor's files have. It should be something pretty simple, unique, and easily visible, for example "_DSKEMU_.CFG" or just "DSKEMU.CFG".

Files with "file system" attribute, can't be opened with "open filehande"

when you "open filehandle" in a file with "file system" attribute, the "filehandle" won't be opened correctly and NO error is returned.

It fails after loading Nextor.SYS on MSX without disk drives.

In compilations Sunride gives failure due to corruption of RAM after loading NEXTOR.SYS in MSX (All versions) that do not have an internal disk drive.
In my case, when compiling for Flashjacks unit the error only occurred in MSX without internal floppy disk. I suspect that they do not work in the IDE (Carnivore, etc ...) but the failure could be extended to all versions of devices.

Slot keys do not work?

Nextor is located in slot 1.3. Whatever alpha key described in the manual as "slot key" I press at its start, machine boots into DOS. Should I expect Nextor in the target slot totally inactive when I press respective key?

Update: funny enough it works in the openMSX emulation, but does not work on real machine. GR8NET is installed into the slot 2 in mapper 8 mode (Nextor is in slot 2.2). In openMSX, when I press "D" key, Nextor does not initialize. On real machine - and it is Russian Yamaha MSX2 machine - when I press the same physical key with same scan code (this key is labelled "W"), Nextor initializes and boots DOS2 from SD-card. I expect it going directly to BASIC without any disk-ROM initializations.

Improvements on the driver initialization/message display procedure

1. On MSX2 or higher, just before doing the round of the 2nd calls to the devices DRV_INIT routines, Nextor should call the subROM's SDFSCR routine to set the screen parameters from the RTC
2. After each 2nd call to the DRV_INIT returns, Nextor should check INTFLG to see if the STOP key was pressed, and pause the flow accordingly. A new press of the STOP key would allow the boot to continue. This feature would be used help the user to pause the boot sequence to read any messages.
3. There should be a standard function on each driver to show the version and copyright info of the driver. A standardized CALL function from Nextor (CALL DRVINFO maybe?) would call this function for each driver, and they would print such info on screen.
4. Write some coding etiquette for drivers, explaining that the driver shouldn't change screen parameters, clear the screen or add unnecessary delays unless some error has occurred.

Originally proposed via email by FRS

Nextor Beta1 doesn't work on Carnivore2 - no longer booting to MSX-DOS2

Just tried Nextor Beta1 on my Carnivore2 cartridge. Flashed the "Nextor-2.1.0-beta1.SunriseIDE.ROM" file into the cartridge as BIDECMFC.BIN, copied the "Nextor.sys" and the tools into the root folder of the CF card and rebooted.

As a result the cartridge is no longer able to boot to MSX-DOS2. The system just hangs after Nextor's copyright message is shown. Sometimes the background color becomes the same as the border color on my MSX2+ before the system hangs.

The test was done on diskless Yamaha YIS503III upgraded to MSX2+.

Device-based removable media replacement problem

I am developing device-based driver for floppies. Performing DIR in DOS2 after diskette replacement lists directory properly, but if I go to Nextor disk-BASIC and perform FILES in there, I see part of previous disk's directory just after floppy disk is replaced. Second time I perform FILES it may give better results (more files listed from new media), and if performing FILES 3rd time directory listing from new media seems to be correct.
Driver reports disk change properly (it performs diagnostic output to the screen).
I am afraid that on first FILES run after disk replacement I do not see required sectors being read to display new media properly.
I report 0 sectors for floppies in LUN_INFO (expecting kernel to read boot sector when needed to find out media geometry). When reading changed disk, kernel reads boot sector at least 3 times (why does it do this as it must be enough to read it once...)
Same problem happens with 720k and 1.44 disks. Tried kernel in openMSX with drive-based disk-basic 1.0 and FILES seems to work properly after virtual diskette change.

DRV_CONFIG behavior when it returns A=1 for function A=1

The driver template states:

;-----------------------------------------------------------------------------
;
; Get driver configuration
; (bit 2 of driver flags must be set if this routine is implemented)
;
; Input:
; A = Configuration index
; BC, DE, HL = Depends on the configuration
;
; Output:
; A = 0: Ok
; 1: Configuration not available for the supplied index
; BC, DE, HL = Depends on the configuration
;
; * Get number of drives at boot time (for device-based drivers only):
; Input:
; A = 1
; B = 0 for DOS 2 mode, 1 for DOS 1 mode
; C: bit 5 set if user is requesting reduced drive count
; (by pressing the 5 key)
; Output:
; B = number of drives
;
; * Get default configuration for drive
; Input:
; A = 2
; B = 0 for DOS 2 mode, 1 for DOS 1 mode
; C = Relative drive number at boot time
; Output:
; B = Device index
; C = LUN index

DRV_CONFIG:

If driver, for configuration index A=1 returns A=1 ("Configuration not available for the supplied index"), kernel assumes that driver wants 2 drives and calls DRV_CONFIG with index A=2 two times for relative drive numbers 0 and 1.
I believe if driver returns error for call with A=1 kernel must assume there will be no drives at all.

If driver returns A=0 and B=0 for the first call, then kernel properly behaves as there are no dirves.

With Nextor call (_RDDRV, 73h) partitions can't be accesible

After a call to read absolute sector (_RDDRV, 73h) in a partitioned device, if you try to search for "Next FIB", the partition won't be accesible anymore...

That doesn't happen with a DISK-IO (4160h) call with the (_CDRVR, 7Bh) Nextor's call.

DEV_STATUS is called for current drive every time ENTER key is pressed on empty string

If I press ENTER key at the empty prompt of the DOS
A:> (enter)
it queries drive A for disk change status, and then reads its structures if disk was changed.
While it is very good to stay up to date even when nothing actually being done by user or any application, it causes problems with floppies.
Original logic of the DSKCHG is when it is invoked, driver gives past/current status to the kernel and clears its internal flag so that next time DSKCHG is called and device is not changed driver gives information that device was not changed since last call.
For floppies, to read the disk change bit, as well as to clear it internally in the FDD, it is required to start motor and perform a seek operation (see here https://wiki.osdev.org/Floppy#DIR_register.2C_Disk_Change_bit). Thus with current logic, on every spare ENTER key press there will be floppy drive motor on and possible seek operation - this wears the drive and floppy disk out.

Implementing phantom floppy drive in device-based subsystem

As I understood from conversation with Nestor that phantom drive and "Insert the diskette form drive X:" must be implemented in driver for device-based configuration. If DEV_STATUS will be called as polling then it will cause driver to display unexpected "Insert the diskette" messages if DEV_STATUS is called for phantom driver and back.
Thus I need confirmation that DEV_STATUS is called only when kernel wants to perform I/O access of specific logical drive.
In general the message "Insert diskette" and related routines are present in both DOS1 and DOS2 kernels of Nextor, and it would be logical to reuse them in device-based configuration.

Modifications to DOS1 mode to support various media geometries

This is already implemented in the GR8BIT storage subsystem, and it would be beneficial for Nextor to implement it too. I am very interested in it as I want to use Nextor in new version 4.0 of the GR8BIT storage subsystem. This is rather enhancement request than issue reporting. I do not see how I can set the relevant state for this request.

When DOS1 kernel enumerates devices at the label A587E, please install addition routine call to the driver which will return the default copy of the DPB for each drive (if supported) for the mode selected - instead of using hard-coded DEFDPB structure. Alternatively, you can require that call to just copy its target default DPB to the location pointed by DE.

Why it is helpful: returning custom DPB for each allocated drive will allow driver to use its own configuration files (like GR8BIT using EEPROM to store the drive configuration and maximal capacities) to size their drives appropriately - for example choosing FAT size (3 sectors/1.5KB RAM space or 9 sectors/4.5KB RAM size) according to user selected settings. Using driver'supplied DPB will also give it opportunity to have devices of different geometry in the system - e.g. 720K 3.5" drive and 360K 5.25" drive as a starting maximal setting.

You can set it up the same way as you did with the DRV_TYPE: e.g. bit 3 set if driver supports individual initial configuration of the drives/devices.

Maybe it has sense to install this into the DRV_CONFIG call with A=3 supplying C=DOS1/DOS2 mode (as driver must know this info, and it is important for storage configuration selection), and relative drive number at boot time (also very important and identifies what drive to get unique DPB). Supply target location for DPB in DE so that driver on this call, if supporting this function, copies respective drive's DPB in the predefined kernel's working location, and then kernel uses this information to calculate the (maximal) size of FAT for the drive in the memory.

I will give you an example:

• in DOS2 mode the size of FAT does not much matter as all variables are located in the high pages of mapped RAM, thus user may have standard 1.44M disk in 3.5" drive (80/2/18, 9 FAT sectors = 4.5KB of RAM), and standard 1.2MB disk in 5.25" drive (80/2/15, 7 FAT sectors = 3.5KB of RAM). In addition, if HDD is installed, its FAT12 may consume up to 12 sectors (6KB), and in total in this configuration will consume 14 KB of space (I hope I calculated it correctly for DOS2);
• in DOS1 taking 14KB of bank 3 CPU RAM is a lot, leaving approximately only 10KB for BASIC. In this mode user can select drives, with reduced size: so called "compatible-1.44M", with 3 sectors per FAT, but 4 sectors per cluster, and "compatible-1.2M", with 3 sectors per FAT and also increased number of sectors per cluster. Note that this "reduced" mode will also support legacy media geometry - 720K and 360K of both 3.5" and 5.25" drives.

For more information on the possible functionality see my knowledge base article "GR8BIT DN0003: Storage subsystem v.3.0 Manual" here: http://kb.gr8bit.ru/DN0003/GR8BIT-DN0003-Storage-subsystem-v-3-0-Manual.html.

Pressing CTRL-STOP on initialization or OS load hangs/reboots the system

Simple test: create AUTOEXEC.BAT with contents "basic autoexec.bas", and then create AUTOEXEC.BAS file with contents "10 defusr=0:a=usr(0)". This will cause machine to reboot in loop.

When Nextor initializes or loads the NEXTOR.SYS press CTRL-STOP, and machine misbehaves - may hang or reboot.

Problem is not present in MSX-DOS2 as far as I tested, DOS2 properly handles CRTL-STOP by "eating" some display characters (displaying "SX DOS version ..." instead of full "MSX DOS version ...", but saying "***Crtl-STOP pressed" and "Terminate batch file (Y/N)?".

This issue should be very closely related to the one I reported some time ago: when you load OS and run PING.COM, and press CTRL-STOP instead of any other key when it asks, PING terminates abnormally and any subsequent DOS command gives "Redirection error: xxx" where xxx is a garbage characters.

That time I have troubleshooted this PING issue to the PING not restoring original slot in CPU bank 1 (4000-7FFF) before calling CHGET BDOS routine, thus when CHGET gets break character, it jumps to abortion routine, and it then jumps to CPU bank 1 which has incorrect slot and thus unexpected code in it. Either application (PING) must restore slots before making ANY BDOS calls, or abnormal termination routine must ensure that slots are restored before jumping.

I use version with "Nextor BASIC version 2.01 beta 1 2018.03.20", but it was confirmed that issue is present in latest build.

Here's the screen shot for PING issue.

In DOS1 mode files with certain extensions can't be found/loaded

When Nextor 2.1.0 Beta 2 is booted in MSX-DOS1 mode from the DSK image, files with certain characters in their extensions can not be found and loaded by the system. If the files are renamed with a different extension, the problem disappears.

The below ZIP archive contains the video showing the problem and the DSK image that Nextor boots from in DOS1 mode:

http://rbsc.su/files/nextor_bug.zip

The bug is shown on the video time 3:50. Files with '3' and '4' in their extensions can't be found.

NEXTOR 2.1 Alpha-2 bug BASIC MAPDRV

Hi,

I have a megaflashrom + sd and 2 partition of 16M each, created with call fdisk command. In both partitions there are nextor file and msx-dos files.
I’m using nextor 2.1 with msx1 mode and i have a strange issue:

if use in msx-dos2 mode and type:
mapdrv d: 2 1 0

work fine

if use in basic mode (type 1 at boot, so going in msx1 mode) the command:
call mapdrv (“D:”,2,1)

return “Bad drive name” or “Invalid device driver” if used call mapdrv (“D:”,2,1,0)

is a bug?

Best Regards

Can't access read-only files with _RDBLK

Submitted by Keiko Mizuo

Read-Only files can't be read with function 27h (_RDBLK). Changing the value of AT_DEV in line 621 of cpm.mac from 07h to 06h it will solve it. The value of AT_DEV is defined in line 161 of const.inc.

Nextor incorrectly identifies certain keys on MSXs with different keyboard layout

Here's my bug report, it affects earlier Nextor (Alpha), also probably applicable to the Beta. On KYBT and KYBT2 systems (Russian versions of YIS503II and YIS503III) the keyboard behaves differently than on other machines - the number keys are somehow shifted to the right. For example if you press '9' at Nextor's bootup screen, it acts as if '0' is pressed on other machines to stop using the previously assigned bootable image. This makes switching disk images and ignoring booting of the assigned DSK image a bit difficult.

On the Russian Yamaha YIS805 the numeric keys above the alphabetic ones don't work at all, so the only way out is to use the numeric keys on the side of the keyboard (numeric keypad).

I presume Nextor is using scancodes to identify the keys. It appears that on some machines there will be a discrepancy between what the scancode is supposed to get and what the key actually means. This is true for non-QWERTY keyboards like in those on Russian Yamahas. So not only the numbers, but letters could be also affected.

Easy install, with all tools and all help files

Nowadays, creating a new Nextor installation is a confusing process for new users, and I've seen them in trouble all the time.

Not only that, but with the files available at the official site, the user will end up with an incomplete installation that misses all the help files and DOS2 utilities like XCOPY, UNDEL, etc

I understand that when Nextor was originally released, it wasn't possible to distribute such files. But now we have Nishi's permission for doing it, so a complete Nextor installation would be welcome.

It could be just a simple ZIP file with all the necessary files organised in folders like the original DOS2 disks: The folders DOS, HELP, KHELP, APPS, UTILS, etc. All the user would have to do would be to decompress the ZIP file into his SD/CF card.

Also a DSK image could be distributed for floppy media. In this case, I suspect that the KHELP folder might have to be omitted to be able to fit everything in 720KB.

Here's a proposal for the folder structure and AUTOEXEC.BAT

1. Folder structure:

\DOS : All DOS2/Nextor own tools
\HELP : English help files
\KHELP : Japanese help files
\APPS : Any DOS2/Nextor apps that need to be on the PATH
\SCRIPTS : A nice place to put general .BAT files
\UTILS : Complementary 3rd party utilities
\TEMP : Temporary files

2. AUTOEXEC.BAT

rem System Configuration
verify off
set BOOTDRV=%1
set EXPERT=ON
set TEMP=%1\TEMP
path %1\DOS;%1\SCRIPTS;%1\APPS;%1\UTILS
set PROMPT=ON
set DATE=DD-MM-YY
set TABORDER=DIR,FILE
rem buffers 10
rem set TIMEZONE=-03:00

Rem Run TEST.BAT if it's present. Useful for MSX under maintenance when the
Rem keyboard cannot be connected.
IF EXIST %1\TEST.BAT %1\TEST

cls
ver
echo

Nextor freezes if an unpartitioned media is used

Nextor freezes if a media that has no file system yet, and a DIR/W is issued.