X-Received: by 10.107.160.8 with SMTP id j8mr15407427ioe.4.1445829139467; Sun, 25 Oct 2015 20:12:19 -0700 (PDT) X-Received: by 10.50.61.169 with SMTP id q9mr36406igr.9.1445829139443; Sun, 25 Oct 2015 20:12:19 -0700 (PDT) Path: csiph.com!xmission!news.glorb.com!kq10no24498654igb.0!news-out.google.com!n2ni45651igy.0!nntp.google.com!kq10no24498643igb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.sys.apple2.programmer Date: Sun, 25 Oct 2015 20:12:18 -0700 (PDT) In-Reply-To: <1mcwnnq.133vugw1sp8ft0N%dempson@actrix.gen.nz> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=162.232.170.149; posting-account=tPtYigoAAABt11LZ6pFddOZA25zCDWme NNTP-Posting-Host: 162.232.170.149 References: <6381b06a-dd7a-499c-88a5-fb3d702acd5a@googlegroups.com> <74a1ca8e-2535-46f4-a4a6-1075827f18c9@googlegroups.com> <1mcp1bw.15r8pdjri3bn4N%dempson@actrix.gen.nz> <1mcpkto.1t87qqt1b36pknN%dempson@actrix.gen.nz> <1mcwnnq.133vugw1sp8ft0N%dempson@actrix.gen.nz> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Zilog 85c30 RS-422 on Apple IIGS From: John Brooks Injection-Date: Mon, 26 Oct 2015 03:12:19 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: csiph.com comp.sys.apple2.programmer:1920 On Sunday, October 25, 2015 at 7:25:22 PM UTC-7, David Empson wrote: > John Brooks wrote: >=20 > > On Thursday, October 22, 2015 at 12:08:12 AM UTC-7, David Empson wrote: >=20 > [...] >=20 > > > Phonenet or LocalTalk would impose half duplex (can't transmit and > > > receive simultaneously) but I expect you'd want to do that anyway. > >=20 > > Yeah, I don't think I want Phonenet due to it's bit-synchronous overhea= d, > > complexity and 1/16 PCLK max speed (ie 3.686MHz/16=3D230K baud). > >=20 > > > You need to use the flow control output signal as a transmit enable. > >=20 > > You mean via CTS? Why is that? I thought in byte-synchronous mode I cou= ld > > use WR5 D1 (RTS) for transmit control (if transmit throttling is even > > needed) and have the receiver use hunt mode to enable the receiver. >=20 > 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.) >=20 > > > No external clock will be possible, because the GPI pin is not connec= ted. > >=20 > > 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 H= SKI > > which is connected to the the Z8530 TRxC input. >=20 > Again - context. I was talking about IF you used LocalTalk or Phonenet > adapters, because they don't have anything going to the GPI pin. >=20 > > > The Mac, Workstation Card and IIgs implementations all use a Z8530 SC= C; > > > the Workstation Card has a dedicated 6502 processor to offload the ti= me > > > critical work, but the IIgs was fast enough to keep up (only just - i= t > > > required special implementation in the interrupt handler). > >=20 > > True, but looking at Apple's implementation, it appears that the GS ser= ial > > code was largely the same as on the //c & Workstation card. >=20 > 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. >=20 > It would have required external hardware with a similar architecture to > the Apple II Workstation Card. >=20 > > Probably because it was more engineering effort to maintain a 65816 & 6= 502 > > version. So there is definitely an opportunity for the GS SCC > > communication code/speed to be better than what Apple released. > >=20 > > > If the device at the other end is compatible, using HDLC framing with > > > automatic CRC handling in the SCC will make error detection easier. > >=20 > > 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 cloc= k > > and CRC-16 calculation enabled. >=20 > 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. >=20 > > > 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). > >=20 > > Yes, I think I'll need to make a custom cable to go from DB9 to mini-Di= n8. > > I think my next step is looking at USB to serial bridge chips to see wh= ich > > ones are a good fit for supplying an external clock on HSKi. > >=20 > > Good stuff Dave. Thoughts? > > -JB > > @JBrooksBSI >=20 >=20 > --=20 > David Empson > dempson@actrix.gen.nz > Again - context. I was talking about IF you used LocalTalk or Phonenet > adapters, because they don't have anything going to the GPI pin. 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 drive= r, 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 (SDL= C/HDLC) are designed for clock+data on one line with the receive clock reco= nstructed 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 b= its 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=20 @JBrooksBSI