SC28L92 blinky lights

[Procrastin8]

I am trying to bring up my SC28L92 on my new SBC (see this post for hardware spec) and so to start, I just want some blinky lights. My hardware has LEDs connected from +5V to TxD and RxD lines so I thought if I can set Tx via the 28L92, I should be able to see some lights!

However, these efforts have failed so far. Here's what I tried (note that the 28L92 is located at base address $BFC0):

Code: Select all

LDA #$30    ; reset transmitter
STA $BFC2   ; send to CRA
LDA #$04    ; enable transmitter
STA $BFC2
LDA #$60    ; assert TxD LOW. this _should_ turn on the light!
STA $BFC2

Sending a BRK start command should have turned the light on but it did not Do I need to actually set up all the baud rates, oscillator dividers, etc. in MRx before I can turn the transmitter on?

Things like writing to and reading from the miscellaneous register work. I can write to c/t upper/lower and lock those values in via a C/T start register read. So basic access appears to be working. Perhaps I am abusing the transmitter function but it seems like it should have worked.

[kernelthread]

If you look at the 28L92 datasheet description of the command codes, it says this:

"Start break. Forces the TxDA output LOW (spacing). If the transmitter is empty the start of the break condition will be delayed up to two bit times. If the transmitter is active the break begins when transmission of the character is completed. If a character is in the Tx FIFO, the start of the break will be delayed until that character, or any other loaded subsequently are transmitted. The transmitter must be enabled for this command to be accepted"

The reference to a delay of up to two bit times strongly suggests that the baud rate divisor must be set up before you can use the functionality.

[Procrastin8]

Quote:

The reference to a delay of up to two bit times strongly suggests that the baud rate divisor must be set up before you can use the functionality.

This did it! Just had to actually write a value to the baud select. Thank you! I'm happy to see i didn't completely screw up wiring. Now to get the counter/timer working...

[BigEd]

BTW you'd usually connect an LED with a series resistor, to limit the current. Without the resistor, depending on the situation, you might even blow the LED with too much current. Also, without the resistor modern LEDs can be unhelpfully bright.

[floobydust]

Procrastin8 wrote:

Quote:

The reference to a delay of up to two bit times strongly suggests that the baud rate divisor must be set up before you can use the functionality.

This did it! Just had to actually write a value to the baud select. Thank you! I'm happy to see i didn't completely screw up wiring. Now to get the counter/timer working...

When setting up the SC28L92, be careful how you access the MRx ports. My 4.01 BIOS explains this in the comments. It's an anomaly in how the 65C02 works with indexed addressing that increments the MRx before you actually load the register.

I also used a soft table (copied from ROM) to set everything up, so you just edit the soft configuration table to alter the operating parameters and call the BIOS routine to change the config realtime.

Once you get the 28L92 functional, you'll never touch a 6551 again

[Procrastin8]

BigEd wrote:

BTW you'd usually connect an LED with a series resistor, to limit the current. Without the resistor, depending on the situation, you might even blow the LED with too much current. Also, without the resistor modern LEDs can be unhelpfully bright.

There are series resistors

[Procrastin8]

Ok weirdness ensues. Can't get it to work again even following exact same steps, but timer/counter and IRQs are working now at least. More debugging! One big positive is that I was able to take my VIA expansion board out. I was using VIA timer to generate system clock and now it's fully onboard which was a big goal of this design.

[Procrastin8]

Ok I have to write values to MRx as well. Haven't nailed down exactly which ones, i just wrote zeroes to all 3. Then wrote baud rate. then did the code originally posted and it works. I was going to write MRx values anyway but now I know.

[BigDumbDinosaur]

Procrastin8 wrote:

Ok I have to write values to MRx as well. Haven't nailed down exactly which ones, i just wrote zeroes to all 3. Then wrote baud rate. then did the code originally posted and it works. I was going to write MRx values anyway but now I know.

The 28L92 has very few defaults at reset. Ultimately, that means at boot time you need to load just about all of the L92’s registers with appropriate values to get the device working. This design feature makes the L92 is highly programmable, and virtually every aspect of serial communication can be tailored to almost any application.

Attached are some source files from my POC V1.3’s firmware that you may find useful in working with the L92.

registers.asm

NXP 28L92 Registers

(4.94 KiB) Downloaded 80 times

The above file defines the L92’s registers. Channel register definitions are offsets relative to the start of the device's block. Since there are two channels, there are two starting points in the block for channel access, one at offset $00 in the block and the other at offset $08 in the block.

data.asm

NXP 28L92 Programming Data

(3.19 KiB) Downloaded 75 times

The above defines the parameters that may be loaded into registers. It also includes some mask values that are used during runtime to control the L92.

ktables.asm

Kernel Tables Loaded During Boot

(13.56 KiB) Downloaded 72 times

The above defines the lookup tables used during system startup. The L92 stuff starts at line 64 in the file. During system boot, the tables are read in reverse, with the first field in each entry identifying the register to be loaded and the second field being the parameter that will be written into the register. As POC V1.3 has two DUARTs, there is a secondary table that is specific to one of the DUARTs. That table sets up DUART #1 to generate a 100 Hz jiffy IRQ.

