I've reviewed his schematic and do see VDA and VPA connected to one of the glue logic GALs. However, I also note this GALasm logic statement:

Code:

IO1SEL = /A20 * /A19 * /A18 * /A17 * /A16 * A15 * A14 * A13 * A12 * /A11 * /A6 * /A5 * /A4 * VDA * !VPA

Is !VPA a synonym for /VPA? What does the ! operator represent in GALasm?

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

It should be of no consequence.. From the source:



-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

One step ahead of ya I actually did try linear initialization code at one point and it didn't help. I also reburned my GALs and verified the VDA/VPA logic just to be sure.

Just to add more evidence to the mystery, I've since gone ahead and enabled my boot banner at 38400 bps, and it's coming out with random missing characters. Occasionally it all prints fine, sometimes it prints with a missing character here or there, and I've even had it miss an entire line. I'm now working on theory that there's a data bus problem between the UART and the CPU, though given what I've seen I'm not entirely sure how it's initializing at all if that's the case.

EDIT: here's a few examples from me repeatedly pressing the reset button. The banner should be four lines and perfectly square:

Your above description smacks of a flow-control error on the serial link. However, I suppose an obscure hardware problem could be present in the computer itself. Here are some things I would consider in the latter case:

1. 74HCT logic is relatively slow, usually no faster than 74LS, with only slightly better fanout. The 74HCT245 you are using as a data bus transceiver may be taking too long to become active after Ø1 goes low and thus may be inadvertently violating the UART's timing requirements, especially during writes. Try replacing your 74HCT245 with a 74ACT245, which is about three times faster than the HCT device.
   
   
2. Most GALs generate TTL-compatible output levels. A check of one of your quiescent chip selects with a DVM will tell you this. The 28L92 requires 2.4 volts minimum on control inputs (excepting the X1 clock) to recognize a valid logic 1. There's a slight chance that the GAL output driving the UART's control inputs is right on the ragged edge.
   
   
3. While on the subject of GALs, they can be power hogs when the outputs are switching states. Be sure your Vcc and ground connections to the GALs are robust and properly bypassed.
   
   
4. Verify that when the X1 (3.6864 MHz) clock signal is high it is greater than 4 volts. Aside from providing the time base for setting data reception/transmission bit rates and driving the counter/timer, the X1 clock is what sequences the UART's internal state machine logic. If your oscillator has a TTL output you are not driving X1 hard enough, which will likely cause the UART to misbehave.
   
   
5. The 28L92 is fussy about its power source. As with the GAL, be sure your Vcc and ground connections are robust and properly bypassed.
   
   
6. Although the NXP data sheet says the 28L92's I/M mode input can be floated when operating in x86 mode (which I know will work from testing in POC V1.1), I'm always leary of leaving an input on a CMOS device unconnected. Try tying I/M to Vcc and see if that has any effect.

Not knowing anything about how you have your unit interfaced to your console device, I can't offer any advice except to see if you can implement flow control. Any speed above 9600 bps will most likely require flow control to avoid mangled data. Typically, flow control is implemented in hardware (CTS/RTS handshaking), as software flow control (XOFF/XON handshaking) at higher speeds is generally unreliable.

On the software side, carefully review your setup data table to verify that you are writing the correct parameters into the UART registers in the correct order. Try working with the unedited setup data that I published, which has been proven to work at 115.2 Kbps on POC versions 1.1 and 2.1 (both equipped with the 28L92). It could be you accidentally changed something that is critical to achieving proper operation.

The 28L92 will reliably perform at high speeds with a good circuit design and correct setup. My POC units drive the console at 115.2Kbps and also the data link to my Linux development box at that speed—without error. Knowing that should reassure you that a solution can be found.

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

