FDC interrupts are time-critical. There is no FIFO there, you either fetch the byte in time as it comes or you just lost your sector read. Same with write.
Most modern OSes are optimized for multithreading, not interrupt latency. In other words these are not real-time control systems. You might think the CPU is fast enough but keep in mind any I/O on a modern system goes through layers of arbitration, starting with the OS kernel and ending with low-level bus access.

In ye olde days you could run Z80 CP/M system with non-DMA FDC, but:
- the CPU was basically in a tight loop a couple instructions long, polling the I/O (status and data registers, and _maybe_ a timeout counter)
- for single density media you'd need 4MHz but double density required shorter CPU cycles so 8MHz
- code would often not do any timeout checks (no spare cycles for that) and just hang if the transfer didn't come through completly
- interrupts might have to be disabled, sometimes the screen was blanked to prevent CRTC from stealing memory cycles

What you want to do might be possible in DOS, with fast enough CPU (but again keep in mind anything above Pentium is still limited by I/O bus speed), when there's just one program running and possibly minimal interrupts. But that is hardly connecting legacy devices to modern OS. For that you have to approach it like the USB floppy drives - there's a local MCU that can deal with the transfer timings and it presents itself to the OS as USB mass storage device. Even that might be hard to pull off with single-core MCU without dedicated logic for the "DMA" since USB also requires some reasonable latency, you can't be waiting in the sector loop and ignoring USB bus, the OS might not like it and kick you.

Yes, I'm aware about this general problems but I intend primary use the floppy under DOS that is single thread and I could even disable interrupts and just polling. There already existed noDMA floppy implementations in some HP Omnibook so maybe that was reason why Linux implemented nodma in floppy driver. Btw Linux in not realtime as is without enabling some RT extensions...

Well, I found that I passed linux kernel cmdline parameters wrong way to linld.com.
it shouldn't be
"floppy=0,4,cmos nodma messages"
but
"floppy=0,4,cmos floppy=nodma floppy=messages"
Then linux booted really in PIO (noDMA) mode and I was finally able to mount and read floppies 😀 A lot of them thrown bunch of various errors in dmesg but some read/write without any error. So I tested that my superIO HW solution works. Now I'd like to make it work under DOS too. It would be a challenge to write a TSR for int13h extension that use floppy nodma code so other dos apps could use via bios services to access floppy in std. way.

Thanks to user Laaca who pointed me the right direction to a DOS FDC test utility that can run with and WITHOUT DMA!
https://github.com/joncampbell123/doslib/tree … aster/hw/floppy

I tried to run test.exe and for some reason it detected DMA 2 enabled by default but it can be disabled in the menu. Then I tried seeking and reading a sector but unfortunatelly it was very unreliable (for sure I tried with a floppy that I tested under Linux it reads OK without any errors). Sometimes I got simply "NDMA read failed -2 (d0h)" error and zero data. Sometimes it read a sector but not full. It usually reads a range of 450-510 bytes and it was messed up at first look (the strings in bootsector). Every read attempt got a different number of readed bytes and different content. I also tried to disable interrupt in the menu and tried again but nothing changed, same mess. So this code would do what I need but it's useless for real use. But still may be good as a reference alongside linux floppy driver to learn something from it. It would take some time...

http://rayer.g6.cz/1tmp/fd1.jpg
http://rayer.g6.cz/1tmp/fd2.jpg