[sdiy] New to list - and DSP development

[Magnus Danielson]

From: Rainer Buchty <rainer at buchty.net>
Subject: Re: [sdiy] New to list - and DSP development
Date: Sun, 12 Dec 2004 22:38:52 +0100 (CET)
Message-ID: <Pine.LNX.4.56.0412122219560.24483 at laptop.buchty.net>

> >No, you had 14,31818 MHz = 4 * 3,579545 MHz. You also had the CPU running at
> >14,31818 MHz / 3 = 4,7727267 MHz (if you guys where wondering wherever that
> >came from).
> 
> Should have checked the ISA specs first...

Well, I don't have the ISA specs, I where dying for the numbers back then.

> >1,8432 MHz = 96 x 19,2 kHz
> >
> >The ratio between these are now 14,31818 MHz / 1,8432 MHz which is about
> >7,7681. This is why the serial interfaces had their own crystal oscillator at
> >1,8432 MHz.
> 
> Now I wonder how those cards which get their timing from the ISA bus
> "high-speed" clock (i.e. 14.31818) manage to get a 7.7681 divisor. I
> have to cards which don't employ any (visible) 1.8432MHz oszillator but
> instead take the high-speed clock into one of those "I do LPT plus 2
> COM ports and don't ask for any datasheet" chips.

I'll tell ya'!

They *do* use that clock. Let's look at it again.

Traditionally (8250/16450) you need a clock which is 16 times higher than the
Baudrate you want. 115,2 kBd is just 1,8432 MHz / 16. You then program the
8250 down from there by the internal counter. Now, if you know that you is
going to run 115,2 kBd (/1), 57,6 kBd (/2), 38,4 kBd (/3), 28,8 kBd (/4),
19,2 kBd (/6), 9,6 kBd (/12), 4,8 kBd (/24), 2,4 kBd (/48), 1,2 kBd (/96),
600 Bd (/192), 300 Bd (/384), 150 Bd (/768) and 75 Bd (/1536) then you could
cheat quite a bit. Besides, you don't need to use /16 all the times either,
/15 or /17 would probably do well too.

14,31818 M / 115,2 k = 124,28976 => 14,31818 M / 124 = 115,46919 kBd
14,31818 M /  57,6 k = 248,57951 => 14,31818 M / 248 =  57,734597 kBd
14,31818 M /  38,4 k = 372,86927 => 14,31818 M / 372 =  38,489731 kBd

And it goes on like that. In the transmitting side it will be a little "hot".
In the receiving side it will be able to handle higher speeds. In the above I
replaced the straight /8 and /16 by a /124 instead. This is used by the
serial logic instead of the /16 state. The programmable speeds is untouched.
Further refinements is possible, but it probably doesn't really care.

When will this be an issue? It will be when you run longer sequences, since you
may fill buffers on the receing side (opposite the hot transmitted). The
receiving side is however safe, since it re-synchronise each byte transmitted
and only uses the baudrate within that byte (start-byte-stop).

So, there is my educated guess of what is happening.

> >When IBM created the IBM PC they did these choices. I guess they had the
> >intention that graphical cards would easilly be able to be simplified by
> >already operate synchronous with the NTSC colour-burst.
> 
> Ah, maybe they just stole the idea from Clive Sinclair who based his
> early machines' timing entirely on video timing :)

Not only him! ;O)

There are numerous computers of that era that had the same design-choice.

> >> As you say, MIDI timing is based on an even multiple of 1MHz. If you
> >> want to convert any vanilla serial card to MIDI, either apply
> >> 16MHz to the 14.7456MHz input or 2MHz to the 1.8432MHz input. Then use
> >> OS settings for 28k8 to get 31k25.
> >
> >Except for the numbers not being quite correct, yes.
> >
> >You could do that by replacing the 1,8432 MHz crystal with a 2 MHz
> >crystal and the choose 28,8 kBd.
> 
> Uhm, yes. That was what I was writing: "...apply 2MHz to the 1.8432MHz
> input. Then use OS settings for 28k8 to get 31k25".

Well, well, "lost in translation".

> >Standards are good, everyone should have their own, but in reality everyone
> >run multiple standards for themselfs.
> 
> There's nothing wrong with multiple standards. Leaves room for an
> interface market :)

... and customers hurting!

Cheers,
Magnus