The QUART's data sheet is not very well written and has at least one outright error in the hardware description, so a little bit of the problem is with documentation. There are some gaps in the discussion of how interrupt arbitration is set up and information related to reading the "current interrupt register," which identifies the source of the interrupt, is incorrectly described, that determined by patient experimenting. Succinctly stated, I'm finding that I cannot use the QUART in the type of interrupt handler that works with the DUART, despite the data sheet implying the 28C94 is functionally equivalent to a pair of 26C92 DUARTs (which is baloney, as some important setup functions were moved from one register to a different one. Hence I don't feel I have a thorough understanding of the QUART.


The key difference between the two machines is the use of a CPLD as glue logic in V2. Other than doing detailed timing analysis, I've verified that the logic works in-circuit exactly as designed and as simulated. I definitely have full RAM access, and the QUART gets a chip select when it should, responds to read and write operations, etc. I can drive the console display via polled I/O (pic attached) and, in fact, verified that I can also drive TIA-232 ports C and D (port B is wired for data transfers from on of my Linux boxes, so I can't yet test it). So I'm confident that there are no hardware anomalies, or at least no show-stoppers.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

May I asked what "It does not work" means more specifically?

To me the RX section looks very well and should work fine.
Within the TX part I´m not sure how

works - which controlregister is written?

As far as I have looked into the datasheet, perhaps using the IMR to suppress IRQs from an empty TX may be an easy way.

I agree the documentation is ... well it´s a complex circuit and that should cause a very clear structured manual. But such things are rare, very rare.


Arne

If the QUART generates an interrupt, issuing an "update current interrupt register (CIR)" command should cause the CIR to be loaded with a byte that indicates the interrupt source, channel number, etc. It doesn't happen. I ruled out the device being defective by substituting another QUART...same results. This tells to me I do not have the device correctly configured, am not understanding how the interrupt arbitration functions work, or there is a time lag from when the command to update the CIR is issued (it's a dummy write to a specific global control block register) until the CIR contains valid data.

A timing issue is a theoretical possibility, as everything that goes on in the QUART is slaved to the 3.6864 MHz X1 clock. Assuming the instruction to read the CIR immediately follows the instruction to update the CIR, only four Ø2 cycles will elapse between the two operations, which could be too fast for the QUART (however, I/O accesses are wait-stated, which does give the QUART more time to respond). However, I think I may have ruled out timing, as I've tested for that by placing some NOPs between the "update CIR" and "read CIR" instructions. That had no apparent effect.


Location TIACR is a set of four direct (zero) page pointers to the command registers of the four channels within the QUART. Earlier in the code, .X was loaded with a channel offset (channel index × 2, where the channel index is 0, 1, 2 or 3). Writing the value NXPCRTXD to the command register disables the transmitter. There is a corresponding value that when written into the command register enables the transmitter.

The use of indexed indirect addressing to access chip registers, such as in the above code fragment, has been tested and verified on the 28L92 DUART in POC V1.1.


Suppressing the TxD IRQ is no easier from a programming standpoint than disabling the transmitter, as the IMR in each block of the QUART controls both transmitters in the block, as well as the RxD IRQs, change-of-state IRQs, etc. Each channel's command register is independent of the others', so no special provisions must be made to disable or enable a specific transmitter. Fiddling with the IMR means keeping track of its current state in a shadow register so the settings of the other interrupt sources' bits are preserved when one specific interrupt source is disabled or enabled—the IMR is write-only, so instructions such as TRB and TSB can't be used..


Data sheets widely vary in quality. For example, the SCSI host adapter I designed for POC V1 uses the AMD 53CF94 bus controller. This device is substantially more complicated than the 28C94 QUART, yet was less challenging to get working, due to a well-written data sheet. If the 28C94's data sheet was as well written as the 53CF94's data sheet we wouldn't be having this discussion.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

OK, the CIR isn´t reflecting the source of IRQ.

This should happen after /IACK or writing into $2A. I assume /IACK is not used.
Hmm, can you detect any change in CIR say before and after an IRQ?

After /RESET CIR should be $00. Setting up baudrates and enabling say a single TX channel should leave CIR unchanged. Perhaps a TxBufferEmpty_IRQ could appear - I am not sure whether this requires a previous transmission or simply corresponds to the buffer state.
If an IRQ appears then CIR should change (after writing into $2A).
If no IRQ appears, then filling the buffer with some characters and wait for their transmission should cause an IRQ.

