I'm not too experienced with git, but my MEEPROMMER fork is overhere.
I also threw together a repo for this project here. Just schematics and a bare bones example program. A mouser BOM is coming.

The board lives. New VIA is in place and it can read a NES controller while blinking leds. Also, the board can spew strings over serial. Nothing thrilling, but they are signs of life.

The only problem I've seen is that the baud rate drifts. I've used a 1.8432MHz crystal and, after some experimentation, 22pf load caps. From what I've read, it should only need a cap on the clock in, but it runs further from baud like that. Hopefully a real oscillator fixes things.

Picture is attached. It has some ugly kludges in place: full can osc wedged in, old reset DIP floating in place of ds1813, oversized regulator heat sink, UART crystal on underside and a wrong sized resistor SIP.

So, the boards, excluding the RS232 header, seem to work. 8 of them are up for grabs. If a mod wants to handle doling them out, contact me.

Thanks everyone.

I got a 1.8432MHz can oscillator on the UART, but it still isn't working. It's set up for 19200 baud, 8N1. Here's a sample of what I receive with my ftdi cable:

My cheapie cp2102 adapter gets slightly different garbage.

I chopped up code from here. Relevant bits include:

I threw in the little delay to make the led flashing visible and maybe avoid overflowing the receiver's buffer.
Any thoughts on what might be wrong? Why is it so erratic?

Thanks.

Does the receiving end report a framing error? It it trying to make the ACIA pause by negating the CTS line? Are you still using the CMOS ACIA? (The NMOS one would not finish a byte it started if CTS went false mid-byte.)

BTW, if "RESET:" really is your reset routine, the SEI is not needed, as it's already part of the reset sequence.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Skidlz:

I'm not sure that what I suggest to you below will help you resolve your issue, except to say that I ran into a similar problem using TeraTerm and a Keyspan quad-port Serial USB adapter recently.

After spending considerable time measuring the start bit, data bit, and stop bit widths and finding no errors, I decided to modify the UART transmitter (on my 65C02 board) so that it would transmit two stop bits regardless of the stop bit settings in the line control register. The Keyspan serial port was set for 19200, 8N1 like your settings and I was getting similar garbage after my UART transmitted 16 or so characters to the USB serial port. After making that change to my transmitter, I had no further issues even when I varied the baud rate from 9600 all the way to 921600.

Prior to making this particular change to my UART transmitter, I was able to send from the PC to the 6502 and echo the data received back to the PC at 921600 without errors. (I sent several large ASCII files, captured the echo from my 65C02 board, and compared it to the original using WinMerge.) If my 65C02 was set to transmit a continuous stream of "U"s, I could not detect any error on TeraTerm, nor measure any bit errors/baud rate frequency errors with my scope. Transmitting any else having not trivial lengths, resulted in garbage being received at the PC after about 16 characters.

In my case, I suspected, without taking the device apart, that the Keyspan's baud rate is set using the 12 MHz oscillator frequency of a full speed USB interface device instead of using a true baud rate oscillator or crystal. Again in my case, I suspected that the Keyspan receiver was not correctly resynchronizing to the start bit of the transmitter of my 65C02 UART. In your case, I suspect that your fast interrupt or polling response time allows your 6502 is able to put data into the transmit holding register such that the start bit of the following character starts immediately on the completion of the stop bit of the current character. Without the additional delay induced by a second stop bit, your USB receiver is having a hard time resynchronizing to subsequent characters.

With my transmitter set for two stop bits, and the Keyspan receiver set for 1, it detects the necessary stop bit, but my transmitter is sending a second one. This additional time appears to allow the Keyspan receiver to synchronize itself correctly to the falling edge of the start bit of the following character and then properly align to the middle portion of each data bit and the stop bit.

In your case, since it's not likely that you can set different transmit and receive formats, I would suggest delaying the writing of the following character to your transmitter holding register for at least 1 bit period after you sense that the transmitter holding register is empty. Another suggestion, which is suggested by the available settings in the TeraTerm terminal settings screen, is to insert a delay between every few characters or lines that is equivalent to 1 ms or so.

Finally, I doubt this has anything to do with anything, but if the USB serial port driver is using an interrupt endpoint to signal for service the period of those USB poll cycles may be part of the problem. On USB 2.0 full speed (12 Mbps) connections the interrupt poll cycles occur every 10ms, and at high speed (480 Mbps), the interrupt poll occur every 1ms. At 19200, each character from your 6502 UART arrives at your USB receiver in approximately 500 microseconds. Depending on the FIFO depth of your USB serial port, that may be enough time to fill the FIFO before a USB interrupt poll cycle determines that your serial port requires service.

_________________
Michael A.

I'm using a R65C51P4 @1MHz, with CTS tied to ground.
The terminal program I use is pretty minimal and doesn't support showing frame errors. My logic analyzer, however, does. I slowed the UART to 1200 baud and capture it at 50kHz. Here's an example of what it shows.



MichaelM, my code already has a delay implemented. Roughly a thousand cycles are wasted between characters. @ 1MHz that should be a 1ms delay.

Anything else I can try?

I've attached a picture of the analyzer's output. I tweaked the code so PORTB is high during the delay function and low while waiting on the UART. This is shown on Channel-0.
As you can see, the output sticks low, the UART spins a bit, soon reports it's ready for another character and then garbles the output. It seems to fail in the same way each time.

I'm not sure how to force tx low even if I wanted it. What's going on here? Is something wrong with the handhaking pins? DSR, DCD and CTS are all grounded.

I don't understand what is going on here. You don't have stop bits at the end of each frame. The start bit is low, then there's the data (lsb first), then the stop bit should be high; but you have bytes ending with a low after the msb. The $48 ("H") is followed by an invalid frame, then the next character would be $65 ("e") and the following frame looks like it's trying to be that, but lacking the falling edge of the start bit. If you look at these with an oscilloscope, are they really such clean 1's and 0's, or are they wandering around the no-man's land between valid logic states? Is there any possibility something else is trying to drive the line at the same time?

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

You are right on the money, Garth. We have some kind of AC problem, not logic.
As a shot in the dark I put a 4.7K pull-up on the line. Now it works perfectly. That being said, I have no idea why that works. Nothing is wired to TXD beside a passive header and a non-populated inverter footprint. Nothing should be fighting for that line.
I don't know what to make of it. Can the TXD line not drive any kind of load?
I'll put my scope on it and edit this post with the results.

Edit: Just before the falling edge on TXD it swings ~1vpp at 500kHz. I guess a division of the 1MHz system clock is being picked up. I probably shouldn't have placed the osc and the UART so close together.
I've already littered that part of the board with bypass caps. What are my options now?

The CMOS output should have a stronger, wider-swinging output than the old NMOS ones did.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Skidlz:

I noticed that delay, but I was stuck on having a high-speed core, so loop times not calculated correctly in my head.

I too am a bit confused by the logic analyzer trace you posted.

Have you checked that the pins, particularly VSS and VDD, of the 65C51 ACIA are not bent under and not making good contact? I've had that happen with the type of socket you appear to be using, and it's difficult to spot.

If I remember correctly, you have a low speed logic analyzer, but is it possible to measure the XTALO and RCLK pins of your ACIA with it? It would be good to know if the oscillator signal is good enough for the ACIA.

From the picture of your SBC posted earlier, I would also check that the screw/bolt of your regulator heatsink is not in contact with the case of your large electrolytic capacitor. I would expect that both the regulator tab and the cap's case are ground (because this is a case of positive linear regulation), but I'd ensure that they are not touching as a precaution since I'm not intimately familiar with all of the circuits that you are using.

I don't expect that you have a power problem, but one common problem that I've encountered is that I get some thermally induced power supply noise when I operate linear regulators at a high enough current draw to require a heatsink. It's an easy oversight, so have you checked that your linear regulator is not supplying so much current that its output is not stable due to thermal issues? If you can't lower the input voltage, you may try dumping some power by installing a series power resistor on your input voltage line.

I can't see on your board photo where you've placed the single gate 'HC1G04s you use as drivers for your TxD and RxD signals. Have you checked/inspected/reflowed their power and ground solder joints recently?

On the schematic that you posted earlier, on what node(s) are you connecting your logic analyzer on?

Just curious, but what is that device in the black package near the bottom of your board photo that looks like it has a DB-9 pin out to fit the unpopulated connector spot on your board?

_________________
Michael A.

As far as I can tell, the chip is seated properly. No pins are bent, missing etc. I'm away from my desk at the moment, but I'll double check later.

My analyzer has very little sample memory, so I ran it slower. At faster speeds it shows the osc running at 1.8432MHz.

The regulator and caps are in very close proximity(probably not the best design on my part), but are not touching.

I don't think the heat sink is strictly necessary. I put it on because my broken VIA chip put a huge load on it and made it hot.

The 'HC1G04s are routed on the underside and are not populated.

I'm probing the MicroVGA header and the PORTB header.

I think you are referring to the NES controller connector at the bottom. It was just part of an IO test.

I would post a capture from my scope, but I think it's too old for windows to support it. Measured without load, TXD's logic high is around 4v but noise on the edges brings it as low as 3v.

EDIT: Inexplicably it now works perfectly. Maybe something wasn't seated quite right, no clue.
EDIT II: And now it doesn't work again. I'm so confused.

Here's a development that makes even less sense: Removing the VIA exacerbates the problem. The line is stuck low more frequently and for longer. Once the VIA is reinserted, it improves significantly. The code is in no way reliant on the VIA; It is written to but never read.
I think I'm just gonna buy another 65c51 and see what it does.

As I don't see many bypass caps on your board (and have done a large amount of testing with 65C51 chips lately) I would suggest adding several more (bypass caps) to your board. Specifically, solder a good bypass directly across the voltage pins of the 6551 and 6522. In testing, I've found that the newer CMOS versions are much noisier than older NMOS parts on the same board layout, and by a quite a large margin, enough to cause clock timing issues resulting in numerous output errors (confirmed with a logic analyzer and scope).

_________________
Regards, KM
https://github.com/floobydust

Skidlz:

From the odd ball symptoms that you are experiencing, I suspect that you (still) have a ground/power issue. Simon in NZ relayed similar odd ball symptoms regarding his project, and most of his problems turned out to be related to some poor grounds on a device or two.

From your last and next to last posts, I would recommend pulling all of your socketed parts, inspect all of the sockets (looking for foreign matter and ensuring that the spring leaf contacts are not inadvertently compressed), and then I would reflow all of the solder connections. I would specifically reflow the connections on your spring leaf contact socket under some magnification to ensure that any flux in the PCB hole and around each pin is fully activated and a clean solder joint is the result. Be careful in applying too much solder or flux to a spring leaf contact socket; the solder has a tendency to wick up into the spring leaf contact and ruin it. (One unlikely possibility that you may want to check your PCB for is connectivity between the (front) component side and the (back) circuit side. It is possible that there is insufficient plating in some of your through holes, so you may not have a connection if your signal connects to the top pad, but the socket is only soldered to the bottom pad.)

You may still want to have a second 65C51 on hand. But while the unit is being shipped to you, I think another once over on your board may be a useful exercise.

PS: I see floobydust has posted a comment before me as I was writing mine. In addition, to bypass caps, you may want to add a small bulk capacitor on any large component which you suspect may be suffering from droop induced because of its separation from the large electrolytic on your board's power supply output. Adding a 1uF to 4.7uF (10V or greater) tantalum capacitor to the processor, EEPROM, ACIA, etc. may be something to consider in addition to floobydust's recommendation for additional 0.1 uF to 0.01 uF (10V or greater) decoupling capacitors.

_________________
Michael A.

The AC-performance issues are addressed in our sticky topic, "Techniques for reliable high-speed digital circuits." Many related design areas are widely misunderstood, and are cleared up there with ap. notes and other articles linked there. In the case of this circuit though, I tend to suspect a connection problem.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?