Konamiman / Nextor

A disk operating system for MSX computers, forked from MSX-DOS 2.31
Other
183 stars 35 forks source link

Nextor fails in DOS1 mode #52

Closed Eugeny1 closed 4 years ago

Eugeny1 commented 4 years ago

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.

DSCN2263-1

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:

DSCN2260-1

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

Eugeny1 commented 4 years ago

Attached is the source code, ROM and kernel used for the test driver.

Nextor-issue-52.zip

Here's the list of routines and their addresses (Nextor subslot ROM page 7): 4296 DEV_IN 41FD DEV_RW 4299 DEV_ST 419C DRV_CO 416D DRV_IN 42A1 LUN_IN

Here's the picture of failure:

nextor-issue-52

Input parameters to the DEV_RW: A=1 (device ID) F=9 (write operation) C=1 (LUN ID) B=1 (one sector) HL=EDAB (buffer containing data) DE=pointer to LBA of 0000F9C3.

The image provided to the Nextor is floppy disk without VOL_ID tag (forced DOS1 mode), with number of sectors=5A0.

The same test driver can be used to reproduce "No enough memory" problem: put breakpoint at the DEV_CO routine, start emulation, press '1' key, when machine gets to DEV_CO, change B from 01 to 00 (no drives at boot time), and continue emulation. You will get the "No enough memory" and system halted.

Konamiman commented 4 years ago

I've been able to reproduce the "No enough memory" error. It happens with any driver when all of the following is true:

  1. The Nextor kernel is the only one in the system (so no internal FDD or other Nextor/DOS kernels)
  2. Booting in DOS 1 mode
  3. Either DRV_CONFIG is implemented and returns B=0 when A=0 is supplied, or it's not and LUN_INFO always returns an error (so no drives are automapped).

So in sum, DOS 1 chokes if there are no drives at all defined.

Konamiman commented 4 years ago

As discussed, I won't fix this as the original MSX-DOS 1 kernel displayed the same behavior.