Zilog 85c30 RS-422 on Apple IIGS

[John Brooks]

Has anyone played with programming the GS SCC for high-speed communication with a PC/Mac over RS-422?

-JB
@JBrooksBSI

[David Schmidt]

On 10/19/2015 8:59 PM, John Brooks wrote:
> Has anyone played with programming the GS SCC for high-speed communication with a PC/Mac

Yes.

> ...over RS-422?

Depends on what you mean by RS-422. As RS-422 has more to do with
signalling levels at the electrical level, it's not got anything
different about it than RS-232 in terms of programming the SCC chip.
What do you want to know?

[John Brooks]

I have several rj11 phonenet cables for the GS/Mac, but no ethernet bridge. I was wondering if the modern USB to rj11 converters like the one below could be used to get a direct 230k baud connection between a GS and a mac or pc.

http://www.bestlinknetware.com/Product/150516

And then 2nd, if that works, can the 8530 in the GS be driven with an external clock and achieve faster point-to-point synchronous communication speeds than localtalk achieved?

-JB

[David Schmidt]

On 10/20/2015 12:59 AM, John Brooks wrote:
> I have several rj11 phonenet cables for the GS/Mac, but no ethernet bridge. I was wondering if the modern USB to rj11 converters like the one below could be used to get a direct 230k baud connection between a GS and a mac or pc.
>
> http://www.bestlinknetware.com/Product/150516

The GS and the SCC will signal at 230kbps, and it'll do Appletalk over
the serial port, yes. Whether a modern Mac at the other end will do
Appletalk over serial (USB) is another matter - and I think the likely
answer to that is "no."

If you have a classic Mac, I *think* phonenet adapters is all you'd
need. Some example setups:

http://apple2.org.za/gswv/USA2WUG/FOUNDING.MEMBERS/HOME.PAGES/EDHEL/texts/ethernet.html
http://www.vintagemacworld.com/iigs_rb.html

> And then 2nd, if that works, can the 8530 in the GS be driven with an external clock and achieve faster point-to-point synchronous communication speeds than localtalk achieved?

I don't think so - the external clock gives you 115.2 or 230.

Some code examples:
http://www.apple2.org.za/gswv/a2zine/Utils/Z8530_SCCsamples_info.txt
http://adtpro.cvs.sourceforge.net/viewvc/adtpro/adtpro/client/src/prodos/serial/iigsscc.asm?revision=1.9&view=markup

I found the Zilog "User's Manual" particularly helpful to understand the
detailed inner workings of the SCC:
http://www.cs.tut.fi/~kajatyo/drivers/pdf/scc_escc_um.pdf

[John Brooks]

Right. I would be amazed if Appletalk over USB was possible. :)

I was just interested in high-speed serial communications between my Mac & GS. Since the GS has RS422 drivers/receivers on the motherboard, I believe it is capable of much faster speeds than RS-232.

The 8530 manual mentions the chip is capable of speeds up into the megabits and I was curious if anyone had tried high-speed point-to-point RS-422 communication on the GS, ideally with an inexpensive FTDI USB cable.

-JB

[David Schmidt]

On 10/20/2015 2:11 AM, John Brooks wrote:
> I was just interested in high-speed serial communications between my Mac & GS. Since the GS has RS422 drivers/receivers on the motherboard, I believe it is capable of much faster speeds than RS-232.
>
> The 8530 manual mentions the chip is capable of speeds up into the megabits and I was curious if anyone had tried high-speed point-to-point RS-422 communication on the GS, ideally with an inexpensive FTDI USB cable.

I'm not sure an unaccelerated GS could do much with speeds above
115.2kbps anyway - I'm not sure you can keep the pipe full unless you're
moving over a pre-filled buffer in a tight loop. So while the signaling
speed could go up to 230kbps, I think real throughput would be a fair
bit less than that. I suppose some benchmarks with actual AppleTalk
would tell the tale.

I'm not sure given the hardware environment the SCC is in that it can be
clocked higher than 230k anyway.

[John Brooks]

I'm ok with a tight loop to transfer data between Mac & GS. Even at 230K baud, 23KB/sec is only 100 65816 cycles per byte, so the CPU should be fast enough to go above 230k baud.

> I'm not sure given the hardware environment the SCC is in that it can be
> clocked higher than 230k anyway.

I'm not sure either, but from Apple's GS TN 30 serial port documentation, it looks like the GS was designed to allow high-speed synchronous serial port communication via an external clock:

"The HSKi line is connected to the SCC's Transmit/Receive Clock (/TRxC) input for that port, so that an external device can perform high-speed synchronous data exchange. "

http://www.1000bit.it/support/manuali/apple/technotes/iigs/tn.iigs.030.html

Is there anybody out there with knowledge of RS-422 & the Z8530 who can help figure out what speeds are possible with a synchronous, short-distance, point-to-point connection?

-JB

[David Empson]

I've used Z8530 (actually later variants like the Z85230 ESCC) in
embedded systems programming, but they were all in async applications at
relatively low speeds, and many years ago so I'm rusty. I still have the
databook and user manual handy.

The maximum external clock frequency is determined by the speed rating
of the SCC. The SCC in the IIgs is labelled "Z8530VS" which is missing
the speed digit from the order number (e.g. "Z853004VSC" for 4 MHz).
Since the IIgs uses a 3.6864 MHz crystal, it is unlikely Apple chose to
use a faster rated SCC, so it is probably 4 MHz.

For a 4 MHz Z8530, the minimum cycle time of the external clock is 1
microsecond, i.e. the maximum external clock frequency is 1 MHz.

If you want to operate the SCC in Async mode with an external clock,
then you should be supplying a 16x clock, which would limit the baud
rate to 62.5 kbps.

It is possible to operate in Async mode with a 1x clock, but it requires
the external clock be synchronized with receive data, so you'd need to
either generate it at the data source, or have a buffering stage which
regenerated the 1x clock and used it to sync data exchange with the
IIgs.

If you use sync modes, then the clock and data need to be in sync.
Typically you'd also use a balanced data encoding method such as FM.

LocalTalk used SDLC/HDLC framing (bit-synchronous) with FM data encoding
at 230400 bps.

I vaguely recall some device which plugged into a Mac serial port and
supplied an external clock to implement an unusual baud rate. A MIDI
interface, perhaps? MIDI is slow enough to use a 16x clock under 1 MHz.

RS-422 should cope with baud rates faster than 230400 at reasonable
distances, but the external clock input is not a balanced signal so it
would need to be kept short.

In theory you might be able to get as fast as 1 Mbps in sync modes with
an external clock, short enough cables, and if the IIgs can keep up.

--
David Empson
dem...@actrix.gen.nz

[John Brooks]

On Wednesday, October 21, 2015 at 5:05:03 PM UTC-7, David Empson wrote:

Thanks David, great info!

> RS-422 should cope with baud rates faster than 230400 at reasonable
> distances, but the external clock input is not a balanced signal so it
> would need to be kept short.

By 'balanced' do you mean differential, ie plus & minus signals for transmit & receive?

I don't mind using phonenet connectors which use differential, terminated signals I believe. Though since I'd have a short cable, I'm not sure the noise-resistance is important, so maybe RS-423 (signal relative to ground) is fine?

I found this helpful page comparing the various serial types:

http://www.lammertbies.nl/comm/info/RS-485.html#char

It looks like the GS serial is designed for RS-485 with 12k ohm receivers. Other than Appletalk, I don't remember hearing of any use of the serial ports for RS-422 or RS-485, and most serial port use was as RS-423 mode (ie, non-differential signaling) because it's compatible with RS-232C. Does that sound right to you?

> In theory you might be able to get as fast as 1 Mbps in sync modes with
an external clock, short enough cables, and if the IIgs can keep up.

That's what I was thinking too. Or at least I have yet to find any evidence that the 8530/GS maxes out at 230K.

I can see why localtalk didn't go faster as the GS used 65816 IRQs to interface with the SCC, and GS IRQs have a ton of overhead. Localtalk also has overhead from collision detection, retries, etc which also slows the CPU. Luckily I could skip all that complexity for point-to-point xfer.

So my thinking is that all I need is a USB to RS422/485 FTDI chipset which will use lower voltages and differential signaling which should allow the 8530 to handle whatever max synchronous clock it can.

I'm still a bit fuzzy on whether I can use a RS422 DB9 to mDIN8 null-modem (ie non-differential signaling & believe), or if I need to go with RS422->RJ11 to a phonenet connector with terminators.

Any thoughts/suggestions on what kind of cables are appropriate for testing this?

-JB

[David Empson]

Yes. The Mini-Din-8 layout Apple uses has positive and negative TxD and
RxD lines, but all the flow control signals only have one pin - they are
effectively RS-423 instead of RS-422.

> I don't mind using phonenet connectors which use differential, terminated
> signals I believe.

Phonenet or LocalTalk would impose half duplex (can't transmit and
receive simultaneously) but I expect you'd want to do that anyway. You
need to use the flow control output signal as a transmit enable. No
external clock will be possible, because the GPI pin is not connected.

Phonenet adapters are not internally terminated - they require a
termination resistor in the empty socket at each end of the bus. I don't
know offhand if there are any impedance issues which would prevent them
working reliabily at higher speeds than 230400 bps.

For comparison, LocalTalk adapters have internal terminators, which is
automatically connected if nothing is plugged into the corresponding
Mini-Din-3 plug.

> Though since I'd have a short cable, I'm not sure the noise-resistance is
> important, so maybe RS-423 (signal relative to ground) is fine?

Probably, if short enough.

> I found this helpful page comparing the various serial types:
>
> http://www.lammertbies.nl/comm/info/RS-485.html#char
>
> It looks like the GS serial is designed for RS-485 with 12k ohm receivers.

The IIgs has RS-422 transceivers, but RS-422 is compatible with RS-485
(with some limits).

> Other than Appletalk, I don't remember hearing of any use of the serial
> ports for RS-422 or RS-485, and most serial port use was as RS-423 mode
> (ie, non-differential signaling) because it's compatible with RS-232C.
> Does that sound right to you?

Yes.

> > In theory you might be able to get as fast as 1 Mbps in sync modes with
> > an external clock, short enough cables, and if the IIgs can keep up.
>
> That's what I was thinking too. Or at least I have yet to find any
> evidence that the 8530/GS maxes out at 230K.
>
> I can see why localtalk didn't go faster as the GS used 65816 IRQs to
> interface with the SCC, and GS IRQs have a ton of overhead.

LocalTalk was implemented for the Mac and LaserWriter first. Timing
suggests the Apple II Workstation Card was part of the original plan.
The IIgs was introduced about a year later.

The Mac, Workstation Card and IIgs implementations all use a Z8530 SCC;
the Workstation Card has a dedicated 6502 processor to offload the time
critical work, but the IIgs was fast enough to keep up (only just - it
required special implementation in the interrupt handler).

I haven't looked into the LaserWriter but I expect it shares a lot of
its implementation with the Mac.

> Localtalk also has overhead from collision detection, retries, etc which
> also slows the CPU. Luckily I could skip all that complexity for
> point-to-point xfer.

If the device at the other end is compatible, using HDLC framing with
automatic CRC handling in the SCC will make error detection easier.

I haven't worked with the byte-synchronous modes of the SCC, but have
implemented HDLC on the SCC and other hardware (including bit-banging a
modem).

> So my thinking is that all I need is a USB to RS422/485 FTDI chipset which
> will use lower voltages and differential signaling which should allow the
> 8530 to handle whatever max synchronous clock it can.
>
> I'm still a bit fuzzy on whether I can use a RS422 DB9 to mDIN8 null-modem
> (ie non-differential signaling & believe)

That's what I'd expect. The DE-9 to Mini-Din-8 doesn't carry the
positive half of the Tx/Rx pairs.

> or if I need to go with RS422->RJ11 to a phonenet connector with terminators.

If you are making your own hardware at the other end, another option to
consider is to put a Mini-Din-8 on your device, and use a standard
Mini-Din-8 to Mini-Din-8 cable (e.g. the one used with an ImageWriter
II).

The standard cable has a crossover arrangement for the appropriate pins
(HSkO to HSkI, RxD pair to TxD pair), with straight through for signal
ground, GPI and shield.

There isn't much point involving LocalTalk/PhoneNet hardware if you
don't need multidrop or long cables.

--
David Empson
dem...@actrix.gen.nz

[D Finnigan]

John Brooks wrote:
> Has anyone played with programming the GS SCC for high-speed communication
> with a PC/Mac over RS-422?

Have you seen this yet?
http://macgui.com/downloads/?file_id=11347&keywords=8530

