Image Map Image Map
Page 1 of 2 12 LastLast
Results 1 to 10 of 15

Thread: How viable is a universal PC parallel/serial connected CP/M disk controller/drive?

  1. #1

    Default How viable is a universal PC parallel/serial connected CP/M disk controller/drive?

    I had an idea and wanted to hear if there are any major technical obstacles.

    Imagine any vintage computer with either a serial port or a parallel port.

    The vintage computer is connected via that cable to a PC (or Raspberry PI or any machine with a serial/parallel port). It would need to be a "laplink" cable in the case of parallel.

    On the PC side there is a server application written in Python that emulates a CP/M disk controller & drive.

    CP/M and disk blocks are loaded via the cable.

    The initial boot loader would be very small and would need to be loaded via cassette or if small enough, entered as machine code. The initial boot loader would have enough code to request data from the parallel port to get itself up and running.

    Anyone have any thoughts on this? Does it seem like a feasible idea? The general idea being to build a server that provides disk functionality to essentially any machine with a serial or parallel port, allowing anyone with a parallel crossover or serial cable to run CP/M.

    Anyone here interested in participating in such a project as an MIT licensed open source project run from github?

  2. #2
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    30,362
    Blog Entries
    20

    Default

    Real parallel and serial ports are getting tough to find. I'd rather equip a cheap MCU with a USB flash drive and have it emulate a disk, while keeping the FAT32 file structure (i.e. translate from CP/M flat file structure to FAT32).

    My opinion only.

  3. #3

    Default

    Quote Originally Posted by Chuck(G) View Post
    Real parallel and serial ports are getting tough to find. I'd rather equip a cheap MCU with a USB flash drive and have it emulate a disk, while keeping the FAT32 file structure (i.e. translate from CP/M flat file structure to FAT32).

    My opinion only.
    Amazon lists quite a few parallel port cards which seem pretty cheap:

    https://www.amazon.com/s/ref=lp_3015...price-asc-rank

  4. #4

    Default

    What you're describing sounds like a network server, although unlike CP/NET you are defining a disk sector interface (rather than a file interface). In either case, you will need to customize the CP/M BIOS (or equivalent) in order to utilize the server. CP/NET allows for extensions to handle booting, which would be more of a "sector interface" - but specialized for booting. CP/NET has some drawbacks, especially on CP/M 2 - mainly that it cuts into your TPA. But one big advantage of CP/NET is that your server code can work on the native filesystem(s) of the host PC and so you have access to your CP/M files there instead of just raw disk sector images.

    As you suggest, booting is the biggest pain. I presume the idea is to get away from floppy technology, which has a limited future. The ideal integration would be to change the ROM (boot code) of the machine to accommodate this technology (and be able to boot over it directly), but that's going to require a custom solution for (at least) each family of CP/M machine. A lot of CP/M machines don't provide an easy way to enter boot code directly, so you are stuck booting on something local first.

    There are several "floppy emulators" out there, which plug into a floppy controller and provide raw disk images in place of floppy diskettes (i.e. they pretend to be a floppy drive). There are ones for replacing SASI harddisks also. One disadvantage of those is that your disk images are not only opaque but generally not accessible directly from a PC (you have to remove the media from the emulator and insert into a PC, then you have to run specialized software to examine the images - if it is even possible to examine the files at all).

    I've spent a lot of time working with CP/NET, both on 1980's technology and in a modern CP/M-to-host-PC arrangement. I have server code for it (modern PC, fairly portable in JAVA), and worked up a module to add CP/NET to CP/M 3. As I said, there are advantages and disadvantages to CP/NET. But it's probably worth discussing your idea more and see where it goes. Of course, it will depend on how much "demand" there is for it among the community.

  5. #5

    Default

    @durgadas sounds like you have some relevant knowledge.

    >> As you suggest, booting is the biggest pain.
    Yes you are right the boot loader is a challenge - it's impossible avoid some sort of initial boot loader to start grabbing data from the parallel port - interestingly you could perhaps integrate it all together - for example on my Exidy Sorcerer I load cassette programs from my PC audio output to the Sorcerer cassette input. So there's no reason why the server application could not provide both the boot loader via cassette port which bootstraps the parallel port - just needs two cables between PC and vintage micro - one parallel and one audio cable.


    I'm thinking that it would be nice to get CP/M disk functionality for your vintage micro for the price of a parallel laplink cable and possibly a parallel interface card. And if the server is written in Python then it can easily run on any platform pretty much.

    laplink cables are available still: https://www.ebay.com.au/sch/i.html?_...c&LH_PrefLoc=2

    Although many vintage microcomputers had weird parallel ports and would need custom cables to do bi directional parallel with a PC.

    Designed carefully it should be possible to make it quite a modular system so that for example you could use a serial cable instead of a parallel cable.

    This PDF shows how to implement parallel to parallel between two Exidy Sorcerer's and includes some pretty compact code for grabbing data from the parallel port so it might be possible to create a very short boot loader to get the boot sector from the parallel port.
    http://messui.polygonal-moogle.com/c...er/exidy_3.pdf

    It should be possible even to make the client/server interface into a message oriented interface so that other traffic aside from disk blocks could be passed between client and server.
    Last edited by flibbledeedo; January 12th, 2019 at 12:59 AM.

  6. #6

    Default

    Programs like the fabulous tapetool https://www.toptensoftware.com/tapetool/ show that it is possible to programatically generate the audio that cassette ports expect to hear, so that opens a path to creating a bootstrap server that any micro with a cassette port can use to get the boot process under way that can then be handed off to the parallel port for higher speed CP/M block transfers.

  7. #7

    Default

    Quote Originally Posted by flibbledeedo
    This PDF shows how to implement parallel to parallel between two Exidy Sorcerer's and includes some pretty compact code for grabbing data from the parallel port so it might be possible to create a very short boot loader to get the boot sector from the parallel port.
    http://messui.polygonal-moogle.com/c...er/exidy_3.pdf
    I wish I'd known about this PDF a while ago, there's a section that breaks down in great detail disk usage on a lot of CP/M platforms and describes the DPB and skew tables. Would've saved me a lot of searching and experimentation last year and not just for Sorcerer stuff!

    As for the original question, such a thing exists for the Grundy Newbrain (also CP/M 2.2) but I’m not sure how freely available the source may be. NBServer runs on a DOS PC and provides ‘network’ drives to a Newbrain via 9600 baud serial. It’s a very handy thing to have. http://www.newbrainemu.eu/component/...,30/Itemid,52/

    Chuck's idea of an MCU has already been implemented for several platforms, and even the Nascom II via its PIO interface. There are schematics for a Newbrain SDcard adapter and the latest I've seen was for an Enterprise 64.

    I do like the idea of a PC-based server though, could easily be written in Python.
    www.binarydinosaurs.co.uk - UK home computer history
    Where RIFA capacitors come to die
    facebook.com/binarydinosaurs

  8. #8
    Join Date
    Aug 2015
    Location
    Virginia, USA
    Posts
    14

    Default

    Quote Originally Posted by flibbledeedo View Post
    I had an idea and wanted to hear if there are any major technical obstacles.

    Imagine any vintage computer with either a serial port or a parallel port.

    The vintage computer is connected via that cable to a PC (or Raspberry PI or any machine with a serial/parallel port). It would need to be a "laplink" cable in the case of parallel.

    On the PC side there is a server application written in Python that emulates a CP/M disk controller & drive.

    CP/M and disk blocks are loaded via the cable.

    The initial boot loader would be very small and would need to be loaded via cassette or if small enough, entered as machine code. The initial boot loader would have enough code to request data from the parallel port to get itself up and running.

    Anyone have any thoughts on this? Does it seem like a feasible idea? The general idea being to build a server that provides disk functionality to essentially any machine with a serial or parallel port, allowing anyone with a parallel crossover or serial cable to run CP/M.

    Anyone here interested in participating in such a project as an MIT licensed open source project run from github?
    Quote Originally Posted by flibbledeedo View Post
    I had an idea and wanted to hear if there are any major technical obstacles.

    Imagine any vintage computer with either a serial port or a parallel port.

    The vintage computer is connected via that cable to a PC (or Raspberry PI or any machine with a serial/parallel port). It would need to be a "laplink" cable in the case of parallel.

    On the PC side there is a server application written in Python that emulates a CP/M disk controller & drive.

    CP/M and disk blocks are loaded via the cable.

    The initial boot loader would be very small and would need to be loaded via cassette or if small enough, entered as machine code. The initial boot loader would have enough code to request data from the parallel port to get itself up and running.

    Anyone have any thoughts on this? Does it seem like a feasible idea? The general idea being to build a server that provides disk functionality to essentially any machine with a serial or parallel port, allowing anyone with a parallel crossover or serial cable to run CP/M.

    Anyone here interested in participating in such a project as an MIT licensed open source project run from github?
    I'm pretty sure this has been done many times, the problem is that each vintage computer is designed differently so every single vintage computer would need a completely different method of running the bootcode. Each time it's been done, it's eventually been forgotten because it's a difficult solution to a problem that we can usually overcome now since you can just load cassette software from a computer anyway. Parallel transfer programs would also require a custom version of CPM on each computer to access the drive in such a way that's compatible with the original software.

    Are you trying to design your own computer? What you're describing doesn't seem like it would be useful for vintage computing.

  9. #9

    Default

    I implemented a PC based serial disk server for the Altair FDC+ (http://deramp.com/fdc_plus.html). The FDC+ includes a high speed serial port that can connect to a PC running this serial disk server. From the perspective of the Altair computer and software, it appears that an Altair 8” floppy drive is attached. Performance of the serial drive is virtually identical to the original Altair floppy drive at baud rate of 460,800.

    Mike

  10. #10
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    30,362
    Blog Entries
    20

    Default

    In my experience, serial (RS232C) interfaces are far more common than are "Centronics" type parallel ones.

    In fact, I've been faced with systems with no functioning floppy controller and neither serial nor parallel (printer was integrated into the system). On one, I was desperate enough to figure out how to blink an LED on the keyboard and taped a phototransistor over that and dumped the hard drive data by blinking it out. On another system, I "dead bugged" a USART with oscillator to one of the boards.

    I don't think there's a "one size fits all" solution.

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
  •