Nextor device based driver, 32-bit sector number?

Door lintweaker

Champion (402)

afbeelding van lintweaker

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 Smile
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:

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

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?

Aangemeld of registreer om reacties te plaatsen

Van Pencioner

Scribe (1423)

afbeelding van Pencioner

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

Van lintweaker

Champion (402)

afbeelding van lintweaker

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

Van konamiman

Paragon (1131)

afbeelding van konamiman

26-02-2021, 09:24

Hi. I see that the documentation of DEV_RW ( 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. :)

Van lintweaker

Champion (402)

afbeelding van lintweaker

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).
line 24 and line 556.