Re: [Freedos-devel] 4, 096 byte sectors and DOSLFN, UIDE...question

[Jim M. <jmi...@ya...>]

 ohh - what utility is that? is that the kernel or...?

is someone saying the kernel already does this? if so, cool! 
still would like to see the filesystem support the full 32GiB. I don't like bumping into limitations - usually goes ouch that hurt now what do I do....
would also like to see long filenames working with freedos on both eltorito cdrom and hard disk.

some people do security videos and such, which make lots and lots of numbered small snapshots/files. logging is another task which creates lots of files in lots of directories.
I also tend to create large stuff. if I make a freedos cd, it's not going to be cd-sized. my utilities are going to be on it, so it's going to be DVD-sized and nearly full.
because DJGPP generates large files and I tend to not separate from my windows files.
only reasons I could think of for making the filesystem as it is handle 32GiB or switch to exFAT and support it as much as possible.
I could see having some sort of fsconvert.exe utility for upgrading/downgrading disks. it could make use of all that nice RAM and the extra disk space available, including unused partitions and areas on the hard disk?

wondering about blu-ray reading/burning now that discs are cheaper...

TRIM support... hmm. DOS on SSD? zowee!
I could see someone developing with that... need TRIM support for that. would be the fastest OS around... :-D (well, still is, just would blaze past everything else, it would "pop" - I like OS's that "pop", it's extremely satisfying... like my mom's windows 3.1 on a pentium mobo with 32MB, it pops)




>________________________________
> From: Bertho Grandpied <y31...@ya...>
>To: fre...@li... 
>Sent: Thursday, January 2, 2014 3:25 PM
>Subject: Re: [Freedos-devel] 4, 096 byte sectors and DOSLFN, UIDE...question
> 
>
>Bret Johnson wrote on Thu, 02 Jan 2014 07:58:29 -0800...
>
>" FWIW, my USB disk driver always did work with any sector size up to 32k, if the 
>OS supports it.  Unfortunately, AFAIK, only MS-DOS supports anything other than 
>512 byte sectors, and even to do that requires a minor modification to the 
>kernel (you just need to change the default sector size, a one word value).  "
>
>No such change is needed, large sectors work 'out of the box'. The (ugly, imo) lernel mod 
>which Bret's programs need is required only because his system has to load after "sysinit"
>is finished processing installable device drivers and sizing its internal buffers.
>
>'  I think MS SMARTDRV may be the only cache that 
>works with sectors other than 512 bytes (or at least doesn't crash / corrupt 
>anything).  From what I understand, UIDE and LBACACHE (the caching programs I 
>think are used by most users nowadays) do not work correctly with anything 
>other than 512 bytes (Eric / Jack can correct me if I'm wrong about that).  
>Also, UIDE and LBACACHE are INT 13h caches, so won't work directly with ASPI / 
>SCSI / USB disks anyway.  SMARTDRV is an INT 21h cache, so doesn't have the 
>same issues."
>
>Agree on all counts. Actually, Smartdrive v.5 does not even have a "notion" of sectors,
>it caches in units ("cache elements" in MS parlance), the size
>of which is controlled by the ./E command line parameter, default is 8192 bytes) and as
>you state correctly, Smartdrb.exe ignores the BIOS completely. FWTW I have verified it <orks
>perfectly with my 4K driver...
>
>"Also FWIW, I think using an ASPI interface is the wrong direction to go for 
>disk "enhancements" ..."ASPI is probably a little easier than INT 13h to 
>implement at first"
>
>Aren't you mixing apples with oranges ? ASPI and "int 13" aren't at the same protocol level
>or "layer" . I'm not 'implementing' ASPI, I'm building over it. As for "int 13", it can be added
>too /over/ the ASPI layer. It is not especially "difficult", but tedious certainly and, for the most
>part, unnecessary. Actually of 2 widely known implementations of DOS disk access using ASPI 
>that I know (limited to 512 K sectors), one of them "does" int 13 [DI1000DD.SYS], while 
>the other, ASPIDISK.SYS, doesn't. Strangely the latter requires more than double the memory 
>footprint with LESS finctionality, I have not investigated why...
>
>" I think DOS will end up in a place it doesn't want to 
>be if we continue down that road.  Just my opinion. "
>
>I can't see how so,  maybe you want to elaborate ! 
>
>None of what I wrote should be read as a criticism of Bret's system, an original, impressive
>USB stack for DOS, including "quasi plug and play" - albeit UHCI only is supported ATM (AFAIK)
>
>The solution I'm advocating is less ambitious, addressing the needs of mass storage devices
>only, does not bother about fancy "plug and play"... OTOH it works with OHCI.UHCI and more 
>importantly hi-speed EHCI (or more, provided you can find the ASPI provider).
>
>And BTW I have just coded-in full width 32-bit sector numbers, which assuming 4K sectors
>provides for access to devices up to 16 "tebibytes"...
>
>Concerning DOSLFN, have emailed Jason - hopefully his old email (jadoxa@y??oo.com.au)
>is still active.
>-----------------------------------------------------------------------------
>
>-- 
>Cz.
>
>------------------------------------------------------------------------------
>Rapidly troubleshoot problems before they affect your business. Most IT 
>organizations don't have a clear picture of how application performance 
>affects their revenue. With AppDynamics, you get 100% visibility into your 
>Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
>http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>_______________________________________________
>Freedos-devel mailing list
>Fre...@li...
>https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
>
>