It's Merlin source to acces the serial port directly (for speed).

--
]DF$
The Marina IP stack for Apple II--
http://marina.a2hq.com/

[John Brooks]

On Thursday, October 22, 2015 at 12:08:12 AM UTC-7, David Empson wrote:

Right. It looks like differential signals won't really help as I am going to have short cables anyway and will need to supply a clock via HSKI.H which can't be made differential as HSKI.L is tied to ground at the 26LS32 receiver. Since the clock has to be single-input, the transmit & receive lines might as well be too.

> Phonenet or LocalTalk would impose half duplex (can't transmit and
> receive simultaneously) but I expect you'd want to do that anyway.

Yeah, I don't think I want Phonenet due to it's bit-synchronous overhead, complexity and 1/16 PCLK max speed (ie 3.686MHz/16=230K baud).

> You need to use the flow control output signal as a transmit enable.

You mean via CTS? Why is that? I thought in byte-synchronous mode I could use WR5 D1 (RTS) for transmit control (if transmit throttling is even needed) and have the receiver use hunt mode to enable the receiver.

> No external clock will be possible, because the GPI pin is not connected.

Can you elaborate? Isn't GPI just a General Purpose Input and connected to the Z8530 DCD input? I've been looking at using an external clock via HSKI which is connected to the the Z8530 TRxC input.

> The Mac, Workstation Card and IIgs implementations all use a Z8530 SCC;
> the Workstation Card has a dedicated 6502 processor to offload the time
> critical work, but the IIgs was fast enough to keep up (only just - it
> required special implementation in the interrupt handler).

True, but looking at Apple's implementation, it appears that the GS serial code was largely the same as on the //c & Workstation card. Probably because it was more engineering effort to maintain a 65816 & 6502 version. So there is definitely an opportunity for the GS SCC communication code/speed to be better than what Apple released.

> If the device at the other end is compatible, using HDLC framing with
> automatic CRC handling in the SCC will make error detection easier.

Why HDLC? Isn't that a bit-synchronous mode which will have extra bits inserted? I was looking at using byte-synchronous with an external clock and CRC-16 calculation enabled.

> If you are making your own hardware at the other end, another option to
> consider is to put a Mini-Din-8 on your device, and use a standard
> Mini-Din-8 to Mini-Din-8 cable (e.g. the one used with an ImageWriter
> II).

Yes, I think I'll need to make a custom cable to go from DB9 to mini-Din8. I think my next step is looking at USB to serial bridge chips to see which ones are a good fit for supplying an external clock on HSKi.

Good stuff Dave. Thoughts?
-JB
@JBrooksBSI

[David Empson]

John Brooks <jbr...@blueshiftinc.com> wrote:

> On Thursday, October 22, 2015 at 12:08:12 AM UTC-7, David Empson wrote:

[...]

> > Phonenet or LocalTalk would impose half duplex (can't transmit and
> > receive simultaneously) but I expect you'd want to do that anyway.
>
> Yeah, I don't think I want Phonenet due to it's bit-synchronous overhead,
> complexity and 1/16 PCLK max speed (ie 3.686MHz/16=230K baud).
>
> > You need to use the flow control output signal as a transmit enable.
>
> You mean via CTS? Why is that? I thought in byte-synchronous mode I could
> use WR5 D1 (RTS) for transmit control (if transmit throttling is even
> needed) and have the receiver use hunt mode to enable the receiver.

I was talking about IF you used Phonenet or LocalTalk adapters, because
their hardware is designed as a multi-drop bus with the output flow
control signal being used to enable the transmitter. (Or am I
misremembering? I just recalled something about the transmitter being
disabled which results in TxD+ and TxD- being grounded rather than just
under +/- 5V.)

> > No external clock will be possible, because the GPI pin is not connected.
>
> Can you elaborate? Isn't GPI just a General Purpose Input and connected to
> the Z8530 DCD input? I've been looking at using an external clock via HSKI
> which is connected to the the Z8530 TRxC input.

Again - context. I was talking about IF you used LocalTalk or Phonenet
adapters, because they don't have anything going to the GPI pin.

