6502.org Forum Projects Code Documents Tools Forum
It is currently Sat Nov 23, 2024 4:04 am

View unanswered posts | View active topics


Board index » 6502.org Users Forum » Programming

All times are UTC




Post new topic Reply to topic  Page 1 of 1
  [ 13 posts ] 
  Previous topic | Next topic 
Author Message
Procrastin8
 Post subject: SC28L92 blinky lights
PostPosted: Wed Aug 03, 2022 10:32 am 
Offline

Joined: Tue Jul 07, 2020 10:35 am
Posts: 40
Location: Amsterdam, NL
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:
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.
Top
 Profile  
Reply with quote  
kernelthread
PostPosted: Wed Aug 03, 2022 11:10 am 
Offline

Joined: Wed Jun 23, 2021 8:02 am
Posts: 166
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.
Top
 Profile  
Reply with quote  
Procrastin8
PostPosted: Wed Aug 03, 2022 12:24 pm 
Offline

Joined: Tue Jul 07, 2020 10:35 am
Posts: 40
Location: Amsterdam, NL
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...
Top
 Profile  
Reply with quote  
BigEd
PostPosted: Wed Aug 03, 2022 1:18 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
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.
Top
 Profile  
Reply with quote  
floobydust
PostPosted: Wed Aug 03, 2022 1:55 pm 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
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 :wink:

_________________
Regards, KM
https://github.com/floobydust
Top
 Profile  
Reply with quote  
Procrastin8
PostPosted: Wed Aug 03, 2022 2:35 pm 
Offline

Joined: Tue Jul 07, 2020 10:35 am
Posts: 40
Location: Amsterdam, NL
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 :D
Top
 Profile  
Reply with quote  
Procrastin8
PostPosted: Wed Aug 03, 2022 2:43 pm 
Offline

Joined: Tue Jul 07, 2020 10:35 am
Posts: 40
Location: Amsterdam, NL
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.
Top
 Profile  
Reply with quote  
Procrastin8
PostPosted: Wed Aug 03, 2022 3:30 pm 
Offline

Joined: Tue Jul 07, 2020 10:35 am
Posts: 40
Location: Amsterdam, NL
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.
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Wed Aug 03, 2022 9:05 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8507
Location: Midwestern USA
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.

Attachment:
File comment: NXP 28L92 Registers
registers.asm [4.94 KiB]
Downloaded 45 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.

Attachment:
File comment: NXP 28L92 Programming Data
data.asm [3.19 KiB]
Downloaded 44 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.

Attachment:
File comment: Kernel Tables Loaded During Boot
ktables.asm [13.56 KiB]
Downloaded 43 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:
;   ———————————————————————
;   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.


Attachments:
reset.asm [12.94 KiB]
Downloaded 52 times

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
Procrastin8
PostPosted: Fri Aug 05, 2022 11:21 am 
Offline

Joined: Tue Jul 07, 2020 10:35 am
Posts: 40
Location: Amsterdam, NL
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...
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Fri Aug 05, 2022 6:53 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8507
Location: Midwestern USA
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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
Procrastin8
PostPosted: Sat Aug 06, 2022 10:58 am 
Offline

Joined: Tue Jul 07, 2020 10:35 am
Posts: 40
Location: Amsterdam, NL
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 :lol:
Top
 Profile  
Reply with quote  
Sheep64
PostPosted: Mon Nov 21, 2022 12:07 pm 
Offline
User avatar

Joined: Tue Aug 11, 2020 3:45 am
Posts: 311
Location: A magnetic field
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.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 1 of 1
  [ 13 posts ] 

Board index » 6502.org Users Forum » Programming

All times are UTC


Who is online

Users browsing this forum: No registered users and 17 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
6502.org is an ongoing project by Mike Naberezny and contributors.