Dual async module XR88C681

[Tadeusz Pycio]

I present a module compatible with RC80 dual serial port using XR88C681 (probably also SCN2681).
The vector interrupt pinout is consistent with what Steve Cousins ​​uses in their products.
Courtesy of Colin C MacArthur who wrote the module software confirming its operation. The issue of IM2 mode remains open.

[Colin MacArthur]

Sorry about the 57.600...

On my board (Alan's QUART), the CLK was the system CLK, 7.3728MHz.

Now that I see you are using a 3.6864 Xtal the attached should work.

CH A = 115.2k BRG = Rx=8(115.2k) & Tx=8(115.2k) With Extended Bit=1

CH B = 230.4k BRG =  Rx=E(Xtal/16) & Tx=E(Xtal/16) With Extended Bit=1 (3.6864MHz / 16)

Try the attached

CM

FYI

If you want to eliminate the Xtal and drive the DUART with the system CLK then the BRG will have to be adjusted...

[Tadeusz Pycio]

Now that I see you are using a 3.6864 Xtal the attached should work.

CH A = 115.2k BRG = Rx=8(115.2k) & Tx=8(115.2k) With Extended Bit=1

CH B = 230.4k BRG =  Rx=E(Xtal/16) & Tx=E(Xtal/16) With Extended Bit=1 (3.6864MHz / 16)

Hi, Colin

Currently works on 115k. Yes, the frequency matches the data sheet.
This dirt makes me wonder.

[Colin MacArthur]

I have seen this before with high speed communications, when the system clock is NOT used as the UART CLK

I will take a look and see if I missed something...

If yo can try 230.4k by changing the console to  device 2 and see if it gets WORSE...

This dirt makes me wonder.

You could try removing the Xtal and using the SYS_CLK...

I can send you a lower speed version 

Which HEX file are you using 8k or 16k?

CM

[Tadeusz Pycio]

Hi, Colin

I run tests on Classic also clocked at 3.6864MHz, I don't have many options here. This effect is only after the DEVICES command, other screens are OK.

[Steve Cousins]

Colin / Tadeusz

The cause of the unwanted characters is a missing NULL after the devices string. See listing below.

No need to worry about clock drift etc.

Steve

; Hardware: Output devices info

;   On entry: No parameters required

;   On exit:  AF BC DE HL not specified

;             IX IY I AF' BC' DE' HL' preserved

Hardware_Devices:

            LD   HL,iHwFlags    ;Get hardware present flags

            LD   DE,@szHwQUART  ;Serial QUART message

            BIT  0,(HL)         ;Serial QUART present?

            CALL  NZ,OutputZString  ;Yes, so list it

            RET

@szHwQUART: .DB  "1 = XR88C681 UART Port 1 (@80)",kNewLine

            .DB 0               ; >>>>>> ADD THIS LINE <<<<<<<<

            .DB  "2 = XR88C681 UART Port 2 (@80)",kNewLine

[Steve Cousins]

Hi Colin

Nice job adding support in SCM. It is great to see others building on SCM.

A couple of observations:

It might be worth you basing future support on SCM v1.1 as this has a cleaner interface with the hardware support layer (BIOS). If I add functionality to SCM it will now be based on v1.1 code and I'd hope to maintain compatibility with BIOS code written for v1.1.

It would be better to give each configuration its own configuration identifier. The screenshot shows this version identifies itself as "R1", which is the configuration for standard RC2014 hardware. There is advice in the documentation about configuration identifiers.

Steve

[Steve Cousins]

Ooops, the ".DB  0" line should have been after the second port string.

Steve

[Tadeusz Pycio]

The cause of the unwanted characters is a missing NULL after the devices string. See listing below.

Hi, Steve

I will check it tomorrow, something has seduced me and I have changed the configuration of the equipment thinking that using Z80CTRL will reduce my desk clutter :)

[Chris Odorjan]

I've done something similar with the PLCC version; my board is a bit cluttered though as I brought out all the I/O lines and added the ability to use the system clock or an oscillator with (or without) a divider (I'm not sure if these will be useful but I like to experiment). I'm also not sure whether 'Z-Mode' will be useful (it was one of the things I didn't test when I had it breadboarded) but I might end up using it with an XR88C92 which doesn't support that anyways.

