Re: Plus/4 RS232 woes

Den Wed, 5 Sep 2018 23:11:28 +0100 skrev smf <smf@null.net>:
> 
> On 05/09/2018 19:40, Jim Brain wrote:
> >
> > a crystal input is a clock input.  It may be imprecise, but most 
> > datasheets use the same term for both input types.
> >
> No, a clock input (at least a single phase like is used on the 6551)
> is a single pin. A crystal has two pins.

You mix up "crystal input" with "crystal connection". A "crystal
connection" (or whatever you want to call the set of pins used to
connect an IC to a crystal) consists of one "crystal input" and one
"crystal output". In fact if you use an external clock connected to the
input, you can generally use the "crystal output" as an output with an
inverted clock signal, although you can't really trust it to follow any
electric standard for digital signals (like TTL, CMOS e.t.c.).

> You can use a clock input directly, a crystal needs a circuit to 
> generate a clock from. This clock circuit is integrated in the 6551.

Well, the crystal needs one input and one output. That doesen't change
that there is one and only input no matter if you use a crystal or an
external clock signal.

> It's not clear from the datasheet whether the circuit is bypassed
> when you select the /16 external clock mode, or whether an external
> clock will go through the internal clock circuit.
>
> I'd like to see a decap of the chip to know what clock circuit it
> uses and what it does when you select / 16 external clock mode.

By looking at how Plus/4 and A2232 works, we can be 100% clear that
the /16 division is made no matter if you use a crystal or an external
clock signal. Plus/4 uses a crystal and A2232 uses a clock signal, both
have the same frequency, and both achieve the same baud rates.

> > The 6551 came out years earlier.  And, Commodore and Apple knew
> > about the speed.  Again, the drivers were no doubt the limiting
> > factor.
> 
> Except it seems to work reasonably reliably & commodore repeatedly
> ran chips outside spec where they barely work. The A2232 board came
> out in 1990, way late enough that 115200 would have been useful.
> 
> The people who wrote that driver obviously didn't know that it could
> do it, or they would have used it.

There is a more reasonable explanations:

Their goal probably were to build a card withr "a large number of ports
with reasonable speed on a Zorro board". The definition of "reasonable"
at the time were probably what you'd use to connect dumb terminals and
modems for a multi-user setup with A3000UX, and modems with a multi
node BBS under AmigaOS. At the time a dumb terminal usually ran at
9600bps although some could run faster (19200 or best case 38400).

9600 were (and is) considered fast enough for a text-mode 80x25 screen.
You can't read text faster, and most "dumb" terminals is fast enough to
help with scrolling both up and down, so you can scroll through stuff
really fast as you only need to send one line of text and some control
chars to scroll the complete screen.

Modems at the time were at best 9600bps (V32) and 19200 were good
enough to communicate with those modems even with MNP5 and/or V42"
compression.

They of course did choose what IC's Commodore made in-house as they
seemed fit for purpose, an 8-bit CPU and UART's that were specified to
run at up to 19200 baud.

The number of ports is the result of how many 8-pin mini-DIN
connectors you can fit on the edge of the card, combined with how much
stuff you can fit on the card. More ports would at least have needed
another bracket with connectors and some way to connect them to the
card.

So that kind of specified the hardware. A card with 7 6551 and a 6502
CPU. At some point a decision were made to have 16k ram on the card,
probably because they couldn't reliably fit the 6502 part of the driver
in 8k (which probably where the smallest reasonable amount of memory
at the time). Or maybe they first decided to use 16 bit access from the
Amiga side, and thus had to have two SRAM chips, but later considered
that unnecessary but the driver had swollen enough to need 16k.

With a fixed set of hardware, and a rather fixed goal, the wrote a
driver as good as they could. The driver weren't that good (at least
the AmigaOS driver, I don't know anything about the UNIX driver).

At the same time, the various network cards A560, A2060, A2065) became
available, so for any faster transfer between computers you would use a
network card. This was also only three years after 16550 started to be
used in PC compatible computers, although 8250 were the most common at
the time.

This is the important part of the time scale:
LATER modems became available that were fast enough for faster speeds
between the computer and the modem to make sense.

At that time, users figured out that they could replace the oscillator
module to achieve 38400 and run that on at least some ports.

Later on someone realized that the driver could be rewitten in a more
efficient way. That rewritten driver actually at least in theory adds
slightly more delay as it polls the card at every VBLANK interrupt
rather than fireing an interrupt immediately. But the rewritten driver
reduced CPU usage and made it possible to use 115200 on two ports at
the same time.

Using two ports at 115200 is far away from the design goal of using
seven ports at 19200bps.

Of course they could have guessed that that would come, but they
probably also did guess that at the time there would be an A3232 or
A4232 or some other follow-up card, or you'd use terminal servers over
network for a bunch of fast modems, or you'd hook up some kind of ISDN
connections and the telco providing modem pools for analogue modems, or
an asteroid hitting the earth and ending all life.

> > You're misreading the DS.  There is no requirement that the /16
> > mode only works with an oscillator.  It will work fine with a
> > crystal.
> 
> I think you're misreading it.
> 
> In the control register it calls it "16x External clock"
> 
> It differentiates between crystal and clock when discussing the XTAL1
> & XTAL2 inputs.
> 
> "XTAL1, XTAL2 (Crystal Pins) These pins are normally directly
> connected to the external crystal (1.8432 M Hz) used to derive the
> various baud rates. Alternatively, an externally generated clock may
> be used to drive the XTAL1 pin, in which case the XTAL2 pin must
> float. XTAL1 is the input pin for the transmit clock."
> 
> The person who wrote the datasheet chose to make the distinction
> between clock and crystal and refer to the 15 baud rates with regards
> to the crystal and the /16 when referring to the clock. There is not
> one place I can find that lets me think it's safe to come to a
> conclusion that it was designed to do this.

At the time those two were the reasonable use cases.

> > Still, I can confirm that /16 and all of the regular bps rates work 
> > with both oscillators and crystals, so the ACIA does not care.
> >
> I understand that it works. Just because it works, doesn't mean it
> was designed.

Anyone with some knowledge of electronics hardware can attest that
there is no reason for some special hardware selecting different mode
of operation for the XTAL 1/2 pins.


-- 
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.