Hi, please check the Pascal driver sources for the DeskWork PCMCIA module (donated to public domain tonight, with extra comments by me, with help of the author... including PCMCIA <-> rest_of_DeskWork interfacing info) ->
http://www.coli.uni-sb.de/~eric/stuff/soft/by-others/deskwork-unit-pcmcia.pas The suggestion: Translate this to C and turn it into a RAMDISK style driver (or int 13 style or CDEX style driver or DRIVER,sys style or ...?) for DOS! The idea: Load as a disk driver (like RAMDISK), allocate some drive letters. For every access, check if devices are present and if they changes since the last access. Use this information to update the disk change flag, return a timeout error or similar if no storage device is present. For PARTITIONED storage (which PCMCIA / CardBus storage types are partitioned, which not?), I would suggest to implement only access to the first drive letter of each MBR to get started. For non-FAT drives, a CDEX style driver would be needed, but that would be a low-priority suggestion... Usual computers have 0, 1 or 2 single or double PCMCIA slots (double: one thick or 2 thin devices fit there). The TODO: Translate the Pascal stuff to C, combine with some generic disk driver skeleton (e.g. taken from a simple RAMDISK), implement sector I/O (suggestion: tweak 40[xx] data area to dynamically add IDE controllers - then the BIOS should be able to do most of the work. Else, check UDMA,sys to learn about direct disk I/O - the non-DMA and maybe even non-IRQ direct disk I/O equivalent of int 13.42 / 13.43 is actually quite simple to do...), implement error handling... The DONE: The released sources have lowlevel functions for PCMCIA bridge and slot configuration, midlevel functions to initialize slots with storage, modem and network devices (i.e. assign I/O ranges and bootstrap the device), and highlevel functions to enumerate the devices in the system. You call the enumerate in one variant for initial detection / boot messages and then as often as you want to update the list (-> hotplugging is possible!). There is a shutdown function, too. When an IDE device is found, the enumeration function can optionally call the initialization function (taking care to init every device not more often than appropriate...), and in the end the plugged device looks like a normal IDE controller (w/o IRQ/DMA support, I guess) for DOS, which can be accessed exactly like any other classic IDE controller (and will feel classic: only 1 drive per controller, no better IRQ/DMA than ISA style if at all). Let me know what you think of the project (e.g. the suggestions to use only 1 drive letter per slot and use a sys disk driver interface instead of an int 13, int 13 + driver,sys or shsucdx/mscdex/network redirector style one) ... and of course let me know how we could find helpers with that project! I am busy enough with other DOS related projects, but I can always help people who want to take on the project but want to have some questions answered first (including "how do I read Pascal source code at all?" ...!). Command line argument of the driver could control how many drive letters to assign (instead of 4, 1 per slot) and what base I/O address is used for the PCMCIA bridge control (otherwise you would have to include PCI and for some cases even ISA PnP bus scanning ability, which you can take from UDMA,sys source code or from the .c sources of one of my DOS projects, available on request...). I wonder whether 40:xx fiddling or BIOS-free disk I/O will be better - for both, I offer my help to figure things out, maybe I even have some code snippets in my archives ;-)). Would be cool if we could make FreeDOS PCMCIA (including external harddisks, Clik disks, CompactFlash / Memory Stick adapters, ...) "FAT style" storage support work! Thanks for your help already. [If nobody wants to work on this soon, then I recommend to make a technote of this mail and the other PCMCIA thing mail (which I just sent to freedos- devel), for later reference. Sending this to freedos-kernel, by the way, because I got the impression that kernel people know more about disks and drive letters than the wider devel audience, kind of. Please read both mails.] Eric PS: the .pas will probably be replaced by a .pas.gz or a zip file at some point in the future. Do not expect the exact URL to stay unchanged eternally. ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
