In my build, I use a 28L92 DUART as my RS-232 chip.
I cannot get a peep out of it, either on the terminal or on a piezo. The terminal gets a $00 when I turn off the 6502, and the piezo clicks when I turn it on.
I was using Termite on Windows(I have Putty there and on Linux as well), and this FTDI cable. It ends in a 1x6 header socket connector, and I've matched the pinout on my board(with the appropriate null-modem connections), connected to the DUARTs channel B. Channel A is connected to two 3-pin headers, intended to go to the keyboard and display. One pin each for power and ground, and one for data(from the keyboard or to the display).
This is the code I used to try and get the thing going. It's written for the SB-Assembler, and all it's supposed to do is spew a stream of 'X's out channel B, using 300 8N1, no handshaking.

I think I'm doing something wrong(otherwise it'd work, right?) and I want to try going after software before I start thinking about hardware. That build is wires under a protoboard, and it's a royal pain to deal with PLCC sockets that way, so I really do not want to have to re-wire it. Does anyone have any suggestions?

I do want to go to a PCB eventually, but laying out the schematic in KiCAD is annoying, because I've already done that work. Doing it a second time in an uncooperative program is frustration that I don't want. I can lay out a circuit board on paper easily enough(I know because I did it), but getting the program to do anything gerber-related without a schematic is not possible, to my knowledge.

Understood. Still, if you don't quickly find an obvious software problem then don't stay focussed there too long. It's worth checking for obvious hardware problems! (eg: check that the DUART is getting a chip-slect signal.)

Seems to me this is possible, although it's not the norm. Read what ElEctric_EyE had to say in this other thread.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I forgot to ask: Are you confident the problem is confined to the DUART? IOW, is your new computer functional otherwise?

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

In line with Jeff's question, please post a schematic so we can examine your interface of the 28L92 to the rest of the circuit. I'm busy right now, but will review your setup code later on. The order in which registers are written is important.

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

I mention a couple of questions which may help to isolate the bug:
0) Power supply and /RESET (at the DUART) checked?
1) Is the processor is running correctly? Have you some other sort of output (e.g. a blinking LED) to verify that the µP is working well?
2) You mentioned a mess of wires - have you take an ohmmeter or a beeper to verify that the wiring is correct?
3) Could you verify regular accesses (DUART CS = low) when looping inb IfnoSpaceleft?
4) Could you verify whether the bausrate oscillator is running?
5) The setup seems to be ok, allthough I haven't read all the datasheet, I would omit disabling channel B at the begin of your setup, as well as I won't touch channel A (STA DUART.CRA). The enable command at the end is ok.
6) What do you mean with "a piezo"? Is there a piezo connected to an output pin of the DUART? If so, have you try to get it beep?

Good luck!

I suspect the problem may be related to how the 28L92 is wired into the circuit, which is why I suggested he post a schematic. In particular, the 28L92 can be configured for use with a Motorola style bus (synchronous) or x86 style bus (asynchronous, which is what I use in my POC units). Each configuration mode has implications on what the device thinks is a hardware reset, as well as how chip select, read enable and write enable are used. Also, understanding the device's timing characteristics is essential to getting access to the configuration register to work as expected.

As for the software configuration steps, disabling the unused channel causes no harm and actually simplifies determining if the DUART is working, as fewer variables are into picture.

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

Yes it is. I have a test program that counts up on a VIA port, and that works. I have not yet tested the 65SPI, but I know that the ROM, 'C02 and VIA all work together.


I have attached a schematic. It is a touch out of date, as there are no 3.3V SPI-10 ports or 3v3 regulator, but the rest is pretty accurate. I have omitted some of the part numbers, but the GAL is a 16V8, and the DUART is the 28L92.


