DOS ain't dead

Hi,
after years I moved on a little bit with my secondary SuperIO exp. board project attached at LPC bus ( http://rayer.g6.cz/hardware/lpc_sio.htm ), still writing the config utility. Now I tried floppy disk controller that I enabled in the SuperIO block. Problem is that on current test machine I don't have wired the LDRQ# signal yet so FDC has no DMA. SuperIO supports setting FDC in PIO mode but probably most of DOS floppy imaging tools (and DOS itself) rely on BIOS services that use DMA? I don't know it there's such utility that use direct FDC access via PIO (noDMA). I remmeber some old tools like HCOPY, COPYQM, etc. but don't know how they access the floppy...

So for further testing I tried Linux that can work with floppy without DMA and can be forced to found a floppy even if not configured in CMOS/SETUP so I added kernel parameter: "floppy=0,4,cmos nodma messages"
[ 0.628332] Floppy drive(s): fd0 is 1.44M
Then /dev/fd0 appeared in my system and I could try to mount. First time without a floppy inserted. It caused a short sound and LED blinked as expected, getting an error:
[ 71.265686] blk_update_request: I/O error, dev fd0, sector 0
[ 71.268236] floppy: error -5 while reading block 0
[ 71.295694] blk_update_request: I/O error, dev fd0, sector 0
[ 71.298239] floppy: error -5 while reading block 0
Then I tried mount with inserted FAT12-formatted floppy, the motor started spinning, LED light and short head move sound at the beginning appeared but then it enlessly spins and the mount command hanged. Any idea what's going wrong? When I pressed CTRL+ALT+DEL multiple times the system started shutdown and complained about hanged mount that was finally shot down by SIGKILL.
I had a suspection if IRQ works properly but when watched /proc/interrupts it seems it works. Without a floppy the int count increases by 3 and with floppy inserted it increases cca by 5 every second so interrupts are comming properly.

         CPU0       CPU1       CPU2       CPU3
  6:          3          0          0          0   IO-APIC   6-edge      floppy
  6:          6          0          0          0   IO-APIC   6-edge      floppy


---
DOS gives me freedom to unlimited HW access.

Just to be sure it's not a FDD problem I tried with another two 3,5" drives that I previously tested on another PC but it behaves the same (endless motor spinning). So I'd like to twst it under DOS by some floppy tool that don't use DMA if there's any...

---
DOS gives me freedom to unlimited HW access.

> Just to be sure it's not a FDD problem I tried with another two 3,5" drives
> that I previously tested on another PC but it behaves the same (endless
> motor spinning). So I'd like to twst it under DOS by some floppy tool that
> don't use DMA if there's any...
Did you try 765 Debug, which is included in the 2M / 2MGUI package? Search for 2mgui19.zip

Also TestFDC by Dave Dunfield. See: http://dunfield.classiccmp.org/img/

> Did you try 765 Debug, which is included in the 2M / 2MGUI package? Search
> for 2mgui19.zip
> Also TestFDC by Dave Dunfield. See: http://dunfield.classiccmp.org/img/

Thanks. I don't know any of them. I just tried TestFDC and it interacted some way with my FDD and makes a bit crazy fast head move sound but all tests failed

TESTFDC 1.16 - Copyright 2007 Dave Dunfield - All rights reserved.   
BIOS reports drive A: as Unknown.                                   
Testing as: 1.44M HD, 80-track                                       
250k Single-Density: Format !error (0) Overun                       
250k Double-Density: Format !error (0) Overun                       
250k Double/128byte: Format !error (0) Overun                       
500k Single-Density: Format !error (0) Overun                       
500k Double-Density: Format !error (0) Overun                       
500k Double/128byte: Format !error (0) Overun                       
                                                                     
Report on FDC capabilities, issued 28/03/2024 4:55:34:               
Single-Density at 250 kbps ............................ Failed       
Single-Density at 300 kbps ............................ Not tested   
Single-Density at 500 kbps ............................ Failed       
Double-Density at 250 kbps ............................ Failed       
Double-Density at 300 kbps ............................ Not tested   
Double-Density at 500 kbps ............................ Failed       
Double-Density at 250 kbps / 128 byte sectors ......... Failed       
Double-Density at 300 kbps / 128 byte sectors ......... Not tested   
Double-Density at 500 kbps / 128 byte sectors ......... Failed       


---
DOS gives me freedom to unlimited HW access.

2mgui19.zip contains only single file 2MGUI.EXE
Well I found 765DEBUG.EXE and also tried ImageDisk 1.2. It can properly detect disk RPM: 300 and it can seek the heads over disk but any attempt to read/write/format cause "Overrun" error, what does it mean? As there are no source available I cannot be sure it's not trying use DMA.

---
DOS gives me freedom to unlimited HW access.

> 2mgui19.zip contains only single file 2MGUI.EXE
> Well I found 765DEBUG.EXE and also tried ImageDisk 1.2. It can properly
> detect disk RPM: 300 and it can seek the heads over disk but any attempt to
> read/write/format cause "Overrun" error, what does it mean? As there are no
> source available I cannot be sure it's not trying use DMA.

ImageDisk 1.18 sources can be found at http://dunfield.classiccmp.org/img/ as imd118sc.zip. Source code for TESTFDC is included.

This should be enough for your purpose, because readme.txt reads:

1.19 = Updated contact information
       Fix to BIN2IMD which swapped side data in some cases.
1.20 = Fix Format to allow start sector 0

---
Forum admin

> Did you try 765 Debug, which is included in the 2M / 2MGUI package? Search
> for 2mgui19.zip

For the record:
- 765DEBUG 5.0 binary: https://www.sac.sk/files.php?d=14
- 765DEBUG 5.0 sources: http://retro.icequake.net/dob/files/bleuge/765debug/SOURCE/

(The link at https://www.gm.th-koeln.de/~wmsr/sourcen/sources.html doesn't work anymore.)

---
Forum admin

> 2mgui19.zip contains only single file 2MGUI.EXE
> Well I found 765DEBUG.EXE and also tried ImageDisk 1.2. It can properly
> detect disk RPM: 300 and it can seek the heads over disk but any attempt to
> read/write/format cause "Overrun" error, what does it mean? As there are no
> source available I cannot be sure it's not trying use DMA.

ImageDisk 1.20 source is available here (https://dunfield.themindfactory.com/dnldsrc.htm). Dave is active on vogons now but no longer seems affiliated with classicmp.

I could be wrong, but I don't think any standard BIOS implementation would use DMA. The only implementation of DMA I think I've ever used for floppies was the venerable FastBack hard drive backup program. DMA helped the data get transferred to the floppies very quickly.

I know in my USB driver for floppies where you can't use DMA (DMA won't work on USB-attached devices without a LOT of virtualization) and it seems to work fine with the few programs I've tested. As a result, the programs can't be bypassing the BIOS and using DMA. I really don't think your problem is DMA, but I can't say for sure what it might be.

> 2mgui19.zip contains only single file 2MGUI.EXE
> Well I found 765DEBUG.EXE and also tried ImageDisk 1.2. It can properly
> detect disk RPM: 300 and it can seek the heads over disk but any attempt to
> read/write/format cause "Overrun" error, what does it mean? As there are no
> source available I cannot be sure it's not trying use DMA.
You may also try Disk2image:

http://www.oldskool.org/pc/disk2img

I believe the source is also in the download on that page. And, further, this program claims to bypass BIOS entirely.

I'm not sure what "overrun" means, but it sounds not related to DMA.

> - 765DEBUG 5.0 sources:
> http://retro.icequake.net/dob/files/bleuge/765debug/SOURCE/

Thanks, a quick look at sources show it uses DMA and as my FDC (in secondary SuperIO chip) doesn't have routed LDRQ# it cause the timeout/overrun error. So this is why I'm looking for nonDMA (PIO) FDD handling implementation...

---
DOS gives me freedom to unlimited HW access.

> ImageDisk 1.20 source is available here
> (https://dunfield.themindfactory.com/dnldsrc.htm).

Thanks, dtto for 765DEB, this program uses DMA too - not usable for my case.

---
DOS gives me freedom to unlimited HW access.

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.

---
DOS gives me freedom to unlimited HW access.

Maybe here could be some DOS floppy code which does not rely to DMA
https://github.com/joncampbell123/doslib/tree/master/hw/floppy

---
DOS-u-akbar!

> Maybe here could be some DOS floppy code which does not rely to DMA
> https://github.com/joncampbell123/doslib/tree/master/hw/floppy

Hm, doslib, I downloaded this huge package some months ago but didn't have time yet to discover whats's all inside, seems to me a bit kludgy...

I just opened floppy.c and at the beginning of file I see
#include <hw/8237/8237.h> /* DMA controller */

this doesn't persuade me that this code don't use DMA...

EDIT: there seems to be maybe something nondma too:
floppy_controller_wait_data_write_non_dma_ready()
it will need a closer look. Maybe that code implements both DMA and non-DMA modes...

---
DOS gives me freedom to unlimited HW access.

> Maybe here could be some DOS floppy code which does not rely to DMA
> https://github.com/joncampbell123/doslib/tree/master/hw/floppy

Yes, you was right, this supports also noDMA mode, thanks!

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

EDIT:
This may be the source of problem:
static inline int floppy_controller_wait_data_ready(struct floppy_controller *fdc,unsigned int timeout) {
        do {
                floppy_controller_read_status(fdc);
                if (floppy_controller_data_io_ready(fdc)) return 1;
        } while (--timeout != 0);

This is called in CLI block with value 1000, maybe my PC is too fast :P (limited just by inp I/O speed)

---
DOS gives me freedom to unlimited HW access.

> I could be wrong, but I don't think any standard BIOS implementation would
> use DMA. The only implementation of DMA I think I've ever used for
> floppies was the venerable FastBack hard drive backup program. DMA helped
> the data get transferred to the floppies very quickly.

Actually, floppy diskette access seems to be a case where it's normal for the ROM-BIOS to use ISA DMA to access the disk. Consider the description of the int 13h error code 09h:

> 09h data boundary error (attempted DMA across 64K boundary or >80h sectors)

Why should this tell us we "attempted DMA" across a boundary if the ROM-BIOS didn't usually use DMA?

---
l

> Actually, floppy diskette access seems to be a case where it's normal for
> the ROM-BIOS to use ISA DMA to access the disk. Consider
> the
> description of the int 13h error code 09h:

Yes. But it seems there was a few implementations of BIOS that didn't use DMA, I read that some HP Omnibook. That was probably the reason why Linux kernel floppy driver implemented both DMA and noDMA methods. So it's possible, I got it working under Linux (some floppies had problems but it's probably caused by theirs age).
I'm still looking for reliable noDMA implementation that can be used under DOS. Linux floppy driver has some depencies to Linux kernel and code pointed by Laaca from the doslib works very unreliable. I didn't have time to debug it yet...

---
DOS gives me freedom to unlimited HW access.