I built a disk using the beta6 full.img.
I am using a program that builds an image file from diskette.  It
reads in an entire track using int 13 at one time (36 sectors) on a
1.44mb floppy disk.
This works great when I boot FREEDOS from a diskette, but if I boot
FREEDOS from a hard drive then the reads fail.  Only if I drop the
number of sectors down to 30 will it be able to successfully read.
There must be a bug in freedos when it is booted from a hard drive
that causes this.
Thanks,
Alan

Subject: probably DMA issue

FREEDOS does not affect INT13 at all; this is a BIOS issue.
That said, other DOSes put a filter before INT13 to transparently
work around DMA issues. So this is a bug.
What these DMA issues are:
a floppy r/w operation may not cross a multiple of 0x10000 in absolute
memory. So you can't read from 1FFF:0000 as 16 bytes ahead lies a
boundary.
Bart

Update: Bart tells me that if you use int 21h or "int" 25h/26h,
newer kernels do work around DMA boundaries, but int 13h is
still left to the BIOS (where it should be, IMHO). I am tempted
to call this bug invalid :-).

Eric.

Bart comments that the bug is NOT invalid: MS DOS does hook
int 13h (BIOS disk handler) to make sure to catch all disk
change events AND to transparently work around DMA problems
for the user. FreeDOS only works around DMA problems in "int"
25h / 26h but does not hook int 13h. Maybe we can move the
DMA workaround code from where it now (2032a) is into an int
13h handler.

is this bug related to VDS support in EMM386?
I'd have to test using MSDOS to confirm

(In reply to comment #1)
> Subject: probably DMA issue
> FREEDOS does not affect INT13 at all; this is a BIOS issue.
> That said, other DOSes put a filter before INT13 to transparently
> work around DMA issues. So this is a bug.
> What these DMA issues are:
> a floppy r/w operation may not cross a multiple of 0x10000 in absolute
> memory. So you can't read from 1FFF:0000 as 16 bytes ahead lies a
> boundary.
> Bart

Gentlemen, this bug & that which I've reported (1952) I believe are related.  I
call it a bug because a) other versions of dos, including Udo Kuhnt's DrDos
(openDos) & MSDos filter the DMA boundary error; & b) because it affects the
functionality of FreeDos in terms of its usefulness in the field of computer
forensics.  Whether or not that use is acknowledged on the homepage (& it
isn't) there are many parts of a computer forensics examination which should be
performed in a non-Windows operating system to minimize the possibility of
accidental disk writes.  FreeDos could prove very useful for forensics work but
not until this issue is fixed.

I do some programming, gentlemen, but have never really delved into the guts of
an operating system.  By the time I could figure out how to fix this, I'd
probably be retired long since.  Could someone please help me out here?  I'd
happily test whatever anyone comes up with.

BTW, I happen to be totally blind now & I love the way FreeDos works w/my
screenreader.  Floppy access is slow & this DMA boundary issue is a pain, but
FreeDos really is nice.

Thanks for any help u guys can give.
Jackie McBride

(In reply to comment #1)
> Subject: probably DMA issue
> FREEDOS does not affect INT13 at all; this is a BIOS issue.
> That said, other DOSes put a filter before INT13 to transparently
> work around DMA issues. So this is a bug.
> What these DMA issues are:
> a floppy r/w operation may not cross a multiple of 0x10000 in absolute
> memory. So you can't read from 1FFF:0000 as 16 bytes ahead lies a
> boundary.
> Bart

Gentlemen, this bug & that which I've reported (1952) I believe are related.  I
call it a bug because a) other versions of dos, including Udo Kuhnt's DrDos
(openDos) & MSDos filter the DMA boundary error; & b) because it affects the
functionality of FreeDos in terms of its usefulness in the field of computer
forensics.  Whether or not that use is acknowledged on the homepage (& it
isn't) there are many parts of a computer forensics examination which should be
performed in a non-Windows operating system to minimize the possibility of
accidental disk writes.  FreeDos could prove very useful for forensics work but
not until this issue is fixed.

I do some programming, gentlemen, but have never really delved into the guts of
an operating system.  By the time I could figure out how to fix this, I'd
probably be retired long since.  Could someone please help me out here?  I'd
happily test whatever anyone comes up with.

BTW, I happen to be totally blind now & I love the way FreeDos works w/my
screenreader.  Floppy access is slow & this DMA boundary issue is a pain, but
FreeDos really is nice.

Thanks for any help u guys can give.
Jackie McBride

This bug is duplicated in bug 1952,
so the workaround mentioned there
should also help for this bug 698:

www.coli.uni-saarland.de/~eric/lowdmaplus.zip

(a small TSR based on UMBPCI LOWDMA)

Eric

*** Bug 1952 has been marked as a duplicate of this bug. ***