Use Turbo Debugger and put a breakpoint before calls to BIOS. Then, find what is really going into the BIOS calls (the exact contents of registers) and what returns the BIOS. Keep in mind that some device controllers and programs may intercept INT 13, and that virus protection in most BIOS may be triggered when trying to read some sectors.

If you're still puzzled about the results, post pieces of code, and what happened when you ran the code.

About games not working, PROTECTED games not working... back in DOS, some games (Comanche Maximum Overkill, for example) refused to work if there was EMM386 running on the computer, complaining about VM86 mode. Try combinations of no memory manager, only XMS, only EMS and XMS+EMS, because not all games behave as nicely as Doom.

you could post here either the minimum binary or the source and then we might be able to pinpoint the problem.

What I don't understand is the fact that the code worked perfectly under windows 98 DOS.

This is what I cam currently thinking. I'll bet windows 98 is not giving me the real int13h - it may even be replacing BIOS code with its own equivalent.

Is it not possible that as motherboards advanced, int13h changed sufficiently so that it no longer works the same? Using windows one might not every notice.

But of course the problem with that theory is that why would the floppy drive work at all? DOS has to be calling int13h to access the floppy.

The other possibility is an incompatibility with the CPU - pentium 3 came LONG after dos.

I did an experiment and tried the program with an AMD K6-3/450 CPU - even downclocked it to 200 - the program still didn't work.

There are at least two potential issues when reading sectors from floppy drive that I can think of: stepper motor startup delay, and segment overflow in ES:BX buffer. If you are trying to read a floppy disk sector in a single BIOS call, INT 13h may fail if the stepper motor didn't reach its maximum rotation speed. You should make several calls in a row (say, 3 to 5 tries) before accepting the error codes returned in CF and AH as actual reading errors.

The second issue may arise if you are trying to read too many sectors in a single BIOS call. For example, if you want to read more than 128 sectors, and sector size is 512 B, you would need a buffer that is larger than 64 KB. This will cause a segment overflow, and a BIOS read fail in some systems. If the buffer isn't located at the start of ES segment, the number of readable sectors in a single BIOS call will be even lower. I would try a conservative value, say 18 sectors (the number of sectors per track in a 1.44 MB floppy).

I appreciate all the feedback 😁

I had read about the stepper motor startup and did try calling the routine several times

And I was trying to read only one sector. I was setting up the video screen (b800h) as the buffer, ES=B800h

Actually in the original program I was reading it into A000H and then copying into into B800h because of the way the character and attribute bytes alternate

Like I say - it worked in windows 98

The light comes on, the drive spins up - but that is all

But - there is MORE. I had a very simple program working. I add PROC and END PROC calls - and suddenly it crashes.

There is something very funny going on here. I wonder if my DOS had a virus.

Just PROC and ENC PROC, with no RET? Sorry if it sounds too obvious, but without reading the source code, I can only take a shot in the dark. Besides, using screen buffer as I/O buffer looks a bit messy to me. Why don't you just allocate a proper buffer in DATASEG, make ES=DS and then call INT 13h?

you might have a programming bug that was hidden under win98.
like setting up a proper stack or something like that.

> I was setting up the video screen (b800h) as the buffer, ES=B800h

This is a *very* bad idea for floppy disk reads - because FD I/O uses (legacy) DMA. You must use standard conventional memory and, to be absolutely safe, you should ensure that your buffer doesn't cross a 64 kB border!

Like I say - it worked in windows 98

Haha.

Just something else, do you actually use END PROC in your code? Because I looked it up in Tom Swan's Mastering Turbo Assembler, and the TASM directive to end a subroutine is ENDP. If you used END PROC, your program may terminate abruptly and crash because there's no code to return to DOS. Again, this is another shot in the dark. Posting your code would be more useful.

I want to thank everyone who made comments or offered suggestions here.

I finally did get the program to work - by reserving a block of memory and having the BIOS call dump it there (as opposed ti dumping it directly to screen memory)

Also - I believe the problem with PROC and ENP was actually due to the improper calling of a DOS function.

Anyway - the program works. You can pull in any sector off a floppy disk, alter it, and write it back. It has about 1000 lines of code and was written in pure assembly 😁

Now, I am working on a program to read and decode the FAT 😁