Dr Jefyll wrote:
I forgot to ask: Are you confident the problem is confined to the DUART? IOW, is your new computer functional otherwise?
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.
BigDumbDinosaur wrote:
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 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.
GaBuZoMeu wrote:
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!
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.
BigDumbDinosaur wrote:
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.
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.