Re: [Freedos-kernel] Analysis: Support for sector sizes != 512 bytes
Hi! 13-Май-2005 15:38 [EMAIL PROTECTED] (Eric Auer) wrote to freedos-kernel@lists.sourceforge.net: >> The more so, does anyone >> contains resources (devices), where non-standard sectors support may be EA> YES, big question! Main question! --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_ids93&alloc_id281&op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Analysis: Support for sector sizes != 512 bytes
Hello Eric, > While we are at it, I would suggest a new category "not planned at all > unless you tell us why it is useful or alternatively send us patches" > for the list: http://fdos.org/ripcord/fdos_1_0/official/post.htm > Candidates are: drivparm / driver sys / 3rd floppy support (kernel, sys...), > himem "cpuclock" and "eisa" options, graphics "lcd" option (for old CGA > 640x200 handhelds with widescreen display), emm386 Weitek FPU MMIO support... > Let me know if I forgot something. add sectorsize != 512 > PS: Eg. FASTOPEN can, imho, be useful, as scanning large directories > causes big load for CPU and BUFFERS / cache which can be reduced by a > specialized FASTOPEN directory entry cache. But thats just my 2 cents. send us patches tom --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: Analysis: Support for sector sizes != 512 bytes
Hi Arkady, > AFAIK, CD-ROM sector is 2352 bytes. That would be the raw (cdda) sector size. For data (iso9660...) CD-ROM, the useable sector size is 2048 bytes, rest is CRC/ECC overhead. > Eric, I suggest, non-standard sector size is not the hottest issue > (and, probably, will never be actual in future). My point was that it would be easier than I had thought to support at least smaller-than-default sector sizes. Ramdisk/Romdisk could be happy about that (although the smallest sector size which still fits a minimal BPB, 64 bytes, would mean up to 1/33th of all space used already by each FAT in FAT16 case). Minimal in this context means: 3 bytes jump + 8 bytes OEM string + full FAT12/FAT16 BPB (including label, serno, FAT type string) + finally the 2 byte magic 55 aa value. So no FAT32 in the 64 byte / sector case. > The more so, does anyone > contains resources (devices), where non-standard sectors support may be YES, big question! Which FAT devices use non-standard sector size, apart from ramdisk/romdisk? For example memory cards, DiskOnModule, Flash, optical storage (e.g. DVD-RAM maybe?), maybe ZIP or LS120 or similar? > TESTED? Whereas for non-standard devices you anyway should install their own > device driver, which may easily emulate 512-bytes sectors. While the ElTorito driver can use sector sizes of 512, 1024 and 2048 bytes (depending on what is provided by the BIOS) I would really need more info about other devices. A driver CAN emulate 512 byte sectors, but WILL it do? After all, not all drivers are open source. I hope somebody can tell me whether there are storage devices which use nonstandard sector size and which could be used for DOS as soon as it supports that. After all, there ought to be a reason why other DOSes have support for it... While we are at it, I would suggest a new category "not planned at all unless you tell us why it is useful or alternatively send us patches" for the list: http://fdos.org/ripcord/fdos_1_0/official/post.htm Candidates are: drivparm / driver sys / 3rd floppy support (kernel, sys...), himem "cpuclock" and "eisa" options, graphics "lcd" option (for old CGA 640x200 handhelds with widescreen display), emm386 Weitek FPU MMIO support... Let me know if I forgot something. Eric PS: Eg. FASTOPEN can, imho, be useful, as scanning large directories causes big load for CPU and BUFFERS / cache which can be reduced by a specialized FASTOPEN directory entry cache. But thats just my 2 cents. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Analysis: Support for sector sizes != 512 bytes
Hi! 12-Май-2005 05:03 [EMAIL PROTECTED] (Eric Auer) wrote to freedos-kernel@lists.sourceforge.net: EA> DOS3.x+ 32bit sector number calls) and 2048 byte (raw sector size EA> on CD-ROM and maybe on magneto-optical drives) cases. AFAIK, CD-ROM sector is 2352 bytes. EA> - To support bigger sectors, raise _maxbksize and make each element EA> of BUFFERS and DiskTransferBuffer bigger Eric, I suggest, non-standard sector size is not the hottest issue (and, probably, will never be actual in future). The more so, does anyone contains resources (devices), where non-standard sectors support may be TESTED? Whereas for non-standard devices you anyway should install their own device driver, which may easily emulate 512-bytes sectors. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_ids93&alloc_id281&op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
