Image Map Image Map
Page 1 of 4 1234 LastLast
Results 1 to 10 of 40

Thread: Adding Text display and keyboard for a homebrew Z80 CPM computer

  1. #1
    Join Date
    Aug 2017
    Location
    New Mexico, USA
    Posts
    140

    Default Adding Text display and keyboard for a homebrew Z80 CPM computer

    I'm moving from a homebrew serial port based CP/M computer to a standalone Z80 CP/M computer with keyboard and text display. I think I know how to add the text display in the console output BIOS where the data go to both serial output and video display output. However, how do I combine both keyboard (PS2 protocol) and serial console input? I still need the serial port because it is how I upload software via XMODEM from my PC to the Z80 CPM computer. This obvious had been done before, but CP/M system guide didn't mention how keyboard is integrated into the computer. My PS/2 keyboard interface is fairly primitive, I'm bit banging the incoming keyboard bit stream without interrupt capability.
    Bill

  2. #2

    Default

    We had an old product called "tandem consoles" which is essentially what you're asking, I think. In this product, the customer had an H89 and a remote H19, and they wanted to be able to use either one (but not at the same time, so not a "multi-user" case). As you said, console output simply sends to both serial ports (or in your case, to a serial port and the CRT controller). For input, you just check both devices and return whichever has a character ready. Again, not a multi-user situation, so no need to keep the input separate. Console (input) status would check both input devices (serial port and PS/2?) and if *either* was "ready" then return "true". Console input would check status and if "true" then return whichever character (device) is ready. You can work out how you'd do that, whether you call the existing status routine or do something that might be a bit more efficient.

    So, when you boot up both "screens" will show the "A0>" prompt. You could type the "DIR" command characters alternately on each keyboard, and it will behave as if it were all typed on one keyboard. Both screens will see all the characters of "DIR" echoed.
    - Doug

  3. #3
    Join Date
    Aug 2017
    Location
    New Mexico, USA
    Posts
    140

    Default

    I'm thinking of the whole generation of standalone CP/M machines (H89, Morrow, Radio Shack, etc) that must have dedicated console input & output BIOS for keyboard and graphic. I can also write the BIOS so console input is keyboard and console output is video display, but I'm struggle with how to use the standard xmodem which use console I/O. How did these standalone CP/M machines do xmodem? They must have a custom xmodem that works with an auxiliary serial port?
    Bill

  4. #4

    Default

    I'm not sure when xmodem became ubiquitous, but I never used it. The H89 console is just another serial port (INS8250 chip like the other ports), and there is an H19 built-in to the box. What little I recall about xmodem-like programs of that era, they did not (normally) use the console to transfer. Many CP/M implementations did provide a "reader/punch" device, and that was often used as the transfer device. Sometimes, the plugin module for a specific system had code to directly access the serial port (many kermit platform modules did that) instead of using a CP/M device (e.g. reader/punch).
    - Doug

  5. #5
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    35,141
    Blog Entries
    18

    Default

    xmodem is all over the place if you look. I have a word processor (Smith Corona) that supports it. Unix/Linux minicom supports it; I think that putty and hyperterm support it. uCon supports it.

    Yes, Kermit is wonderful, if you can get it working--and if your file names are compatible with the client and host systems. The great thing about xmodem is that you get to specify the file name when receiving.

    So why not Ymodem/Xmodem1K...etc.? Lack of standards, mostly. Zmodem works well when there isn't too much latency in the link, but isn't supported to the same extent that good old xmodem is. Xmodem is simple and can be implemented on almost any hardware that can handle serial data and has sufficient memory for a transfer.

  6. #6
    Join Date
    Jan 2014
    Location
    Western North Carolina, USA
    Posts
    1,387

    Default

    Plasmo, the TRS-80 machines typically would use a comm program (like Procomm or Telix on DOS) with an auxiliary serial port for file transfers. Most of these comm programs embedded xmodem or other protocols (kermit, ymodem, wxmodem, xmodem, etc). Programs like IMP, MEX, and QTERM for CP/M come to mind (I was an LS-DOS user, and used Mel Patrick's FASTterm or my own ANSItetm (later Richard van Houten's ANSIterm4).

    EDIT: it was possible with LS-DOS at least to set up serial host redirection, so the serial port could be a console; you'd then use xmodem or other program to do the transfer through the console.
    --
    Thus spake Tandy Xenix System III version 3.2: "Bughlt: Sckmud Shut her down Scotty, she's sucking mud again!"

  7. #7
    Join Date
    Aug 2017
    Location
    New Mexico, USA
    Posts
    140

    Default

    Hmmm, I need to rethink the "standalone Z80 CP/M computer" concept. I have designed a Z80 SBC with PS2 keyboard interface and tightly coupled text display (64 columns x 48 lines) where every character is directly read/write addressable, but it may not be a good fit with CP/M.

    I can abandon the keyboard interface, go back to CP/M connected by serial port, and retain the text display for special application. A shame, it was a tightly designed minimalist hardware.
    Bill

  8. #8
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    35,141
    Blog Entries
    18

    Default

    Recall that the original target terminal for CP/M was a tty (hard copy). Niceities like cursor addressing are not, part of any standard DRI CP/M 2.2 program, as far as I know. Third-party software such as Wordstar did make use of those features, but was targeted toward standard terminal protocol, with lots of leeway on what that protocol could be.

    That's not to say that OEM vendor-supplied programs did not make use of those features. There are CP/M-based PLCs, for example, with color graphics screens.

  9. #9

    Default

    I don't see the problem. CP/M was intended to be able to revector both input and output. You just need the serial I/O handler code and select between the two as needed. While running Xmodem, you could have both running at the same time in parallel as well. CP/M doesn't care. That is why CP/M was made the way it is. The I/O is user provided.
    Dwight

  10. #10

    Default

    Quote Originally Posted by Plasmo View Post
    Hmmm, I need to rethink the "standalone Z80 CP/M computer" concept. I have designed a Z80 SBC with PS2 keyboard interface and tightly coupled text display (64 columns x 48 lines) where every character is directly read/write addressable, but it may not be a good fit with CP/M.

    I can abandon the keyboard interface, go back to CP/M connected by serial port, and retain the text display for special application. A shame, it was a tightly designed minimalist hardware.
    Bill
    That should work fine, no need to abandon anything. The CP/M BIOS can provide any code necessary for the "console". There is no (or at least shouldn't be any) assumption that the console is a serial port (unless some program *only* uses the console for file transfers). The Kaypro is an example, where they have (not-quite) direct access to the video display RAM. The BIOS (although it is in ROM) contains the routines to interact with the CRT controller chip and video RAM.

    Provided your hardware does not restrict "alternate" uses, you can use the serial port for file transfers. I'm assuming at this point that you did not intend to use both serial port and CRT controller for the CP/M console, so you then can just re-purpose the serial port for whatever you want. But, that depends on whether you are "up" for writing/modifying the CP/M BIOS. I guess it also is impacted by how the ROM works.
    - Doug

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
  •