Call to BDOS from the DOS2 driver ends nowehere

[Eugeny1]

I am trying to create new file from the driver code (page 7), to be exact within the CALL statement handler:

ld	c,16h
ld	de,FCB
call	_BDOSC			; call BDOS - create file

...

_BDOSC:
	exx
	ld	hl,XF37D
	ld	(CODE_ADD),hl
	exx
	jp	CALLB0

This code causes Nextor calling driver in the page 7 routine LUN_INFO a number of times, looking like it tries to get statuses of all the devices attached (like Nextor does during initialization). LUN_INFO returns A=1 (error), and at the end Nextor kernel "returns" to the address 0ffffh without restoring the stack.

Note: CODE_ADD in the driver template I use has address of 0F1D0h, while online documentation states that must be at 0F84Ch. Tracing the code I see that 0F1D0h must the correct address though.

More technical information: driver returns A=1 for DRV_CONFIG (as real hardware is not available in emulation), and Nextor allocates no drives for its driver (mode is DOS2). When I perform SAVE"A:ASD" in BASIC, it accesses machine's built-in floppy drive, thus Nextor is operational through another disk ROM from BASIC. Nextor is in slot 3.1, built-in DOS1 controller is in slot 3.3.

Update: if I move code from the "JP CALLB0" location to 0c000h, and perform CALL F37D from this location (thus call has the same input data), the call returns properly with error (A=1) as expected. Thus there's something wrong with the CALLB0 mechanism, or I do something wrong.
No, I am wrong, It performs the same and execution ends up in the same nowhere place even if BDOS is called from RAM and with pages 0/1 switched in the Nextor mapper (ASCII8 mapper). I can not believe it as this function "create file [fcb]" must be used very frequently by the system or applications.

Update:. when I perform SAVE"file" from BASIC with Nextor kernel in effect it uses function 44h "create file handle" rather than function 16h.

Update: if I invoke this function in the binary using BLOAD it works properly creating the file on the functional device or returning expected 0xff for missing device. Would the problem be caused because I invoke it from DRV_BASSTAT?

Some progress here. I am using openMSX to troubleshoot the problem. My setup is Nextor in slot 3.1, and internal disk ROM in slot 3.3. Nextor's BASSTAT returns error (0x01), as well as all other routines return error as storage microcontroller is not available.
A: is being attached to the the internal disk drive (driver in slot 3.3), no letters are attached to Nextor (this is normal).

Now to the tech details:

• if internal drive is having diskette in it when I invoke function 016h with drive identifier 01h (drive A:), then file is being properly created on the diskette.
• if internal drive does NOT have a diskette when I invoke function 016h, Nextor kernel ends up in its internal driver routines (for non-existent device attached to the Nextor) after trying to access the inaccessible floppy media.

Thus the problem has something about error handling for the inaccessible device (in this case - floppy).

This has been tested on another driver, behavior is the same: as soon as function 016h is invoked for internal driver-attached device returning error (e.g. missing disk in the floppy drive), call ends nowhere inside the Nextor kernel, causing machine to crash.

Final general test for the the issue: running the driver invoking function 016h from BASSTAT I inserted floppy disk into internal drive, and it properly created target file on the floppy.

[Eugeny1]

Thank you for the fixed code. Now system does not crash, but there's still a problem: in case of disk error (e.g. write protected or disk missing in the drive) the execution goes to the BASIC error handler and terminates into BASIC prompt with respective message "Disk offline" or "Disk write protected" instead of returning to the BDOS caller with A=0ffh (error condition).

[Konamiman]

Fixed in v2.1.0 (please open a new issue for last comment)