Image Map Image Map
Page 2 of 6 FirstFirst 123456 LastLast
Results 11 to 20 of 56

Thread: CP/M question...

  1. #11
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    25,233
    Blog Entries
    20

    Default

    Quote Originally Posted by JohnElliott View Post
    The Amstrad PCW uses a variant of the force-feeding technique -- at startup, memory fetches come from the printer controller, which emits 779 bytes (instructions and data reads). The CPU executes these to generate a 256-byte program in RAM. That program then reads the first sector from disc, and jumps to it.
    What's remarkable is that the Tarbell controller used a 32-byte bipolar PROM to do its work.

  2. #12
    Join Date
    Aug 2013
    Location
    Larose, LA, USA
    Posts
    333

    Default

    I have a feeling my Lanier uses this method, being as it also has a tiny PROM to boot from and sits, waiting for the floppy drive, displaying nothing on the screen.

    It's given me a direction to go in, at least. Appreciate this insight. Might be able to "force feed" from something that is pretending to be a floppy drive and get some signs of life...


    --Phil

  3. #13
    Join Date
    Feb 2006
    Location
    in the basement
    Posts
    764

    Default cp/m with hierarchical file system

    Hello Folks,

    Has there been any attempt to provide cp/m with
    a hierarchical file system and subdirectories? Is it
    even possible?

    ziloo

  4. Default

    In CP/M-86, yes; CP/M-86 Plus for the Apricot PC has native support for DOS-formatted discs.

  5. #15

    Default

    I remember Gary Kildall and Tom Rolander giving an ad-hoc lecture on the evils of hierarchical filesystems and why CP/M was better... Of course, in modern times we have robust and reliable hierarchical filesystems. Back then, it was a bit easier to believe that - at least for "weak" CPUs like the x86 family (or 8-bit'ers) - it made no sense to have hierarchical filesystems. Of course, it was a matter of opinion, but it's too bad DRI never spent the time to develop one... we might not have been subjected to the horrors of FAT filesystems for so long...

  6. #16
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    25,233
    Blog Entries
    20

    Default

    Kildall was focused on floppy file systems initially, so the CP/M does make a bit of sense for small volumes. When Shugart brought out their first Winchester hard drives (the SA-4000, a 14" drive), they sent us one to work with. What they supplied was about 40MB (I still have the drive). My reaction was "what the heck am I going to do with this much storage and an operating system that can't work with it?"

    Hierarchical filesystems make sense on large drives, but even there, I've used "flat" file systems on mainframes that worked quite well. Hierarchy is simply one method of compartmentalizing files. There are other ways that are just as effective--and perhaps more secure.

  7. #17
    Join Date
    Dec 2005
    Location
    Toronto ON Canada
    Posts
    6,807

    Default

    Quote Originally Posted by Chuck(G) View Post
    Hierarchical filesystems make sense on large drives, but even there, I've used "flat" file systems on mainframes that worked quite well. Hierarchy is simply one method of compartmentalizing files. There are other ways that are just as effective--and perhaps more secure.
    I'm very interested; any details anywhere?

    m

  8. #18
    Join Date
    May 2009
    Location
    Connecticut
    Posts
    3,447
    Blog Entries
    1

    Default

    Not Chuck(G) but Wikipedia has a long article on the CMS file system which lasted a long time.

    Smaller systems stuck with flat file systems even longer as shown by RT-11 and UCSD P-system though P-system had a clunky method of creating subvolumes.

  9. #19
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    25,233
    Blog Entries
    20

    Default

    Bitsavers in the mainframe area, is full of this sort of thing. I'll give you an example.

    CDC SCOPE/NOS starts a user out in a session or job with only two files: INPUT and OUTPUT; the former is connected to the standard input device and the latter, to the standard output device. There are no other files (with perhaps the exception of PUNCH). If you want to work on an existing file, you access the permanent file system with the ATTACH command, which specifies the job-local name, the permanent file name, user ID, cycle (version--you can have up to 1,000 versions of the same file) and access passwords (read/write/control are different). Any other local file created in the session is discarded unless explicitly saved at creation or otherwise pre-disposed of by the user.

    It's quite secure--simply logging on as a valid user gets you no file access.

    An added feature is that a permanent file can be offline (i.e. kept on removable media not physically present on the system; e.g. a tape). When an ATTACH command is given, the system will look up where the file resides and instruct the operator to mount the medium, if not already mounted.

  10. #20

    Default

    I think the appearance microprocessors really ushered in a new era in filestem standardization. Of course, floppy disks were a part of that. Other than "IBM Tape" interchange (sequential storage), I think most disk storage was at most interchangeable within the same computer series. With 8" floppies came the chance to exchange diskettes between various computer models. One early example, perhaps even pre-dating CP/M, was FDOS-II. I recall being able to read FDOS-II files that were written on a 6800-based computer with an 8080-based computer. Of course, programs were not runnable. a CP/M 8" SD SS floppy (IBM 3740) could be read on any CP/M system that supported 8" floppies. Of course, CP/M started out as strictly 8080 (and compatible CPUs).

    Perhaps there were other, earlier examples of standardization for disk storage? Were disk packs ever interchangeable between dissimilar computers? Seems like the microprocessors really began the idea of industry standardization of disk formats. Although, it may have been the IBM 3740 that drove that.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •