• Please review our updated Terms and Rules here

CP/M 2.2 won't sign on with "a>" prompt

P

Plasmo

Experienced Member
Joined
Aug 29, 2017
Messages
217
Location
New Mexico, USA
I am developing a couple new Z80 SBC hardware. The first design works; CP/M2.2 and CP/M3 were successfully ported to it. The second design is closely related to the first except the serial transmit hardware is replaced with software bit banging function. The 2nd design works with a simple monitor that loads file, display/modify memory and I/O, and test memory and compact flash disk. When boot into CP/M 2.2, it will correctly execute the BOOT BIOS which displays a sign-on message, clear a few memory locations in page 0 and install the jump addresses of warm-boot and BDOS and then jumps into CCP but does not display the "a>" prompt. What's curious is that when I press the carriage return, it will display TWO "a>". If I continue to press the carriage return, it will display the "a>" with each press, but if I enter a command or even just a character, it will echo back the command or character, but takes another carriage return for it to process the command. The CP/M command "dir" works with two carriage returns, but only display the first file.

I've built two copies of the 2nd design hardware and both work (and not work) the same. I can switch back and forth between the 1st design and the 2nd design and see the first design works, but the 2nd design doesn't.

I'm puzzled by why it appears to recognize & echo back the keystroke, but unable to process the keyboard input the first time, but does the second time.
 
Without more details I'm just guessing, but if you are bit-banging the serial output you must also have to "bit bang" the serial input? What's on the other end of the serial port? Do you get each character echoed as you type them? or only after pressing return? Assuming you are using some standard terminal emulation program on the host side (i.e. no "line buffered input" issues), one thought occurs: Th return character (all control characters) has a longer period where the line is at the spacing level (compare to most printable characters), and I wonder if the serial input algorithm might be losing sync on that. SPACE also has a long spacing segment at the beginning of the character, as does '@' and others. This is just a guess, based on assumptions. Maybe check some other characters, ones with long spacing, or marking, sections in their code.

Also, whatever is sending to your SBC is, by definition, out of sync and so you have to make sure your serial input sampling is faster than the baud rate to ensure you can properly detect the bits. That's why UARTs normally operate with a 16x (or higher) clock - they sample the incoming data at 16x the baud rate. Not sure why a problem sampling wouldn't affect every character, but maybe it has to do with the bit patterns and their electrical side effects.

Are you using RS232 transceivers on the serial lines? or are they logic level signals? How long are the wires between SBC and the terminal/host?
 
Thank you for your quick response.

I don't have a very good documentation right now. The 1st design (the one that works) is pc board version of this wirewrap design: https://github.com/Plasmode/Z80SBCRC

The simplified design (the one having problem with CP/M 2.2 prompt) has some documentation here: https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:z80sbc64

My goal was to have a simple 20MHz Z80 SBC that can be built by hobbyists. The serial receiver is in CPLD hardware--a simple shift register sampling data at 16x clock followed by a buffer and a status bit indicating Receive-Data-Ready. The signal level is TTL interfacing to a PC via an USB-serial adapter, it is sitting next to my PC a few feet apart. I looked at it with scope and the timing variation of different bit-bang transmit characters is within +/-2% of the spec.

I'm using Tera Term on my Windows PC running at 115200, N81. I have slowed it down to 38400 N81, but having the same problem. I have inserted some diagnostic code in the serial receive BIOS and verified that the correct characters were received, but somehow CCP is not processing it.
Bill
 
Still not getting a usable link. That link responds:

You've followed a link to a topic that doesn't exist yet. If permissions allow, you may create it by clicking on “Create this page”.

However, I was able to manually navigate to it using the sidebar.

So, you have a CPLD between the Z80 and the serial port connector. Is the CPLD performing the ASYNC serial translation, or is the Z80 actually doing bit-banging and the CPLD just passes through a single data bit? I don't see any RS-232 drivers/receivers on the RX/TX lines, so have to ask what is connected to those? If you have a cable of any length running to a PC serial port, I have to wonder if the CPLD is capable of driving that, or discerning the (noisy) received signal. Standard RS-232 drives a +/-12V signal, which has the potential to destroy any unsuspecting MOS-LSI chips. Perhaps the CPLD pins are protected. Maybe what you have is perfectly OK in modern setups, but to my old-school point of view, it seems dangerous.

The page for the new SBC seems to imply that the exact same software is used as for the previous SBC, which would suggest that this CPLD must be simulating a UART? So, if there were a "bit-bang" bug then it would be in the CPLD? Are you using some standard library for the CPLD ASYNC serial? What sort of equipment is connected to the other end - is it a standard RS-232 serial port, driven by a hardware UART?
 
This the picture of the hardware setup right now. The TTL-level USB-to-serial adapter plugs directly into the 6-pin serial connector, so there is not much wiring to pick up signal noises. The USB serial adapter is a CP2102 from eBay that I used for many different applications without problems.

On the receive side, the CPLD hardware is doing the 16x data sampling (with noise rejection mid-point sampling), shifting, and double data buffering. To the Z80, the serial receiver appears as 8-bit data port plus a status port with a Rx_data_ready flag (like a simplified, regular UART). On the transmit side, it is just a 1-bit I/O addressable register that Z80 needs to write one bit at a time with the appropriate software timing corresponding to 115200 baud (bit banging).

The first design (the one that works) has UART transmit & receive in CPLD so it looks like a simple UART from Z80 point of view. The 2nd design has the same CPLD receive circuitry, but just a bit-bang transmit register. So the software for the first design and the 2nd design is different--just in the transmit BIOS, however.

The CPLD UART design is my own. It has been around for a few years and I usually use it as a diagnostic port for whatever experiment I need to observe.

By the time the 2nd board is testing CP/M, it has already successfully received & execute the 255-byte bootstrap code via the serial port. It then successfully received and execute a monitor software, also through the serial port. The monitor software then receive the CP/M CCP/BDOS/BIOS in Intel Hex and execute it. In between these three file transfers, there are manual interactive commands. The serial port works quite reliably. I seldom require re-transmission of files.

Bill

PS, Hmmm, I thought there is a way to upload picture somehow...
 
Oh, I just realized what I've done... I had a diagnostic stub that waits on serial transmit buffer to empty out by checking the transmit empty flag. In the 1st design, the transmit buffer is always empty so the code executes through it. In the 2nd design there is no transmit empty flag, but the same flag position is used for receive ready, Since the routine requires the flag to be set (transmit empty in first design or receive ready in 2nd design), it needs to receive a character before it can proceed. This is way the 2nd carriage return (or any character) is needed for the command to proceed. Fixed that and CP/M 2.2 is working now.

Thank you for serving as a sounding board so I can retrace some of my design steps.

Bill
 
You must log in or register to reply here.
Back
Top