If the CIR doesn´t reflect this - well then things getting ugly


Arne

/IACK isn't being used—I don't have enough I/O pins on the CPLD. I am writing on register $2A to get CIR to update. I haven't tried comparing CIR's contents pre- and post-IRQ.


The QUART has 8-deep receiver and transmitter FIFOs. Following a hard reset and assuming the relevant bits in the interrupt mask register (IMR) have been set, RxD will interrupt if its FIFO is not empty. TxD will interrupt if its FIFO is empty. I am not getting the TxD IRQ, even though it has been enabled in the IMR. That said, merely enabling the IRQ in the IMR is not sufficient to generate interrupts. The interrupt arbitration must be set up to give interrupts enough priority so the IRQN output will be asserted. That appears to be the sticking point.


TxD should interrupt the instant it is enabled, as the condition that must be present for TxD to interrupt, an empty FIFO, will exist at the time when TxD is enabled.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

What does happened if you send a dummy char via TXn regardless of the IRQ state? Will then appear a TX_Empty_IRQ?
(In the datasheet i didn´t found a clear statement, that enabling TX interrupts will cause IRQs even if the corresponding channel was never used so far.)

Arne

Nothing. Writing to TxD would immediately withdraw the interrupt, if it was there to begin with.


Now you are starting to understand why the data sheet is more of a problem than the QUART itself.

In all NXP 26- and 28-series "industrial" UARTs, TxD will interrupt any time its FIFO is empty.¹ As soon as at least one datum is written to the FIFO the interrupt will be "withdrawn," which simply means the interrupting condition will no longer be present and the IRQN output will no longer be driven low.

RxD works the same in reverse: as soon as at least one datum is de-serialized and stored in the FIFO an interrupt will occur, and the interrupt will be withdrawn when a datum is read from the FIFO.² This is, of course, assuming the relevant bits in the interrupt mask register (IMR) have been set.

———————————————————————————————————————————————————
¹TxD can be configured to interrupt any time there is an empty position in the FIFO or can be configured to only interrupt when the FIFO is completely emptied. I use the latter configuration, as it produces fewer interrupts during a period of continuous transmission.

²RxD can be configured to interrupt only when the FIFO is full and to withdraw its interrupt as soon as at least one datum is read from the FIFO, which is the method I use. Doing so creates an interesting problem of "stale data," for which the solution is to enable the RxD watchdog IRQ, which will happen if data becomes stale for a period of 64 bit times, which is approximately 556 microseconds at a 115.2Kbps data rate. Use of the watchdog feature means an IRQ will occur in response to a single datum being transferred from the serial shift register into the FIFO, but not right at the time of the transfer.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Of course, writing into TxBuffer withdraws the IRQ, but when the char is then transmitted the buffer becomes empty, which should trigger the IRQ. I would not wonder if this happens. This would simply means the Tx_Empty_IRQ_statusbit would only trigger bidding and so on if the FIFO becomes empty.

Don´t misunderstand me, I don´t want to fool you with dull questions and/or suggestions. I have no equivalent hardware, so I cannot try this by myself. Nor do I remember whether this QUART had been used in some machine so I might take a look, how init was performed there.

Arne

My long familiarity with NXP UARTs has been in the realm of machine controllers, not computers. Unfortunately, I have never encountered the 28C94 in the past, so I don't have an example to follow. The code I developed for the 26C92 (and later, 28L92) in POC V1 was based upon software I had developed 25 years ago for a 65C02-based terminal server, which had a Philips (later NXP, now Microchip) SCC2698B octal UART.

The 2698B doesn't have TxD FIFOs or an interrupt arbitration system and hence is not very efficient in using host resources, as it generates an IRQ for each datum transmitted from each active port. For example, a full screen repaint of a WYSE 60 running at 38.4 Kbps attached to one port would have meant 1920 IRQs generated during a period of 500 milliseconds. If all eight ports were simultaneously transmitting, which was often the case in the terminal server application, 15,360 IRQs could be generated in rapid succession. It got really onerous at high CBAT data rates, often causing an interrupt storm that would all but kill foreground processing.

When I designed POC V1.0, I used an NXP 2692, which is essentially one of the four blocks in a 2698B. It was the quickest way to getting a functioning design. Once I had it working I decided to try out the 26C92, which has 8-deep FIFOs on both RxD and TxD. That then led to use of the 28L92, whose FIFOs are twice as deep as those of the 26C92 and 28C94—the 28L92 is what is currently in POC V1.1.

