Problem appears to be LOT related, not format. I have PLCCs and PDIPs, all of the same LOT number and all with the same problem, Xmit bit stuck on.

LOT: A6A749.1
1016G015

Above is for PDIP, PLCC has same LOT but the lower number is 1112.

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

Nice analysis - hope you get this resolved by WDC.

Toshi

I'm hoping to receive some different LOT samples from WDC to test. I also found an older (circa 2007) datasheet that shows the (65C51) chip as having the 1M resistor built in for the oscillator, but the new chips don't. Needless to say, WDC has made some changes along the way. I currently have 7 PDIP and 6 PLCC versions, all same LOT number from 3 different sources, and all have the same problem.

To get around the problem for now, I wrote a small delay routine where I can change one loop count with the CPU clock speed and it maintains the delay time for sending out at 19,200 baud. The delay replaces the polling routine against the status register, so no actual performance difference vs polled mode. Due to the nature of the defect, IRQ driven transmit is NOT possible, only receive.

There is one up side... I'm now running my small CPU and I/O board set at 12MHz... and it's surviving very well. I'm a bit surprised with this as I'm using 74HC logic chips (clocking, ROM and I/O decode), a 70ns static RAM and an Atmel 28C256 EEPROM rated at 150ns on one board and a 65C22, 65C51 and MAX238 on a second board with a (very short) 30-pin ribbon connector between them.

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

I have the same lot (A6A749.1) and the same problem, garbage on the serial terminal, which is a bummer, because otherwise I would have a WORKING COMPUTER (well, prototype, still). Argh!

Anything more on this from WDC? Can we send these in as defective?

EDIT: Sent an email to WDC (contact form on their website) asking for assistance. Will post here when I get a reply.

Damn, as you (scotws) have the parts from my order, I should have the same problem. I did not noticed yet, cause I first started with the 6850 on the breadboard. I will give them a try and report here too, as well as sending a message to WDC.

Mario.

_________________
How should I know what I think, until I hear what I've said.

WDC replied very quickly -- within hours -- and very politely. This is the most interesting part for us, I think:

As for exchanges, we do not have an updated chip at this time. We use this chip on our upcoming board product and out software so far has been designed to work within the parameters of the issues with the chip. At this point we do not know if/when we will be making another version of the chip.

As a workaround, they point to floobydust's entry with the loop here in the forum (and praise him for his helpfulness, I should add).

Floobydust, might I trouble you to post the code segment you wrote to get your system working? I'm not quite sure what I am going to do at this point -- still have a 2692A here, or since I was just going to connect TX and RX to a USB-Serial chip like the FS232, I might take another look at some construction with a VIA.

Again, as a follow up, the basic problem is that the Xmit bit is stuck on in the status register. So, depending on how you Xmit routine works, you may need to go thru some other code rewrite:

Polled I/O:
- Which is what I'm using right now. Most polled I/O routines loop on reading the status register, mask off the Xmit bit and loop back to reading/testing until it can handle another byte. This is where you can substitute the delay routine. in the Xmit routine.

IRQ-driven I/O:
- This would be much uglier... as the problem with the chip will endlessly generate IRQs due to the Xmit being stuck on. Putting a delay routine in the IRQ driven code likely won't work and will probably cause other code failures.

So, here's the base Xmit routine from SyMon (which I've change quite a bit lately):

I edited the above to:

And the simple delay routine to be called:

Hope this helps.

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

floobydust, put [code] and [/code] around your code above to make the forum sofware leave your white space and keep the right margins preserve monospacing, so you'll have for example (your first piece of code),

I did still change the number of spaces some to make things line up. It's best to do this stuff in a text editor with monospacing and then copy it over so you can see what you're doing better.

Edit, years later: I forgot to mention that tabs don't translate well when copying to the phpBB post-composing window. If you have an easy way to replace them with spaces first, do so.

_________________
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?

Thanks for the code. I'll have to see about getting it to work, though no interrupts sounds bad ... at the moment, using a 6850 from Mario.

Garth, thanks for pointer on code formatting. I formatted it a bit in the reply window online, which doesn't work so well.... tis better at least.

Scotws,

You can still use IRQ-driven receive, which works perfectly fine with the new chip. SyMon also defaults to IRQ-driven receive and that's working fine. Transmit is the only issue I've found (beyond what WDC shows as errata in the latest datasheet). Still, it's okay as a console chip, noting the CPU tie up on sending data of course.

You could incorporate a transmit routine in a IRQ timer routine with some pointers and a jiffy clock of sorts. That would eliminate the CPU tie up during transmit, but would also require some overhead in your IRQ service routine... no free lunch.

PS - make sure you use the 1Meg resistor in parallel with Crystal or use a Can oscillator.

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

Alternative number three would be to not beat a lame horse and instead use a UART that works right. The 6551 has had problems since inception and it seems that even WDC can't get the pesky critter to behave.

Interfacing a Motorola 6850 to the 65xx bus is fairly trivial, but unless you wait-state it, your maximum possible Ø2 speed will be significantly constrained, no more than a couple of MHz with the 68B50. Interfacing a 2692/26C92 is a little more involved but not too much so, and you gain a significantly higher performance part in the process, as well as dual channels. The 26C92 also gives you access to "battle-tested", IRQ-driven code for both RxD and TxD that takes advantages of the device's FIFOs.

Regardless of whether you choose the 6850 or the 2692, you avoid the hassle of working around 6551 chip errata and gain a more flexible and powerful UART in the process.

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

Well, the plan for the moment is this: Go with the 6850 for this machine, because we're keeping it simple. Then, with the experience gained, see about a more complex second machine with a (yes) 65816 and the 2692. This one is simple and straightforward, the next will focus more on powerful and fast(er). But one step at a time.

Sounds like a good plan. The 6850 works well, especially when the age of the design is considered, and isn't difficult to program. It doesn't have a hardware reset, though, so a little creativity in that department will be necessary if you want such a feature. There is a "master reset," which is a software procedure. However, my (distantly recalled) recollection is that it doesn't fully reset the UART.

Do you have a data sheet for the 6850?

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

Yes, got the data sheet, thank you, and the stuff with the Master Reset is covered in Leventhal, so that's working. The data sheet sort of makes easy things seem hard, but it works. Next thing I'll have to figure out with it are the interrupts, but I'll need to have the VIA attached before then. Getting crowded on that breadboard.

My SBC was built with mostly junk box parts. I use a Rockwell 6551 that had several broken pins. Was going to replace it with a new 65C51 but maybe not now. There's enough of a nub left to conduct