Aitor Santamar�a Merino wrote: ...
actually current ATAPICDD, which is now split into cdrom.sys & ataspi.sys to separate the CD code from the IDE/ATAPI code uses FASM.
Could you extend a little bit on this?
ATASPI for the ATAPI/ASPI layer and CDROM over it (which means I need to load two drivers, isn't it?), or
ATASPI for ASPI CD-ROM, and CD-ROM for ATAPI or...?
And in this case, CDROM will be the char device and ATASPI a TSR...?
Aitor
2 drivers need to be loaded (well really three) for CD-ROM support in DOS using this driver. Just as SCSI devices, there is the ASPI layer
(depending on when/who you ask -- Adaptec/Advance SCSI Programming Interface or some such) which provides a mostly hardware independant interface. For AtatpiCDD this is for IDE/ATAPI devices instead of SCSI (here I'm referring to the general physical card, not necessarily SCSI specs in specific). Other ASPI drivers could be loaded for SCSI, USB, Firewire, parallel port, or whatever someone has the knowledge and time to write it for. Programs such as cdrecord, etc. can access the devices or you can load a device driver for DOS support. Each specific device has its own driver, such as for a hard drive (though its generally easier to use SCSI BIOS for these), scanner, CD-ROM, etc. AtapiCDD provides one for CD-Roms, that may work over other's ASPI layer. Then for a drive letter one would need to load shsucdx or compatible.
I have split it to ease development, as these are the two major logic pieces (the CD-ROM control/driver and the physical IDE/ATAPI interface). As CD-ROMs are controlled by what are essentially SCSI packets over an ATA(IDE) interface, using ASPI makes a convenient method to separate them allowing me to use a SCSI card or existing CD driver for testing.
Technically ATASPI is a Future Domain specification for ASPI over ATA, but is incompatible with current Adaptec defined ASPI in a few minor ways (mostly related to initially reserved flags and architectural limits of ATA/IDE devices).
From a distribution standpoint, this may allow us to simplify some, as the same CD-ROM driver could be used, with users only needing to provide alternate ASPI drivers (depending on their SCSI card or interface). For most of us used to IDE devices, this may seem a little odd at first, but should be easy enough for anyone used to SCSI cards. This also allows for better support of programs such as cd writing.
And given it is public domain code (shortly to be availble via a public cvs repository) anyone can remerge into one driver or modify to suite individual needs.
Jeremy
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
