Hi Alain,
I don't reallyknow, IIRC there is a timeout or idle detection for
flushing. It did not impact speed as a do-not-flush would do
It greatly improved databade system stability
As far as I know, both FreeDOS kernel and caches for it never
buffer multiple writes, waiting to flush them
I don't reallyknow, IIRC there is a timeout or idle detection for
flushing. It did not impact speed as a do-not-flush would do
It greatly improved databade system stability
Alain
Em 27/02/2025 19:02, tom ehlert via Freedos-devel escreveu:
Hallo Herr Alain Mouette via Freedos-devel,
am Donner
> That makes me wonder: what is the realistic datarate of a 1,5 MB/sec UHCI
> connection? Is it really 1,5 MB of transferred data or more like 1/3 of that
> (0.5MB/sec) as is the case in USB 2.0?
It is similar to USB 2 in that respect, but USB 1 is even a little less
efficient than USB 2 in some
Hallo Herr Bret Johnson via Freedos-devel,
am Freitag, 28. Februar 2025 um 00:52 schrieben Sie:
>> FreeDOS is much more stable then MS-DOS due ot:
>> 1) Eric Auer did a nice job flushing files to disk which lowered considerably
>> power failure problems
>> 2) It is much better then MS-DOS for com
> Are you sure about the non 512 byte sector support?
> The fake RAM disk that I show when a NetDrive drive letter is not connected
> uses four 64 byte sectors and FreeDOS can read it just fine. FreeDOS Chkdsk
> is
> limited to only working on 512 byte sector devices, but normal reads from the
>
> Yes. With the tiny little difference that we have one broken machine, and no
> broken hypervisors.
Incorrect. We have a case of a _class_ of broken machines (technically, broken
CMS's). The fact that Laaca took the time to isolate the problem on his
machine doesn't mean his machine is the on
Hallo Herr Kirn Gill II via Freedos-devel,
am Donnerstag, 27. Februar 2025 um 23:34 schrieben Sie:
> Isn't this the same argument I made for broken hypervisors?
Yes. With the tiny little difference that we have one broken machine, and no
broken hypervisors.
Tom
> --
> Kirn Gill II
> Mobile:
Are you sure about the non 512 byte sector support?
The fake RAM disk that I show when a NetDrive drive letter is not connected
uses four 64 byte sectors and FreeDOS can read it just fine. FreeDOS
Chkdsk is limited to only working on 512 byte sector devices, but normal
reads from the RAM disk wor
> FreeDOS is much more stable then MS-DOS due ot:
> 1) Eric Auer did a nice job flushing files to disk which lowered considerably
> power failure problems
> 2) It is much better then MS-DOS for compatibility with modern machines,
> specialy
> big disks and memory
>
> So I vote for implementing wha
Isn't this the same argument I made for broken hypervisors?
--
Kirn Gill II
Mobile: +1 813-300-2330 <+18133002330>
VoIP: +1 813-704-0420 <+18137040420>
Email: segin2...@gmail.com
LinkedIn: http://www.linkedin.com/pub/kirn-gill/32/49a/9a6
On Thu, Feb 27, 2025 at 4:03 PM tom ehlert via Freedos-dev
Hallo Herr Alain Mouette via Freedos-devel,
am Donnerstag, 27. Februar 2025 um 21:53 schrieben Sie:
> Em 27/02/2025 13:08, Bret Johnson via Freedos-devel escreveu:
>> I don't know how often you use other versions of DOS (like MS or PC or DR or
>> EDR or ...) compared to FreeDOS, but a TSR woul
Em 27/02/2025 13:08, Bret Johnson via Freedos-devel escreveu:
I don't know how often you use other versions of DOS (like MS or PC or DR or
EDR or ...) compared to FreeDOS, but a TSR would solve the problem for all of
them while modifying FreeDOS would only fix FreeDOS. I personally prefer
M
> It seems that I have two possibilities how to fix my problem. The first one
> is to
> create a TSR hooking INT13h.
> Second possibility is to compile my own FreeDOS modification when I could
> modify
> the function FL_LBA_READWRITE inside FLOPPY.ASM.
> This seems to be valid because I am maybe
It seems that I have two possibilities how to fix my problem. The first one
is to create a TSR hooking INT13h.
Second possibility is to compile my own FreeDOS modification when I could
modify the function FL_LBA_READWRITE inside FLOPPY.ASM.
This seems to be valid because I am maybe the only per
Hi! As you wondered about int 21.40, 25/26 and 13:
Check out int2526_handler in inthndlr.c ;-)
The actual work is done when dskxfer in blockio.c
calls the block device driver, see blockio in dsk.c
and LBA_transfer which calls fl_read, fl_write or
fl_lba_ReadWrite either of which do call int 13
15 matches
Mail list logo
