I don't understand why my 1979-dated Z8002 is behaving like that, either. During my working career, I've worked with pre-production engineering samples with a long list of errata, but this flaw seems too serious to be released even as engineering sample.
I've tried many differnt ways of accessing the serial receive including memory mapped the receiver but IO map the transmitter. That arrangement actually worked well enough for me to go ahead and wire up the RAM. I was resigned to memory mapped serial port as the permanent solution until I stumbled across the indirect register access method. According to the databook, the CPLD can be reprogrammed 100 times. I have easily exceeded that limit trying different ways of working with the serial port!
CPLD latches AD[0] to produce A[0] and uses it to control upper and lower chip selects of RAM. A[0] is not involved with serial port interface.
I've tried both 3.68MHz clock and 1.84MHz clock for Z8002 and didn't see any difference.
I didn't "spin" on UART status bit because IN instruction is not working using direct addressing, so I can't read the status bit with IN instruction. When I did memory map of the receiver, I was able to spin correctly on UART status bit when UART status is accessed as memory.
The DataReady looped back to RdData is for moving data from serial port's internal register to data buffer thus reset the serial receiver state machine to accept next serial input. This implements the "double buffer" of serial receiver. I have used this particular serial port design for 5-6 years for different processors, so I'm fairly confident the serial Rx and Tx are working properly, but anything can go wrong, as any practicing engineer knows.
I've revised the CPLD design to correct a problem with RAM access. The current CPLD design has a serial loader in ROM that loads and runs 256-byte program in RAM. It is working well using register-indirect access of the serial port.
Bill