Did CP/M support custom hardware using device drivers?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












10















MS DOS Ver 1.0 did not have OS support for device drivers. DOS ver2 added support for device drivers in the config.sys file during boot with the "DEVICE=[path][filename][parameters]".



  1. Did CP/M have OS support for device drivers?

  2. Did DOS ver1 leave device drivers out, or was DOS v2 device support a new advancement over CPM?









share|improve this question
























  • You could have custom device drivers in CP/M, but you'd have to recompile CP/M to use them (an approach similar to many other systems at that time). Not sure if that was the kind of "support" you had in mind.

    – dirkt
    Mar 14 at 7:07











  • Your question sounds a bit as if you assumed that MS-DOS implemented everything like CP/M - No, it actually didn't - The user-visible concepts were somewhat aligned, like 8+3 filenames and a loadable command processor. MS-DOS did not implement a BIOS, but expected that to be supplied by the firmware. Actually, I think there were more differences than similarities.

    – tofro
    Mar 14 at 10:54







  • 3





    @tofro The CP/M BIOS, BDOS and Console Command Processor corresponded to the MS-DOS files IO.SYS, MSDOS.SYS and COMMAND.COM (or the PC-DOS files IBMIO.SYS, IBMDOS.SYS and COMMAND.COM). Although there was another layer of system calls below the OS, still called the BIOS, MS-DOS was also available for clones without a PC BIOS, and came with a different IO.SYS. Windows 95 changed MSDOS.SYS into a text configuration file.

    – Davislor
    Mar 14 at 15:44






  • 1





    @tofro MS-DOS did everythign exactly like CP/M - this includes the BIOS - here called IO.SYS. ROM BIOS was only meant to keep IO.SYS small.

    – Raffzahn
    Mar 14 at 21:23















10















MS DOS Ver 1.0 did not have OS support for device drivers. DOS ver2 added support for device drivers in the config.sys file during boot with the "DEVICE=[path][filename][parameters]".



  1. Did CP/M have OS support for device drivers?

  2. Did DOS ver1 leave device drivers out, or was DOS v2 device support a new advancement over CPM?









share|improve this question
























  • You could have custom device drivers in CP/M, but you'd have to recompile CP/M to use them (an approach similar to many other systems at that time). Not sure if that was the kind of "support" you had in mind.

    – dirkt
    Mar 14 at 7:07











  • Your question sounds a bit as if you assumed that MS-DOS implemented everything like CP/M - No, it actually didn't - The user-visible concepts were somewhat aligned, like 8+3 filenames and a loadable command processor. MS-DOS did not implement a BIOS, but expected that to be supplied by the firmware. Actually, I think there were more differences than similarities.

    – tofro
    Mar 14 at 10:54







  • 3





    @tofro The CP/M BIOS, BDOS and Console Command Processor corresponded to the MS-DOS files IO.SYS, MSDOS.SYS and COMMAND.COM (or the PC-DOS files IBMIO.SYS, IBMDOS.SYS and COMMAND.COM). Although there was another layer of system calls below the OS, still called the BIOS, MS-DOS was also available for clones without a PC BIOS, and came with a different IO.SYS. Windows 95 changed MSDOS.SYS into a text configuration file.

    – Davislor
    Mar 14 at 15:44






  • 1





    @tofro MS-DOS did everythign exactly like CP/M - this includes the BIOS - here called IO.SYS. ROM BIOS was only meant to keep IO.SYS small.

    – Raffzahn
    Mar 14 at 21:23













10












10








10








MS DOS Ver 1.0 did not have OS support for device drivers. DOS ver2 added support for device drivers in the config.sys file during boot with the "DEVICE=[path][filename][parameters]".



  1. Did CP/M have OS support for device drivers?

  2. Did DOS ver1 leave device drivers out, or was DOS v2 device support a new advancement over CPM?









share|improve this question
















MS DOS Ver 1.0 did not have OS support for device drivers. DOS ver2 added support for device drivers in the config.sys file during boot with the "DEVICE=[path][filename][parameters]".



  1. Did CP/M have OS support for device drivers?

  2. Did DOS ver1 leave device drivers out, or was DOS v2 device support a new advancement over CPM?






ms-dos software-development cp-m






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Mar 15 at 7:20









Thorbjørn Ravn Andersen

31919




31919










asked Mar 14 at 1:17









jwzumwaltjwzumwalt

2,09141640




2,09141640












  • You could have custom device drivers in CP/M, but you'd have to recompile CP/M to use them (an approach similar to many other systems at that time). Not sure if that was the kind of "support" you had in mind.

    – dirkt
    Mar 14 at 7:07











  • Your question sounds a bit as if you assumed that MS-DOS implemented everything like CP/M - No, it actually didn't - The user-visible concepts were somewhat aligned, like 8+3 filenames and a loadable command processor. MS-DOS did not implement a BIOS, but expected that to be supplied by the firmware. Actually, I think there were more differences than similarities.

    – tofro
    Mar 14 at 10:54







  • 3





    @tofro The CP/M BIOS, BDOS and Console Command Processor corresponded to the MS-DOS files IO.SYS, MSDOS.SYS and COMMAND.COM (or the PC-DOS files IBMIO.SYS, IBMDOS.SYS and COMMAND.COM). Although there was another layer of system calls below the OS, still called the BIOS, MS-DOS was also available for clones without a PC BIOS, and came with a different IO.SYS. Windows 95 changed MSDOS.SYS into a text configuration file.

    – Davislor
    Mar 14 at 15:44






  • 1





    @tofro MS-DOS did everythign exactly like CP/M - this includes the BIOS - here called IO.SYS. ROM BIOS was only meant to keep IO.SYS small.

    – Raffzahn
    Mar 14 at 21:23

















  • You could have custom device drivers in CP/M, but you'd have to recompile CP/M to use them (an approach similar to many other systems at that time). Not sure if that was the kind of "support" you had in mind.

    – dirkt
    Mar 14 at 7:07











  • Your question sounds a bit as if you assumed that MS-DOS implemented everything like CP/M - No, it actually didn't - The user-visible concepts were somewhat aligned, like 8+3 filenames and a loadable command processor. MS-DOS did not implement a BIOS, but expected that to be supplied by the firmware. Actually, I think there were more differences than similarities.

    – tofro
    Mar 14 at 10:54







  • 3





    @tofro The CP/M BIOS, BDOS and Console Command Processor corresponded to the MS-DOS files IO.SYS, MSDOS.SYS and COMMAND.COM (or the PC-DOS files IBMIO.SYS, IBMDOS.SYS and COMMAND.COM). Although there was another layer of system calls below the OS, still called the BIOS, MS-DOS was also available for clones without a PC BIOS, and came with a different IO.SYS. Windows 95 changed MSDOS.SYS into a text configuration file.

    – Davislor
    Mar 14 at 15:44






  • 1





    @tofro MS-DOS did everythign exactly like CP/M - this includes the BIOS - here called IO.SYS. ROM BIOS was only meant to keep IO.SYS small.

    – Raffzahn
    Mar 14 at 21:23
















