Oddly its not listed in any of the SNA server documents I have, and SNA server would drive most SDLC/HDLC/X.35 cards? -----Original Message----- From: Dave McGuire Sent: Saturday, March 17, 2012 7:49 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: Unidentified Emulex card from 1991 "Posh" is a great way to put it! The 8530 is a fantastic chip. That's a pretty serious board. There's also a '286 on there, DMA and interrupt support, a bunch of memory...whatever it did, it needed some horsepower! My guess is a high-speed sync port with onboard protocol handling. -Dave On 03/17/2012 12:11 PM, Dave wrote: -- Dave McGuire, AK4HZ New Kensington, PA

On 03/17/2012 04:16 PM, Glen Slick wrote: Sure looks like it to me! -- Dave McGuire, AK4HZ New Kensington, PA

On Sat, Mar 17, 2012 at 8:37 PM, Dennis Yurichev <dennis_mailing_lists at conus.info> wrote: It looks like there was a DCP-286 and a DCP-286I. Maybe your board was one of the two? Also, while the date screened on your board is 1991 there are date codes on some of the chips from 1996. A net search turns up the following manuals which were available at some point. This FTP site does not appear to allow anonymous logins see if these manuals are still there and if they are of any use for the card you have: ftp://ftp.emulex.com/pub/manuals/dcp/DCP-286-Inst-Guide.pdf ftp://ftp.emulex.com/pub/manuals/dcp/DCP286-SBCPrgTech.pdf ftp://ftp.emulex.com/pub/manuals/dcp/DCP286iInstDiags2prt.pdf ftp://ftp.emulex.com/pub/manuals/dcp/DCP286iSBCInstGuide.pdf

On 03/17/2012 11:17 PM, Mouse wrote: Yup, that's the one, and, that's why it was a bad idea for Sun to use it as a friggin' console port that will only every do 9600 8/N/1 async ever in its whole life. ;) (well, and interface to kbd/mouse, but that's even less demanding!) All the "miscellaneous" control registers deal primarily with SDLC operation, which it does extremely well. AMD's isn't more recent or more "friendly"; it's a second source of the same chip. The '8530 is pretty damn friendly to being with, though. I've done five or six designs with that chip, some of which go VERY fast (megabits) and some of which used its synchronous capabilities. It is extremely powerful. Whining about how to access the control and status registers that mostly only get dealt with at initialization time is worrying over about twenty extra lines of code. "These kids today, I just don't know.." ;) -Dave -- Dave McGuire, AK4HZ New Kensington, PA

On 03/18/2012 12:09 AM, Eric Smith wrote: Could be...still the same chip, at least to the level that I used it. (SDLC) I use the two interchangeably; I tend to put them in SBC designs. Well, like I said, I use 'em interchangeably in my boards. They're compatible enough to that level. The 85230 is a bit different though. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

On 03/18/2012 12:12 AM, Mouse wrote: Sure it can. But does anyone run their consoles at anything other than 9600 8N1? Seriously? And how many people really did lots of serial I/O on ttyb, in such a way that they actually cared about the register layouts of the chip? By the standards of today, or when it was designed thirty years ago? My meaning of "awesome" (though I said "fantastic") is that I've designed systems with this chip and it was really, really easy to deal with and performed extremely well. It's a descendant of the Z80 SIO, for which the same is true. How many systems have you designed with it? -Dave -- Dave McGuire, AK4HZ New Kensington, PA

