Nextor device based driver, 32-bit sector number?

Champion (365)

25-02-2021, 18:06

I am converting a dos 1 based disk driver to a Nextor device based one. So far it is going well, I already get a directory listing
For reading / writing sectors, Nextor supplies an address in DE where a 32-bit start sector number is stored.
I guess it uses the normal little endian format where sector 1 is stored as:

01 00 00 00

and sector 0x12345678 as

78 56 34 12

I thought this was a nice way to increase the sector number when multiple sectors have to be read at once:

inc_sector:
    ld iy,00h
    add iy,de
    inc (iy+00h)
    ret nz
    inc (iy+01h)
    ret nz
    inc (iy+02h)
    ret nz
    inc (iy+03h)
    ret

Using this made things worse. Now I am not even getting a directory listing anymore.
What am I doing wrong? Should a leave the original start sector alone?

Для того, чтобы оставить комментарий, необходимо регистрация или !login

By Pencioner

Scribe (1351)

25-02-2021, 19:00

small optimization maybe

push de
pop iy

for faster loading of de value to iy
but i can't tell you about sector number... maybe you shouldn't touch it, because Nextor relies on its value so if you change it you screw it up

By lintweaker

Champion (365)

25-02-2021, 19:48

Case closed! Nextor really does not like it when you touch the original start sector. I now use a local copy and the system now happily boots to Nextor DOS2!
Maybe this feature is already somewhere (hidden) in the Nextor docs...

By konamiman

Paragon (1116)

26-02-2021, 09:24

Hi. I see that the documentation of DEV_RW (https://github.com/Konamiman/Nextor/blob/v2.1/docs/Nextor%20...) is indeed not specifying that the 32 bit sector number must be stored in little endian, sorry about that.

About the issue with changing the sector number buffer: I didn't really remember about it so I took a quick look at the source and I see that indeed, the Nextor kernel relies on the value of the sector number supplied to DEV_RW to be unchanged since it's used while scanning for suitable partitions (as a pointer to the current one being examined). It's indeed not documented and perhaps this shouldn't be the case and a separate temporary buffer should be used instead, but for now, be aware that this bug/"less than optimal behavior" is indeed there. :)

By lintweaker

Champion (365)

26-02-2021, 09:49

Hi, thanks for the heads up!
With the provided template and sample drivers the porting effort was very doable.

btw 'DRIVER.ASM' example contains two small issues preventing it from assembling properly (at least with the default M80/L80 combo).
https://github.com/Konamiman/Nextor/blob/v2.1/docs/DRIVER.ASM
line 24 and line 556.