On Thu, Sep 6, 2012 at 11:50 PM, Rugxulo <rugx...@gmail.com> wrote: > On Wed, Sep 5, 2012 at 5:50 AM, Rugxulo <rugx...@gmail.com> wrote: >> On Wed, Sep 5, 2012 at 2:14 AM, Felix Miata <mrma...@earthlink.net> wrote: >>> >>> Is FreeDOS HD access as slow as PC or MS DOS? IIUC, the latter use slow 16 >>> bit BIOS code, which is what makes it painful for me to use compared to >>> running DOS apps in an OS/2 VM. >> >> Yes, probably just as slow as it also uses the BIOS. >> >>> Is FreeDOS disk I/O in the same class as 32 & >>> 64 bit operating systems speed-wise? >> >> No, FreeDOS is pure 16-bit, but with Ultra DMA enabled and a software >> cache (e.g. UIDE) can help a lot. That's about the best you can do >> outside of just running under DOSEMU or similar (NTVDM). >> >> BTW, things like DOSLFN slow down file accesses a lot, so avoid them >> if possible.
I'd be interested in what Felix is doing and where he sees visible slowness. As you mention, FreeDOS is 16 bit code. But how fast things will appear to be will have more to do with the hardware you are running on than whether the code is 16 or 32 (or 64) bit. HD access varies depending upon the drive and the BIOS. The old notebook I run FreeDOS on is hobbled, because the HD is IDE 4, with an 18 mbit/sec transfer rate. This is a BIOS limitation, so I can't just swap in a faster drive. FreeDOS flies, but Windows and Linux notice. I remember the old MS-DOS days where I would do things like change the interleave value on a drive for faster operation. By default, disk blocks allocated to files were stored sequentially - 1,2,3,4,5,6,,,. The problem was that the machine might not be ready to access block 2 when it came under the drive head after reading block 1, and you would have to wait for the drive to rotate and the block to come under the head again. Reordering the blocks, like 1, 3, 2, 4, 6, 5... gave the machine time to finish loading the first block before the second came under the drive head, and you didn't have to wait a full drive rotation for it to happen. You got a nice I/O boost. It has been a long time since I was concerned with such things. :-) On a current machine with a multi-ghz CPU and an IDE 6 or SATA drive, I'd be a bit startled at perceptible slowness in file I/O, even with 16 bit code running. The faster the underlying machine, the faster the code will run, even it it's 16 bit. Better performance under something like DOSEMU isn't really a surprise, as it's essentially a virtual machine, and the actual file I/O is being passed to and performed by the native routines of the underlying OS. ______ Dennis https://plus.google.com/u/0/105128793974319004519 ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
