6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Fri Apr 26, 2024 9:52 am

All times are UTC




Post new topic Reply to topic  [ 148 posts ]  Go to page Previous  1 ... 6, 7, 8, 9, 10
Author Message
PostPosted: Sun Oct 07, 2018 8:33 pm 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1373
Older 6551 chips should be fine. I have an old Synertek that runs flawlessly at 6MHz. Also some Rockwell 6551 which really don't work beyond their rated speed... at least the ones I have don't. You can also find some newer CMOS 65C51 chips available in speeds up to 4MHz, but not necessary for the C64.

As for running at 38.4K baud, you might be able to push the 6551 with a double-speed clock (3.6864MHz), but would recommend a can oscillator instead of a crystal. I've pushed some newer CMOS versions and they work fine. Also, per the datasheet, you can run the 6551 at 115.2K baud, but if you're planning on using interrupt driven I/O (preferred) that be more difficult with a slower running 6502 (C64 runs a bit less than 1MHz).

You can also easily interface a NXP UART for more flexibility and such with one extra chip (74HC00 to generate qualified read and write signals plus an inverted reset signal). For a remote console, you might want to consider a FTDI UART-USB interface module, which can connect directly to the 6551 without any level conversion. This makes interfacing to any modern PC or Mac trivial and can use just about any decent terminal program via a USB port.

Just as long as you can find a prototype board for the C64 port, you can easily wire-wrap a working board in an evening.

edit: Garth replied while I was typing... but my post just shares my experience with some of the chips and such...

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


Top
 Profile  
Reply with quote  
PostPosted: Mon Oct 08, 2018 5:38 am 
Offline

Joined: Sun Oct 07, 2018 6:04 pm
Posts: 30
Thanks!

I checked the design again of the 6551 cartridge board mentioned and it uses a 3.6864MHz crystal for 38400. It seems that speed has been in use for several previous similar designs, which should indicate that many older 6551 will work at that speed.

I will open another thread later for additional advice on getting that board manufactured, if I decide to go that route. It is probably better to use something other C64/C128 users may have access to (as this seems like a somewhat common hardware for C64/C128). That way any monitor software I produce can be used by others too.


Top
 Profile  
Reply with quote  
PostPosted: Mon Oct 08, 2018 1:18 pm 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1373
Another thread makes good sense of course. As far as making up the PCBs, you might want to rethink exactly what to put on the board. Perhaps add an 8KB EEPROM which can hold your monitor code and be switchable between a couple ROM locations. Also add some additional I/O decoding for the 6551 so you can add some other hardware bits if desired.

Also, there are numerous machine language style monitors that exist for the C64.... depending on what your needs/requirements are, one of the existing ones might fit the bill for that, worth checking into. Have fun with the 6551... there's already lots of code implementations to run these... just pick your I/O address, buffer locations, etc. and you can easily integrate this into the C64 IRQ structure and Kernel routines.

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


Top
 Profile  
Reply with quote  
PostPosted: Thu Oct 11, 2018 7:19 pm 
Offline
User avatar

Joined: Tue Oct 25, 2016 8:56 pm
Posts: 360
The W65C21N datasheet has recently been updated to incorporate this bug as a "feature".

There is no longer any errata section; instead it simply says that Bit 4 of the Status Register is always 1. It does note in a footnote that this is different behaviour from previous 6551 chips. Additionally, the mode bits to enable transmitter empty interrupts and to enable parity are listed as "Do Not Use".

I don't think this is going to go away. Whilst definitely not ideal, I suppose at least the datasheet is no longer misleading as to the capabilities of the chip.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.


Top
 Profile  
Reply with quote  
PostPosted: Thu Oct 11, 2018 7:51 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8143
Location: Midwestern USA
Alarm Siren wrote:
I don't think this is going to go away.

That's likely the case. There would be no economic incentive for WDC to fix the part and produce new ones, given how old the design is.

Quote:
Whilst definitely not ideal, I suppose at least the datasheet is no longer misleading as to the capabilities of the chip.

There are many more UARTs that are much better than the 65C51 and are relatively easy to adapt to a 6502 machine. I see this as a non-issue.

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


Top
 Profile  
Reply with quote  
PostPosted: Thu Oct 11, 2018 8:28 pm 
Offline
User avatar

Joined: Tue Oct 25, 2016 8:56 pm
Posts: 360
Quote:
I see this as a non-issue.

Unless you're looking to use this chip as a replacement for a 6551 in an existing machine.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 12, 2018 5:42 am 
Offline

Joined: Mon May 21, 2018 8:09 pm
Posts: 1462
Actually, it's a pretty important feature for a UART, to be able to indicate when its transmit buffer can accept more data without corrupting previously accepted data. Without it, the only way to transmit successfully is to manually insert a calculated time delay between byte submissions. Even that doesn't account for any flow control imposed by the receiver. Hence I consider the WDC 6551 effectively unusable.


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 12, 2018 6:16 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8428
Location: Southern California
Chromatix wrote:
Actually, it's a pretty important feature for a UART, to be able to indicate when its transmit buffer can accept more data without corrupting previously accepted data. Without it, the only way to transmit successfully is to manually insert a calculated time delay between byte submissions. Even that doesn't account for any flow control imposed by the receiver. Hence I consider the WDC 6551 effectively unusable.

Again— Use a free timer in a VIA, and start it when you store a byte to the transmit data register, either to check for completed time by polling, or use it to generate an interrupt, so the processor can do something else useful while waiting for the byte to go out. No need for a time-wasting delay loop.

