I've been experimenting with 68k driver development with codewarrior and the results so far are a very simplistic, but apparently functional ramdisk driver. It's not at all useful on its own, but represents lots of information collected into a somewhat usable form. Hopefully it can be useful to others learning this stuff as well.
Basically, there's the 'memdrv' project that builds the driver that handles open/close/prime/control/status calls. MacOS drivers don't follow C or Pascal calling conventions, so assembly glue is necessary. Codewarrior automatically generates this glue, and funnels all driver calls to main() in the form of:
Where the paramblock and dctlentry pointers are pointers to the IOParam/CntlParam structure and dctlentry is the Device Control Entry structure. cmd is whether the call is Open, Prime, Control, Status, Close.
Once that's all straightened out, you've got yourself a driver in the form of a DRVR resource.
However, getting a driver is only half the battle. Next up is loading the driver, and in this project is handled by the 'loaddrv' codewarrior project. Essentially, it loads the DRVR resource (the actual driver built above), traverses the UnitTable (a table of pointers to device control entries) looking for an empty slot in a valid range, and calls OpenDriver to create the DCE structure for the DRVR resource, and insert it into the UnitTable at the slot found earlier.
Once the driver is loaded, it has to let the File Manager know a new disk is available. It then finds the drive queue, locates an available drive number, creates a DrvQEl structure, and inserts the structure representing the disk into the system's drive queue. After that, the memory disk isn't initialized with any known filesystem, so it still can't actually be used. 'loaddrv' then uses DIZero() to initialize the disk, and from this point, it should show up in the finder and be usable.
A word of caution when testing this, don't quit the loaddrv.A application until after you've ejected the disk. The resources are allocated within the context of the app instead of the system, so quitting while the driver is in use will cause a crash/hang.
Anyway, the code is here
Basically, there's the 'memdrv' project that builds the driver that handles open/close/prime/control/status calls. MacOS drivers don't follow C or Pascal calling conventions, so assembly glue is necessary. Codewarrior automatically generates this glue, and funnels all driver calls to main() in the form of:
Code:
short main(Ptr paramblock, Ptr dctlentry, short cmd)
Once that's all straightened out, you've got yourself a driver in the form of a DRVR resource.
However, getting a driver is only half the battle. Next up is loading the driver, and in this project is handled by the 'loaddrv' codewarrior project. Essentially, it loads the DRVR resource (the actual driver built above), traverses the UnitTable (a table of pointers to device control entries) looking for an empty slot in a valid range, and calls OpenDriver to create the DCE structure for the DRVR resource, and insert it into the UnitTable at the slot found earlier.
Once the driver is loaded, it has to let the File Manager know a new disk is available. It then finds the drive queue, locates an available drive number, creates a DrvQEl structure, and inserts the structure representing the disk into the system's drive queue. After that, the memory disk isn't initialized with any known filesystem, so it still can't actually be used. 'loaddrv' then uses DIZero() to initialize the disk, and from this point, it should show up in the finder and be usable.
A word of caution when testing this, don't quit the loaddrv.A application until after you've ejected the disk. The resources are allocated within the context of the app instead of the system, so quitting while the driver is in use will cause a crash/hang.
Anyway, the code is here