IIGS 115,200 Baud Serial Port - How?
Hugh Hood
serial ports (Zilog 8530 SCC chip) max out at 57,600 baud.
When pros like David Empson say so, I believe it.
And yet, along comes David Schmidt, with his ADTPro, and he's transferring
files at 115,200 baud from the IIGS modem port.
David Schmidt is nice enough to post his source for his program, and after
examining it, it appears he does 115,200 baud by changing the SCC clock
factor from 16x to 32x.
OK, pretty neat. Time to look at the Zilog manual again.
So, I get out my block editor and start patching away on ProTERM 3.1. First,
I change its settings from a 16x clock factor to a 32x clock factor, and
then recalculate the values for the Time Constants for the various bauds.
Finally, I patch everything into its correct place.
My results - failure, after failure, after failure. And it wasn't just at
115,200 baud. Whenever the 32x clock factor was selected, I failed even at
_much_ slower speeds.
So, I ask, how in the world does Schmidt do it? What am I missing? It seems
he may be throwing the SCC into transmit only mode, but I just don't know.
Any takers?
Hugh Hood
Michael J. Mahon
> For many years, it's been generally accepted that the (2) IIGS built-in
> serial ports (Zilog 8530 SCC chip) max out at 57,600 baud.
>
> When pros like David Empson say so, I believe it.
>
> And yet, along comes David Schmidt, with his ADTPro, and he's transferring
> files at 115,200 baud from the IIGS modem port.
Even more interesting is the trick suggested by Stephen Thomas (and
reported here by me ;-), to skip the clock divider on the Super Serial
Card to allow the 6551 ACIA to move data at 115,200 bps.
The SCC has *always* been known to be capable of considerably higher
rates, as, for example, when it is used to support AppleTalk.
-michael
******** Note new website URL ********
NadaNet and AppleCrate II for Apple II parallel computing!
Home page: http://home.comcast.net/~mjmahon/
"The wastebasket is our most important design
tool--and it's seriously underused."
schmidtd
> Hugh Hood wrote:
> > For many years, it's been generally accepted that the (2) IIGS built-in
> > serial ports (Zilog 8530 SCC chip) max out at 57,600 baud.
>
> > When pros like David Empson say so, I believe it.
>
> > And yet, along comes David Schmidt, with his ADTPro, and he's transferring
> > files at 115,200 baud from the IIGS modem port.
>
> Even more interesting is the trick suggested by Stephen Thomas (and
> reported here by me ;-), to skip the clock divider on the Super Serial
> Card to allow the 6551 ACIA to move data at 115,200 bps.
>
> The SCC has *always* been known to be capable of considerably higher
> rates, as, for example, when it is used to support AppleTalk.
I learned all I know from two sources... first, this source code:
http://www.apple2.org.za/gswv/a2zine/Utils/Z8530_SCCsamples_info.txt
and second, from the Zilog manual. (Well, also from some early Darwin
code (< OSX) to support the SCC on earlier Mac hardware, but that's
largely redundant with the Zilog book.)
Bill Buckels
news:0496c78b-8491-4c83...@e1g2000pra.googlegroups.com...
>Zoom, zoom. :-)
You seem pretty energetic these days. If ProTERM becomes open source will
you be offering your services to add Zoom,zoom? I am only curious...
Bill
Hugh Hood
First, thanks for the input.
Second, accept my congratulations on getting 115,200 out of the IIGS ports.
I'd say that rate has been pretty much been considered 'unobtainable', aside
from the references to Localtalk running around 230K baud.
Third, please pardon my 'Lt. Colombo' style questions on how the heck you
did it.
OK, I've looked once again at the SCC manual and the source code you
referenced. The Apple II source code pretty much assumes a 57,600 max rate.
Of course, the SCC manual offers much more promise, and your ADTPro source
calls on upping the 16x clock rate multiplier to 32x to get the 115,200
baud.
I'm pained to admit that I can not get communications to work when I jack
the multiplier to 32x. Can you pull back the wizard's curtain and reveal
something else? <g>
For those patching along at home, ProTERM 3.1's PT3.Code0 file contains all
the relevant info.
The first table corresponds to ProTERM's table of values for writing to the
SCC's write register #4 (concerning data bits, parity, stop bits and clock
multiplier), as follows:
Memory Byte Hex Binary Function
$09D0 $2751 $47 01000111 7E1 (16x multiplier)
$09D1 $2752 $45 01000101 7O1 (16x multiplier)
$09D2 $2753 $44 01000100 8N1 (16x multiplier)
$09D3 $2754 $4C 01001100 8N2 (16x multiplier)
$09D4 $2755 $4F 01001111 7E2 (16x multiplier)
$09D5 $2766 $4D 01001101 7O2 (16x multiplier)
I changed these to:
Memory Byte Hex Binary Function
$09D0 $2751 $87 10000111 7E1 (32x multiplier)
$09D1 $2752 $85 10000101 7O1 (32x multiplier)
$09D2 $2753 $84 10000100 8N1 (32x multiplier)
$09D3 $2754 $8C 10001100 8N2 (32x multiplier)
$09D4 $2755 $8F 10001111 7E2 (32x multiplier)
$09D5 $2766 $8D 10001101 7O2 (32x multiplier)
The second table corresponds to ProTERM's table of values for writing to the
SCC's write register #12 (concerning the lower byte of the baud rate
generator time constant), as follows:
Memory Byte Hex Function
$24EB $15 110 Baud (Low Byte Time Constant)
$24EC $7E 300 Baud (Low Byte Time Constant)
$24ED $5E 1200 Baud (Low Byte Time Constant)
$24EE $2E 2400 Baud (Low Byte Time Constant)
$24EF $16 4800 Baud (Low Byte Time Constant)
$24F0 $0A 9600 Baud (Low Byte Time Constant)
$24F1 $0A 19200 Baud (Low Byte Time Constant)
$24F2 $01 38400 Baud (Low Byte Time Constant)
$24F3 $00 57600 Baud (Low Byte Time Constant)
I changed these to:
Memory Byte Hex Function
$24EB $EE 2400 (Low Byte Time Constant)
$24EC $76 4800 (Low Byte Time Constant)
$24ED $4E 7200 (Low Byte Time Constant)
$24EE $3A 9600 (Low Byte Time Constant)
$24EF $1C 19200 (Low Byte Time Constant)
$24F0 $12 28800 (Low Byte Time Constant)
$24F1 $0D 38400 (Low Byte Time Constant)
$24F2 $08 57600 (Low Byte Time Constant)
$24F3 $03 115200 (Low Byte Time Constant)
For those who have yet to glaze over, the Time Constant calculates as:
Clock Frequency [3.6864 MHz]
------------------------------- - 2
2 x (Clock multiplier) x (Baud)
So, can ProTERM be patched to communicate at 115,200 baud through the SCC,
or not?
Surely some young (or old), fresh, sharp minds will solve this and will lead
me from the wilderness before I lose what's left of my sanity.
Hugh Hood
schmidtd
> David,
>
> First, thanks for the input.
absorb from all that others have tried to impart to me.
> Second, accept my congratulations on getting 115,200 out of the IIGS ports.
> I'd say that rate has been pretty much been considered 'unobtainable', aside
> from the references to Localtalk running around 230K baud.
Um, no. The SCC data sheets clearly talk about what the chip is
capable of. LocalTalk is one system that took advantage of it.
ADTPro is another. The rub is keeping all players happy at the same
time. And, so, you mentioned David Empson. He is of course exactly
correct when he talks about the 19200 baud limit (when using the
firmware support in the IIgs for the serial ports). If you want to
"play nice" within the IIgs ecosystem which includes LocalTalk,
interrupts, and all that... there are limits as to what you can expect
to get out of the serial port. But ADTPro takes liberties and makes
assumptions that are not at all compatible with what Apple Computer,
Inc. intended for that ecosystem. ADTPro assumes it's the only game
in town, and gets to go home with all the marbles. The BBS code I
mentioned earlier plays much nicer than ADTPro in that ecosystem, but
still can't go as fast as the chip allows. You can't have everything
in a 2.8MHz system.
> OK, I've looked once again at the SCC manual and the source code you
> referenced. The Apple II source code pretty much assumes a 57,600 max rate.
Yes, true - but again, it's playing much nicer than I am. >:-)
> Of course, the SCC manual offers much more promise, and your ADTPro source
> calls on upping the 16x clock rate multiplier to 32x to get the 115,200
> baud.
>
> I'm pained to admit that I can not get communications to work when I jack
> the multiplier to 32x. Can you pull back the wizard's curtain and reveal
> something else? <g>
It's been a while to remember all the particulars. And you're making
me look at the code. But there's something different that happens
when you shift into 32x mode. I branch over to GOFAST: you no longer
set the BRG (Baud Rate Generator) but instead set clocking
differently. It's a whole different ball game. My datasheet is at
home, and I'm physically elsewhere just now, so I'm going to have to
ask you to look up SCC write registers 4 and 11 (decimal) and related
stuff (see section 3.5, "Clock selection") to remember how you set the
baud rate once you're in 32x mode. It's different than the standard
16x BRG.
For those following at home - here's one source of Zilog's SCC book:
http://www-clips.imag.fr/projet-systeme/Z85230/contents.html
> The second table corresponds to ProTERM's table of values for writing to the
> SCC's write register #12 (concerning the lower byte of the baud rate
> generator time constant), as follows:
Yeah, it's different when going fast... sorry I can't remember enough
right now to be more specific. But at 32x, you *disable* the BRG.
That much I do remember. Looking at the code, I just hit WR4 with #
%10000100, and I hit WR11 with #%00000000. I skip WR11, 12 and 13 in
this scenario (noting that the time constants only get you to 56kbps
with the BRG...).
> So, can ProTERM be patched to communicate at 115,200 baud through the SCC,
> or not?
I bet it can. But it's going to take some slightly different
registers to tweak.
> Surely some young (or old), fresh, sharp minds will solve this and will lead
> me from the wilderness before I lose what's left of my sanity.
I've been there before with the SCC. Don't worry, it'll come back to
you. :-)
David Wilson
> For those who have yet to glaze over, the Time Constant calculates as:
>
> Clock Frequency [3.6864 MHz]
> ------------------------------- - 2
> 2 x (Clock multiplier) x (Baud)
>
> So, can ProTERM be patched to communicate at 115,200 baud through the SCC,
> or not?
>
> Surely some young (or old), fresh, sharp minds will solve this and will lead
> me from the wilderness before I lose what's left of my sanity.
As far as I can see, changing from 16x to 32x clock HALVES the baud
rate if all other settings are the same.
Baud Rate = CLK / (2 x ClkMode x (TC + 2)) /* page 3-3 of SCC
datasheet */
If we try:
CLK = 3686400
ClkMode = 16
TC = 0
we get 3686400 / (2 x 16 x 2) = 3686400 / 64 = 57600 bps
The problem is the two 2's in the denominator. The first is caused by
a flip flop converting the output of the 16-bit down counter into a
square wave. The second appears to be caused by a delay reloading the
BRG counter when it reaches 0.
Eureka!
Using register WR11, the transmit clock my be chosen from one of 4
sources:
WR11 Bits
65 Receive Clock
43 Transmit Clock
-------------------
00 = /RTxC pin
01 = /TRxC pin
10 = BRG output
11 = DPLL output
By using the /RTxC clock source directly (bypassing the BRG) you
remove one (or both?) of 2s in the denominator.
schmidtd
> "schmidtd" <schmi...@my-deja.com> wrote in message
>
> news:0496c78b-8491-4c83...@e1g2000pra.googlegroups.com...
>
> >Zoom, zoom. :-)
>
> You seem pretty energetic these days. If ProTERM becomes
I am not well adapted to holding my breath. That said, single-file
transfer protocols to/from the Apple don't excite me much any
more. :-) I'm much more interested in sending an entire filesystem en
masse and manipulating things via CiderPress or AppleCommander at the
destination.
Jeff Blakeney
On Mon, 29 Dec 2008 22:15:35 -0600, Hugh Hood wrote:
> So, can ProTERM be patched to communicate at 115,200 baud through the SCC,
> or not?
>
> Surely some young (or old), fresh, sharp minds will solve this and will lead
> me from the wilderness before I lose what's left of my sanity.
Does ProTERM not use port drivers? I seem to recall having to select a
port driver when I set up ProTERM last so wouldn't it be easier to write
a IIgs port driver that supports 115,200 bps? If the main ProTERM
program won't let you display a selection for 115,200 bps, which I'm
pretty sure it won't, the driver could be called "IIgs Modem 2xBPS" and
you could tell the users that the speed setting they select in ProTERM
will be half the actuall port speed thereby making the 57,600 bps
selection in ProTERM set the port speed to 115,200 bps. This way, no
patching is required.
Michael J. Mahon
As schmidtd has pointed out, running at 115kbps requires very tight
timing constraints, and it is unlikely that the standard mechanisms will
support them.
Bill Garber
"Michael J. Mahon" <mjm...@aol.com> wrote in message news:1rOdnXiHipenEsfU...@giganews.com...
> Jeff Blakeney wrote:
>> To: Hugh Hood
>> On Mon, 29 Dec 2008 22:15:35 -0600, Hugh Hood wrote:
>>
>>> So, can ProTERM be patched to communicate at 115,200 baud through the SCC,
>>> or not?
>>>
>>> Surely some young (or old), fresh, sharp minds will solve this and will lead
>>> me from the wilderness before I lose what's left of my sanity.
>>
>> Does ProTERM not use port drivers? I seem to recall having to select a
>> port driver when I set up ProTERM last so wouldn't it be easier to write
>> a IIgs port driver that supports 115,200 bps? If the main ProTERM
>> program won't let you display a selection for 115,200 bps, which I'm
>> pretty sure it won't, the driver could be called "IIgs Modem 2xBPS" and
>> you could tell the users that the speed setting they select in ProTERM
>> will be half the actuall port speed thereby making the 57,600 bps
>> selection in ProTERM set the port speed to 115,200 bps. This way, no
>> patching is required.
>
> As schmidtd has pointed out, running at 115kbps requires very tight
> timing constraints, and it is unlikely that the standard mechanisms will
> support them.
>
> -michael
As I recall, it requires the updated version
of the 6551, does it not? ;-)
Bill Garber from GS-Electronics
http://www.garberstreet.com
"If you wish to forget anything on the
spot, make a note that this thing is to
be remembered." (Edgar Allen Poe)
Hugh Hood
You've led a crazed old man from the brink. Thanks.
After taking your advice to heart, it seems the SCC WR11 _does_ appear to be
the key to this 115,200 baud stuff (dare I say 230,400 with a 64x clock
factor) on the IIGS's SCC built-in serial ports.
I'm back to patching ProTERM and will report. I'm very optimistic about
getting this to go. I hope my wife will understand that New Year's Eve will
have to take a back seat. <g>
Thanks a MEG. The ability to hook up a IIGS via ProTERM (or perhaps
Spectrum) to a Unix computer (especially a getty on Mac OS X) via null modem
at 115,200 would be welcome.
Hugh Hood...
David Wilson
> After taking your advice to heart, it seems the SCC WR11 _does_ appear to be
> the key to this 115,200 baud stuff (dare I say 230,400 with a 64x clock
> factor) on the IIGS's SCC built-in serial ports.
If you look at the description of WR4 you will see that 64x clock
means that the clock is 64x the data rate so this would be half the
speed of 32x (not twice).
With a 3.6864 MHz crystal and the BRG disabled you have the following
4 speed options:
x1 3.6864 Mb/s (not usable for NRZ async comms)
x16 230,4 kb/s
x32 115.2 kb/s
x64 57.6 kb/s
Hugh Hood
fdd60a38-56d7-4a06...@b38g2000prf.googlegroups.com, David
Wilson at mcs...@gmail.com wrote on 12/30/08 7:41 PM:
David,
You've made an excellent point. You're right ... I got it wrong. A higher
denominator (clock mode multiplier) will _decrease_ the baud rate.
Extending on the point you made in your prior post, it does seem that _both_
"2's" are removed from the Baud Rate formula when WR11 is set to _not_ use
the SCC Baud Rate Generator, thus rendering the Baud formula as:
3.6864 MHz [Clock Frequency]
Baud = ----------------------------
Clock Mode
Thus, just as you stated:
16x clock: 3.6864 MHz / 16 = 230,400
32x clock: 3.6864 MHz / 32 = 115,200
64x clock: 3.6864 MHz / 64 = 57,600
In the meantime, I've located the code in ProTERM where WR11 is set. ProTERM
enables the BRG (no surprise). So, let me disable it and give it a go.
Thanks for the fine analysis and input.
I suspect Greg Schaefer, when coding ProTERM, really only envisioned dial up
modem transfers (as opposed to high speed null modem stuff), so that speeds
> 57,600 weren't really considered.
Or, as maybe I'll find out, even ProTERM has trouble at that rate, although
I believe at one point Greg modified the program to use the Turbo ASB Super
Serial Card daughterboard at higher speeds. We'll see.
BTW, has anyone modified ProTERM to work with the stock (with a 65C51 for
proper RTS/CTS handshaking) Super Serial Card using the 115,200 mode? I'm
not sure a 1 MHz //e could keep up with a 2-way data transfer, but one with
an 8 MHz Zip Chip sure might.
Hugh Hood...
Jeff Blakeney
On Tue, 30 Dec 2008 23:56:02 -0600, Hugh Hood wrote:
> I suspect Greg Schaefer, when coding ProTERM, really only envisioned dial up
> modem transfers (as opposed to high speed null modem stuff), so that speeds
>> 57,600 weren't really considered.
>
> Or, as maybe I'll find out, even ProTERM has trouble at that rate, although
> I believe at one point Greg modified the program to use the Turbo ASB Super
> Serial Card daughterboard at higher speeds. We'll see.
>
> BTW, has anyone modified ProTERM to work with the stock (with a 65C51 for
> proper RTS/CTS handshaking) Super Serial Card using the 115,200 mode? I'm
> not sure a 1 MHz //e could keep up with a 2-way data transfer, but one with
> an 8 MHz Zip Chip sure might.
I only have ProTERM v3.0 so my port drivers all max out at 38,400 bps
but even so, I find doing null modem transfers between my IIgs and my PC
with the Zmodem protocol are faster at 38,400 bps port speed with
ProTERM v3.0 than they are at 57,600 bps port speed with Spectrum v2.3.
I can increase the transfer speed with Spectrum some by using a text
online display instead of a SHR one but ProTERM still outperforms it
because it doesn't have all the other GS/OS interrupts and
inits/CDEVs/DAs to deal with.
My IIgs currently has a ZipGS with a 28.3220 MHz crsytal so it is
running at 7.08050 MHz.
Someday I'll get around to upgrading my stuff so that my accelerator
runs faster and both those programs are up to the latest versions. :-)
Hugh Hood
IIGS's built in serial ports (Zilog SCC 8530 chip) at 115,200 baud.
After instructing the SCC _not_ to use the Baud Rate Generator (WR11) and
setting the clock factor to 32X (WR4), I attempted to make connection with
an OS X G3 PowerMac with built-in serial ports via a Unix getty.
The IIGS has a 9/32 Zip in it, FWIW.
BTW, this connection works flawlessly with an unpatched ProTERM 3.1 at
57,600 baud. Standard parameters are 8N1 (8 data bits, no parity, and 1 stop
bit).
I was _not_ able to connect after patching ProTERM. Frustrated, I decided to
switch ProTERM into 7O1 mode (7 data bits, odd parity, 1 stop bit) while
keeping the PowerMac at 8N1.
Strangely, the connection sprang to life, with all data transmitted _to_ the
IIGS coming through fine.
Unfortunately, with ProTERM obeying 7O1, any character transmitted _from_
the IIGS which had an even number of '1' bits had the parity bit set (e.g.
the lowercase letter 'l' [01101100] ), so these characters were not
transmitted as they should have been. Conversely, letters such as the
lowercase 'm' [01101101] went through just fine.
I am at a loss as to why I introduced a parity/framing error when none of
the SCC parameters dealing with these issues were patched.
So, I suppose I've got some additional work ahead. I'll do some more
disassembly and see what ProTERM is doing with WR3 and WR5.
For you energetic types (or those simply lonely or bored during the
holidays), the file in ProTERM 3.1 is 'PT3.CODE0', and the relevant portions
start around block 19. Just do a disassembly, and when you see references to
$C038 (modem port) and $ $C039 (printer port), you're there.
Finally, thanks to David Wilson pointing out my math error (my exponential
notation skills were way off that day), I recalculated the time constants
for a _1X_ clock factor (please disregard my previous post showing my
calculated time constants -- way off) , patched those in, re-enabled the
Baud Rate Generator, set the clock factor to 1X, and tried again.
Again, I was not able to connect, although by setting ProTERM to _7E1_, I
made connection, but it had plenty of errors in it. Not pretty.
Oh well. Thanks to the guys who helped me out on this. Monday I go back to
earning a living and will probably be scarce again for another 50 weeks.
Hugh Hood...
David Wilson
> I recalculated the time constants
> for a _1X_ clock factor (please disregard my previous post showing my
> calculated time constants -- way off) , patched those in, re-enabled the
> Baud Rate Generator, set the clock factor to 1X, and tried again.
I hope you really mean _32X_ rather than _1X_ because standard async
comms using NRZ encoding cannot use the _1X_ setting. The reason is
that you need to sample the incoming bit stream near the centre of
each bit. The way an ACIA/UART works is by using a 16x/32x/64x clock
and counting 8/16/32 periods after the leading edge of the start bit,
checking that the start bit is still present (false start bit
detection) and then sampling every 16/32/64 periods for each bit that
follows.
I don't have ProTerm but I do have Gary B. Little's PointToPoint which
I believe I can add a new serial port module to. Should be interesting.
Hugh Hood
Actually, I meant the _1X_ clock factor.
At _32X_, with the Baud Rate Generator enabled, _no_ values for the Time
Constant will produce a 115,200 baud rate, because as you previously
demonstrated (I listened to you then, and I believe you now <g>), the
denominator of the formula becomes too high to be overcome by a Time
Constant integer > 1.
Now, however, with your detailed explanation of why a 1X clock factor is not
functional in our particular application, I understand why I obtained such
unsatisfactory (to say the least) results using 1X. Thanks for going into it
for me.
Gary Little is an amazing guy. I own (and refer to) a couple of his books,
and still remember his time as an editor of A+ Magazine.
I recall reading in the old Open-Apple magazine that Little's training was
as an attorney. Man, I'm glad he turned his life around!
Correct me if I'm wrong, but I think development on Point-to-Point stopped
before Little had a chance to add the Zmodem protocol. That, however, should
not be relevant when you start your patching for 115,200 baud.
Thanks again for the input on serial comm. I appreciate it.
Hugh Hood...
in article
b2f516cf-9183-47ce...@z28g2000prd.googlegroups.com, David
Wilson at mcs...@gmail.com wrote on 1/1/09 5:11 PM:
David Empson
> Hugh Hood wrote:
> > For many years, it's been generally accepted that the (2) IIGS built-in
> > serial ports (Zilog 8530 SCC chip) max out at 57,600 baud.
> >
> > When pros like David Empson say so, I believe it.
> >
> > And yet, along comes David Schmidt, with his ADTPro, and he's transferring
> > files at 115,200 baud from the IIGS modem port.
>
> Even more interesting is the trick suggested by Stephen Thomas (and
> reported here by me ;-), to skip the clock divider on the Super Serial
> Card to allow the 6551 ACIA to move data at 115,200 bps.
>
> The SCC has *always* been known to be capable of considerably higher
> rates, as, for example, when it is used to support AppleTalk.
[Just got back from holiday or I'd have answered sooner]
AppleTalk has the SCC operating in a different mode (SDLC) with a
different clocking system (FM modulation, but I forget offhand whether
it uses FM0 or FM1), and a DPLL to recover the clock from received data.
When using the DPLL in FM mode and the SCC master clock at 1X as the
source (3.6864 MHz), the DPLL outputs a divide-by-16 clock, so AppleTalk
runs at 3.6864e6/16 = 230400 bps.
In async mode with NRZ encoding, the SCC can't be operated with a 1X
clock if you want to receive anything, because it needs oversampling to
detect bit transitions. You therefore must use a 16X, 32X or 64X
clocking mode.
In the IIgs, for async mode, the SCC is normally configured to use baud
rate generator and a 16X clock source. The baud rate generator has a
minimum divisor of 4 due to the 2x multiplier and offset of 2 from the
value programmed into the registers. The maximum baud rate is therefore
3.6864 MHz / 16 / 4 = 57600 bps.
To get higher baud rates, you must bypass the baud rate generator and
use the RTxC pin as the direct source for the transmit and receive clock
(controlled via WR11, with separate settings for receiver and
transmitter).
In combination with the clock mode options in WR4, this gives you
potential baud rates of 3.6864 MHz divided by 16, 32 or 64, which are
230400, 115200 or 57600 bps.
I haven't experimented with these high baud rates, and I wouldn't expect
the IIgs to be able to keep up with 230400 async data even with an
accelerator. 115200 is more likely to be achievable.
(AppleTalk uses high priority interrupts combined with polled operation
to achieve 230400, but it locks out normal operation for tens of
milliseconds at a time and relies on relatively short packets of data
and half duplex operation. This technique is likely to be impractical
for asynchronous communication.)
--
David Empson
dem...@actrix.gen.nz
David Wilson
ANSWERS" Application note.
Q. Can RTxC on both channels be driven from the same crystal.
A. No. A separate crystal should be used for each channel.
The crystal should be connected between
/SYNC and RTxC of the respective channels. The alternate
solution may be to use crystal on one channel
and reflect the clock out of the TRxC output and feed
it into another channel
It seems that Apple worked out how to do it with one crystal by using
the /SYNC output to drive the 2nd RTxC input.
Michael Black
> It is interesting to read the "ZILOG SCCZ8030/Z8530 QUESTIONS AND
> ANSWERS" Application note.
>
> Q. Can RTxC on both channels be driven from the same crystal.
> A. No. A separate crystal should be used for each channel.
> The crystal should be connected between
> /SYNC and RTxC of the respective channels. The alternate
> solution may be to use crystal on one channel
> and reflect the clock out of the TRxC output and feed
> it into another channel
>
But that question is ambiguous. Clearly, the question is whether
one needs 2 crystals. And the answer should never be "yes".
But the point is that one wouldn't put the two pins of each channel
in parallel and then put one crystal in there.
The two pins where the crystal connects are undoubtedly the input and
output of a gate that is linearized internally. Putting the crystal
across the pins causes the gate to oscillate, and at the frequency
of the crystal. One of those pins will be an input, one will be
an output of that gate.
So one can presumably feed the pin that connects to the input of
the gate with an external oscillator signal, certainly this is normal
procedure for that sort of situation. ONce that is the case, then
it's a simple matter for determining which of the two pins is the
output of the gate, and then feeding that to the input pin of the
second channel.
Michael
Hugh Hood
Thanks for weighing in on this SCC business.
Over the years I've come to rely on your accurate and detailed explanations
on what are oftentimes complex subjects. This time you've not disappointed.
Frankly, before I tore into the SCC manual and the ADTPro Source, and
started patching ProTERM a couple of weeks ago, I suspect your post would
have left me dumbfounded.
Mr. Wilson had previously mentioned that I wasted my time trying a 1X clock
in async with the Baud Rate Generator and NRZ encoding, and it seems you
agree. (So do I - it didn't work).
My patches to ProTERM (PT3.Code0, Blocks 19 and 20) have been:
WR11 - Instruct the Transmit Clock and the Receive Clock to source from the
RTxC Pin rather than from the Baud Rate Generator. Bit 7 is set per IIGS
Tech Note 18 ('1' for Printer Port/Channel A/$C039 and '0' for Modem
Port/Channel B/$C038).
WR14 - Disable the Baud Rate Generator (I'm not sure if this is necessary
since the clocks source from RTxC, but it was done regardless).
WR4 - Changed the clock mode from 16X to 32X. [3.6864 MHz / 32 = 115,200]
So far, my results are unsatisfactory.
The Apple IIGS (Zip 9/32) on which I'm testing this is connected to a Beige
PowerMac G3 (strangely also with built-in SCC-type ports) set to communicate
at 115,200 baud with 8N1 parameters.
Inexplicably, I achieve _some_ measure of functionality by instructing
ProTERM to communicate at 7O1 rather than 8N1. It _receives_ characters just
fine, but introduces errors when sending characters with an even number of
'1's, as would be expected when trying to talk to an 8N1 device with 7O1.
I've gone over the disassembled code again, but have not been able to figure
out how I could introduce a framing/parity error with my patches. The WR's
that deal with bits and parity have not been touched.
Oh well. <g>
Thanks again for the expert instruction.
Hugh Hood...
Hugh Hood
Great observation.
I pulled the schematic on the IIGS and it shows one side of the 3.6864 MHz
oscillator connected to Channel A's (Printer Port) RTxC pin, while the other
side is connected to _both_ Channel A's SYNC pin _and_ Channel B's RTxC pin.
I suppose this is why the IIGS tech note #18 states:
"Because of this single circuit, Write Register 11 (WR11) bit 7 must be set
to 1 for SCC channel A and must be set to 0 for SCC channel B."
Bit 7 is the RTxC-XTAL/NO XTAl select bit, BTW.
Hugh Hood
port(s), I must mention that there's a _chance_ that my final patches will
produce positive results.
I now have reason to believe that my host machine for these tests, a Beige
G3 PowerMac running OS X 10.4.11 (Tiger) with built-in (SCC-type) serial
ports, _may_ have been the limiting factor. The unsupported OS X drivers I'm
using for the built-in serial ports appear to restrict the ports to 57,600
baud max for async comm.
This week I'll try the patched ProTERM on a MDD Dual 1.25 GHz PowerMac with
a dedicated PCI slot serial card at 115,200 and report back. I'm cautiously
optimistic.
Hugh Hood...
Hugh Hood
It turns out that the 115,200 baud IIGS built-in SCC port ProTERM 3.1
patches _were_ a success. When I connected another IIGS up to a host machine
that could actually support a 115,200 baud serial port, ProTERM 3.1 (patched
for 115,200 baud) shined.
Thanks go out to David Schmidt, David Wilson and David Empson, whose replies
forced me to look more closely at the Zilog 8530 SCC manual and try one more
time.
To obtain a rough benchmarch comparison, I did a Zmodem null-modem transfer
of an uncompressed 33.5K AppleWorks Spreadsheet file from ProTERM 3.1 on the
Apple IIGS to a Mac OS X machine running in the background the rz/sz Zmodem
Unix programs, controlled of course from the getty-enabled Apple IIGS serial
terminal.
Here are the results of the error-free Zmodem transfer at (2) different
speeds:
File Size Time CPS
------------------------------------
57,600 baud 34,211 bytes 7 seconds 4901 cps
115,200 baud 34,211 bytes 4 seconds 8577 cps
Obviously, the 115,200 baud (and even the 57,600 baud) CPS file transfer
rate is significantly higher than that obtained from a 9,600 or 19,200 baud
connection. In addition, normal terminal work is _very_ snappy at 115,200
baud compared to the lower baud rate connections.
Please keep in mind that these results were obtained with an 7/32 Zipped
IIGS connected via hardware handshaking cable to a PowerMac G4 with a PCI
slot serial card. Both the IIGS built-in serial ports and the PowerMac PCI
slot card serial ports were RS-422, and cabled accordingly.
I do suspect that a IIGS _without_ an accelerator might drop some characters
at this speed during a screen update, but that Zmodem transfers would not
suffer from that, since the screen is not updated during those processes.
I'm really amazed that ProTERM 3.1 can keep up with the screen updates at
115,200 baud, but it does. What a program!
Anyway, I'll prepare a short post describing how to make these patches to
ProTERM 3.1 with a block editor, such as ProSel's Block Warden. The main
patches are to PT3.CODE0. There are a few 'cosmetic' patches in PT3.CODE1 to
reflect the fact that the baud rate is 115,200 and _only_ 115,200. Since
this patched copy of ProTERM is a single baud pony, you would want to keep
it as a _separate_ program on your drive.
If Tony Diaz thinks it appropriate (and legal, and wanted), I'll just upload
the patched versions of these (2) files to his new home for the freeware
ProTERM. But, I'll wait to hear from him first.
Hugh Hood...
in article C586DF38.14DE%hugh...@earthlink.net, Hugh Hood at
hugh...@earthlink.net wrote on 1/4/09 9:48 PM:
Hugh Hood
dem...@actrix.gen.nz wrote on 1/3/09 7:47 PM:
>
> I haven't experimented with these high baud rates, and I wouldn't expect
> the IIgs to be able to keep up with 230400 async data even with an
> accelerator. 115200 is more likely to be achievable.
>
David,
You're right. I went ahead and patched ProTERM for 230400 baud (3.6864 MHz /
16) and was unable to make a satisfactory connection.
So, 115200 baud does appear to be the IIGS max for async comm on its
built-in ports.
Also, concerning the ProTERM patches I previously mentioned, I now think a
more elegant solution may be for me just to write a ProTERM global macro
using the 'MEM' command to poke in the patches after the program has loaded.
If I couple this with some memory peeking and the right macro logic, I think
a user then could toggle back and forth between the patched 115200 baud rate
code and the unpatched 110 - 57600 baud code fairly effortlessly, and not
have to keep (2) copies of ProTERM on his/her drive.
Hugh Hood...