You can short CTS\ to DSR\ to check (in the 51's status register) for CTS\ getting negated immediately after storing a byte in the transmit data register to know if it's going to go out or not. If it won't, keep polling periodically until it's no longer negated, then start your VIA timer. Many UARTs don't even have a DSR\ input anymore, so you might not be giving up anything to change its function. If you really do need DSR\ for an actual modem, you can use a spare VIA input bit for CTS\.

None of this is ideal of course; but these are ways to keep the W65C51 usable.

Edit, 2/8/19: I think GaBuZoMeu has the best solution yet: Use the 51's pin 5 (if in DIP), the x16 clock, as an output to drive a VIA's PB6 for its T2 to count pulses and generate an interrupt. The T2 latch value does not need to change with Φ2 rate nor with baud rate. viewtopic.php?f=1&t=5482&p=66433#p66433

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


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 12, 2018 10:40 am 
Offline

Joined: Mon May 21, 2018 8:09 pm
Posts: 1462
GARTHWILSON wrote:
Chromatix wrote:
Actually, it's a pretty important feature for a UART, to be able to indicate when its transmit buffer can accept more data without corrupting previously accepted data. Without it, the only way to transmit successfully is to manually insert a calculated time delay between byte submissions. Even that doesn't account for any flow control imposed by the receiver. Hence I consider the WDC 6551 effectively unusable.

Again— Use a free timer in a VIA, and start it when you store a byte to the transmit data register, either to check for completed time by polling, or use it to generate an interrupt, so the processor can do something else useful while waiting for the byte to go out. No need for a time-wasting delay loop.

I included that (implicitly) in the range of possibilities. But it's still quite a significant increase in software complexity, compared to what a directly attached UART *should* require.


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 12, 2018 12:30 pm 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1373
It is most unfortunate that their (WDC's) latest run of W65C51 chips are defective... and it should be fairly obvious that there are no plans to rectify the situation. WDC has updated their datasheet a few times since this discovery. In the datasheet from 24th October 2014, they noted the problem in the errata section and also had this on page 7 via the "*" to the TDRE bit:

Note:
The W65C51N has an operation issue concerning TDRE. This bit is not being reset after loading the Transmitter Data Register. Polling the TDRE bit of the status register will never show the TDR as Empty. Due to this issue, the W65C51N is not suggested as a direct replacement for older 6551 devices if the firmware uses this bit. It is recommended to using IRQ handling or software timeout for transmission as a workaround for this issue.


They also documented it wrong... as the the bit always shows the transmit register as empty. So.... after 4+ years, they opted to declare the defect as a feature.... so be it. I agree with BDD on this one... just move on to something else. Adding complexity and more hardware to work around it just doesn't make any sense.

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


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 12, 2018 2:29 pm 
Offline
User avatar

Joined: Fri Dec 12, 2008 10:40 pm
Posts: 1000
Location: Canada
WDC have not handled this well. Back in 2013 - 2014 (not 100% sure)* I got some of their 65C51s and had trouble using them. I called them, but they were of no help at all. It was like they didn't know what was wrong.

*(Edit - actually it was in 2012 and the chips have a 2010 date code on them.)

If you need or would just like to use a 65C51 there are no shortage of them available. I have had great success at running them well beyond their rated speed. As fast as 20MHz in the case of the Intersil CDP65C51. Just keep the select propagation delay to an absolute minimum. 7ns in the case of the 20MHz use and 24ns in the case of 16MHz use.

_________________
Bill


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 12, 2018 7:41 pm 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1373
BillO wrote:
WDC have not handled this well. Back in 2013 - 2014 (not 100% sure)* I got some of their 65C51s and had trouble using them. I called them, but they were of no help at all. It was like they didn't know what was wrong.

*(Edit - actually it was in 2012 and the chips have a 2010 date code on them.)

If you need or would just like to use a 65C51 there are no shortage of them available. I have had great success at running them well beyond their rated speed. As fast as 20MHz in the case of the Intersil CDP65C51. Just keep the select propagation delay to an absolute minimum. 7ns in the case of the 20MHz use and 24ns in the case of 16MHz use.


Well, I picked up one Intersil 65C51 about 4 years ago... 4MHz rated speed. I found it to be somewhat buggy, i.e., some corrupted transmit problems and wouldn't run beyond 4MHz in any case. I do have one WDC W65C51 that does work properly... but needs a can oscillator to function... I've had it running at 12MHz without issues so far.... but that's the only one. I received the chip directly from the folks at WDC before the latest versions were released.

I'm somewhat amazed that you them running at such high speeds... impressive.

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Oct 14, 2018 4:36 pm 
Offline
User avatar

Joined: Fri Dec 12, 2008 10:40 pm
Posts: 1000
Location: Canada
floobydust wrote:
I'm somewhat amazed that you them running at such high speeds... impressive.


No more so than I. I can assure it's nothing I did to make this happen. I expected I might be able to push the odd 2MHz device to 4MHz, but I kept pumping up the speed and they kept working. I am using them completely asynchronously too. No hardware or software flow control, no interrupts. Just polling the status registers for empty transmit or full receive buffers.

Not that it probably matters, but these are the CDP65C51A series with the corrected CTS response.

_________________
Bill


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 148 posts ]  Go to page Previous  1 ... 6, 7, 8, 9, 10

All times are UTC


Who is online

Users browsing this forum: No registered users and 31 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron