Replying to Eric Auer e.auer@***.de
This refers to the following quote from an earlier 4 kB
related mail:
I stumbled upon a couple pages that say otherwise : the industry
has agreed to sell AF disks only *until the end of 2014*!
It was actually you yourself who said that on 25 Jan 2012
On Sun, 5 Feb 2012, Kenneth Davis jeremyd@***.org wrote :
test kernel supporting 4KB sectors, note it limits
buffers to 2 to avoid memory corruption on boot.
Thanks for testing,
Eager to try your kernel mods with real HW, but, there is a but! in order for
my Iomega device to be
test kernel supporting 4KB sectors, note it limits
buffers to 2 to avoid memory corruption on boot.
Thanks for testing,
By an extraordinary coincidence - I am not making this up ! I received mail
from PLoP's developer today, a short time after I had posted the following note
to this
you *could* try USBASPI.SYS /V /W
followed by DI1000DD.SYS
( works for me )
..
eufdp...@yahoo.com
eufdp...@yahoo.com
eufdp...@yahoo.com
eufdp...@yahoo.com
eufdp...@yahoo.com
Mark Brown-27 wrote:
you *could* try USBASPI.SYS /V /W
followed by DI1000DD.SYS
( works for me )
In my opinion, this is applying a band-aid to a problem that actually
requires drastic surgery. USBASPI.SYS + DI1000DD.SYS may in fact work in
certain situations. But, it is not a
In reply to: Mark Brown eufdppue@ya???.com
you *could* try USBASPI.SYS /V /W
followed by DI1000DD.SYS
This is what I tried first thing, and the DI1000DD.SYS [Ninja ASPI DISK DRIVER
Ver2.00, 16368 bytes, MD5=9C240A5F1848F76893364AB3A26D545F] which I use
definitely /won't/ work with 4K
Op 7-2-2012 15:05, Bertho Grandpied schreef:
Also of note, PLoP's license has changed it is now free for use including
commercial. Donations will be accepted still? Please watch what Elmar had to
say about the change (at the above URL).
The donation button is quite well hidden, and seems
This is correcting my mistake,
--- On : Tue 2/7/12, Bertho Grandpied y31415926536@y??? wrote :
In reply to: Mark Brown
you *could* try USBASPI.SYS /V /W
followed by DI1000DD.SYS
This is what I tried first thing, and the DI1000DD.SYS
[Ninja ASPI DISK DRIVER Ver2.00, 16368 bytes,
In reply to: Bernd Blaauw bblaauw@ho...
Op 7-2-2012 15:05, Bertho Grandpied schreef:
Also of note, PLoP's license has changed it is now free for use including
commercial. Donations will be accepted still?.
The question mark after the word still was un,intended (a typo). Sorry if it
clouded
On Sun, 5 Feb 2012 22:56-0500 Kenneth Davis jeremyd@f***.org wrote :
For testing only - warning may corrupt data!!!
https://www.fdos.org/kernel/testing/4K/
Got'm alright! For information, had to downgrade URL protocol to HTTP:// (from
http per provided link). Not sure if it's a temporary
On Sat, Feb 4, 2012 at 3:13 PM, Bertho Grandpied y31415926...@yahoo.fr wrote:
Hi, Guys! Replying to self, sort of, and Jeremy at the same time.
I've been glancing thru the ram disk, TDSK, source. Internal buffer (used for
init only) was provisionned for one 4K sector, but for some reason
Improved support for sectors other than 512 bytes has been committed,
I am still working on it, default support will still be for 512 bytes
(currently not while testing). I have tested 256, 512, 1024, and 2048
byte sectors with tdsk (currently my only way to test). Using max
sector size higher
Hi Jeremy, Bret, Georg, others,
Improved support for sectors other than 512 bytes has been committed,
I am still working on it, default support will still be for 512 bytes
(currently not while testing). I have tested 256, 512, 1024, and 2048
byte sectors with tdsk (currently my only way to
Kenneth J. Davis jeremyd@fd... wrote :
Improved support for sectors other than 512 bytes has been committed,
I am still working on it, default support will still be for 512 bytes
(currently not while testing). I have tested 256, 512, 1024, and 2048
byte sectors with tdsk (currently my only way to
Hi, Guys! Replying to self, sort of, and Jeremy at the same time.
I've been glancing thru the ram disk, TDSK, source. Internal buffer (used for
init only) was provisionned for one 4K sector, but for some reason author(s)
limited sector size to 2K, as specified on the driver's command line.
I
Just a note, Folks, /who/ said advanced format disks (presenting 512 byte
sectors) are with us for ten years - or more, so we should be little concerned
about having to support true 4K sector disks ?
But I stumbled upon a couple pages that say otherwise : the industry has
agreed to sell AF
Links please?
On 1/25/12 1:46 PM, Bertho Grandpied wrote:
Just a note, Folks, /who/ said advanced format disks (presenting 512 byte
sectors) are with us for ten years - or more, so we should be little
concerned about having to support true 4K sector disks ?
But I stumbled upon a couple
In reply to : Eric Auer e.a...@de
Realising I left away this point of your previous msg :
Someone, maybe not Eric, asked what I have been using for accessing
USB mass storage in DOS. Answer : a version of Panasonic's
USBASPI.SYS. This allows access to 4k sectors using SCSI commands.
I had a look at Bret's open source USB drivers, unfortunately they
only support Intel/Via (UHCI) controllers yet.
True. Working on that.
I also think they have hard coded 512 bytes per sector.
No. USBDRIVE reads the maximum buffer size from the DOS List of Lists (as
discussed some earlier
The advantage of a write-delay cache is that that the writing can be
done when the system is idle (a simple form of multi-tasking).
That counts as advanced cache with a lot of code and can go as far as a
sort of ramdisk which syncs
back to the harddisk slowly but steadily when the
In reply to: Bret Johnson bretjohn@ju...
only support Intel/Via (UHCI) controllers yet.
True. Working on that.
Great :=)
I also think they have hard coded 512 bytes per sector.
No. USBDRIVE reads the maximum buffer size from the DOS List of Lists (as
discussed some earlier in the
From: Bertho Grandpied y31415926...@yahoo.fr
To: freedos-user@lists.sourceforge.net
Sent: Wednesday, January 18, 2012 1:46 PM
Subject: [Freedos-user] Re : Support for 4k byte sectors
In reply to: Bret Johnson bretjohn@ju...
only support Intel/Via (UHCI) controllers yet.
True. Working
Op 18-1-2012 20:15, Mark Brown schreef:
is this too simplistic or what (?):
you could reformat ntfs and use a freeware reader,
or reformat the whole hard drive and then use that...
or i've had excellent luck with USBASPI.SYS 2.27 +
DI1000DD.SYS (links below).
How would your
Op 18-1-2012 17:11, Bret Johnson schreef:
I had a look at Bret's open source USB drivers, unfortunately they
only support Intel/Via (UHCI) controllers yet.
True. Working on that.
That's promising, even to see if your drivers can really make FDISK
work. I probably should prepare a bootdisk
On Wed, Jan 18, 2012 at 2:23 PM, Bernd Blaauw bbla...@home.nl wrote:
Formatting something as NTFS doesn't guarantee a proper working on such
a USB bridge. Besides, using a reader implies no writing.
I use NTFS under Windows. Mark Russinovitch offered a freeware NTFS
*reader* for DOS through
That's promising, even to see if your drivers can really make FDISK
work.
Trust me, it works. I've partitioned many USB disks from DOS, though I
normally use Ranish Partition Manager instead of FDISK (it's MUCH easier to
use, and will also format the partitions).
I know MS FDISK will crash
I use NTFS under Windows. Mark Russinovitch offered a freeware NTFS
*reader* for DOS through his
old Sysinternals site, and a payware driver that could also *write* to
NTFS from DOS through the sister
Winternals site. (It was intended for rescue operations on NTFS
filesystems from DOS.)
Hi,
On Wed, Jan 18, 2012 at 4:31 PM, BretJ bretj...@juno.com wrote:
I use NTFS under Windows. Mark Russinovitch offered a freeware NTFS
*reader* for DOS through his
old Sysinternals site, and a payware driver that could also *write* to
NTFS from DOS through the sister
Winternals site. (It
On Wed, Jan 18, 2012 at 5:31 PM, BretJ bretj...@juno.com wrote:
I use NTFS under Windows. Mark Russinovitch offered a freeware NTFS
*reader* for DOS through his old Sysinternals site, and a payware driver
that could also *write* to NTFS from DOS through the sister Winternals site.
(It was
Hi Bret,
The advantage of a write-delay cache is that that the writing can be
done when the system is idle (a simple form of multi-tasking).
That counts as advanced cache with a lot of code and can go as far as a
sort of ramdisk which syncs
back to the harddisk slowly but steadily when
I am saying that for gaining speed on modern disks, in particular
flash disk ands large sector disks, you should already make a big
difference with a small pooling cache and a short delay,
That's true -- but I don't think either LBACACHE or UIDE actually do that. I
could be wrong, but I
...
No cache will ever compete with a RAM disk. RAM is always faster
than disks with their seek/rotational latencies and their much
slower transfer rates.
I knew this would provoke a comment from you, Jack.
The purpose of a cache is to put as much data in RAM as it can, so that the
disk
I knew this would provoke a comment from you, Jack.
Yes, you always were a provoker, weren't you, Bret?
The purpose of a cache is to put as much data in RAM as it can, so that
the disk is accessed as little as possible. It's true that the cached
data does eventually get written to
In reply to : Eric Auer e.auer@*.de
Hi Bertho, trying to reiterate / re-explain my plan /
idea:
Fine !
a DRIVER could interface with any disk with
any sector size and then just provide an int13 or int25/26 interface
with 512 byte sector size for data transfer to DOS.
As explained in a
Op 17-1-2012 18:48, Jack schreef:
Also, FWIW, you can disable write-delay caching in SMARTDRV if you want,
in which case it works sort of like UIDE or LBACACHE (except that it
will also _natively_ work with non-INT 13h disks like USB and SCSI), but
at the expense of requiring more memory.
Op 17-1-2012 18:48, Jack schreef:
SCSI disks are rarely seen on PCs, due to their high disk and controller
cost. USB disks are also rarely seen, since they are not-yet reliable,
nor in many cases are they fast-enough to replace hard disks. SATA/IDE
own the hard-disk market and probably
Hi Bertho,
a DRIVER could interface with any disk with any sector size and
then just provide an int13 or int25/26 interface with 512 byte
sector size for data transfer to DOS.
I'm not opposed to this method, which I see as a workaround rather
than a fully satisfying answer however.
On one
Hi Jack,
Try to find any Write Back caches that do so much, for so little memory!
Sure, it takes more memory. If it is not just local pooling
within a few kB and with tiny timeout, it will take even more
memory, for logics and extra security logics for writeback.
But larger writes really
Re: 4K sector sizes, I realized today that UIDE, UIDE2,
and UIDEJR likely will NOT be affected at all --
1) DOS has a 64K-byte limit for read/write requests, in
fact 127 sectors of 512 bytes (the UIDE drivers do
accept 128). Since 4K-byte sectors fit into this
limit, no
Hi Bertho, trying to reiterate / re-explain my plan / idea:
By the way - a DRIVER could interface with any disk with
any sector size and then just provide an int13 or int25/26 interface
with 512 byte sector size for data transfer to DOS.
As explained in a longer mail this week, it actually
Hi Bret,
yes you would see a problematic mismatch if you were to
talk raw SCSI or CHS to a disk while being inconsistent
about whether you use 512 byte or rather 4096 bytes per
sector...
However, when DOS mounts a partition with help of a
loadable block device driver, nothing would access the
yes you would see a problematic mismatch if you were to talk raw
SCSI or CHS to a disk while being inconsistent about whether you use
512 byte or rather 4096 bytes per sector...
That's precisely the problem. Depending on which DOS programs you use, some
simply call DOS, some may use INT
To set the record straight on caches and on UIDE --
Can you recommend any free int 13 or block device based delayed/
pooled write caching software? As far as I can remember, all
modern (LBA compatible, given disk sizes on current PCs)
implementations of this are commercial.
I don't know
On Sat, 14 Jan 2012 Michael B. Brutman wrote :
As far as 4K blocks go, I wouldn't worry about it too much. 512 byte
sectors will be supported either natively or by emulation in the drive
itself for a long time to come - at least 5 to 10 years. Too many
existing systems depend on a 512
Eric Auer e.a...@jpberlin.de wrote :
Interestingly, even 3 TB disks are still sold with 512 byte sectors.
Conversely, even 1 TB USB disks are already sold with 2048 byte sectors ;=)
(...snipping much...)
By the way - a DRIVER could interface with any disk with
any sector size and then just
Op 14-1-2012 23:23, Eric Auer schreef:
Talking about new ways of booting, it would be very interesting to
have a CD / DVD / BD boot loader for DOS. However, after you loaded
the kernel, you still need some initrd from which you can load a
CD/... driver pair like UIDE + SHSUCDX or ...CDROM +
Bertho,
I spoke from the point of view of the device (the hard drive) - if the
hardware that the device is attached to chooses not to expose all of the
options that the device supports, there is little the device can do
about that. In the case of your external storage somebody made a design
FWIW:
In my USB disk driver (USBDRIVE), here's what I've done.
USBDRIVE does not try to virtualize the sector sizes as others are suggesting
here as a possibility -- I figure doing that has the potential to cause as many
problems as the alternative (using defective utilities/programs that are
Hi Bret,
USBDRIVE does not try to virtualize the sector sizes as others are
suggesting here as a possibility -- I figure doing that has the
potential to cause as many problems as the alternative...
Maybe you could make that configurable, so people can experiment
with virtual 512 byte sectors
In reply to : Michael B. Brutman mbbrut...@brutman.com
Michael,
So the bottom line is that DOS will probably work just fine
when
natively attached to storage devices, and that will work
for a long
time. Appliance storage devices are going to break
that if they can't
emulate 512 byte
In response to : Bret Johnson
Subj : MSDOS - increasing max sector size
...
Likewise, it will ignore disks with sector sizes larger
than what DOS says it can handle (this particular detail is
part of the easily accessible DOS List of Lists). In
the source code for USBDRIVE (starting at line
New follow-up ! In response to : Bret Johnson
Subj : MSDOS - increasing max sector size
quoting myself (sorry!) :
According to Rudolf Loew, increasing maximum sector size in LoL of an
unpatched MSDOS will work up to 2048 byte sectors, not 4096 :( I have
not verified it for a fact.
Wow!
USBDRIVE does not try to virtualize the sector sizes as others are
suggesting here as a possibility -- I figure doing that has the
potential to cause as many problems as the alternative...
Maybe you could make that configurable, so people can experiment
with virtual 512 byte sectors at their
Hi Bret,
maybe virtual 512 byte sectors are actually not that evil:
Imagine a NORMAL 4096 byte sector based FAT32 filesystem.
Each cluster and each FAT will be a multiple of 4096 byte
in size, as will be the boot and fsinfo sectors. In FAT32
the root directory is just any directory, so like all
Hi Bret,
Not Bret, but I'll provide answers to 2 of your points.
BPB CHS geometry differs - but does a disk with 4096 byte
sectors allow CHS based access at all? I hope it does not.
you can't preclude it, it may for compatibility sake (at the int 13h
interface).
(big big snipping)
By
maybe virtual 512 byte sectors are actually not that evil:
Imagine a NORMAL 4096 byte sector based FAT32 filesystem.
...
Actually they are, or at least potentially are, at least from a compatibility
perspective. In the case of USB, the SCSI protocol is normally used. The
sector size is not
Dear Freedos-user List !
On Tue, 10 Jan 2012 19:00:30 + (GMT) I wrote :
Hi FreeDOS users and developers !
This is my first time posting to these lists, I hope I'm
not breaking etiquette in the act.
It's been a few days and I'm surprised my first mail hasn't been acknowledged
in any way,
Op 14-1-2012 19:48, Bertho Grandpied schreef:
It's been a few days and I'm surprised my first mail hasn't been acknowledged
in any way, let alone answered; strange, I've been part of various lists
before, usually 'newbies' are greeted rather than ignored altogether. So I'll
reiterate and
The list membership is not that large. You can assume that people are
busy or don't know the answer.
As far as 4K blocks go, I wouldn't worry about it too much. 512 byte
sectors will be supported either natively or by emulation in the drive
itself for a long time to come - at least 5 to 10
Hi Mike,
The list membership is not that large. You can assume that people are
busy or don't know the answer.
I was grepping though a backup of our FAQ (which is down, is it
worth the effort to replay a September 2008 backup? Apparently
SourceForge server directory structure changed...) but
At this time there are no plans to explicitly support 4K block sectors
directly in the kernel. The kernel itself does not support any block
devices directly, it relies on the BIOS interface, though additional
drives or support may be added through device drivers.
I would like to review the
Hi, Bernd!
should I try posting to the kernel or developers lists instead ?
Truth is we're not sure, this 4K sector size thing comes in several
versions:
1) emulation with aligned 512byte sector emulation
2) emulation with non-aligned 512byte sector emulation
3) native 4K (especially USB
Hi Eric,
I expect that in the next few years we'll see very large hard drives and
they will continue to support 512 byte sector sizes - that is what the
system manufacturers demand. The actual sector size of the drive might
be 4KB but the drive will allow the host to choose a 512 byte or 4KB
Hi Jeremy,
At this time there are no plans to explicitly support 4K block sectors
directly in the kernel. The kernel itself does not support any block
devices directly, it relies on the BIOS interface, though additional
drives or support may be added through device drivers.
Unfortunately,
Replaying a 12 May 2005 mail :-)
[Freedos-kernel] Analysis: Support for sector sizes != 512 bytes
Hi, I have browsed the CVS kernel a bit, and got the impression
that it would not be too hard to support sector sizes below 512
bytes (32, 64, 128 and 256 bytes should be possible). For sector
For what it is worth, my take on 4K-byte (or other-than-512
byte) sectors for DOS systems is very-much the same as Eric's
and I shall reply to some comments from one of his posts --
Also depending on your BIOS, you could have a limit of at
most 2^28, 2^32 or 2^48 sectors per disk ...
Not a
Hi Jack,
driver, I issue 28-bit commands for up to 28-bit addresses,
while I issue 48-bitters for larger addresses. Runs fine!
I meant if the BIOS only sees the first 2^N sectors and
the partition table describes more than that, UIDE will
probably not modify the BIOS-reported disk size: So
67 matches
Mail list logo
