Int 13h buffer 64k boundaries (was: 8085 Dissasembly?

On Wed, 18 Apr 2018, Charles Anthony wrote: I'm learning a lot these days that would have been handy back then! Segment:Offset hides it until you normalize the resulting address. IIRC, INT13h should return a code of 09h if the DMA straddles a 64K boundary. But, not all code checks for that, or knows what to do when it happens. Looking at the value of ES:BX? can work, or, if it happens, swap your DMA buffer with one that is not used for DMA (and doesn't happen to be 64K away :-) In my code, I happened to have buffers for several purposes, so that was easy to do. If operating above Int 13H (DOS calls), then you are dependent on DOS error checking. "Can you trust THAT?" If operating below Int 13h, then be careful where your DMA ends up, work without DMA, or simply watch for occurrence. And, of course, a lot of C code can't tell the difference between end of file and a disk error. #define EOF (-1) /* depending on implementation */ while ((ptr2++ = fgetc(fp2)) != EOF); /* does not differentiate between error and end of file */ fgets() returns a null pointer for EITHER end-of-file OR error! and therefore assumes total reliability and any failure to read is assumed to be EOF. IFF available, feof(fp2) is much better. You certainly did the right thing, narrowing it down to load address. The final conclusion would have been to systematically try many/all load addresses, and see whether it was consistent for given ones, and what the failing ones had in common. Yes, the "solution" for the extraneous FORMAT failure was "add or remove TSRs and device drivers"! When I first hit it, I used a P.O.S.T. card, and put in minimal code to output values until I realized that DS was the key, and that I had mishandled error #9. Eventually I realized that even for code not my own, I needed to write a TSR intercepting Int 13H calls. (For exampole, the critical error handler in certain early versions of PC-Tools was more concerned with protecting their pretty display than success of writes!) Microsoft's response to error reporting was amusing. I was in the Windows 3.10 Beta, and encountered the SMARTDRV write caching problem. There was apparently a flaw on one of my drives, that neither SPINRITE nor SSTOR could find. But, during Windoze installation, a write would fail, and with write caching ON (Windoze installation did NOT give you a choice), there was no way to recover from a write error! (SMARTDRV had already told SETUP that it had been successful, so now, when the error occured, there was no way to (I)gnore the error (figure out which file copy had failed, rename the failed copy "BADSECS", and go back later to copy that one manually). All you could do was (R)etry which didn't work, or (A)bort, which cancelled the entire setup before it ever wrote the directory entries for the files that had worked. By loading a bunch of space filler files on the disk, I was able to get the installation to be in a working area. Once I finally determined WHERE the bad track was, I put in a filler file to keep it from being used. (SPINRITE tried to return it to use when I just marked it as BAD!) Microsoft's response was, "YOU have a HARDWARE problem. NOT OUR PROBLEM." I was unable to either convince them that CORRECT response to a hardware problem was a responsibility of the OS, NOR that SMARTDRV with write-caching was going to cause a lot of data losses that they would get blamed for, inspite of it not be narrowed down to SMARTDRV, and that it would end up costing them a lot. Sho'nuff, COMPRESSION got blamed for the data losses. DOS 6.2x had to be put out for FREE to fix "the problems with compression". The "problems with compression" were fixed by having SMARTDRV NOT default to write caching ON, have SMARTDRV NOT rearrange writes for efficiency (it wasn't writing DIRectory sectors until later), and having SMARTDRV NOT returning a DOS prompt until its buffers were emptied. (One of the common losses was people would save a file, and turn off the computer as soon as the word processor came back to the DOS prompt. SMARTDRV had not finished writing their file! When my girlfriend went back to school for some classes, she would stand with her coat on, pulling on the paper as her homework printed, then kit ^KD? and turn off the computer.) I was not invited to be in the 3.11, nor WIN95, Betas. They wanted cheerleaders, not testers, anyway. -- Grumpy Ol' Fred cisin at xenosoft.com