Adding Text display and keyboard for a homebrew Z80 CPM computer

[Plasmo]

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

 

[durgadas311]

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.

 

[Plasmo]

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

 

[durgadas311]

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).

 

[Chuck(G)]

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.

 

[lowen]

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.

 

[Plasmo]

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

 

[Chuck(G)]

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.

 

[Dwight Elvey]

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

 

[durgadas311]

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.

 

[Eudimorphodon]

CP/M ran fine on early memory-mapped video cards like the VDM-1 (and improved clones like the Solid State Music VDB-1) so there's definitely no requirement that CP/M use a serial port for console. You should be able to find a version of CP/M with drivers for these memory-mapped cards linked into the BIOS appropriately without a whole lot of trouble to use as an example of how to "fix things" for your particular computer.

Note that the keyboard-in with these memory-mapped video cards was generally implemented as an 8-bit ASCII parallel-encoded keyboard mapped to a pair of I/O ports (the data on one port, a status flag on the other.). That also shouldn't be too hard to hack for whatever you're doing.

 

[Eudimorphodon]

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

By any chance have you shared this design anywhere? Lately I've taken an interest in minimal computer designs that have memory-mapped video instead of the typical serial interface you find on most small SBCs.

 

[Dwight Elvey]

I don't know of any generic CP/M applications that assume memory mapped video. That is at the bios level. CP/M assumes one byte at a time going to a terminal. It has no idea how that terminal interprets that byte. It might go to a memory mapped display or serial or both. The keyboard is also just a byte at a time as provided by the bios. Again, it doesn't know if the data is from a serial port or some program that is talking to a PC type keyboard. The common point should always be a byte. How your display interprets that byte is not CP/Ms problem, or at least shouldn't be.
Dwight

 

[Chuck(G)]

A minimal system for memory-mapped video on an 8085 CP/M system would be the 8085, an 8257 DMAC and an 8275 CRTC. I don't care for it much, because when your CPU crashes, the screen goes dark--but it shares main memory with the CPU without any fancy interfacing.

 

[Eudimorphodon]

A minimal system for memory-mapped video on an 8085 CP/M system would be the 8085, an 8257 DMAC and an 8275 CRTC.

I want a Z80, alas, because my goal is a rotgut TRS-80 clone. I spent the weekend trying to teach myself enough AVR assembly to hack some TV-out generation code so I can use a 328P *basically* as a self-programming CRTC, and the loose design I have in mind incorporates a GAL programmed as a counter to accelerate address generation because I'm not positive I can make the code tight enough to drive the addresses that need to be incremented per-line directly. (I have a bunch of 20v8's sitting around so, hey, use 'em.) Whether I'll be able to make it work is the $64,000 question.

 

[Chuck(G)]

Well, there's a lot of "that depends" in this. Do you need attributes? Text (number of rows) or graphics too?

Anything wrong with a good old 6845?

I remember seeing, a few years ago, some Russian (IIRC) guy who overclocked an ATMega8 to produce a text display. The limit, of course was the 1K of RAM on-chip. Still it was remarkable for what could be done. Sharing memory might be a little more "interesting". Was it the Televideo CP/M boxes that isolated display memory from main memory?

 

[Eudimorphodon]

Well, there's a lot of "that depends" in this. Do you need attributes? Text (number of rows) or graphics too?

Anything wrong with a good old 6845?

Mostly the issue with just using a 6845 is it needs quite a lot of support circuitry. Trying to be "clever" and seeing if I can minimize things a bit.

The code I'm starting with for my idea is Grant Searle's video processor, which uses a 16mhz Atmega328 combined with a 74LS166 to be able to do 80x25 with the character buffer stored internally on the chip. There are 8 machine cycles available per character, so the display routine for each cell is basically:

"increment the pointer for the line buffer (assembled previously) that has the byte needed to display the dots for this character at this row"
" stuff the byte at that location into the output port the shift register is on"
"toggle the load latch on the shift register".
"untoggle the load latch"

My idea is to have the shift register sitting in front of the output of a character ROM, use the output port to represent 4 bits of row data for the character ROM and four bits of data for character line (remember, the TRS-80's video screen is 16 rows high), and use 6 bit counter to represent the line address. (Obviously this won't work for an 80 column line, or any other format where the number of characters per line isn't divisible by a power of two.) Then I have 8 cycles to:

1: toggle OE/MEMR for the RAM character buffer chip
2: toggle OE/MEMR for the character generator ROM
3: toggle the load latch on the shift register
4: untoggle all of the above. (All this toggling is achieved by writing pre-baked byte patterns to an output port)
5: send a pulse to increment the counter that's the bottom 6 bits of the memory address
6 untoggle that pulse.

All of the things above are *supposedly* single cycle instructions, so I think the math works out? Obviously I'll still need to multiplex the memory address lines to share with the CPU, or use a dual-port RAM chip if I want to make it non-conflicting. (The latter is tempting but, man, those turkeys are expensive.)

I think this is basically similar to the recipe that Tynemouth Software is doing with their Mini-Pet and Minstrel computers, but I have no doubt my implementation is going to be clunkier. (Their video processor is closed source.) One thought is to have a second shift register sitting directly on RAM output lines and set up the code so I can also optionally do a full 512x192 graphics mode. (Just use the character generator row address lines as upper address lines for a framebuffer instead. I actually intend to test the thing by just burning a bitmap into a flash ROM and using the address lines to clock that out row by row.)

Another thing that would be needed for a full TRS emulation would be a toggle-able clock divider to do a 32 column text mode, of course.

 

[Plasmo]

By any chance have you shared this design anywhere? Lately I've taken an interest in minimal computer designs that have memory-mapped video instead of the typical serial interface you find on most small SBCs.

It is called Z80ALL. Here is link: https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:z80all:z80all_rev1

It uses CF disk as system EPROM and mass storage, overclocks Z80 to 25.175MHz (VGA pixel clock); has 128K RAM in 4 banks of 32K, and a 4K dual port RAM where 3K is text (64x48) and 1K is font. The serial port is in CPLD along with VGA timing generation. The dual ported RAM allows simultaneous access by Z80 and VGA logic. The 4K dual ported RAM is accessible on the Z80 side as 4K of contiguous I/O addresses.

Bill

Edit: I picked my parts mostly for cost consideration. Z80 is given; I happened to have a roll of 128K RAM, but they are about $1 each; CPLD is lesser then $3; 4K dual port RAM (IDT71342) is pretty cheap, just over $2 each in quantity of 10 from UTSource; low capacity CF disk is $1-$2 used; and 2-layer pc board 100mm x 100mm is cheap. Should be able to keep part cost below $20.

 

[Plasmo]

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.

What makes me want to "rethink the standalone Z80 CP/M computer" is not the PS/2 keyboard input. It is probably quite reasonable to accept inputs from both serial port and keyboard; at a minimum don't touch the keyboard while xmodem is running. It is the text display that has me rethinking; the CP/M applications that manipulate display use VT100 escape sequence, so if I want to run these applications, I'll need to implement VT100 emulation in console output BIOS. That's a mess, the direct mapping video doesn't help at all.
Bill

 

[Eudimorphodon]

4K dual port RAM (IDT71342) is pretty cheap, just over $2 each in quantity of 10 from UTSource;

You were actually able to lay hands on them for that cheap? That's a fraction of what I was able to find for similar on AliExpress. (And digikey wants like $14 each for them, it's ridiculous.)