0) I checked power and ground, and they have continuity up to the chip pin. So does the reset line, which is active-high for this device. I'm using the 16V8 to generate that from the normal reset line. I also measured the reset line voltage at the chip, and it coresponds with an active-high reset.
1) Yes, I have 8 blinking LEDs!
2) I did a big bout of electrical tests when I finished wiring it up, and I think I fixed all the problems that manifested. There was one, which I think was a transient error, that involved two of the data lines shorting. I don't know what caused it, but it doesn't pop up often, if at all.
3) I don't have a scope available to me, but my multimeter says there's 3.59V on that pin, so I assume that means it's being selected repeatedly.
4) I put that on an oscilloscope when I was at uni(just because), and it worked there. Probing the output pin on the oscillator can with a multimeter gives 2.51V, so it's probably working.
5) I disabled channel B at the beginning because I wanted to try and avoid any problems with configuring it while it was running. The channel A accesses are to ensure that the baudrate group is the one with 300 baud in it.
6) I have a piezo that I reclaimed out of a dead computer. It was serving as its internal speaker(back when BIOS beeps were a thing). I connected it between the DUART's output and ground. It clicked when I turned it on and off(hard to hear against the noise of the switch), but that was all the noise it produced.

I don't disable channel A. That write to CRA is to get MR0A into focus so I can set the baudrate group, because the same bits in MR0B don't do that. I'll try disabling channel A in the same write(as the datasheet says you can), and see how that goes.

So far everything looks OK. More questions/suggestions:

The beeper may be of that kind that acts only like a speaker, so you have to toggle the output pin rapidly. Some of them require a parallel resistor to work. Perhaps you can give it a try. To be sure that it could beep, you may start using one pin of the VIA. 1KHz is good. And if this works with the VIA, then using the 28L92 could verify, that there is no addressing problem.

Did you checked the TxD pin of the 28L92 whether there something happens or did you look at the FTDI/Terminal only?

Again good luck!

I don't see connections for channel A's CTS and RTS pins. You need to assert CTS if you expect that channel to transmit.


What specifically is the voltage at the DUART's reset input when asserted?


You really need to use a logic probe (or scope) to ascertain that /CS is being pulled low and that you aren't seeing something else.

What are the logic equations for the GAL? I'm curious about how you are generating the DUART /CS, as well as the /RD and /WR signals.

Lastly, check the data sheet for the X1 clock generator and verify that it produces a CMOS output, not TTL.

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

It is that type, and I have gotten it to beep on a VIA before, so I know it works.


I plan to disable hardware handshaking, as neither keyboard nor LCD has handshaking support. Is that going to be an issue?
The voltage at the DUARTs RESET pin is 4.81V when I'm holding the reset button. It isn't on the schematic, for some reason, but it's connected between the /RES line and GND.


I tried to build a logic probe when I had my last issue with this build, but it never worked. Probably something about 74HC as opposed to 4000. I still have it lying about, but I don't really know why it isn't working.

I can't find the code I used for the GAL, but I remember how it works. The chip selects are all generated by the address lines and nothing else. I'm synthesizing /RD and /WR, both from Phase 2 and R/W. RES is generated by inverting /RES.

The X1 generator is an MXO45 can oscillator. The datasheet says it produces HCMOS/TTL signals. Looking at the actual numbers, the output with a CMOS load is 90% of Vcc. This one only has a single CMOS load, so that number should be good.

It won't be as long as the 28L92 transmitter setup has been configured to not look at CTS. Bit 4 of MR2 of each channel must be set to 0 to disable transmitter hardware handshaking.


4.81 volts is well above the minimum, so you should be okay with reset.


That logic sounds right, so I think you should be okay with chip select, etc.


I'd say at this point your hardware should be good to go. Time to carefully examine your configuration.

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

Well then you could try let it beep. After setup the OPCR you only need to store a constant value first in SOPR then delay then same value in ROPR delay and loop. Perhaps you should set & reset simply all outputs (if you have wrongly counting the pins and the beeper is not connected to the expected one). If this would work, addressing, /CS, /WR would be ok. If not, you know where to seek in detail.

Although, it's not generally a good idea to have floating inputs, even if you believe you don't care about their value. In some technologies there's a free weak internal pullup, but it still might be best to have a pullup resistor.

Good thing you mentioned it. In the case of the 28L92, unless the input pins are configured to be active, meaning set to receive inputs, they may be floated. Of course, there's no harm of course in biasing them to ground or Vcc. Other than the two inputs acting as CTS for the two channels, I left all input pins as no-connects in POC V1.1. I have not observed any issues to date.

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

That is what I should have done as well, but I put a couple of SPI-10 signals there. I'll change the AUX line when I do the PCB, and put it on the SS7 pin of the 65SPI, and connect the IRQ line in to the system IRQ. Splitting up one function into multiple chips is not such a bright idea.