> > The Mac, Workstation Card and IIgs implementations all use a Z8530 SCC;
> > the Workstation Card has a dedicated 6502 processor to offload the time
> > critical work, but the IIgs was fast enough to keep up (only just - it
> > required special implementation in the interrupt handler).
>
> True, but looking at Apple's implementation, it appears that the GS serial
> code was largely the same as on the //c & Workstation card.

The //c never got AppleTalk: it appears an attempt was made but
abandoned, since there was a partial implementation in the original
firmware but it got deleted in subsequent updates.

It would have required external hardware with a similar architecture to
the Apple II Workstation Card.

> Probably because it was more engineering effort to maintain a 65816 & 6502
> version. So there is definitely an opportunity for the GS SCC
> communication code/speed to be better than what Apple released.
>
> > If the device at the other end is compatible, using HDLC framing with
> > automatic CRC handling in the SCC will make error detection easier.
>
> Why HDLC? Isn't that a bit-synchronous mode which will have extra bits
> inserted? I was looking at using byte-synchronous with an external clock
> and CRC-16 calculation enabled.

Personal preference. I've been using HDLC at work since the late 1980s.
Works well over a wide variety of hardware. Probably overkill if you are
just going short distances.

> > If you are making your own hardware at the other end, another option to
> > consider is to put a Mini-Din-8 on your device, and use a standard
> > Mini-Din-8 to Mini-Din-8 cable (e.g. the one used with an ImageWriter
> > II).
>
> Yes, I think I'll need to make a custom cable to go from DB9 to mini-Din8.
> I think my next step is looking at USB to serial bridge chips to see which
> ones are a good fit for supplying an external clock on HSKi.
>
> Good stuff Dave. Thoughts?
> -JB
> @JBrooksBSI

--
David Empson
dem...@actrix.gen.nz

[John Brooks]

On Sunday, October 25, 2015 at 7:25:22 PM UTC-7, David Empson wrote:

Ah right.

> The //c never got AppleTalk: it appears an attempt was made but
> abandoned, since there was a partial implementation in the original
> firmware but it got deleted in subsequent updates.

Right, but it looks like the code to interface with the Z8530 originated as //c 6502 which then migrated to the //gs serial port driver and then to GS localtalk. While localtalk has a lot more 65816 code than the serial driver, there appears to be a lot of shared 6502 architecture and implementation between the serial port driver and the localtalk driver.

> Personal preference. I've been using HDLC at work since the late 1980s.
> Works well over a wide variety of hardware. Probably overkill if you are
> just going short distances.

From what I can tell from the Z8530 user manual, the synchronous modes (SDLC/HDLC) are designed for clock+data on one line with the receive clock reconstructed via the SCC PLL. The two drawbacks of this config for high-speed SCC serial communication(AFAIK):

1) There is a limit to the number of contiguous set bits (6 I think) so 0 bits will be automatically inserted periodically, reducing bandwidth.

2) Because the bit-sync modes expect the clock to be reconstructed via the SCC PLL, they max at 1/16 PCLK vs 1/4 PCLK for the byte synchronous modes.

-JB
@JBrooksBSI

[John Brooks]

Thanks David.

While that code is a good reference for using the GS SCC, it's pretty much designed for 300-57.6k baud speeds using the SCC baud rate generator & async communications via interrupts.

I'm looking more at 230k baud+ synchronous SCC communications.

BTW, if this code is in active use in current GS programs, there are a few things to note:

1) In emulation mode, the IRQ handler doesn't save the Data Bank (B) register and assumes B=0. B can be changed in emu mode and if it is, then the IRQ handler may not only fail to access the SCC registers at $00/$C03x as expected, it will also save it's internal state to the B bank instead of bank 0, corrupting data in that bank.

2) In many cases the IRQ handler is saving more register data than necessary, using more internal state vars than necessary, and using non-optimal addressing modes. Code size, CPU time, IRQ latency, and stack use could be improved somewhat by optimizing the IRQ handler.

HTH,
-JB
@JBrooksBSI

[D Finnigan]

John Brooks wrote:
>
> While that code is a good reference for using the GS SCC, it's pretty much
> designed for 300-57.6k baud speeds using the SCC baud rate generator &
> async communications via interrupts.
>
> I'm looking more at 230k baud+ synchronous SCC communications.

Sorry that's now what you were looking for. :-(

>
> BTW, if this code is in active use in current GS programs, there are a few
> things to note:

Thanks. I added your commentary to the file description.