Hi!
To put it in un-technical terms, I am talking about a block
device driver which tells the kernel "hey here is a nice FAT
partition, 512 bytes per sector" but when a DOS kernel asks
the driver to read or write sectors in that partition, the
driver will actually access a 4096 byte per sector di
Op 21-2-2012 22:47, Bertho Grandpied schreef:
> Hi, FreeDOS-devel !
>
> Upon C. Masloch's harsh request\\kind invitation, I'm joining
> Freedos-devel now and shall continue this question here that started in
> Freedos-user. Apologies to anybody this change of venue may inconvenience.
Wel
Hi, FreeDOS-devel !
Upon C. Masloch's harsh request\\kind invitation, I'm joining
Freedos-devel now and shall continue this question here that started in
Freedos-user. Apologies to anybody this change of venue may inconvenience.
--
On Mon, 20 Feb 2012 11:15
> Oh? I wasn't aware. I was assuming everyone thought of the lower
> interface as to a block device driver that presents 4 KiB sectors.
So you were thinking everyone was talking about a "shim"? I agree that would
be the best approach, as it could then be used for all kinds of devices, not
just
> You and Eric are discussing it in "general" technical terms, i.e., not
> talking about what the "downward" side is (ASPI, INT 13h, a "shim"
> between a non-compliant kernel and a device driver, etc.). Bertho is
> talking about a specific (USB)ASPI implementation.
Oh? I wasn't aware. I was
> Questions of licence aside, is that so? I was under the impression
> that a general transformation driver would simply load a different
> block device driver (here: DI1000DD) to interface with, downwards.
You and Eric are discussing it in "general" technical terms, i.e., not talking
about what
> What is being discussed here would essentially be a replacement for
> DI1000DD.SYS, not an adjunct to it.
Questions of licence aside, is that so? I was under the impression that a
general transformation driver would simply load a different block device
driver (here: DI1000DD) to interface
> You either lack understanding of the involved request and issues, or
> your writing lacks in showing your understanding.
Correct. What is being discussed here would essentially be a replacement for
DI1000DD.SYS, not an adjunct to it. From a licensing perspective, I don't
believe either USBAS
> it would be one of the best ways, to get panasonic USBASPI.SYS 2.27
> (only!)
> and matsushita
> DI1000DD.SYS ("motto hairu")
> going on a usb drive, say a 1/2 terabyte one, like i've got,
> then adapt everything over to the 4k-sector standard
it would be one of the best ways, to get panasonic USBASPI.SYS 2.27 (only!)
and matsushita DI1000DD.SYS
("motto hairu")
going on a usb drive, say a 1/2 terabyte one, like i've got,
then adapt everything over to the 4k-sector standard with
the eq
10 matches
Mail list logo
