As SYS is part of the kernel sources, maybe somebody on the
kernel mailing list has an idea for me...? Thanks! :-)



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-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Reply via email to