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
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 comp
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
On Sat, Feb 4, 2012 at 3:13 PM, Bertho Grandpied 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 author(s)
> limited s
Hi,
On Sat, Feb 4, 2012 at 9:50 AM, Bertho Grandpied wrote:
> Kenneth J. Davis wrote :
>
> TDSK is maintained by, IIRC, Mathias Paul - isn't Mathias on this list ? If
> so I was going to ask him if he couldn't do a quick and (not so) dirty build
> of the ramdisk driver with increased bytes per
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
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 th
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 cou
> 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 th
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 bu
On Wed, Jan 18, 2012 at 5:31 PM, BretJ 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 intended fo
Hi,
On Wed, Jan 18, 2012 at 4:31 PM, BretJ 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 int
> 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.
> 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
On Wed, Jan 18, 2012 at 2:23 PM, Bernd Blaauw 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 his old Sysinte
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 bootd
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 sugge
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).
http://panasonic.jp/com/support/drive/other/f2h_usb.html
http://www.hir
>> 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 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 earli
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 he
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 howe
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 probab
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 memo
> 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
> ...
> 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
d
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
> 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 25
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
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 actua
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 physical
> 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 n
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
>> 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 sector
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
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 sec
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
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
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 ...CDRO
Eric Auer 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 provide an int13
Eric,
>> ... 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 siz
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
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
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
siz
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.
Unfortunatel
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
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 FreeDO
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...) bu
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 y
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
50 matches
Mail list logo
