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
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
