[Freedos-kernel] Commit 1705
Hi, Commit 1705 renames a particular LoL field CPULevel and adds a comment correctly claiming that MS-DOS sets this field to 1 on 386+ CPUs and to 0 otherwise. The commit however makes the boot loader store the detected CPU level (0, 1, 2, or 3) there instead. I don't think it's necessary 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 -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Regarding commit 1702 (large sector sizes)
Dear PerditionC, UBYTE DiskTransferBuffer[MAX_SEC_SIZE]; wastes 3,5 KB low memory for *everybody*, not only when it's needed. regarding how much time we have spend until we had 64 byte free I think this is a bad idea I also think that these experiments should NOT be in the stable branch. fork it, and make another 'unstable' branch if you want to experiment, but don't experiment with code that is supposed to be stable. Regards, Tom -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Commit 1705
Hi Chris, Jeremy, Commit 1705 renames a particular LoL field CPULevel and adds a comment correctly claiming that MS-DOS sets this field to 1 on 386+ CPUs and to 0 otherwise. The commit however makes the boot loader store the detected CPU level (0, 1, 2, or 3) there instead. I don't think it's necessary to use the field in an incompatible manner, and neither is the new 21.33 I totally agree. Reporting 386 versus older is more compatible and good enough. Only in rare cases when you want to know exactly, you would have to fall back to a tool such as CPULEVEL, but for a kernel flag, 32 bit CPU is exact enough information :-) subfunction that the commit adds, because no one uses it yet. Even so, You do not need an unused API function to read a rarely read field because the very few tools interested in the field can read LoL :-) the subfunction does not require using that particular field to store the detected CPU level. Even that... And by the way, I agree with Tom that flexible sector sizes are a bit shaky and the default compile should use 512 byte. However, a CONFIG.SYS option to modify the max sector size at boot would be a good compromise between hardcoding this at compile time and spending code and effort on automatic sizing at boot initdisk. Eric -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Regarding commit 1702 (large sector sizes)
On Tue, Feb 7, 2012 at 9:51 AM, Tom Ehlert t...@drivesnapshot.de wrote: Dear PerditionC, UBYTE DiskTransferBuffer[MAX_SEC_SIZE]; wastes 3,5 KB low memory for *everybody*, not only when it's needed. regarding how much time we have spend until we had 64 byte free I think this is a bad idea please see my previous messages, I know exactly how much space is wasted and clearly stated this along with statement 512 will be default (and was already changed to such earlier) I also think that these experiments should NOT be in the stable branch. fork it, and make another 'unstable' branch if you want to experiment, but don't experiment with code that is supposed to be stable. Regards, Tom These are not experiments, this is me working to improve compatibility with MSDOS and existing though rare disks. I purposely left a default value larger than needed so I could track down a kernel issue with memory allocation during initialization. This issue still exists and I believe may be one of the reasons why there are occasional reports of invalid opcode/crash during boot. MSDOS sets the value based on known devices during startup, this is documented in books describing it. The FD kernel has been hardcoded for 512 bytes. My plan was first to ensure sizes 512 bytes work then make the changes to allow user to choose larger size than 512 so only those who need the different value are penalized with increased memory usage and can use FD kernel with their drive while everyone else only has minimally larger kernel but more like MSDOS. Part 1, the changes so sizes 512 can be used was committed and uncovered a memory allocation issue. I put part 2 on hold because this seemed important to find - instead I will leave the 512 hard coded which rarely triggers the bug. The experimental 4K build is based on my forked 0xdc (DOSC OEM id) kernel, and it is where I do most of my changes before merging/testing with the 0xfd kernel. Jeremy. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