Is there a RomWBW driver for the DUART? I was planning on starting one as soon as I get the hardware assembled (the breadboard version has long since been dismantled to make room for other projects). Unfortunately, the PCB is somewhere between OSHPark and my house right now...

--

Chris Odorjan

[Tadeusz Pycio]

The cause of the unwanted characters is a missing NULL after the devices string.

Hi, Steve

Adding NULL helped. We can conclude that the 88C681 driver in Small Computer Monitor is working. I will now rebuild my test kit to be able to write BIOS CP/M with support for this serial port.
Picture that shows before and after correction.

[Colin MacArthur]

Hello

The board looks GREAT

Would you please send me your gerber files so I can add this card to my monthly jlcpcb order...

I looked in my PLCC UART parts box and found 7 x SCC2692AC1A44, these are pin comparable (https://www.maxlinear.com/appnote/dan123.pdf)....

All the internal registers in the SCC2692 and XR88C92/192 are identical with only a few exceptions: 

• The XR88C92/192 has an additional mode register, Mode Register 0 (Watch dog timer, RX and TX trigger levels and extended baud rate tables), for channels A and B while the SCC2692 does not. 

• Since the XR88C92/192 has a larger FIFO than the SCC2692, the selectable transmit and receive trigger levels are different. 

• At the address offset of 0x2 and 0xA, the SCC2692 has a read-only BRG Test Register and 1X/16X Test Register, respectively, while these offsets are reserved for the XR88C92/192. 

• The XR88C92/192 has a Miscellaneous Command in the CRA and CRB register bits 7-4 that has a different function than the SCC2692. When 0xB is written to the upper nibble of CRA or CRB,

   the XR88C92/192 sets the MR pointer to MR0, but this has no effect on the SCC2692.

Thank-You

CM

FYI

The SCM driver that I posted should work with your card...

I will be talking with Wayne to see if I can help get XR88xxx drivers working in RomWBW...

[Chris Odorjan]

On Tuesday, 24 March 2020 11:22:39 UTC-4, Colin MacArthur wrote:

Hello

The board looks GREAT

Would you please send me your gerber files so I can add this card to my monthly jlcpcb order...

Thanks, hopefully I've generated the gerber files properly (so far I've only dealt with OSH Park which accept .kicad_pcb files directly). Licence is CC BY-SA 4.0 if anyone's wondering...

 

I looked in my PLCC UART parts box and found 7 x SCC2692AC1A44, these are pin comparable (https://www.maxlinear.com/appnote/dan123.pdf)....

All the internal registers in the SCC2692 and XR88C92/192 are identical with only a few exceptions: 

• The XR88C92/192 has an additional mode register, Mode Register 0 (Watch dog timer, RX and TX trigger levels and extended baud rate tables), for channels A and B while the SCC2692 does not.

The presence of MR0 can be used to differentiate between an XR88C681 and XR88C92/192, which is nice as their extended baud rate tables are different and enabled differently. Looks like the SCC2692 is different again and the tables are toggled with a read from register 2?

Thanks,

--

Chris Odorjan

[Alan Cox]

The 88C681 is much nicer because the baud rate select (as with the 684) is by commands to CR and is per channel not per pair so you don't have to do all the horrible machinations to reprogram both channels and find a BRG that has the two different rates in (or error if the combination is not possible).

It's not just minor register differences the CR register commands are different.

Alan

[Chris Odorjan]

On Tuesday, 24 March 2020 18:39:42 UTC-4, Alan Cox wrote:

The 88C681 is much nicer because the baud rate select (as with the 684) is by commands to CR and is per channel not per pair so you don't have to do all the horrible machinations to reprogram both channels and find a BRG that has the two different rates in (or error if the combination is not possible).

Oh bother, I had assumed the extended table selects were specific to each channel but checking the datasheets for the XR88C92 and SC26C92 it's clear that the bits in MR0A affect both channels (and the same bits in MR0B don't do anything and should be zero) :-P 

--

Chris Odorjan