Hmm that's the best idea I've heard so far. I'm actually going to be ordering some 74ACT245's this week since I don't have any in my collection and I've just been working with what I had. In fact one reason the prototype wiring is messy is because I originally tried building it without the buffer, figuring it wasn't needed since nothing else would be on the bus during PHI2 low anyway...and then I discovered my SRAM only outputs TTL compatible logic levels and the CPU wasn't able to read RAM at all...



I did notice that; the GAL's high values are more like 4.2ish volts than 5V; a bit low but definitely strong enough for the UART.



Well it's a breadboard so I dunno how robust they can be. What I can do is try running the 5V lines directly from the power bus strips at the top instead of the vertical ones, just to eliminate some power loss.



Funny you mention that because I was checking that last night; it turns out the batch of oscillators I bought isn't guaranteed to put out quite enough voltage for the UART, so I rewired the oscillator output through a 74hct125 buffer and the clock is now definitely a healthy 5V. Unfortunately that didn't seem to make a difference.



This one I'm pretty confident about; since the UART is on its own little breaboard it is powered directly from the top strip of the main board. Everything has a bypass cap but it may be worth trying to toss a larger electrolytic up near the power input just to make sure everything is smooth. Thing thing is already drawing about 0.275 amps according to my bench supply, largely due to the two GALs...and the final version will draw even more, because the prototype only has half the RAM, and I'm also toying with adding a second VIA.



No difference, unfortunately.



I'm using some generic USB->TTL serial cables, not sure where I picked them up (Amazon, I think). The far end is my Linux workstations running Minicom, set to 38.4k bps, 8N1, and hardware handshaking. This exact same cable works flawlessly when connected to my COLE-1 SBC, which runs 115.2k with no flow control through a 6850.



I'll try copying back in your original file and table just to be safe; they should only differ in baud rate and the removal of the disable powerdown mode command, but it's also possible the magic I did in vim to convert the file over to ca65 format may have inadvertently removed something.

I too am confident it will eventually work; if it works on my original SBC with a 6850 I'm sure it will work with the 28L92.

AC / ACT series chips have less propagation delay than HC / HCT (also LS) but their outputs exhibit very fast rise and fall times, and it's well known how troublesome those can be, especially in a poorly controlled environment such as a breadboard.

Luckily, AHC / AHCT chips also have low propagation delay, but without the noisy output transitions. I suggest you consider ordering some 74AHCT245's instead.

IMO this family deserves more attention in our community, especially as it's a "have your cake and eat it, too" solution to the speed vs noise conundrum. AC / ACT series does have its place (such as when driving low-impedance transmission lines) but that implies a special need and a well-controlled environment. For our purposes, AHC / AHCT is usually a much better choice.

Some of the less popular devices are only available in surface-mount packages. But I'm happy to report that mainstays like the '245 and others are also readily available in through-hole packages.

-- Jeff

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

Thanks, I just put in a Mouser order for some 74AHCT245's. I also grabbed a couple 74AHCT573's, just in case I want to swap out the 74AC573 that's on there now (at $0.55 each I figured why not). And just to be on the safe side I also added a brand new 28L92 and a higher-quality oscillator to the order.

I'm currently taking a day off from this project while I try to think of additional things to try, because I'm almost to the point where I may have to start tearing down and rebuilding...maybe not the whole thing, but at least the UART section since the rest of the build seems to be functioning perfectly.

I doubt you'll regret the decision. To be clear, I don't necessarily subscribe to the theory that the 74HCT245 originally used may be taking too long to become active after Ø1 goes low. But if you want to rule out that possibility it's better to do it with an AHC / AHCT device than with noisy AC / ACT. The latter does NOT mix well with construction techniques like this.

Um, well.... ... This is a good chance to remind everyone that it's impossible for signal wiring to carry current without the ground and VCC lines also carrying current (in order to establish a complete circuit). In other words, for every signal there will inevitably be a return path. Most of us know enough to avoid a signal path that's longer than necessary, but what's sometimes forgotten is that the ground / VCC wiring, in addition to supplying DC power to IC's, also participates in carrying the AC signal -- ie, it provides the AC return path. And it's best to ensure that the return path is close to the signal path. ("Close to the signal path" generally means "short," because hopefully the signal path is short.)

For example, the yellow wire near the bottom of the image evidently carries a clock signal from the oscillator to the PLCC on the right. But the return path -- the red and black power/Gnd lines -- offers only a circuitous route back to the oscillator. I didn't highlight the entire path back to the oscillator, but we can easily see it's suboptimal. There should be additional power/Gnd wiring that hugs closer to the yellow wire. (Multiple return paths are permitted -- indeed, encouraged.)

In an ideal world we'd have power/Gnd wiring that runs from everywhere to everywhere -- in other words, a ground plane. But, as a compromise, the power/Gnd wiring should include enough redundancy to form a rudimentary grid. This tends to ensure that, for any signal traveling from hypothetical Point A to hypothetical Point B, there'll be a matching return path nearby. This post examines another breadboard project, with respect to the same issue.

-- Jeff

ps- among other benefits, bypass capacitors tend to strengthen the grid because, with regard to AC, a cap is "just a piece of wire." Thus the Gnd and power wiring get linked together in every place where a cap appears. You could think of it as being two grids -- Gnd and power -- and the caps interconnect them, resulting in mutual reinforcement. For example if the power grid has a gap somewhere then that deficiency gets patched over by nearby caps and the Gnd grid.

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

This is also why 4-layer PCBs are so favoured for professional builds. Typically the inner two layers are used as VCC and GND planes, offering comprehensively short return paths on both polarities everywhere, and helping to decouple adjacent signal lines from each other (reducing crosstalk). The close proximity of these layers also turns them into a distributed, low-ESR parasitic capacitor, further enhancing power integrity.

The effects are so good that the cheaper models of computer motherboard still use 4-layer PCBs, operating some signals at multiple GHz and some power supply lines at tens of amps.

All of my POC units have been built with four-layer boards. Poking around in various places with the 'scope shows the benefits of the power and ground planes.

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

I suggested it because the symptoms are so erratic, which usually smacks of some sort of timing contretemps. Of course, with the tangled mess 'o wires that is involved...

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

Some cheap USB to RS232 with level converters and some TTL types without level converters either lack hardware flow control, or their hardware flow control is poor. And amazingly some actual RS232 ports on some modern PCs also perform poorly in regards to precise flow control. So it is worthwhile testing your RS232 system with known good equipment.

Mark

My first SBC that I mentioned is pretty much the only thing I have around the house that actually does serial natively.. Oddly the missing characters seem to get worse as i lower the bit rate; at 1200 bps for example the banner is unrecognizable...and I'm pretty sure my PC and the serial dongle can keep up with 1200 bps without handshaking. This makes me think that something is causing the TxRDY bit to be misread by my driver, and so my code is slamming characters in so fast that the FIFO fills and characters are dropped.

At this point I'm pretty damned sure there's no software issue going on, and no obvious hardware issue like a loose or misrouted wire. I think for now I'm going to wait until the new parts from Mouser arrive so that i can try to rule out timing violations, and failing that I suppose I'll start doing a complete rebuild, maybe with the UART's adapter module on the same breadboard as everything else so that the wiring isn't so all over the place.

To rule out flow control issues and other factors you could tie the UART handshake lines high or low as required and then just let the project "talk" to your oscilloscope (ie, not a dongle or another computer). In your very first post you mentioned "trying to blast out a stream of 'J' " which is exactly the sort of thing I'm talking about. See how the project behaves in the simplest possible context. Reducing the number of variables is fundamental to troubleshooting.

Have fun, and keep us posted!

-- Jeff

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

The above code should work fine. I'm still of a mind that it's either a timing problem in your system or your serial link is not working as it should. Or it could be your X1 clock signal. Although a faulty UART is certainly a possibility, these are high quality products that are used in automotive and aircraft control buses. A defective part is unlikely.

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