I've been thinking about the UART problem recently, and was pleasantly surprised by this thread. I apologize in advance for the length of this post -- I'm using it to collect my thoughts and summarize what has already been said (as I understand it).

As I see it, there are three practical approaches to serial communications with 6502-class microprocessors:

• Use dedicated hardware like the 65C61, 68B50, 26C90, etc.
• Use an MCU like an AVR or PIC
• Implement a UART in programmable logic

I was looking for a solution that is low cost and available in DIP form, so that rules out the programmable logic solution. Perhaps like many here, I'd prefer to use a 65C51 if they were inexpensive and not buggy, but alas that is not the case. Other UART solutions are possible, but those that can be clocked above 6 MHz and exist in through-hole form are hard to come by and/or expensive (e.g. 26C90). This is what led me to look at a MCU solution.

I just skimmed over this entire thread and see that a number of approaches have been tabled for using an MCU:

• Let the MCU control PHI2
• Let the MCU deassert RDY until it can complete the bus transfer
• Augment the MCU with external logic in order to mitigate some of the performance limitations that come with the above

While each of the above approaches will undoubtedly work, none of them seem to offer much in the way of improvement over existing UART chips in terms of complexity or performance.

Another user mentioned MCUs with parallel ports. I haven't kept up with Atmel's latest offerings lately, but I am relatively current on Microchips parts. They do offer several 16-bit parts with PMP (parallel master ports) on them. Parts such as the PIC24FJ32GA002 come in a 28-pin DIP and cost around $3.00 in single-unit quantities. The PMP can be run in an addressable (2 separate address lines) slave mode with a full bidirectional 8-bit bus. They are designed for asynchronous bus transfers, so there is no need for the MCU to share a clock with the 6502 and there should be no need to pull the RDY line low when they are clocked faster than the 6502. Additionally, this part will run at 5 volts, so there is no need for level converters, either.

Microchip has a specification sheet here for the above PIC: http://ww1.microchip.com/downloads/en/DeviceDoc/39881e.pdf

Using this MCU (or another of the several offerings Microchip has with this peripheral feature set) it should be possible to implement a UART device in an MCU without any of the performance limitations inherent in some of the other approaches mentioned in this thread:

• No need to share clocks or have the 6502 clock controlled by the MCU
• No need to ground RDY while waiting for the MCU to complete a bus transfer
• No need for hardware other than the MCU itself
• Cheaper than any UART offering comparable performance
• Widely available

The PIC MCUs also have a wealth of other built-in peripherals, including I2C, SPI, PWM, etc. which could all be advantageously interfaced with the 6502 using the PMP peripheral. I'd be curious to hear other users' thoughts on the subject. If there is interest, I'll volunteer some of my time to develop PIC firmware to emulate a 65C51, and if that is successful, then I'd consider going further with I2C, SPI, and PWM peripherals as well.

Wouldn't it be easier to use the AVR or PIC programmed as a typical UART and have the 6502 access the AVR/PIC?
The AVR/PIC would process the incoming serial data and when data is available have a pin go low then the 6502 can read the 8 bit AVR/PIC data pins.
For transmit just put 8-bits of data from the 6502 on the data pins and use another pin as /WR to signal the AVR/PIC to send the data.

No it doesn't. Its a 3V3 part with 5V5 input tolerance on SOME digital input pins but sadly not enough to operate as a UART. In the data sheet only 7 pins are marked as 5V compatible.

The 18F/16F parts with PSP will work at 5V. A PIC24 would need a level convertor unless you run the whole system at 3V3.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

3V3 still gives a 8MHz 6502 system. Not too bad. I think the use of a AVR/PIC as IO controller will have some performance penalties. So using a PIC24 and running the whole system at 3V3 might have the least impact on performance. Moreover SPI for CF-Cards must be run at 3V3. So I think a 3V3 sytem might be a good compromise.

You are absolutely right. I have become overly reliant on the Microchip Advanced Parts Selector (see link below) and failed to review the datasheet to note that the 5.5 volt specification was for tolerance, not full operation.

http://www.microchip.com/maps/Microcontroller.aspx

Apologies for misleading everyone.

Thanks for bringing up the 16F/18F parts with PSP that will work at 5V. Unfortunately, they do not include address selection lines, so the bus transaction cannot take place without MCU interaction. This means some handshaking will be necessary (e.g. grounding RDY while the MCU updates the PSP register). This will compromise the performance of the system compared to operation with a conventional UART or a PIC with the PMP peripheral.

So it looks like my 1-chip proposal was wishful thinking after all. At least one bidirectional level translator will be necessary for the data bus. Anyone know of any suitable candidates available in DIP form and with a direction pin logic compatible with the 6502 RW output?

Operation at 3.3V is possible for those who are inclined to do so and would like to eliminate the level translation. I'd prefer to test a solution out in both configurations in order to be sure it will work well in either case.

The 74LVX4245 (below) is like a '245 octal transceiver but with level translation. It's made by several manufacturers but AFAIK is only available in surface-mount. (Luckily, SOIC isn't too bad to deal with... ) As for the logic levels on the direction pin and /OE pin, they side-stepped the 5Volt-vs-3Volt issue by making those inputs accept TTL levels.

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

What do you call "expensive?" It seems to me that making an MCU act like a UART is more "expensive" in programming and debugging time than using a real UART, which does very efficiently in hardware what an MCU will do more slowly and less efficiently in software. There is a reason UARTs exist.

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

Your comment about "expensive" is a funny statement to hear here. I thought this was a forum for a vintage processor where considerations such as the cost of one's time (in pursuit of one's hobby) were not really a factor? I'll grant you your point if your idea of fun is not programming PICs. OTOH, f someone else does the "work" then why not use a pre-programmed PIC instead of a 26C92 for all your UART needs when it costs you less money and is more readily available?

With the PMP interface, the PIC is actually faster than most hardware UARTs available in DIP form. If the 6502 could keep up, you might be able to run up to around 1 Mbaud -- considerably faster than the 26C92 can do (230 kBaud). In terms of efficiency, the 26C92 that you like uses 5-10 mA of operating current. With careful programming (e.g. using the SLEEP instruction appropriately), I should think that a PIC24 implementation would be close to this as well (less when idle, more during heavy I/O). Perhaps more importantly, it would provide a segue for inexpensive I/O interfaces to more modern standards like SPI and I2C. Wouldn't that be a boon for those interested in interfacing their 6502s to some of the many interesting hardware peripherals out there?

Sometimes it's worth spending time to save money, sometimes the opposite. "Expensive" can mean one thing if you're planning to sell kits or products, and another thing if you have a limited budget for your hobby activities. It's all relative: someone might spend $300 on a 'scope and then not want to spend $20 on a chip.

I can't speak for other members, but my time is sometimes more valuable to me than money. I can always earn more money if need be, but I can't "earn" more time. So I evaluate the amount of time that will be required to get a result as carefully as I evaluate the monetary cost. It's a bad habit I've acquired from 30-some years of self-employment.


I'm not familiar enough with the PIC assembly language to decide if working with it would be "fun" (comments I've read from others in the past suggest to me that "tedium" would be a better description). In any case, the monetary cost difference between the PIC and a 26C92 is sufficiently small that I would not consider the PIC as a substitute for the 26C92 (incidentally, I'm now using the 28L92, which has deeper FIFOs and faster overall bus timings).

The handy thing about a real UART is that it works right out of the box and my time spent with it is limited to how long it takes to plug it into the socket. Ditto for the 53CF94 SCSI controller I use on POC's host adapter. Yes, I could bit-bang the bus as André Fachat did with his project (and my admiration for him for doing so is considerable—the SCSI bus protocol is complicated), but again it comes down to time vs. money. 'CF94s are available from bulk liquidators at a reasonable price and can drive the single-ended bus without requiring additional hardware other than biasing resistors.


Ahem...all 26Cxx and 28Lxx Philips UARTs can be operated at a maximum speed of 921.6 Kbps, simultaneously on all channels, and assuming a 3.6464 MHz X1 clock.

As for whether the 6502 could stay with the IRQ onslaught that would result from high speed CBAT on any given UART channel, that would depend to some extent on which member of the 6502 family is being used and how well the ISR has been written. All 26Cxx and 28Lxx UARTs have both RxD and TxD FIFOs, which if correctly used, have to potential to keep the IRQ rate in check during CBAT. Also, the QUARTs and OCTARTs have an IRQ "bidding" feature, which makes it possible to determine which channel is interrupting without having to poll all channels looking for the IRQ source. Although I have not tested 921 Kbps on my POC unit, I have test 230 Kbps in loopback on both channels (using one of my servers to tap into the data stream for monitor purposes) and found that the 65C816 can easily handle that data rate with the Ø2 clock running as slowly as 2 MHz.


In my designs, current consumption is generally not a consideration. I use a PC power supply to run POC, which means there is more than enough juice to run everything and maintain good voltage regulation. Incidentally, the 26C92 can be put into sleep mode when both channels are idle, at which time its quiescent current consumption is reduced to about 15 µA maximum.


A PIC or other MCU isn't needed to implement SPI. The 65C22 can take care of it with some adroit programming. Or, one can use Daryl's SPI adapter that is designed around a CPLD.

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

I think most of the members out here have their own priorities on where to focus their time, efforts and spend. Some like the challenge of using a microcontroller and doing interesting things with them, like making a UART, EEPROM programmer, Video interface, etc. Others look for industry standard parts to fulfill those functions and focus on their specific project. As you get older the reality of how much free time you have sinks in. Granted, I applaud those that do the more custom work with PICs, etc., but I just don't have that abundance of time to indulge to that level.... too many hobbies, including playing music (classical trumpet), building (vacuum tube) audio gear, cycling, cars and track events, cooking and the endless computer parts/projects. One needs to pick a level of involvement and stick to it. I also like to reuse code when possible, so I dragged out my old source for the 6551 from the 80's when I built my small 65C02 system and wrote the BIOS for it.

I'm probably more in the BDD camp, I prefer standard I/O parts so I can focus on the project I'm doing. I also spend more on development tools than most as I don't want to design and build tools which already exist. When I got back into the 65C02 projects, I bought a Dataman programmer which handles a ton of stuff properly including many PALs, GALs, CPLDs, plus a 16-channel logic analyzer (Saleae) which made diagnosing the 65C51 bug much easier. I also bought an early copy of the WDC tools and standardized on that for my code development along with a licensed version of UltraEdit. Having a large collection of other tools between signal generators, scopes and both analog and digital meters (acquired over 4 decades), it's pretty easy to sort through stuff when problems crop up.

Back on the project side, I still need to switch UARTs... but lack of time has been a problem, so my collection of NXP UARTs are still sitting in static bags patiently waiting. I also need to finish an Xmodem loader to include S-Record formats from the WDC linker... but as BDD noted, I just can't buy more time

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

I completely agree with you about the importance of the prioritization of one's time.


I've worked with PIC processors for nearly a decade now and only very rarely do I use assembly language. 99% of my programming is done in C which I find about as much fun to program in as 6502 assembly language, albeit far more practical. Of course, YMMV.


I can see there is a great deal of skill and experience among the members of the forum and you all have my respect. From my point of view, once the PIC UART is programmed, it will become equivalent to a $3 off-the-shelf high-speed UART to me. I may be underestimating the amount of effort required to make it work (I often do), but it really doesn't seem like something that would require more than a few weekends to complete,.


Apologies. I did check a datasheet and it did say 230 kBaud. Of course I have never actually used one so I'll take your word that it will run at 921.6 kBps.


There will always be a soft spot in my heart for the 6502 thanks to the large amount of fun it afforded me a few decades ago. I hope I'm not committing blasphemy by saying I'm not a fan of the 65816, however. By the time the 65816 was ascendant, I had already switched to the 68000.


I mentioned current consumption because you spoke of efficiency. Not sure if the PIC can get down to 15 uA in sleep mode offhand, but it probably wouldn't be much more than that.


Nice work by Daryl and kudos to him for making it available to the community. However, IMHO, a CPLD is not the best tool for this job. It's more expensive than a PIC, not available in DIP format (e.g. not easy to breadboard with), and considerably less versatile when it comes to programmability. I'm sure the 6522 is a fine solution if your speed needs are modest. I have in mind to interface to some microSD cards with an SPI adapter and would prefer the 6502 bus to be the limiting factor on I/O rather than how fast I can bit bang a 6522.

I think he was referring to using the 6522's shift register which can shift out a bit every second clock, so for example the shift clock would be 10MHz if the phase-2 rate were 20MHz. Then shifting a byte in or out takes approximately the time of four instructions, and you would need those to handle the incoming data or fetch the outgoing data and feed it to the SR anyway. The VIA's SR is not ideal for implementing SPI, but it has been done.

If the address decoding allowed a range of addresses for the SR, I can imagine a situation where the '816 could transfer bursts at one byte every 7 clocks, or 2MB/second @ 14MHz, using the MVN or MVP instructions. Unfortunately the VIA's SR can't go that fast. It would need the SPI clock to be faster than phase 2.

I think my next 65K project will use the MAX3100 UART which is SPI-interfaced and comes in a 14-pin DIP or 16-pin SOIC. Very compact. The MAX3110 is the same thing with a few more pins and line drivers and receivers onboard, again very compact and eliminating the need for a separate line driver/receiver IC.

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

In the 26C92 data sheet on page 18, a table is present which describes both "standard" data rates and alternate ones. The table doesn't specifically state 921.6 Kbps, but the last three entries are related to extending the data rate out to the maximum, which is the X1 clock divided by 4. That would be 3686400 ÷ 4 or 921600 bits per second.


Perhaps you should take another look at the '816, as it is quite a bit more powerful than you think. It's hard to like or dislike anything (or anyone) about which you know little.

Incidentally, the '816's interrupt performance is substantially better than that of the 68K when running at the same clock rate. In a system that is often I/O bound, that could make quite a difference in throughput.


Nor is an MCU the best tool for driving a TIA-232 data link. If it were, real UARTs would have disappeared from the scene long ago.


As Garth noted, the 65C22's serial shift register can output bits at a very high rate if the Ø2 rate is up there (officially, 14 MHz maximum).

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

Much of what I dislike about the 65816 stems from the different design choices they made compared to the 68000. Here is a brief list:

• 8-bit data bus (vs. 16-bits for 68000)
• Small register file and lack of general purpose registers
• Segmented memory architecture (ala x86)
• Lack of prioritized interrupts

However, I'm sure you're right that there are some good things about it that I may not be aware of not having used it much. For one, I believe it's more efficient than the 68000 in terms of clock cycles, though back in the day you couldn't get a 65816 that could be clocked nearly as fast as a 68000. And I suppose that as an experienced 6502 programmer, it may feel somewhat natural to transition to from the 6502.


Back in the day it would be a 2.8 MHz 65816 vs. a 7-8 MHz 68000. If you're telling me that the 2.8 MHz 65816 had better interrupt-driven I/O performance than a 7-8 MHz 68000, it'll definitely be worthy of a closer look.


Here are my assumptions: Given that many hobbyists prefer to work with through hole (breadboardable parts), prefer not to have to spend hours hunting down sources for difficult-to-find parts, and prefer not to to pay large premiums for those difficult-to-find parts, there is a demand for some sort of alternative UART implementation. In the best world, one of us would be an ASIC designer and would put design a UART which is pin-compatible with a 65C51 (or 26C92) and find a FAB to make a few thousand of them for us while absorbing the 6-figure NRE charges. Given that this is unlikely to happen, it seems to me the closest we can get to this ideal is an MCU substitute. If I could make one that you couldn't tell apart from a real UART (at least not in software -- I can't make the pinouts the same), then would you say that was a worthwhile cause? Because I think I can do this (or very nearly do it). It's not as "silicon efficient" as a real UART, but that doesn't matter to most of us and in fact is invisible except perhaps in the form of slightly lower power efficiency.


The 6522 looks like a nice chip, but can it simultaneously shift data out and in as it needs to in order to fully implement the SPI protocol? How much CPU overhead is needed to configure each byte of I/O? With a well-implemented MCU version, you'd have input/output FIFOs and it would operate just like a UART while giving you full compatibility not only with regular SPI, but also with double and quad data rate SPI (not that the 6502 could ever keep up with typical speeds used by those rates, but it does help future-proof the design). And then there's the popular I2C standard which is now specified for operation up to 5 MHz.

Back to the UART discussion... Surprisingly, I don't have the PIC24FJ32s in my parts box so I'll order a few today. That'll leave me the weekend to setup a test bed for development. When everything is working, I'll publish instructions and the source code on Github as well. Sooner if anyone wants to collaborate on the project.