For those still wanting to use the W65c51, warts and all, the idea of externally counting time and feeding back a signal to the /DSR input is a good one. There's an easier way to do it, however, which will work in most practical configurations with less "gubbins". I think I have it down to two dedicated ICs, plus an inverter that might be left over from somewhere else in the design.

My solution would be to use a 74HC40103 (an 8-bit presettable down-counter) to count pulses of the RxC clock, which the W65c51 presents as an output if neither Rx nor Tx are configured to use an external clock. With both configured for the internal clock, both also run at the same baud rate, and the RxC output pulses at 16x rate. The external clock input feature is primarily used to explicitly synchronise one ACIA to another, or to run at a non-standard baud rate such as for MIDI, so for most applications RxC will accurately reflect the Tx clock.

In 8N1 format (10 bit times per frame), and 16 clock pulses per bit, each byte transmitted takes 160 pulses. This can be hardwired into the '40103 preset, or you could play it safe by presetting it to 192 instead (12 bit times); either option straps two pins high ($A0 and $C0 respectively) and the rest low. An active-low pulse on the /PL pin will load this value into the counter independently of the RxC clock. Tie /MR and /PE high to prevent spurious presets.

When the counter expires, it will pull the /TC output low. Feed this through an inverter and back to the /TE input, so it will stop counting at zero and keep /TC asserted, then resume counting when the preset is loaded. No additional flipflop is required to hold this status. Either the active-low direct or active-high inverted /TC drives /DSR on the W65c51. The /DSR status bit then replaces the TxBUSY status bit as previously described.

As well as saving several ICs, the major advantage of this approach is that you don't need to change anything to support different baud rates or frame formats, largely because the RxC clock is automatically varied by the ACIA for you. The 192 preset (12 bit times) is enough to cover an 8-bit byte, a parity bit, and two stop bits - a maximum combination which I'm not sure the W65c51 even supports in the first place. Smaller frame sizes will also work with this preset, but there will be slight gaps between characters and the transmission rate will be correspondingly reduced.

I managed to distill this into a diagram:

Nice and compact, I think you ought to AND in PHI2 though on the PL signal, otherwise it could get triggered erroneously while the buses transition.

If that proves necessary, it could be done by substituting a /WE signal (which most systems will have anyway) for the R/W input to the trigger circuit. Same gates otherwise.

Good point!

Here's another spin -- one of many possible -- on the supporting logic.

-- Jeff

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

Just a thought that occurred while reading about this hardware bug. I haven't seen it suggested by anyone else so apologies if it's there somewhere but I've missed it.

Since the Rx side of the W65C51 works as expected and can be used with interrupts, why not flog a dead horse back to life with another dead horse? What I mean is this: use a second W65C51's RxD input to monitor the TxD output of the main chip. Then use the second chip's 'Rx register full' interrupt to indicate that the character has been sent - a pretty fair replacement for the broken 'Tx register empty' interrupt.

I'm designing a breadboard circuit to test this and I think in practice it will be simpler to dedicate one chip to providing the Tx function, using its Rx half as the monitor, and dedicating the other chip to providing just the Rx function.

Disadvantages: Needs an extra ACIA chip and occupies PCB space. Not suitable for replacing existing 6551s. Needs its own I/O address space.

Advantages: Uses only one extra chip, though quite a big one. Existing interrupt driven code should be easy to adapt. Not dependent on timers or polling loops and is independent of PHI2 and baud rate.

That's an interesting idea and I might just try it as I have a bunch in a tube otherwise unused...

My plan would be to solder one directly on-top of another and just bring out the relevant tx/rx and select pins. you could put pads on the underlying PCB for these 3 pins if needed. I did that with 2 x 32KB RAM chips on my original Ruby 6502 board, so no reason why it might not work here...

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Thanks Gordon. I should think a lot of members have a few of them lying around. This is the circuit I came up with and initial testing on a breadboard based on checking the status registers looks promising. I need to work on an IRQ handler next.

- John

I guess you can also use some of the other pins on the extra one as general purpose output pins. Be careful with all the output pins if you solder them together.

You could also connect TX and RX together on the same chip instead of connecting them between chips.

However if you do have a VIA then it is extremely easy to connect up PB6 and get the interrupts you need from that, so I do recommend that route.

That's what I decided to do for my testing and it's shown that way in the diagram. It's much less confusing to think of one chip being dedicated to Tx and the other one to Rx.

- John

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

I know your views on the subject, BDD, and respect them. I even posted my diagram in monochrome in your honour, having spent a long time reading before posting. To answer your question, I want to do it this way because I think it might work; because I haven't seen anyone else suggest it; because I have, along with many readers of this thread, a small collection of the chips that would otherwise sit there doing nothing; because, if it works, anyone using this method will need to buy twice as many W65C51s which will rapidly deplete the stocks and signal to WDC that the chip is an amazing success after all and cause them to worry about running out and consider that making a new batch with all bugs fixed would be a great and profitable idea; but mostly because I've decided it's what I want to do, for the sheer enjoyment of it. Isn't that what it's all about, anyway?

That plus some of us have a tube of them and would rather use them than consign them to landfill...

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Exactly what I did (though on a different system) to cope with ISO9141 comms which on some systems share a single line for TX/RX and on some have them separate.

It's fairly simple to implement an output routine which always expects an immediate echo, though of course with a single part you can't have full duplex operation... but incoming data can always be handled *unless* you've just sent a byte.

Neil

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