There is another QUART in the NXP lineup, the 28L194, which is sort of like two 28L92s in a single package. Unlike the 28C94, the 28L194 uses an external clock (presumably Ø2 in a 65xx system) to sequence internal operations, and may be operated synchronously or asynchronously. I haven't a clue at this time if it can be adapted to the 65xx bus. If it turns out it is adaptable then that means the 28L198 OCTART would also be adaptable, as it too uses an external clock, although the minimum frequency has to be 33 MHz. That might not be a problem in a system using a WDC 65C02 or 65C816, since the clock can be divided by a flop to generate Ø2 in a range that is acceptable to the MPU.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I´ve found this:


I wonder that they use COS interrupt.

I have also studied the 26C92. It is easier to read but again it is not stated whether enabling of a transmitter (nerver used before) will cause an immediate interrupt (due to TxEMT). But as you have used that in POC-1 you know how it behave.

The above application note (which I have) describes a specific scenario where half duplex is used on a TIA-485 link, which can support bi-directional operation. The COS interrupt is used to cause a transmitting station to "relinquish" the link when it is through sending data so other stations can talk. COS is not relevant to full duplex TIA-232, which is what is implemented in the POC series.


TxD behavior is implied. As I said earlier, TxD will interrupt if the FIFO is empty, assuming the relevant bit is set in the IMR. As it is not possible to load data into the FIFO of a disabled transmitter, enabling the transmitter will cause an immediate TxD empty interrupt. The interrupt will be cleared if a datum is written into the FIFO or the transmitter is disabled.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I have scanned all old projects, sadly none uses the 28C94. But I have found this http://man.openbsd.org/OpenBSD-5.9/qsc.4. I have no experience how to get access to that driver they mentioned there, but perhaps you.

In Philips Components Data Communication Products Handbook 1990, the Preliminary Product Specification for the SC26C94/SC68C94 says ICR threshold is reset to $3F (!) - this may simply be wrong but would very well suppress any Tx IRQs.

EDIT(1): perhaps therein you may found some clues:

Thanks for tracking that down. I read through the source code but didn't really see anything that would be helpful.

I have two data sheets for the 28C94, one from 1998 and the current version. Neither mentions the ICR threshold being set to any specific value at reset (BTW, I do have the active high reset wired up and functioning).

However, your comment kicked a little thought in my head that has to do with undocumented hardware quirks. When I built POC V1.0 I ran into a seemingly obdurate hardware glitch involving use of <addr>,X addressing in order to select a specific register in the SCC2692. As it turned out, it was a characteristic of the 65C816 that was provoking the problem (and solved with VDA and VPA address qualification). In troubleshooting the matter, I discovered that NXP's statement concerning consecutive accesses of a command register was not correct. They were saying that consecutive writes to the command register had to be separated by at least three X1 clocks so the DUART would correctly process the previous command. It turned out that consecutive accesses were what mattered, not just writes. I took care of that little issue by intentionally making the process of loading the registers during POST a bit on the slow side.

In the process of sorting out this current mess, I accidentally downloaded the data sheet for the 28L202 DUART, which is a souped-up version of the 28L92, and discovered that its write-up on the interrupt arbitration makes more sense. In reading it, it became glaringly apparent that the 28C94's documentation is rough around the edges and guilty of some omissions. That, along with your statements, made me suspect that some type of non-zero value must be written into the ICR to activate interrupt arbitration, which I haven't done up until now. The ICR is read/write, and during my experimentation, I determined the ICR is loaded with $00 following reset. I mistakenly assumed that if ICR contained $00 any interrupt would be active. The four bidding control registers (BCR, also read/write) are likewise defaulted to $00 at reset, but apparently need to be non-zero so the counter/timer interrupt, which is crucial to the firmware's operation, will occur.

So the new plan of attack is to work out proper values for the ICR and BCRs, add them to the setup data tables, and see if things start working.

I have actually considered redesigning POC V2 and eliminating the 28C94, replacing it with a pair of 28L92s, just to get this problem out of my hair. However, that would be tantamount to quitting—and when it comes to solving computer hardware problems, I tend to keep going, even when quitting would be the smart thing to do. So armed with the bit of insight I've gotten from reading the 28L202 data sheet I am redetermined to kick the 28C94 to the curb and make it do what I tell it to do.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I´m sure you will get your quadriga the way you want.

Not sure how a quartet of horses will help, though.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!