Hi Nicholas, clarifying...:
- filesystems were broken because "FAT1x root directory entries"
value was not 0. That confused FreeDOS but was ignored by MS,
even by MS SCANDISK (FAT32 drive).
- after fixing, we copied files again just to make sure that they
were not written to the wrong data sectors before (but I think
ONLY the boot sector and DOSFSCK, not the kernel, got confused
by the non-zero value, so this was probably not needed).
- finally, because the MBR did not pass the drive number to the
FreeDOS boot sector in DL, we had to patch the FreeDOS FAT32 LBA
boot sector to use drive 0x80 instead of "DL value". See my mail
to freedos-kernel 5 minutes ago.
For the records, from the broken MBR:
...
00000024 803C80 cmp byte [si],0x80
00000027 7409 jz 0x32
...
00000032 8BD6 mov dx,si
...
00000047 8BF2 mov si,dx
00000049 8B14 mov dx,[si]
0000004B 8B4C02 mov cx,[si+0x2]
0000004E CC int3
0000004F E85800 call 0xaa
00000052 803EE90801 cmp byte [0x8e9],0x1
^--- not normally used!?
00000057 750E jnz 0x67
...
Okay, I spare you with the rest. NDISASM is very useful.
...
00000080 BF007C mov di,0x7c00
00000083 B85000 mov ax,0x50
00000086 8BEE mov bp,si
00000088 06 push es
00000089 53 push bx
0000008A CB retf
As you can see or probably not, the FreeDOS boot sector is called
with DI=0x7c00 AX=0x50 BP=pointer to the partition table entry which
is used, at 0:0x7c000 (ES:BX). But DX does not contain the required
drive number.
That MBR looks a bit like a virus.
At 0xaa you have the LBA install check and if okay then
int 13.48 is used to get drive parameters. After that, int 13.8
is used for more drive parameters. Depending on some geometry checks,
the flag at 0xe89 is either set o not. Okay, I take that virus thing
back :-). But having an int3 in an MBR is strange.
Whatever. The only REAL error in this MBR: It does NOT pass a proper DL.
Because DX is abused to store SI for a while.
Eric.
PS: Our FAT32 LBA boot sector does not REALLY use the "FAT1x root directory entries"
value BUT it assumes it to be zero (it interprets the "number of FATs" value
as 32bit value (lazy coding, we believed that the following word with the FAT1x
root directory entries would always be 0...). Luckily Arkady already fixed
that by using MOVZX ..., BYTE ... when reading the number of FATs value.
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Freedos-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-user
