BIOS Disk Read/Write Error

[dncprogrammer]

Thanks in advance,
I have been working on several little asm programs to read and write a floppy with BIOS INT13h and I get an error the first time that I execute a read or write but the second time it works. Ok, now I understand that this means the first time the drive isn't ready and I am missing a step. Can anyone put me in the right direction?
Thank you again.
jon

[MichaelW]

If the function returns an error you should retry the operation several times, resetting the drive controller between tries. I code for four tries, exit the loop on the first success, and fail if the error persist through the fourth try, or if the function call to reset the drive controller fails.

[dncprogrammer]

Thank you Michael,
The reason why I posted this question is that I have read in my interrupt lit that the Disk Reset function for 13h is no longer supported and it seems like the drive engages quite abruptly when it does the actual read/write. I was concerned that I might be missing a step in the process such as waking the drive up properly or something. I have been studying asm for about 6 months now and there are some concepts that I have trouble finding information on. One of these has been proper read or write initiation. I will try to read the the return register and repeat the operation based on it's value. Thank you again.
jon

[Tedd]

Ignore the return value in ax - it's unreliable, and often set to zero when successful.
Just check the status of the carry flag - if it's set, there was an error; if not, successful.

[dncprogrammer]

Thanks Tedd,
I am still wondering if it is true that the diskette reset function of INT13h actually does anything or not. It is good practice to include it in any condition?
jon

[Tedd]

I would include it. I can't see why it wouldn't be supported, but it should do no harm. Even if it does nothing on newer bioses (doubtful), it will still work for older ones.
All it's really meant to do is move the disk read head to 0, which allows the controller to callibrate to the inserted disk.

[dncprogrammer]

You guys are great,
I haven't had anyone to talk to about this assembler stuff. Things are going to be moving much more smoothly now. Thank you!
jon

[skywalker]

You guys are great,
I haven't had anyone to talk to about this assembler stuff. Things are going to be moving much more smoothly now. Thank you!
jon

Your welcome to have most of my 16 bit code if you like.

It's pretty well commented and runs the gamut from intros, utilities, some simple games, tsrs, and the like.

Outta here.

[dncprogrammer]

Thank you as well,
I have embarked on a personal mission to write x86 assembler for reasons unknown. I have been programming for a long time but this is a slightly different world. I can't get enough of it. I scour the internet for sample code to see how each different writer implements things, such scope! I am working on a really basic operating system type of thing. Im not a sparkly-eyed kid who wants to take over the world but I have done a bit of DOS programming and I want to see what the machine is like when Im in control. Any BIOS heavy code, mathematics code, and anything on writing & placing ISRs would be great. That is the level that Im currently at. I have read extensively on writing ISRs but I haven't sat down to try it yet. Im still working on my functions outline but moving forward quickly! Thank you so much! So glad I joined.
jon

[MichaelW]

Under Windows 2000, if I start debug, set up code to call interrupt 13h with ah=0 and dl=0, and then trace through the call it never reaches the BIOS. Instead, this is what I get before execution continues back in my code in debug:

Code Select Expand


AX=0000  BX=0000  CX=0000  DX=0000  SP=FFE8  BP=0000  SI=0000  DI=0000
DS=0B07  ES=0B07  SS=0B07  CS=0210  IP=045D   NV UP DI PL NZ NA PO NC
0210:045D 80FA80        CMP     DL,80
-t

AX=0000  BX=0000  CX=0000  DX=0000  SP=FFE8  BP=0000  SI=0000  DI=0000
DS=0B07  ES=0B07  SS=0B07  CS=0210  IP=0460   OV UP DI NG NZ NA PO CY
0210:0460 7228          JB      048A
-t

AX=0000  BX=0000  CX=0000  DX=0000  SP=FFE8  BP=0000  SI=0000  DI=0000
DS=0B07  ES=0B07  SS=0B07  CS=0210  IP=048A   OV UP DI NG NZ NA PO CY
0210:048A C4C4          LES     AX,SP
-t


I assume that this is the NTVDM blocking the call in an effort to protect the system. If I repeat the process from an MS-DOS 6.22 boot diskette, the call does reach the BIOS, executing several thousand instructions there, including several hundred I/O instructions. So basically the function is not supported by the more recent versions of Windows (IIRC it was under Windows 9x). My system is 5-6 years old, but I would be very surprised if support has been dropped from the later BIOS's because doing so would interfere with the system's ability to run DOS, Windows 9x boot diskettes, etc.

[dncprogrammer]

Thats interesting. I have an interrupt list that simply said that function 0 was no longer supported, Im sure that could have meant under certain operating systems. I went ahead yesterday and add a 4 try counter to my disk write code including a reset for every retry and it worked perfectly. I actually went into my other programs that access disk and added the 10 lines of code and everything works properly now. I see my projects really moving from here on out.
Thanks a million,
jon

[Tedd]

I think most of the disk i/o ints are replaced by windows simply to avoid contention. So of course, resetting the disk should do nothing -- if another process is using it, it's not a good idea (for that process at least) -- so windows will take care of doing the reset when appropriate (after a non-access timeout.) Therefore any call to reset should basically be eaten by the os.
I doubt any int13 call from windows will reach the bios, but are implemented by windows.

On the bios side, int13,0 will reset the disk, since the only process running is the actual one requesting the reset.

[MichaelW]

I doubt any int13 call from windows will reach the bios, but are implemented by windows.

Yes, I verified this under Windows 2000 by setting up in debug a call to read the boot sector of the first diskette drive and tracing through the call. The call never reaches the BIOS, but the call does succeed. I seem to recall under Windows 9x that such a call will reach the BIOS, or at least what appears to be the BIOS. Under Windows 2000 if I change the selected drive to 80h, I get a dialog with:

16 bit MS-DOS Subsystem

An application has attempted to directly access the hard disk, which cannot be supported. This may...