On 03/18/2012 12:58 AM, Mouse wrote: The big issue with Sun's design is that they used a crystal frequency that was way too low. I don't recall the details, but I do remember that. IF (and that's a big "if") that was why you needed to hack up the driver, surely that's not the Z8530's fault. Ok, so what UARTs are (or were at the time) better? I'll look into them, and if I agree, I will use them, and I will thank you. Well...not trying to be contrary here, but as someone who uses async serial pretty much all day, every day, I can't even remember the last time I needed or used hardware flow control. I can't really speak to the Z8530's support of that one way or the other. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

On 03/18/2012 02:59 AM, Mouse wrote: Ahh, the DC319. I sure would like to find a few tubes of those lying around. I've never heard of the 7750, what is it? You're certainly entitled to your opinion. As I've said, I've used that chip quite a bit, and I like it a lot. Yes, it's work to use, but this line of work isn't for the faint of heart to begin with. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

I needed it for a Commodore 64 that was acting as a console. -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- In memory of DeForest Kelley -----------------------------------------------

On 03/18/2012 07:14 AM, Alexander Schreiber wrote: Hmm. I run my (modern server) consoles at 9600, because that's what everything else uses, and I don't actually use the consoles often enough for it to be a pain. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

On Sat, Mar 17, 2012 at 10:17 PM, Mouse <mouse at rodents-montreal.org> wrote: Yes, and on most/all 68K Macs. It has no FIFO. It came from an era before serial chips routinely had FIFOs, but I've used it at 56K and faster with no problems - your CPU just has to keep up, which I know was a problem in the DOS era with 8250 and 16450 serial chips. That is true. It _is_ possible to stick it on a 68000 bus, but some glue logic, including, possibly wait-states or careful driver crafting may be required. It is full of registers. You don't just fiddle one thing one time, then slam data in and out. It's a very complex dual-port USART that will do Async, Bisync, SNA, and more. We used them on the later models of COMBOARDs, though to a fraction of their capability. Older models had a COM5025 sync serial chip (because we modeled that section after some DEC sync serial cards), so when we switched to the Z8530, we only ever used the secondary port for async debugging. One thing that complicated _our_ design was that we started using the Z8530 very early in its evolution, so we were hanging either a 4MHz or 6MHz part off of an 8MHz 68000. We had to inject wait states (via registered PALs and /DTACK, IIRC) _and_ we had to ensure we didn't jam up the inner workings of the Z8530 by hitting the registers too fast. We had NOPs in the driver between selecting and using the registers. Perhaps 8MHz parts would be easier to use now. Once we worked out what was needed, it was a solid, reliable chip, but I will admit that our embedded application guys did have a few fits trying to port front-end code from the older models that expected a minimal-option simple chip like the COM5025. -ethan

On Mon, Mar 19, 2012 at 11:37 AM, David Riley <fraveydank at gmail.com> wrote: I think the 85230 does. I don't remember there being any sort of SILO in the 8530, but there may have been a latching register so you could drop in "the next byte" while the old byte was still going out. I'm not positive it has that, but I'm reasonably certain that it has nothing more sophisticated than that. That looks like a fun one. There are places I would have liked to see that in the late 80s/early 90s. Right. Our board had no DMA engine. We ran up to 128Kbps sync serial with an 8MHz 68000 doing all the packet assembly/breakdown and USART stuffing. Probably NOPs... I think double access would gum up the innards of the chip and require it be reset. I know of that mode, but I'm not sure we were using it. We started making 68000 peripherals in 1981 - the first prototype was made before we got a chip in hand. The original socket was 0.6" wide because nobody noticed the 1" dimension on the preliminary spec sheets. Once the first processor showed up (XC68000 w/ S/N 424 hand engraved on the lid), I heard they had to make a mechanical adapter to fit the CPU onto it. By 1985, the team had learned more about the 68000, but since there were a variety of /DTACK-delaying peripherals on the original board (like the Unibus DMA engine to move buffers in and out of host memory), one more chip with a custom /DTACK term wasn't the end of the world, plus they could tune it to match the 4MHz speed of the early 8530s and not run it off of the E clock at 1/2 or 1/4 speed. I don't know if they even tried using the E clock, so I don't know if it was tried and failed, but with such a complex design they probably just wanted to stick with the technique that was already in use. I know a bit of the whole "DTACK Grounded" saga, and our design was far too complicated to even think about that as a solution. -ethan