Hi Tom,
>>>> - int 21.1c should report invalid drives via AL (keep other regs?)
>>>> News here: DR-DOS modifies BX/CX/DX but not DS for inv drives.
[patch to preserve DS:BX and set AL=-1 if FatGetDrvData... == NULL]
> should get the job done
Indeed, test for NULL as return value of FatGetDrvData and if
NULL then do not return the pointer but do set AL to -1 :-).
It seems no other registers need fixing in 21.1c / 21.36...
>> Unfortunately I do not know to what value DR DOS sets BX/CX/DX,
> MS-DOS is the king, and it lets all registers unchanged.
Okay! Do you want to upload your int 21.1c fix or should I do it?
>>>> - CHS calculations are off by 1 and overflowing (thanks Rayer)
>>>> If your BIOS has no LBA, this was probably a real pain for you.
>>> any details about this ? like the original email ('thanks Rayer' is
>>> not enough of a description)
>> The discussion is spread over mail and chat,
> but this is certainly in the kernel mailing list, isn't it ?
No sorry I just assisted RayeR on ICQ a bit and then at some
time he had a kernel with a fix, mixed with other fixes. This
probably has a thread on the BTTR forum, where I never post.
The two changed lines are:
593 pddt->ddt_ncyl = driveParam->chs.Cylinder + 1;
Here, +1 got added. And:
762 driveParam->total_sectors =
763 (ULONG)(driveParam->chs.Cylinder+1)
764 * driveParam->chs.Head * driveParam->chs.Sector;
Here, min(...Cylinder,1023) got replaced by (ULONG)(...Cylinder+1).
Can you confirm the usefulness of those two CHS related changes?
In addition, a few format strings changed: DebugPrintf about drive
parameters from %02x %04lu %u %u to %02Xh %u %u %u for drive, C, H, S
and %02x to %02Xh for drive in "Error reading partition table" printf.
Last but not least, LBA-Transfer error now also mentions LBA_address+1
(dunno why +1) using %lu format. Do these changes make sense?
About BSS_INIT in init-mod.h, suggestion is to always use
>> #define BSS_INIT(x) = x
> it shouldn't matter if
> int SomeVariable;
> or
> int SomeVariable = 0;
> is declared. in the former case it is put into the BSS segment, and
> initialized by the runtime libray. As we don't have the normal runtime
> library, we do it in main.c
> /* clear the Init BSS area (what normally the RTL does */
> memset(_ib_start, 0, _ib_end - _ib_start);
Maybe this broke when Bart tuned the memory model recently?
Remember for example "JEMM386 int 19 fastboot compatible
storage of original pointers of hooked BIOS intr" here...
As quite a few BIOSes also clear the RAM, it would be plausible
that a bug in this area could stay undetected for quite a while?
> in both cases the variable ends up as 0
Not for RayeR, apparently: Some variables were nonzero in initdisk.
> if this makes any difference, either
> the memset() memset above doesn't work
> or
> the error relates to the actual placement of the variable in the
> DATA segment. usually an overwriting problem or similar.
> good luck hunting if it's the latter
As RayeR was able to fix the symptom by using BSS_INIT(x) = x style
for the macro, I hope that "if it is the latter" his fix would have
broken something else, so I believe that the memset has a problem.
Eric
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