You could have custom device drivers in CP/M, but you'd have to recompile CP/M to use them (an approach similar to many other systems at that time). Not sure if that was the kind of "support" you had in mind.

– dirkt
Mar 14 at 7:07





You could have custom device drivers in CP/M, but you'd have to recompile CP/M to use them (an approach similar to many other systems at that time). Not sure if that was the kind of "support" you had in mind.

– dirkt
Mar 14 at 7:07













Your question sounds a bit as if you assumed that MS-DOS implemented everything like CP/M - No, it actually didn't - The user-visible concepts were somewhat aligned, like 8+3 filenames and a loadable command processor. MS-DOS did not implement a BIOS, but expected that to be supplied by the firmware. Actually, I think there were more differences than similarities.

– tofro
Mar 14 at 10:54






Your question sounds a bit as if you assumed that MS-DOS implemented everything like CP/M - No, it actually didn't - The user-visible concepts were somewhat aligned, like 8+3 filenames and a loadable command processor. MS-DOS did not implement a BIOS, but expected that to be supplied by the firmware. Actually, I think there were more differences than similarities.

– tofro
Mar 14 at 10:54





3




3





@tofro The CP/M BIOS, BDOS and Console Command Processor corresponded to the MS-DOS files IO.SYS, MSDOS.SYS and COMMAND.COM (or the PC-DOS files IBMIO.SYS, IBMDOS.SYS and COMMAND.COM). Although there was another layer of system calls below the OS, still called the BIOS, MS-DOS was also available for clones without a PC BIOS, and came with a different IO.SYS. Windows 95 changed MSDOS.SYS into a text configuration file.

– Davislor
Mar 14 at 15:44





@tofro The CP/M BIOS, BDOS and Console Command Processor corresponded to the MS-DOS files IO.SYS, MSDOS.SYS and COMMAND.COM (or the PC-DOS files IBMIO.SYS, IBMDOS.SYS and COMMAND.COM). Although there was another layer of system calls below the OS, still called the BIOS, MS-DOS was also available for clones without a PC BIOS, and came with a different IO.SYS. Windows 95 changed MSDOS.SYS into a text configuration file.

– Davislor
Mar 14 at 15:44




1




1





@tofro MS-DOS did everythign exactly like CP/M - this includes the BIOS - here called IO.SYS. ROM BIOS was only meant to keep IO.SYS small.

– Raffzahn
Mar 14 at 21:23





@tofro MS-DOS did everythign exactly like CP/M - this includes the BIOS - here called IO.SYS. ROM BIOS was only meant to keep IO.SYS small.

– Raffzahn
Mar 14 at 21:23










3 Answers
3






active

oldest

votes


















22














The answer depends on the version.



CP/M 2.2 did not support any loadable device drivers. There simply was no provisioning to do that. Originally, the in-built device drivers were limited to storage, console, and serial drivers. The system vendor could extend the BIOS with new devices, but that was fixed during the system build and nothing was loadable on demand. (Some of the mechanisms described below were, however, back-ported into 2.2 and alike systems like MP/M)



CP/M 3.0 actually did support loadable system extensions (Resident System Extensions, RSX). These extensions were loaded resident into the computer and could extend the BDOS with new calls. A similar, but not identical expansion was GSX, a loadable extension to support graphical devices like terminals and printers, that itself relied on device-specific loadable drivers. These extensions implemented a standardized way of calling specific new vendor-defined system calls.



Some CP/M vendors, notably Amstrad/Sinclair (thus, Locomotive Software), implemented loadable system extensions on top of that - Amstrad/Sinclair CP/M 3.0 implemented a concept of FID (Field Installable Device drivers) that allowed extending the BIOS with support for new devices (hard disks or RAM disks, for example) without touching the original code. CP/M 3.0 for the ZX Spectrum 3 comes with a RAM disk driver as FID in source code, for example, that implements a drive M:.






share|improve this answer

























  • The GSX drivers are PRL files upload.wikimedia.org/wikipedia/commons/9/91/Cbasic.svg

    – Polluks
    Mar 14 at 12:06






  • 1





    Given the lack of memory protection, it's not really true that things were not loadable on demand. One could very easily overwrite parts of the loaded operating system with new code to extend it - that may not have been widely known and common until the MS-DOS era of terminate and stay resident programs, but it was definitely possible and probably done by a few. What was missing were hooks in standard places to make linking easy. Though even those weren't entirely unheard in software of the era, for example Wordstar had a manual listing routines in the binary offered for patching.

    – Chris Stratton
    Mar 14 at 19:42












  • Drats, I forgot about the RSX part :)) - Then again, CP/M 3.0 came way after DOS 1.0, didn't it?

    – Raffzahn
    Mar 14 at 21:20












  • @Raffzahn yes,it did - but how does that matter?

    – tofro
    Mar 14 at 21:31






  • 1





    @Raffzahn Like in "Give me a cup of coffee, but leave out the milk?". ;) But that's splitting hair. Maybe the OP wants to help us here what he intended.

    – tofro
    Mar 14 at 22:53



















