Hi Jeff,

thanks, indeed /RES and PHI2 are labeled the wrong way, here an updated version



Peter

I just noticed this thread, but I wanted to leave a note and hopefully follow the discussion.

I have a real need for the topic at hand here, but it does not appear any of the options thus considered will work for me.

I need a drop in replacement for the 6551 that handles faster BPS rates, has FIFOs, and supports the 6551 register set, at least as a subset of the full register set.

I have decided on combining an AVR/PIC with a CPLD. The CPLD will handle the buffers between the uC and the host system, and the AVR will handle the RS232.

I also thought of using the CPLD to massage a 8250-ish register set to match the 6551, but I have not found success there as yet. That would be the holy grail (as I'd prefer to use a stock UART instead of rolling my own in SW).

Jim

Is there really a need for something that looks like the 6551? There are so much better UARTs out there—and without errata.

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

Well, as for a drop-in replacement of the 6551, I can't ever see that happening. The same goes for the register set as well, unless someone opted to make something custom... and I don't see that happening either. Even trying to build up a drop-in PCB with SMT logic would be difficult as the 6551 only uses 2 address lines and most modern UARTs have at least 3 address lines.

I think most people (including myself) use the 6551 as it's like "comfort food". Once you've written the code to run it properly, it just works and is trivial to interface into any 65xx system. But if you need function and performance beyond the 6551, I would agree with BDD that the NXP line of UARTs is a much better choice going forward. Having said that, I still haven't gotten my NXP chips out of the static bags.... must be that comfort food thing.

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

What are you waiting for?

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

Well, as I'm fond of saying, timing is everything. I retired from Big Blue last year. Thought I would have some free time to do some fun projects, then it started... aging parents required some assistance from surgeries, family deaths at 90+. Then a leak in the roof caused a lot of damage inside and out over the holidays. And in January I came out of retirement to join an old colleague and took an exec job with another company starting up in the US, and my timing is, well,

Still, I really want to finish up the little perfboard I started on almost 2 years ago. It has a NXP SCC2691, a 74HC00 and a MAX232 chip along with a crystal and some caps. This will plug into my I/O board in place of a 6522 and give me a second serial port to start coding for. I just need to solder in the sockets, wire it up and start coding. My current C02BIOS has proven to be rock solid at least which supports a 65C51 and 65C22, so the comfort factor still reigns, who knew.

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

Yes, significant need.

I understand the desire to use a better UART, but most people don't want to buy a device that is not compatible with existing SW, and newer SW developers don't want to develop for a device that no one owns.

Jim

Well, as a stepping stone, I have created a 6551 plug in module that adds 230K, 115K, and 57.6K to the device without changing the footprint or the register numbers.

It uses a CPLD to redefine one of the registers (the bps rate reg)It extends the baud rate selection bits by 1 bit, using up the RXC bit and turning it into another 16 bps rate selections. I use 3 of them for the additional bps rates, storing them in the CPLD but sending 'b10000 to the 6551 so it uses the /16 bps rate setting. I then use the internally stored bits to set the divisor of the counter that feeds the XTAL pin on the 6551 to set the correct rate.

I also use bps rate 'b00000 to "lock" the bps rate if you want to set a faster rate and then use an older program. Setting the correct bps rate and then "locking" it will prevent any attempts to write to the register until unlocked or hard reset.

The above requires a 6551A as a minimum to be plugged into it, but can fit it in any 6551 socket.

Still no FIFOs and such, but it's a start.

Jim

Nice! It's a man in the middle approach which, in the course of accomplishing its goal, "lies" to the underpowered legacy silicon. The 'C02 in my KK computer gets told a fib or two, too.

A very original idea! It's somewhat wonky, but that's in keeping with the wonky problem itself. IE: when is a request to change baud rates not a request to change baud rates?

cheers
Jeff

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

So, I have this idea working, and will be exhibiting it soon.

I am not sold on the 'b00000 lock idea, and so wanted to ask for suggestions. My concern with 'b00000 locking is: How do you unlock?

I also considered a "port knocking" approach using the status register:

lda #$55
sta status_reg
lda #$aa
sta status_reg
lda #$01
sta status_reg
lda #$00 ;-> lock after next store
sta status_reg
lda #<acia control>
sta cmd_reg ; <- and now locked.

lda #$55
sta status_reg
lda #$aa
sta status_reg
lda #$01
sta status_reg
lda #$01 ; unlocked.

I'm not familar with the 6551 and its registers, but is there any reason you couldn't use bps rate 'b00000 as a command to toggle locking on and off? IOW, the first 'b00000 engages locking. A subsequent 'b00000 would cancel locking. And so on.

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

I can do that, and had it mostly implemented. Just thought it might be too easy for existing apps to do:

lda #0
sta cmd_reg
lda #<real bps rate>
sta cmd_reg

And thus the lock is undone and the incorrect rate is stored.

I could fix by using 01111 as the value, though.

The only challenge is that it is tougher to know when the IC is locked.

Jim

Instead of enhancing the 6551 externally with a CPLD I suggest that you integrate the logic of the 6551 into the CPLD. Then you can extend it with all type of registers outside the normal ACIA.

Adding all of the needed logic into a CPLD to emulate the 6551 *AND* pushes the design into a CPLD size that is more expensive than a small CPLD and a regular 6551.

Jim

At mouser the small CPLD ATF1504 and a W65C51 cost together about 12 swiss franks and the larger CPLD ATF1508 costs 8 swiss frank. I know that the receiver and the transmitter with buffering fits in a ATF1508 (i have done this and the design requires about 70 flipflops). Whether all the other features still fit in the ATF1508 I need to check. But if you can live without modem control signals (and honestly who does need them nowadays) it should not be a problem and as the ACIA only requires very few pins you can use the rest of the pins to build your address decoder. a address decoder typically requires alot of pins but very little CPLD resources. In other words they complement each other perfectly.