From: Bret J. <bre...@ju...> - 2012-01-29 15:21:25
|
As I was designing USBDRIVE, I considered writing it as a straight ASPI driver (similar to the architecture of DIDD1000 or ASPIDISK), but decided against it for a multitude of reasons. The most important reason was the lack of freely available DOS ASPI support programs (e.g., to format or partition a disk). I also decided against a simple device driver approach, like Georg did, for similar reasons. USBDRIVE provides a device driver, but also provides an INT 13h interface. There are lots of freely available DOS tools that will work with this type of architecture, since the USB disk appears to be a simple removable hard drive. DOS should have been natively supporting sectors other than 512 since the early 1980's, anyway. OTOH, an ASPI driver might make sense for USB CDs and DVDs instead of an MSCDEX-style driver approach, since ASPI allows for easy writing to disks instead of just reading. The standard MSCDEX-style drivers aren't set up for writing. My opinion, FWIW. |
From: Bertho G. <y31...@ya...> - 2012-01-29 17:31:51
|
In reply to: Bernd Blaauw <bblaauw@home...> > Op 29-1-2012 12:21, Bertho Grandpied schreef: >> Hard Disk -- USB (4K sectors) -- DOS with "usbaspi.sys" (ASPI manager) -- "didd1000.sys" (ASPI to DOS converter) (...) >> The ASPI to DOS converter is the part that has to > adapted, or else redone from scratch. I mm using Novac's > excellent DIDD1000.SYS as a reference, unfortunately as > distributed that assumes 512 byte sectors for hard disks. > From scratch would be most likely, I guess Brett's USB > drivers could > work as a foundation for that, as he mentions int13 (and > fdisk) support. We'll hear from Bret again I hope. I don't know if he has a separate SCSI emulation layer or rather a monolithic approach. > Not possessing an UHCI controller, I've got no way of > experimenting. > Finding and purchasing such a controller also seems to get > challenging. That, and the lack of EHCI (and higher) speeds is the problem of course with solution based on Bret's present drivers. He has already stated he's currently working on OHCI/UHCI. On the other hand, the USB interface problem is already resolved satisfactorily by USBASPI.SYS (several versions) - at least OHCI/UHCI/EHCI- The USBASPI.SYS I have been using (a Chinese? "Yaya DIY" hacked Panasonic version 2.27) works well and has no problems dealing with 4K sectors. Hence in this thread I proposed one should concentrate on the part which doesn't work yet with 4K sectors, the ASPI to DOS conversion : the part played by Motto Hairu or Novac"s DIDD1000.SYS, or several similar. (...) >> It is my understanding, in vague terms, that most >> stringent "anti reverse engineering" laws allow for >> independent fixes and enhancements to IP protected code, but >> IANAL. > I don't know about fixes and enhancements, but USA's DMCA > aside, usually > the cleanest way of writing another implementation of some > piece of > software is to use "cleanroom reverse-engineering": > * 1st team studies/disassembles/debugs and documents the > program into a > specification. > * 2nd team creates a piece of software out of this > specification Ideally, yes. But how do we DOS lovers recruit and feed those teams ? -- Czerno |
From: Bernd B. <bb...@ho...> - 2012-01-29 15:41:26
|
Op 29-1-2012 16:19, Bret Johnson schreef: > USBDRIVE provides a device driver, but also provides an INT 13h interface. There are lots of freely available DOS tools that will work with this type of architecture, since the USB disk appears to be a simple removable hard drive. DOS should have been natively supporting sectors other than 512 since the early 1980's, anyway. > > OTOH, an ASPI driver might make sense for USB CDs and DVDs instead of an MSCDEX-style driver approach, since ASPI allows for easy writing to disks instead of just reading. The standard MSCDEX-style drivers aren't set up for writing. Traditional SCSI controllers had the following layout: [1] Mass Storage Controller driver (SCSI/ASPI) (providing int13?) [2] Disk controller driver (usually not needed), hooks into [1] [3] CD driver (hooks into [1], thus independent of [2]). LUN-support [4] CDEX-driver (hooks into [4], giving a DOS driveletter) As USB and Firewire are simplified (ahem..) SCSI implementations anyway, various operating systems use SCSI stacks for this. Think IOMEGA used ASPI/SCSI also a lot for their infamous ZIP drives. I think some (Linux-based?) backup software went through ASPI. Most notable are indeed CD-writing software like CDRECORD and WODIM, only requiring [1] to be loaded to talk to a device. Some commercial USB/Firewire CD-drivers might also depend on ASPI. Jack has his own private reasons for not being a fan of ASPI, thus his UIDE driver (PCI IDE/SATA storage and optical disk driver) doesn't implement nor hook into ASPI. I'm not aware of opensource CD-writing software that doesn't require ASPI. My solution in VMware for example has been attaching the physical CD-drive as a SCSI (Buslogic) drive to the virtual machine, then loading the BTDOSM.SYS driver followed by using WODIM. Slightly more convenient/generic might be the ASPI.SYS driver by OAK Technologies. An opensource generic ASPI driver for USB and/or IDE could be a very nice addition. Even if your purpose is 4K sector support :) Bernd |
From: Jack <gyk...@ea...> - 2012-01-29 16:51:52
|
> Jack has his own private reasons for not being a fan of ASPI, thus his > UIDE driver (PCI IDE/SATA storage and optical disk driver) doesn't > implement nor hook into ASPI. I'm not aware of opensource CD-writing > software that doesn't require ASPI. Not entirely true -- UIDE can call "Int 13h" drivers for all types of hard-disks, and upon return from their drivers, UIDE will cache their read/write data, as well. If a SCSI disk has such a software driver or even a BIOS chip on its interface card that handles Int 13h calls, UIDE will "cache" such disks. What UIDE will NOT permit is handling any BIOS units flagged as being "removeable"!! One CANNOT be certain all DOS variants will handle a "media change" (new disk) within their Int 13h coding, which was done at a time when Int 13h hard-disks really were "HARD"! As I will NOT have UIDE get "blamed" for an older DOS system failing to "flush" its disk buffers on media-changes, UIDE will NOT handle "removeable" hard disk drives! That includes USB types! My "private" reasons for not liking ASPI are many -- 1) ASPI is too complex. Whatever happened to a SIMPLE interface that provides read/write and perhaps format commands only?? All other functions are rarely used by disks and should be diagnostic-only. 2) ASPI is mainly for SCSI drives, which are expensive, same as their $200+ controller cards. You get IDE for nothing, last I heard. 3) In 1998, I came back to California to take a job at Adaptec, after 4 years in Utah, only to find that the man who would have been "my boss" hadn't cleared my paperwork before offering me the job, i.e. I had NO job!! Absolutely UNETHICAL, and INEXCUSABLE, and I have had nothing to say for that man, nor for Adaptec, from then on! If the idea of doing drivers for USB is still "open", why NOT write a simple Int 13h driver that handles disk reads/writes only, instead of "obeying" the full SCSI/ASPI set of rules simply because they ARE the so-called "rules"?? In 1980, an associate of mine "took one look" at a 750K video package [done in "C" of course!], and he noted "They've got GUTS calling THAT a 'driver'"!! I have precisely the same feelings about a lot of the software for using USB, thus far. Something simpler/Better/SMALLER for USB disks and CDs/DVDs really is NECESSARY, people! Until we get it, I plan to avoid all USB devices like the PLAGUE! |
From: Bernd B. <bb...@ho...> - 2012-01-29 17:30:36
|
Op 29-1-2012 17:52, Jack schreef: > What UIDE will NOT permit is handling any BIOS units flagged as being > "removeable"!! One CANNOT be certain all DOS variants will handle a > "media change" (new disk) within their Int 13h coding, which was done > at a time when Int 13h hard-disks really were "HARD"! As I will NOT > have UIDE get "blamed" for an older DOS system failing to "flush" its > disk buffers on media-changes, UIDE will NOT handle "removeable" hard > disk drives! That includes USB types! It's a good protection method indeed. I don't think anyone actually removes USB storage disks in DOS, sounds way too suicidal with regard to bootsector/MBR and data contents on the device itself. I've used MEMDISK's disk-hiding capacibilities, but still not dare remove the USB drive (suppose you boot from a flash device in USB1.1 controller, then load ramdisk, then pause, put flash device in a faster non-bootable USB3 port, then continue from pausing, then load USB driver to load rest of the USB flash device in a faster way than 150KB/s) > 1) ASPI is too complex. Whatever happened to a SIMPLE interface that > provides read/write and perhaps format commands only?? All other > functions are rarely used by disks and should be diagnostic-only. Ah yeah, diagnostic software. I never use those I'm afraid, easier to start over. I've got no idea how complex ASPI really is, but the API seemed doable, it's just that each and every piece of hardware had its own specific drivers instead of generic ones. > 2) ASPI is mainly for SCSI drives, which are expensive, same as their > $200+ controller cards. You get IDE for nothing, last I heard. IDE is usually onboard indeed, except if going for some add-on card, be it a non-raid or raid card. Due to BIOS/DOS, it's often not needed to load drivers for the interface and disks, only for CD drives. Your UIDE driver does load for interface, not for disks ( I mean partition recognition here instead kernel doesn't do it) and at same time also for optical drives. It combines [1] and [3] out of the list I made in an earlier mail. I don't think currently any driver exists for IDE harddisk partition enumeration as all DOS kernels do that by default at boot-time. > > 3) In 1998, I came back to California to take a job at Adaptec, after > 4 years in Utah, only to find that the man who would have been "my > boss" hadn't cleared my paperwork before offering me the job, i.e. > I had NO job!! Absolutely UNETHICAL, and INEXCUSABLE, and I have > had nothing to say for that man, nor for Adaptec, from then on! You mentioned that in years before indeed, I'd consider it a decent private reason to never look back at such stuff. > If the idea of doing drivers for USB is still "open", why NOT write a > simple Int 13h driver that handles disk reads/writes only, instead of > "obeying" the full SCSI/ASPI set of rules simply because they ARE the > so-called "rules"?? Georg created a slightly simplified version of a full implementation. The problem with these kinds of things is things can become very complicated if doing technical stuff. For example an USB stick connected to an USB hub inside a USB keyboard, connected to front USB ports (USB hub thus) connected to motherboard port (USB hub) connected to USB controller. Any single USB-stack driver-loading seems to completely override BIOS USB emulation on a per-controller or complete basis. Keyboard emulation no longer working due to loading an USB storage driver is painful. > In 1980, an associate of mine "took one look" at a 750K video package > [done in "C" of course!], and he noted "They've got GUTS calling THAT > a 'driver'"!! I have precisely the same feelings about a lot of the > software for using USB, thus far. It's not getting easier indeed. I'm noticing the same in the stuff I have to implement on the FreeDOS distribution. Boot from an USB CD-drive, load DOS USB-storage driver and you're suddenly working from a non-accessible drive. Same for a bootdisk in USB floppy drive. > Something simpler/Better/SMALLER for USB disks and CDs/DVDs really is > NECESSARY, people! Until we get it, I plan to avoid all USB devices > like the PLAGUE! Let's see what Bret comes up with, I'd be interesting in playing with OHCI (as my machine has) instead of UHCI (unless buying something like a VIA/Intel based controller, as is [ http://eu.startech.com/Cards-Adapters/USB-2/Card/7-Port-PCI-Express-Low-Profile-High-Speed-USB-20-Adapter-Card~PEXUSB7LP ] ) If your machine still fits your purposes, by all means stick to it :) Bernd |