Hi,
On Wed, Jul 20, 2016 at 12:58 PM, Eric Auer <e.a...@jpberlin.de> wrote:
>
> Hi Dimitris,
>
> long analysis follows, some suggestions at the bottom of this mail :-)
>
> > Thank you for your reply. I tried few kernel and here are the results:
>
> I gather you mean "you tried the SYS of a few kernels together with
> the corresponding KERNEL versions"? My focus is on the SYS activity,
> as the kernel should at least show a version message before hanging
> as long as the boot sector put by SYS has done the correct stuff.
>
I downloaded the zip file, extracted the contents of BIN on a floppy,
executed install.bat from the floppy inserted in the 486 system. Sometimes
I modified install.bat, others just ran sys c: from within the BIN folder,
sometimes I copied the bin folder to the 486 hdd, ran install.bat, rebooted
from floppy and then sys c:, reboot. I was not very consistent.
>
> > 2041_86f16 : floppy boots but no hard drives detected
>
> If you only have FAT32 partitions, then using a kernel without
> FAT32 support would lead to that expected result, yes ;-)
>
Ok, makes sense.
>
> Other versions, sorted (2020 is anycient anyway) from old to new:
>
> > 2030: BOOTS!
> > 2031_32: BOOTS!
>
> > 2032: hangs
> > 2032a: hangs
>
> > 2035a: boots, detects HDD, sys [...] hard drive fails to boot
> > 2039_86f32: as above
> > 2041_[3]86f32: as above
>
> In short, we introduced a bug in the SYS of version 2032?
> That would be 2003-09-21 while version 2031 is 2003-07-19.
>
> But your pictures on Google seem to say that version 2032
> still is okay, while newer versions are not okay?
>
I do not think this is correct. 2031 is the latest version that was able to
boot my system from hard drive. I am using the version referring both to
kernel.sys and the accompanying sys in the zip file where I got the kernel
from - probably this is confusing.
>
> > And that one results in a hang:
> >
> > https://drive.google.com/open?id=0B2zW1ur6Z_WedkQtSXBYMS1YN0U
>
> As Google is a pain for DOS users, a summary of what it says...
>
> SYS 2.8 detects FAT32, FAT at sector 3f+20, 0 root dir entries,
> FAT at sector 63+32, root dir at PREVIOUS + 0*2, kernel.sys has
> 45884 bytes, command.com has 92109 bytes... (date 2003-09-21)
>
> > This is a successfully sys c: output
> >
> > https://drive.google.com/open?id=0B2zW1ur6Z_WeX1pZSXktNTd3SFE
>
> SYS 2.6 (unknown date) kernel.sys 44900 bytes, FAT at sector 5f
> which is 3f+20, data at sector 603f, 0 root dir entries, 255 root
> dir sectors (really???), FAT at sector 487060009 = 63+32 (???),
> root dir at sector 1313429276 = PREVIOUS + 0*2, data starts at
> sector 1163081785 = PREVIOUS + 255, command.com is 92109 bytes.
>
> Note that the displayed numbers look very wrong, so SYS might be
> calculating bogus FAT32 parameters... Or maybe it only displays
> wrong values, while internally using correct values. This can be
> a side effect of compiling SYS with the "wrong" compiler in case
> of incomplete portability. The weird thing is that SYS works for
> you in version 2.6 :-)
>
> Checking the source code...
>
> >
> https://sourceforge.net/p/freedos/svn/1744/log/?path=/kernel/trunk/sys/sys.c
>
> 2009: Jeremy introduced a command line option to force CHS / LBA.
>
> 2004, 2009, 2010, 2011: Fixes to make things work for all compilers?
>
> 2007: Faster file copy, update FAT32 backup boot sector if needed.
>
> 2007: Fixes for FAT32
>
> 2003-09-21: Metakern compatibility r702
>
> 2003-08-08: Support for other sector sizes on FAT16, SYS 2.7
> (note that the kernel itself only works for 512 byte sectors)
>
> 2003-06-16: This is version SYS 2.6 here.
>
> >
> https://sourceforge.net/p/freedos/svn/607/tree/kernel/trunk/boot/boot32.asm
>
> > https://sourceforge.net/p/freedos/svn/607/tree/kernel/trunk/sys/sys.c
>
> etc. Note that SYS 2.6 only supports CHS style boot for FAT32!
>
> I suggest the following: Apparently the FAT32 boot sectors have
> not changed since 2004, but SYS itself has evolved further. In
> particular, try the newest SYS 3.6e which has two options for
> /FORCE:LBA and /FORCE:CHS with obvious effects. Please try with
> /VERBOSE and with > output.txt so you can paste results into a
> mail, without Javascript-heavy DOS-unfriendly Google Drive pics.
>
> I see two possible problems: Either your BIOS supports LBA but
> our FAT32 LBA boot sector is incompatible with it. In that case,
> the /FORCE:CHS option for SYS will help you. Or SYS itself has
> errors in calculating FAT32 parameters. Then both LBA and CHS
> might be broken in certain versions of SYS, but should at least
> be fixed again in newest versions.
>
> >
> https://sourceforge.net/p/freedos/svn/1744/log/?path=/kernel/trunk/boot/boot32.asm
>
> >
> https://sourceforge.net/p/freedos/svn/1744/log/?path=/kernel/trunk/boot/boot32lb.asm
>
> This tells me that the FAT32 boot sectors changed at those dates:
>
> 2004-01-24 different load seg and stack handling, no int 13.0
> (SYS 3.1, kernel 2.0.33, claims to improve FAT parameter calculation)
>
> 2003-09-21 different padding, a:\metakern.sys detect & use (SYS 2.8)
> (not sure if SYS really copies metakern.sys to the target drive??)
>
> 2003-08-08 new CHS and LBA FAT32 boot sectors (patches: Jon & me)
> and new CHS-LBA-auto-detect FAT12 FAT16 boot sector (by Tom) (SYS 2.7)
>
> Note that SYS 2.6 and older did not support LBA for FAT32 at all
> and the CHS FAT32 and CHS or LBA FAT12 FAT16 boot were different.
>
> The different versions of the kernel download (which include SYS)
> can be found in our Sourceforge file area:
>
> https://sourceforge.net/projects/freedos/files/Kernel/
>
> Thanks! Cheers, Eric
>
>
So I did, with sys 3.6e - FreeDOS 1.2 pre floppy:
sys c: /FORCE:CHS - system hangs on reboot
sys c: /FORCE:LBA , followed by sys CONFIG c:\kernel.sys FORCELBA=1
GLOBALENABLELBA=1
- system tries to BOOT, hangs at Loading FreeDOS , the hard drive works
like mad until I hit control-alt-delete
Cheers,
Dimitris
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