As flooby noted, there is a bug in the 65C02 that causes it to do a spurious read on the base address when using ,X or ,Y addressing. If not accounted for, it will result in MR being “touched” when it shouldn’t be, making it, among other things, impossible to program MR0. You can work around this annoyance by using <base_address> - 1 as the base for accessing the 28L92 during setup. The register number should be incremented by one to compensate. The resulting page crossing on each access will prevent the spurious read on MR. The 65C816 doesn't have this problem if addresses are qualified with VDA and VPA.

The following code is how I configure the DUARTs in my POC units:

Code: Select all

;	———————————————————————
;	Configure Virtual QUART
;	———————————————————————
;
         ldy #s_nxptab-s_word   ;main setup table index
;         
.0000110 ldx nxpsutab,y         ;get register
         lda nxpsutab+s_byte,y  ;get parameter
         sta io_sioa,x          ;write to DUART #1
         sta io_siob,x          ;write to DUART #2
	.rept s_word
         dey
	.endr
         bpl .0000110           ;next register
;
         ldy #s_nxptax-s_word   ;auxiliary setup table index
;
.0000120 ldx nxpsxtab,y         ;register
         lda nxpsxtab+s_byte,y  ;parameter
         sta io_sioa,x          ;write to DUART #1 only
	.rept s_word
         dey
	.endr
         bpl .0000120           ;next register
;
;	————————————————————————————
;	Activate Interrupt Subsystem
;	————————————————————————————
;
         ldx #hz                ;jiffy IRQ rate
         ldy #nxpairq | nxpbirq ;DUART #2 IRQ enable
         stx jiffct             ;set jiffy counter
         sty io_siob+nx_imr     ;DUART #2 channel IRQs only
         cli                    ;start...
         bit io_quart+nx_scta   ;jiffy IRQs

In the above, S_BYTE = 1, S_WORD = 2, and hz = 100, the latter which is the number of jiffy IRQs that occur per second. The .REPT — .ENDR pseudo-op pair repeats code. Labels such as .0000110 are local, with limited scope.

[Procrastin8]

This was very helpful, thank you. Armed with this, I now have everything working synchronously (basically just replacing my old synchronous get/send byte routines). The only issue I've found so far is probably from either my terminal software on the connected computer or the CH340 usb-to-serial chip I'm using. ~CTS isn't always being asserted on cold start. If I manually deassert, reassert (or just restart connection) from terminal software everything works a treat. I don't see anything I can configure or change on the 28L92 side so must be further upstream. That said, I have removed the ACIA expansion board, upped the system (and 28L92) clock to the intended 3,6 Mhz and I'm ripping right along! Would be interesting to test double clock at my stretch goal of 7+ Mhz...

[BigDumbDinosaur]

Procrastin8 wrote:

The only issue I've found so far is probably from either my terminal software on the connected computer or the CH340 usb-to-serial chip I'm using. ~CTS isn't always being asserted on cold start. If I manually deassert, reassert (or just restart connection) from terminal software everything works a treat. I don't see anything I can configure or change on the 28L92 side so must be further upstream.

Poorly-implemented or non-functional hardware handshaking seems to be relatively common with USB <—> serial adapters. You can get away with XOFF/XON handshaking up to 9600 bPS, but that is actually more difficult to implement than the 28L92’s automatic CTS/RTS. I've tested the auto CTS/RTS at 230.4 KbPS...it’s 100 percent reliable.

It is possible to “manually” control the L92’s RTS output by manipulating the state of OP0 (channel A) or OP1 (channel B) so the remote station is told to stop transmitting before some arbitrary queue level has been reached. I’ve fooled around with that feature, but concluded the auto CTS/RTS is more than adequate on a system running at a reasonable clock rate.

Quote:

That said, I have...upped the system (and 28L92) clock to the intended 3,6 Mhz and I'm ripping right along! Would be interesting to test double clock at my stretch goal of 7+ Mhz...

The maximum permissible X1 clock rate supported by the 28L92 is 8 MHz. If using the X1 clock as the bit rate generator, which is the default, none of the standard rate tables would apply. In most cases, there is little to be gained by upping the X1 clock. If you do, it would be best to use 7.3728 MHz to allow you to continue to use the standard rate tables, doubled, of course.

You really need to separate the Ø2 clock from the X1 clock.

[Procrastin8]

Quote:

You really need to separate the Ø2 clock from the X1 clock.

Everyone has to make trade-offs. For me, the trade-off was (and still is) everything must fit on a 100mm x 100mm board. Ultimate speed is not my real aim, I was actually pretty happy with 2Mhz on v1 of the board, so 7,3728 would be more than adequate. I did have the idea of running the 28L92's clock through the GAL. It could just be a passthrough if the speed was within range or I could divide it if it wasn't. Or if I can get rid of the 74HC00 I'm using to create the qualified read/write and inverted RES lines and move those to the GAL I could have enough space for another clock. It's always a series of trade-offs. So far I'm quite happy with what i've chosen but who knows how long that will last

[Sheep64]

BigDumbDinosaur on Fri 5 Aug 2022 wrote:

You really need to separate the Ø2 clock from the X1 clock.

I presume Procrastin8 is working on a minimal system where the UART frequency is critical and processor frequency isn't. On this basis, they can share one crystal.