If it comes down to it,one could simply create a config option for the LBA
support.By default,LBA would be enabled.If the user experiences issues
booting,or if it detects an issue booting,it would then revert to the old
SYS update code,grouped as a function or something of the liking.

On Sat, Aug 20, 2016 at 8:28 PM, Eric Auer <e.a...@jpberlin.de> wrote:

>
> Hi everybody,
>
> apparently the same SYS update which introduced FAT32 LBA support also
> broke FAT32 CHS support: On Dimitris' PC, CHS based FAT32 boot always
> fails, but his BIOS lacks LBA support. After installing MBR-based disk
> drivers to add LBA support and support for 4 instead of 2 harddisks,
> FreeDOS boots fine with modern FAT32 LBA boot sectors. Before that, he
> had to use ancient CHS-only-for-FAT32 SYS to get a working boot sector.
>
> I was busy trying to find out what broke and when, but cannot find it.
> Maybe you can help me out here... :-)
>
> - old SYS sets drive number to -1 but it gets overwritten on boot anyway
>
> - new SYS sets drive number to 0x80 but it gets overwritten on boot, too
>
> - new SYS uses signed byte to word comparison in cluster code (fff fff8
>   versus fff -8) but source code is unchanged, maybe a NASM auto tune?)
>
> - r751 moves the load location far pointer to inside the code, while it
>   was at +5a in the variable area before. Not sure why that was changed?
>
> Apparently both good and bad are AFTER this diff, so that should be
> safe? The r321 to r343 patch makes CHS calculations small but obscure:
>
> > https://sf.net/p/freedos/svn/343/tree//kernel/trunk/boot/
> boot32.asm?diff=321
>
> This leaves the main "calculate parameters at runtime, instead of using
> SYS to hardcode them" patch as suspicious change. We have this patch to
> keep FAT32 partitions bootable even when you resize them with 3rd party
> tools. Of course the patch adds yet more obscure code to the boot sect:
>
> > https://sf.net/p/freedos/svn/652/tree//kernel/trunk/boot/
> boot32.asm?diff=382
>
> Note that this r382 to r652 patch also drops the last call of "print",
> so we could drop that function to gain some space for making the code
> a bit less unreadable by "un-optimizing" some bits. Apparently somebody
> simply forgot to drop print after dropping the last place using it ;-)
>
> Not sure why, but the patch also moves around the offsets of 4 variables
> by 4 bytes each: fat_start, data_start, fat_secmask, fat_secshift, which
> makes the before / after the patch situation a bit harder to "diff" now.
>
> The basic function of the patch is to add some code after the setup of
> stack, segments and registers and relocation to 1FE0:xxxx, but before
> the first call to "find sector for cluster" and "read sector from disk"
> after which the root directory is scanned and, when a kernel is found,
> the kernel file is loaded by cluster chain:
>
> dword fat start [+5E] = DI:SI = dword hidden [+1c] + word reserved [+0e]
>
> DI = DI + (byte fats [+10] * word sec per fat HIGH [+26])
> [+62] = DX:AX = (byte fats [+10] * word sec per fat LOW [+24]) + DI:SI
>
> word sec mask [+66] = CX ... = (AX >> 2) - 1
> AX = 1 ...
> do
>   CX >>= 1
>   AX++
> while CX not 1
> byte sec shift [+68] = AL
>
> (the above is my attempt to summarize what the code actually does, see
> the source code for the description of what it wants to do - as said,
> I fail to see a problem here, but the symptom still is a failed boot!)
>
> Thanks for helping out!
>
> Cheers, Eric
>
> PS: Of course the boot sector stores DL to byte drive [+40] before it
> starts juggling with DX:AX, so that value seems to be safe as well.
>
>
> ------------------------------------------------------------
> ------------------
> _______________________________________________
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
------------------------------------------------------------------------------
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Reply via email to