I think there is another potential issue with INT26. As it uses dskxfer() directly, block cache entries containing written sectors might not be invalidated. Invoking DeleteBlockInBufferCache() inside the INT26 handler to invalidate the buffers might fix this?
> Am 01.06.2025 um 14:48 schrieb Eric Auer via Freedos-devel > <freedos-devel@lists.sourceforge.net>: > > > Hi Bernd, > > I am not sure whether the boot sector should get > a special treatment either. > > In any case, I would only do media_check if the > I/O free get_dpb has failed. > > Also, I think the kernel tries to init all drive > DPB and CDS data at boot. If this would work, you > would not have to do this check in int 25 / 26. > > On the other hand, floppies are special, as they > can be taken out of the drive and changed etc. :-p > > Makes me wonder which strategies other DOSes use. > > Regards, Eric > > > >> The handler does not check if sector zero has to be read / written. But I >> think it should, and bypass the check for FAT32 etc, as access to sector >> zero probably means reading / writing a new BPB. >> As a test I altered the handler to call media_check() if sector to be read / >> written is NOT sector zero, and bypass the FAT32 check for sector zero. Has >> fixed the problem for me. >> I am not sure if it is a good idea to call the media_check() for all >> INT25,26 calls, as this should result in an additional driver call for every >> INT25,26. >> [1]: >> https://github.com/FDOS/kernel/blob/654e7b7a6c244c81ff8ef1d39a5fb07608e3d07a/kernel/inthndlr.c#L1809 > > > > > > _______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
