On at 2018-11-05 15:51 +0100, Tom Ehlert wrote:
>> the FreeDOS kernel is seriously slower then MSDOS when doing
>> larger copy/xcopy operations.
>
>> the cause: the disk I/O code avoids transfers that cross a 64K
>> boundary, and splits these transfers into 3 (smaller) transfers.
>
>> this was
Hi Eric,
Kernel on that image uses 386+ instructions... and it seems as if it
does that without (properly) checking for the presence of a 386.
That is correct, as a kernel cannot be both optimized
for 386 and compatible with 8086 at the same time.
Well, yes it could (look at FreeDOS
When DOS detects an unreliable floppy change line hardware,
it should use the floppy label / serial / similar to detect
changes in software ...
How does DOS ever detect that any hardware is unreliable??
I do not know, but earlier in this thread, somebody said that
the numbering of FAT
Note that the 1702 changes were effectively reversed by 1704.
The 1705 changes are unrelated.
Wrong From
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but
to use
the field in an incompatible manner, and neither is the new 21.33
subfunction that the commit adds, because no one uses it yet. Even so, the
subfunction does not require using that particular field to store the
detected CPU level.
Regards,
C. Masloch
end signature location?) while you
might have to get creative for the very small sizes, because a full BPB
would not fit. I'd suggest just expecting the BPB to stretch several
sectors then; the filesystem already allows reserved sectors to be
properly implemented using the BPB.
Regards,
C
is too large, but
still working on relearning the init time segment relocations and
order to determine a proper fix for buffer allocations. It would help
if printf worked correctly in all the init code...
The virtues of high-level language kernel development ;)
Regards,
C. Masloch