9














CPM 2.2, the most widely used and generally the progenitor of MS-DOS, supported only a few predefined devices via its BIOS.



These were:



  • console input and output

  • a listing device (printer) output

  • a punch (presumable paper tape) output

  • a reader (also paper tape) input

  • various calls to control a mass storage device (floppy disk)

and that was that.



No loadable device drivers, even though there were a few terminate and stay resident style things, I have no references for those.



Generally, memory was so tight on these old machines that nobody wanted to load anything extra.



More info on the BIOS can be found here: CPM 2.2 Alteration Guide






share|improve this answer
































    9















    Did CPM support custom hardware using device drivers?




    Yes, of course, that's what the BIOS was for.



    The title is somewhat misleading, as from the question body it seems you're asking about loadable device drivers, where loadable means that drivers were loaded at startup (or later) from separate binaries and linked into the system to offer their services. Further it seems as if the question is about CP/M prior to 1981, the time MS-DOS was introduced, thus CP/M 2.2 and MP/M. Right?




    Did CPM have OS support for device drivers?




    • Yes, as part of the customized BIOS.


    • No, CP/M did not have loadable device drivers (*1).


    All drivers were a part of the BIOS (Assembly) code. DR supplied sample code to customize the BIOS for system builders (buyers of a non dedicated CP/M licence).



    Adding new devices worked much the same way on CP/M and MS-DOS 1.x. In both cases new devices had to fit the existing structure of BIOS calls (17 for CP/M 2.2) (*2). New devices must be compiled into the BIOS (*3)




    Did DOS ver1 leave device drivers out, or was DOS v2 device support a new advancement over CPM?




    Loadable drivers were newly added to MS-DOS 2.0. To some degree it was part of the step toward a unixoid system structure for DOS, like adding subdirectories even including a virtual /dev directory for devices.



    Except, it never went fully that way. Much was added (including IOCTRL), but device drivers still had to fit for most parts the existing structure, which wasn't always up to the task. For the CD-ROM driver this meant that it had to hook itself as a network driver (introduced with DOS 3.1) and present the disk as a remote directory assigned to a drive letter instead of simply a disk.




    *1 - There's a 'yes but' part: With GSX, CP/M introduced loadable device drivers much like MS-DOS 2.0, but that's after MS-DOS was created.



    *2 - Another 'but': With MP/M and later CP/M 3.0 (CP/M Plus), the Character Device Table was introduced. Here an arbitrary number of character devices could be added by system builders, using 6 character names to identify them. Assignment to the logical devices was done using the DEVICE utility and controlled by according BIOS calls.



    So while for block devices system builders had to assign a hard disk number to a new device, they could use sounding names for character devices. The default table size was 12 entries for each (In/Out), enabling limited run time extension within the existing structure.



    *3 - It was possible (and done) to add new devices during run time by hooking the BIOS entry table and catching/redirecting calls for a drive. Unlike MS-DOS, CP/M did not provide a TSR functionality, so everything dynamic was up to detailed system knowledge and patching.






    share|improve this answer

























    • CP/M Plus uses a 16-bit word to hold character device assignments, so wouldn't be able to support more than 16 character devices at a time. There are some comments in the source code suggesting that four are reserved for intended future functionality, leaving the 12 table entries.

      – john_e
      Mar 14 at 10:26











    • @john_e interesting. I only remembered that the character device table itself was null terminated, thus of arbitrary length.

      – Raffzahn
      Mar 14 at 21:18











    • The limit of 12 is on page 54 of the CP/M 3 System Guide (§3.4.2, 'Character I/O Functions'). One hint at what may have been intended: if you manually assign physical device 15 (by setting bit 0 of the word at SCB+28h, for example), DEVICE will show this as 'File'.

      – john_e
      Mar 14 at 21:55











    • @john_e You do not need to convince me any further, I do not doubt your explanation in any way. What makes you think otherwise?

      – Raffzahn
      Mar 14 at 21:59












    • I didn't think you were doubting me - I just wanted to add more detail once I had my references to check.

      – john_e
      Mar 14 at 22:31











    Your Answer








    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "648"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader:
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    ,
    noCode: true, onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













    draft saved

    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f9356%2fdid-cp-m-support-custom-hardware-using-device-drivers%23new-answer', 'question_page');

    );

    Post as a guest















    Required, but never shown

























    3 Answers
    3






    active

    oldest

    votes








    3 Answers
    3






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    22














    The answer depends on the version.



    CP/M 2.2 did not support any loadable device drivers. There simply was no provisioning to do that. Originally, the in-built device drivers were limited to storage, console, and serial drivers. The system vendor could extend the BIOS with new devices, but that was fixed during the system build and nothing was loadable on demand. (Some of the mechanisms described below were, however, back-ported into 2.2 and alike systems like MP/M)



    CP/M 3.0 actually did support loadable system extensions (Resident System Extensions, RSX). These extensions were loaded resident into the computer and could extend the BDOS with new calls. A similar, but not identical expansion was GSX, a loadable extension to support graphical devices like terminals and printers, that itself relied on device-specific loadable drivers. These extensions implemented a standardized way of calling specific new vendor-defined system calls.



    Some CP/M vendors, notably Amstrad/Sinclair (thus, Locomotive Software), implemented loadable system extensions on top of that - Amstrad/Sinclair CP/M 3.0 implemented a concept of FID (Field Installable Device drivers) that allowed extending the BIOS with support for new devices (hard disks or RAM disks, for example) without touching the original code. CP/M 3.0 for the ZX Spectrum 3 comes with a RAM disk driver as FID in source code, for example, that implements a drive M:.






    share|improve this answer

























    • The GSX drivers are PRL files upload.wikimedia.org/wikipedia/commons/9/91/Cbasic.svg

      – Polluks
      Mar 14 at 12:06






    • 1





      Given the lack of memory protection, it's not really true that things were not loadable on demand. One could very easily overwrite parts of the loaded operating system with new code to extend it - that may not have been widely known and common until the MS-DOS era of terminate and stay resident programs, but it was definitely possible and probably done by a few. What was missing were hooks in standard places to make linking easy. Though even those weren't entirely unheard in software of the era, for example Wordstar had a manual listing routines in the binary offered for patching.

      – Chris Stratton
      Mar 14 at 19:42












    • Drats, I forgot about the RSX part :)) - Then again, CP/M 3.0 came way after DOS 1.0, didn't it?

      – Raffzahn
      Mar 14 at 21:20












    • @Raffzahn yes,it did - but how does that matter?

      – tofro
      Mar 14 at 21:31






    • 1





      @Raffzahn Like in "Give me a cup of coffee, but leave out the milk?". ;) But that's splitting hair. Maybe the OP wants to help us here what he intended.

      – tofro
      Mar 14 at 22:53
















    22














    The answer depends on the version.



    CP/M 2.2 did not support any loadable device drivers. There simply was no provisioning to do that. Originally, the in-built device drivers were limited to storage, console, and serial drivers. The system vendor could extend the BIOS with new devices, but that was fixed during the system build and nothing was loadable on demand. (Some of the mechanisms described below were, however, back-ported into 2.2 and alike systems like MP/M)



    CP/M 3.0 actually did support loadable system extensions (Resident System Extensions, RSX). These extensions were loaded resident into the computer and could extend the BDOS with new calls. A similar, but not identical expansion was GSX, a loadable extension to support graphical devices like terminals and printers, that itself relied on device-specific loadable drivers. These extensions implemented a standardized way of calling specific new vendor-defined system calls.



    Some CP/M vendors, notably Amstrad/Sinclair (thus, Locomotive Software), implemented loadable system extensions on top of that - Amstrad/Sinclair CP/M 3.0 implemented a concept of FID (Field Installable Device drivers) that allowed extending the BIOS with support for new devices (hard disks or RAM disks, for example) without touching the original code. CP/M 3.0 for the ZX Spectrum 3 comes with a RAM disk driver as FID in source code, for example, that implements a drive M:.






    share|improve this answer

























    • The GSX drivers are PRL files upload.wikimedia.org/wikipedia/commons/9/91/Cbasic.svg

      – Polluks
      Mar 14 at 12:06






    • 1





      Given the lack of memory protection, it's not really true that things were not loadable on demand. One could very easily overwrite parts of the loaded operating system with new code to extend it - that may not have been widely known and common until the MS-DOS era of terminate and stay resident programs, but it was definitely possible and probably done by a few. What was missing were hooks in standard places to make linking easy. Though even those weren't entirely unheard in software of the era, for example Wordstar had a manual listing routines in the binary offered for patching.

      – Chris Stratton
      Mar 14 at 19:42












    • Drats, I forgot about the RSX part :)) - Then again, CP/M 3.0 came way after DOS 1.0, didn't it?

      – Raffzahn
      Mar 14 at 21:20












    • @Raffzahn yes,it did - but how does that matter?

      – tofro
      Mar 14 at 21:31






    • 1





      @Raffzahn Like in "Give me a cup of coffee, but leave out the milk?". ;) But that's splitting hair. Maybe the OP wants to help us here what he intended.

      – tofro
      Mar 14 at 22:53














    22












    22








    22







    The answer depends on the version.



    CP/M 2.2 did not support any loadable device drivers. There simply was no provisioning to do that. Originally, the in-built device drivers were limited to storage, console, and serial drivers. The system vendor could extend the BIOS with new devices, but that was fixed during the system build and nothing was loadable on demand. (Some of the mechanisms described below were, however, back-ported into 2.2 and alike systems like MP/M)



    CP/M 3.0 actually did support loadable system extensions (Resident System Extensions, RSX). These extensions were loaded resident into the computer and could extend the BDOS with new calls. A similar, but not identical expansion was GSX, a loadable extension to support graphical devices like terminals and printers, that itself relied on device-specific loadable drivers. These extensions implemented a standardized way of calling specific new vendor-defined system calls.



    Some CP/M vendors, notably Amstrad/Sinclair (thus, Locomotive Software), implemented loadable system extensions on top of that - Amstrad/Sinclair CP/M 3.0 implemented a concept of FID (Field Installable Device drivers) that allowed extending the BIOS with support for new devices (hard disks or RAM disks, for example) without touching the original code. CP/M 3.0 for the ZX Spectrum 3 comes with a RAM disk driver as FID in source code, for example, that implements a drive M:.






    share|improve this answer















    The answer depends on the version.



    CP/M 2.2 did not support any loadable device drivers. There simply was no provisioning to do that. Originally, the in-built device drivers were limited to storage, console, and serial drivers. The system vendor could extend the BIOS with new devices, but that was fixed during the system build and nothing was loadable on demand. (Some of the mechanisms described below were, however, back-ported into 2.2 and alike systems like MP/M)



    CP/M 3.0 actually did support loadable system extensions (Resident System Extensions, RSX). These extensions were loaded resident into the computer and could extend the BDOS with new calls. A similar, but not identical expansion was GSX, a loadable extension to support graphical devices like terminals and printers, that itself relied on device-specific loadable drivers. These extensions implemented a standardized way of calling specific new vendor-defined system calls.



    Some CP/M vendors, notably Amstrad/Sinclair (thus, Locomotive Software), implemented loadable system extensions on top of that - Amstrad/Sinclair CP/M 3.0 implemented a concept of FID (Field Installable Device drivers) that allowed extending the BIOS with support for new devices (hard disks or RAM disks, for example) without touching the original code. CP/M 3.0 for the ZX Spectrum 3 comes with a RAM disk driver as FID in source code, for example, that implements a drive M:.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Mar 15 at 6:04









    John Dallman

    3,6341817




    3,6341817










    answered Mar 14 at 9:03









    tofrotofro

    16.8k33597




    16.8k33597












    • The GSX drivers are PRL files upload.wikimedia.org/wikipedia/commons/9/91/Cbasic.svg

      – Polluks
      Mar 14 at 12:06






    • 1





      Given the lack of memory protection, it's not really true that things were not loadable on demand. One could very easily overwrite parts of the loaded operating system with new code to extend it - that may not have been widely known and common until the MS-DOS era of terminate and stay resident programs, but it was definitely possible and probably done by a few. What was missing were hooks in standard places to make linking easy. Though even those weren't entirely unheard in software of the era, for example Wordstar had a manual listing routines in the binary offered for patching.

      – Chris Stratton
      Mar 14 at 19:42












    • Drats, I forgot about the RSX part :)) - Then again, CP/M 3.0 came way after DOS 1.0, didn't it?

      – Raffzahn
      Mar 14 at 21:20












    • @Raffzahn yes,it did - but how does that matter?

      – tofro
      Mar 14 at 21:31






    • 1





      @Raffzahn Like in "Give me a cup of coffee, but leave out the milk?". ;) But that's splitting hair. Maybe the OP wants to help us here what he intended.

      – tofro
      Mar 14 at 22:53


















    • The GSX drivers are PRL files upload.wikimedia.org/wikipedia/commons/9/91/Cbasic.svg

      – Polluks
      Mar 14 at 12:06






    • 1





      Given the lack of memory protection, it's not really true that things were not loadable on demand. One could very easily overwrite parts of the loaded operating system with new code to extend it - that may not have been widely known and common until the MS-DOS era of terminate and stay resident programs, but it was definitely possible and probably done by a few. What was missing were hooks in standard places to make linking easy. Though even those weren't entirely unheard in software of the era, for example Wordstar had a manual listing routines in the binary offered for patching.

      – Chris Stratton
      Mar 14 at 19:42












    • Drats, I forgot about the RSX part :)) - Then again, CP/M 3.0 came way after DOS 1.0, didn't it?

      – Raffzahn
      Mar 14 at 21:20












    • @Raffzahn yes,it did - but how does that matter?

      – tofro
      Mar 14 at 21:31






    • 1





      @Raffzahn Like in "Give me a cup of coffee, but leave out the milk?". ;) But that's splitting hair. Maybe the OP wants to help us here what he intended.

      – tofro
      Mar 14 at 22:53

















    The GSX drivers are PRL files upload.wikimedia.org/wikipedia/commons/9/91/Cbasic.svg

    – Polluks
    Mar 14 at 12:06





    The GSX drivers are PRL files upload.wikimedia.org/wikipedia/commons/9/91/Cbasic.svg

    – Polluks
    Mar 14 at 12:06




    1




    1





    Given the lack of memory protection, it's not really true that things were not loadable on demand. One could very easily overwrite parts of the loaded operating system with new code to extend it - that may not have been widely known and common until the MS-DOS era of terminate and stay resident programs, but it was definitely possible and probably done by a few. What was missing were hooks in standard places to make linking easy. Though even those weren't entirely unheard in software of the era, for example Wordstar had a manual listing routines in the binary offered for patching.

    – Chris Stratton
    Mar 14 at 19:42






    Given the lack of memory protection, it's not really true that things were not loadable on demand. One could very easily overwrite parts of the loaded operating system with new code to extend it - that may not have been widely known and common until the MS-DOS era of terminate and stay resident programs, but it was definitely possible and probably done by a few. What was missing were hooks in standard places to make linking easy. Though even those weren't entirely unheard in software of the era, for example Wordstar had a manual listing routines in the binary offered for patching.

    – Chris Stratton
    Mar 14 at 19:42














    Drats, I forgot about the RSX part :)) - Then again, CP/M 3.0 came way after DOS 1.0, didn't it?

    – Raffzahn
    Mar 14 at 21:20






    Drats, I forgot about the RSX part :)) - Then again, CP/M 3.0 came way after DOS 1.0, didn't it?

    – Raffzahn
    Mar 14 at 21:20














    @Raffzahn yes,it did - but how does that matter?

    – tofro
    Mar 14 at 21:31





    @Raffzahn yes,it did - but how does that matter?

    – tofro
    Mar 14 at 21:31




    1




    1





    @Raffzahn Like in "Give me a cup of coffee, but leave out the milk?". ;) But that's splitting hair. Maybe the OP wants to help us here what he intended.

    – tofro
    Mar 14 at 22:53






    @Raffzahn Like in "Give me a cup of coffee, but leave out the milk?". ;) But that's splitting hair. Maybe the OP wants to help us here what he intended.

    – tofro
    Mar 14 at 22:53












    9














    CPM 2.2, the most widely used and generally the progenitor of MS-DOS, supported only a few predefined devices via its BIOS.



    These were:



    • console input and output

    • a listing device (printer) output

    • a punch (presumable paper tape) output

    • a reader (also paper tape) input

    • various calls to control a mass storage device (floppy disk)

    and that was that.



    No loadable device drivers, even though there were a few terminate and stay resident style things, I have no references for those.



    Generally, memory was so tight on these old machines that nobody wanted to load anything extra.



    More info on the BIOS can be found here: CPM 2.2 Alteration Guide






    share|improve this answer





























      9














      CPM 2.2, the most widely used and generally the progenitor of MS-DOS, supported only a few predefined devices via its BIOS.



      These were:



      • console input and output

      • a listing device (printer) output

      • a punch (presumable paper tape) output

      • a reader (also paper tape) input

      • various calls to control a mass storage device (floppy disk)

      and that was that.



      No loadable device drivers, even though there were a few terminate and stay resident style things, I have no references for those.



      Generally, memory was so tight on these old machines that nobody wanted to load anything extra.



      More info on the BIOS can be found here: CPM 2.2 Alteration Guide






      share|improve this answer



























        9












        9








        9







        CPM 2.2, the most widely used and generally the progenitor of MS-DOS, supported only a few predefined devices via its BIOS.



        These were:



        • console input and output

        • a listing device (printer) output

        • a punch (presumable paper tape) output

        • a reader (also paper tape) input

        • various calls to control a mass storage device (floppy disk)

        and that was that.



        No loadable device drivers, even though there were a few terminate and stay resident style things, I have no references for those.



        Generally, memory was so tight on these old machines that nobody wanted to load anything extra.



        More info on the BIOS can be found here: CPM 2.2 Alteration Guide






        share|improve this answer















        CPM 2.2, the most widely used and generally the progenitor of MS-DOS, supported only a few predefined devices via its BIOS.



        These were:



        • console input and output

        • a listing device (printer) output

        • a punch (presumable paper tape) output

        • a reader (also paper tape) input

        • various calls to control a mass storage device (floppy disk)

        and that was that.



        No loadable device drivers, even though there were a few terminate and stay resident style things, I have no references for those.



        Generally, memory was so tight on these old machines that nobody wanted to load anything extra.



        More info on the BIOS can be found here: CPM 2.2 Alteration Guide







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Mar 14 at 4:58









        manassehkatz

        3,132625




        3,132625










        answered Mar 14 at 2:00









        Peter CamilleriPeter Camilleri

        88439




        88439





















            9















            Did CPM support custom hardware using device drivers?




            Yes, of course, that's what the BIOS was for.



            The title is somewhat misleading, as from the question body it seems you're asking about loadable device drivers, where loadable means that drivers were loaded at startup (or later) from separate binaries and linked into the system to offer their services. Further it seems as if the question is about CP/M prior to 1981, the time MS-DOS was introduced, thus CP/M 2.2 and MP/M. Right?




            Did CPM have OS support for device drivers?




            • Yes, as part of the customized BIOS.


            • No, CP/M did not have loadable device drivers (*1).


            All drivers were a part of the BIOS (Assembly) code. DR supplied sample code to customize the BIOS for system builders (buyers of a non dedicated CP/M licence).



            Adding new devices worked much the same way on CP/M and MS-DOS 1.x. In both cases new devices had to fit the existing structure of BIOS calls (17 for CP/M 2.2) (*2). New devices must be compiled into the BIOS (*3)




            Did DOS ver1 leave device drivers out, or was DOS v2 device support a new advancement over CPM?




            Loadable drivers were newly added to MS-DOS 2.0. To some degree it was part of the step toward a unixoid system structure for DOS, like adding subdirectories even including a virtual /dev directory for devices.



            Except, it never went fully that way. Much was added (including IOCTRL), but device drivers still had to fit for most parts the existing structure, which wasn't always up to the task. For the CD-ROM driver this meant that it had to hook itself as a network driver (introduced with DOS 3.1) and present the disk as a remote directory assigned to a drive letter instead of simply a disk.




            *1 - There's a 'yes but' part: With GSX, CP/M introduced loadable device drivers much like MS-DOS 2.0, but that's after MS-DOS was created.



            *2 - Another 'but': With MP/M and later CP/M 3.0 (CP/M Plus), the Character Device Table was introduced. Here an arbitrary number of character devices could be added by system builders, using 6 character names to identify them. Assignment to the logical devices was done using the DEVICE utility and controlled by according BIOS calls.



            So while for block devices system builders had to assign a hard disk number to a new device, they could use sounding names for character devices. The default table size was 12 entries for each (In/Out), enabling limited run time extension within the existing structure.



            *3 - It was possible (and done) to add new devices during run time by hooking the BIOS entry table and catching/redirecting calls for a drive. Unlike MS-DOS, CP/M did not provide a TSR functionality, so everything dynamic was up to detailed system knowledge and patching.






            share|improve this answer

























            • CP/M Plus uses a 16-bit word to hold character device assignments, so wouldn't be able to support more than 16 character devices at a time. There are some comments in the source code suggesting that four are reserved for intended future functionality, leaving the 12 table entries.

              – john_e
              Mar 14 at 10:26











            • @john_e interesting. I only remembered that the character device table itself was null terminated, thus of arbitrary length.

              – Raffzahn
              Mar 14 at 21:18











            • The limit of 12 is on page 54 of the CP/M 3 System Guide (§3.4.2, 'Character I/O Functions'). One hint at what may have been intended: if you manually assign physical device 15 (by setting bit 0 of the word at SCB+28h, for example), DEVICE will show this as 'File'.

              – john_e
              Mar 14 at 21:55











            • @john_e You do not need to convince me any further, I do not doubt your explanation in any way. What makes you think otherwise?

              – Raffzahn
              Mar 14 at 21:59












            • I didn't think you were doubting me - I just wanted to add more detail once I had my references to check.

              – john_e
              Mar 14 at 22:31















            9















            Did CPM support custom hardware using device drivers?




            Yes, of course, that's what the BIOS was for.



            The title is somewhat misleading, as from the question body it seems you're asking about loadable device drivers, where loadable means that drivers were loaded at startup (or later) from separate binaries and linked into the system to offer their services. Further it seems as if the question is about CP/M prior to 1981, the time MS-DOS was introduced, thus CP/M 2.2 and MP/M. Right?




            Did CPM have OS support for device drivers?




            • Yes, as part of the customized BIOS.


            • No, CP/M did not have loadable device drivers (*1).


            All drivers were a part of the BIOS (Assembly) code. DR supplied sample code to customize the BIOS for system builders (buyers of a non dedicated CP/M licence).



            Adding new devices worked much the same way on CP/M and MS-DOS 1.x. In both cases new devices had to fit the existing structure of BIOS calls (17 for CP/M 2.2) (*2). New devices must be compiled into the BIOS (*3)




            Did DOS ver1 leave device drivers out, or was DOS v2 device support a new advancement over CPM?




            Loadable drivers were newly added to MS-DOS 2.0. To some degree it was part of the step toward a unixoid system structure for DOS, like adding subdirectories even including a virtual /dev directory for devices.



            Except, it never went fully that way. Much was added (including IOCTRL), but device drivers still had to fit for most parts the existing structure, which wasn't always up to the task. For the CD-ROM driver this meant that it had to hook itself as a network driver (introduced with DOS 3.1) and present the disk as a remote directory assigned to a drive letter instead of simply a disk.




            *1 - There's a 'yes but' part: With GSX, CP/M introduced loadable device drivers much like MS-DOS 2.0, but that's after MS-DOS was created.



            *2 - Another 'but': With MP/M and later CP/M 3.0 (CP/M Plus), the Character Device Table was introduced. Here an arbitrary number of character devices could be added by system builders, using 6 character names to identify them. Assignment to the logical devices was done using the DEVICE utility and controlled by according BIOS calls.



            So while for block devices system builders had to assign a hard disk number to a new device, they could use sounding names for character devices. The default table size was 12 entries for each (In/Out), enabling limited run time extension within the existing structure.



            *3 - It was possible (and done) to add new devices during run time by hooking the BIOS entry table and catching/redirecting calls for a drive. Unlike MS-DOS, CP/M did not provide a TSR functionality, so everything dynamic was up to detailed system knowledge and patching.






            share|improve this answer

























            • CP/M Plus uses a 16-bit word to hold character device assignments, so wouldn't be able to support more than 16 character devices at a time. There are some comments in the source code suggesting that four are reserved for intended future functionality, leaving the 12 table entries.

              – john_e
              Mar 14 at 10:26











            • @john_e interesting. I only remembered that the character device table itself was null terminated, thus of arbitrary length.

              – Raffzahn
              Mar 14 at 21:18











            • The limit of 12 is on page 54 of the CP/M 3 System Guide (§3.4.2, 'Character I/O Functions'). One hint at what may have been intended: if you manually assign physical device 15 (by setting bit 0 of the word at SCB+28h, for example), DEVICE will show this as 'File'.

              – john_e
              Mar 14 at 21:55











            • @john_e You do not need to convince me any further, I do not doubt your explanation in any way. What makes you think otherwise?

              – Raffzahn
              Mar 14 at 21:59












            • I didn't think you were doubting me - I just wanted to add more detail once I had my references to check.

              – john_e
              Mar 14 at 22:31













            9












            9








            9








            Did CPM support custom hardware using device drivers?




            Yes, of course, that's what the BIOS was for.



            The title is somewhat misleading, as from the question body it seems you're asking about loadable device drivers, where loadable means that drivers were loaded at startup (or later) from separate binaries and linked into the system to offer their services. Further it seems as if the question is about CP/M prior to 1981, the time MS-DOS was introduced, thus CP/M 2.2 and MP/M. Right?




            Did CPM have OS support for device drivers?




            • Yes, as part of the customized BIOS.


            • No, CP/M did not have loadable device drivers (*1).


            All drivers were a part of the BIOS (Assembly) code. DR supplied sample code to customize the BIOS for system builders (buyers of a non dedicated CP/M licence).



            Adding new devices worked much the same way on CP/M and MS-DOS 1.x. In both cases new devices had to fit the existing structure of BIOS calls (17 for CP/M 2.2) (*2). New devices must be compiled into the BIOS (*3)




            Did DOS ver1 leave device drivers out, or was DOS v2 device support a new advancement over CPM?




            Loadable drivers were newly added to MS-DOS 2.0. To some degree it was part of the step toward a unixoid system structure for DOS, like adding subdirectories even including a virtual /dev directory for devices.



            Except, it never went fully that way. Much was added (including IOCTRL), but device drivers still had to fit for most parts the existing structure, which wasn't always up to the task. For the CD-ROM driver this meant that it had to hook itself as a network driver (introduced with DOS 3.1) and present the disk as a remote directory assigned to a drive letter instead of simply a disk.




            *1 - There's a 'yes but' part: With GSX, CP/M introduced loadable device drivers much like MS-DOS 2.0, but that's after MS-DOS was created.



            *2 - Another 'but': With MP/M and later CP/M 3.0 (CP/M Plus), the Character Device Table was introduced. Here an arbitrary number of character devices could be added by system builders, using 6 character names to identify them. Assignment to the logical devices was done using the DEVICE utility and controlled by according BIOS calls.



            So while for block devices system builders had to assign a hard disk number to a new device, they could use sounding names for character devices. The default table size was 12 entries for each (In/Out), enabling limited run time extension within the existing structure.



            *3 - It was possible (and done) to add new devices during run time by hooking the BIOS entry table and catching/redirecting calls for a drive. Unlike MS-DOS, CP/M did not provide a TSR functionality, so everything dynamic was up to detailed system knowledge and patching.






            share|improve this answer
















            Did CPM support custom hardware using device drivers?




            Yes, of course, that's what the BIOS was for.



            The title is somewhat misleading, as from the question body it seems you're asking about loadable device drivers, where loadable means that drivers were loaded at startup (or later) from separate binaries and linked into the system to offer their services. Further it seems as if the question is about CP/M prior to 1981, the time MS-DOS was introduced, thus CP/M 2.2 and MP/M. Right?




            Did CPM have OS support for device drivers?




            • Yes, as part of the customized BIOS.


            • No, CP/M did not have loadable device drivers (*1).


            All drivers were a part of the BIOS (Assembly) code. DR supplied sample code to customize the BIOS for system builders (buyers of a non dedicated CP/M licence).



            Adding new devices worked much the same way on CP/M and MS-DOS 1.x. In both cases new devices had to fit the existing structure of BIOS calls (17 for CP/M 2.2) (*2). New devices must be compiled into the BIOS (*3)




            Did DOS ver1 leave device drivers out, or was DOS v2 device support a new advancement over CPM?




            Loadable drivers were newly added to MS-DOS 2.0. To some degree it was part of the step toward a unixoid system structure for DOS, like adding subdirectories even including a virtual /dev directory for devices.



            Except, it never went fully that way. Much was added (including IOCTRL), but device drivers still had to fit for most parts the existing structure, which wasn't always up to the task. For the CD-ROM driver this meant that it had to hook itself as a network driver (introduced with DOS 3.1) and present the disk as a remote directory assigned to a drive letter instead of simply a disk.




            *1 - There's a 'yes but' part: With GSX, CP/M introduced loadable device drivers much like MS-DOS 2.0, but that's after MS-DOS was created.



            *2 - Another 'but': With MP/M and later CP/M 3.0 (CP/M Plus), the Character Device Table was introduced. Here an arbitrary number of character devices could be added by system builders, using 6 character names to identify them. Assignment to the logical devices was done using the DEVICE utility and controlled by according BIOS calls.



            So while for block devices system builders had to assign a hard disk number to a new device, they could use sounding names for character devices. The default table size was 12 entries for each (In/Out), enabling limited run time extension within the existing structure.



            *3 - It was possible (and done) to add new devices during run time by hooking the BIOS entry table and catching/redirecting calls for a drive. Unlike MS-DOS, CP/M did not provide a TSR functionality, so everything dynamic was up to detailed system knowledge and patching.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Mar 15 at 13:47









            Community

            1




            1










            answered Mar 14 at 7:33









            RaffzahnRaffzahn

            55.9k6136225




            55.9k6136225












            • CP/M Plus uses a 16-bit word to hold character device assignments, so wouldn't be able to support more than 16 character devices at a time. There are some comments in the source code suggesting that four are reserved for intended future functionality, leaving the 12 table entries.

              – john_e
              Mar 14 at 10:26











            • @john_e interesting. I only remembered that the character device table itself was null terminated, thus of arbitrary length.

              – Raffzahn
              Mar 14 at 21:18











            • The limit of 12 is on page 54 of the CP/M 3 System Guide (§3.4.2, 'Character I/O Functions'). One hint at what may have been intended: if you manually assign physical device 15 (by setting bit 0 of the word at SCB+28h, for example), DEVICE will show this as 'File'.

              – john_e
              Mar 14 at 21:55











            • @john_e You do not need to convince me any further, I do not doubt your explanation in any way. What makes you think otherwise?

              – Raffzahn
              Mar 14 at 21:59












            • I didn't think you were doubting me - I just wanted to add more detail once I had my references to check.

              – john_e
              Mar 14 at 22:31

















            • CP/M Plus uses a 16-bit word to hold character device assignments, so wouldn't be able to support more than 16 character devices at a time. There are some comments in the source code suggesting that four are reserved for intended future functionality, leaving the 12 table entries.

              – john_e
              Mar 14 at 10:26











            • @john_e interesting. I only remembered that the character device table itself was null terminated, thus of arbitrary length.

              – Raffzahn
              Mar 14 at 21:18











            • The limit of 12 is on page 54 of the CP/M 3 System Guide (§3.4.2, 'Character I/O Functions'). One hint at what may have been intended: if you manually assign physical device 15 (by setting bit 0 of the word at SCB+28h, for example), DEVICE will show this as 'File'.

              – john_e
              Mar 14 at 21:55











            • @john_e You do not need to convince me any further, I do not doubt your explanation in any way. What makes you think otherwise?

              – Raffzahn
              Mar 14 at 21:59












            • I didn't think you were doubting me - I just wanted to add more detail once I had my references to check.

              – john_e
              Mar 14 at 22:31
















            CP/M Plus uses a 16-bit word to hold character device assignments, so wouldn't be able to support more than 16 character devices at a time. There are some comments in the source code suggesting that four are reserved for intended future functionality, leaving the 12 table entries.

            – john_e
            Mar 14 at 10:26





            CP/M Plus uses a 16-bit word to hold character device assignments, so wouldn't be able to support more than 16 character devices at a time. There are some comments in the source code suggesting that four are reserved for intended future functionality, leaving the 12 table entries.

            – john_e
            Mar 14 at 10:26













            @john_e interesting. I only remembered that the character device table itself was null terminated, thus of arbitrary length.

            – Raffzahn
            Mar 14 at 21:18





            @john_e interesting. I only remembered that the character device table itself was null terminated, thus of arbitrary length.

            – Raffzahn
            Mar 14 at 21:18













            The limit of 12 is on page 54 of the CP/M 3 System Guide (§3.4.2, 'Character I/O Functions'). One hint at what may have been intended: if you manually assign physical device 15 (by setting bit 0 of the word at SCB+28h, for example), DEVICE will show this as 'File'.

            – john_e
            Mar 14 at 21:55





            The limit of 12 is on page 54 of the CP/M 3 System Guide (§3.4.2, 'Character I/O Functions'). One hint at what may have been intended: if you manually assign physical device 15 (by setting bit 0 of the word at SCB+28h, for example), DEVICE will show this as 'File'.

            – john_e
            Mar 14 at 21:55













            @john_e You do not need to convince me any further, I do not doubt your explanation in any way. What makes you think otherwise?

            – Raffzahn
            Mar 14 at 21:59






            @john_e You do not need to convince me any further, I do not doubt your explanation in any way. What makes you think otherwise?

            – Raffzahn
            Mar 14 at 21:59














            I didn't think you were doubting me - I just wanted to add more detail once I had my references to check.

            – john_e
            Mar 14 at 22:31





            I didn't think you were doubting me - I just wanted to add more detail once I had my references to check.

            – john_e
            Mar 14 at 22:31

















            draft saved

            draft discarded
















































            Thanks for contributing an answer to Retrocomputing Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid


            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.

            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f9356%2fdid-cp-m-support-custom-hardware-using-device-drivers%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown






            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Displaying single band from multi-band raster using QGIS

            How many registers does an x86_64 CPU actually have?