Groups | Search | Server Info | Login | Register

Re: I could use a hand locating hardware bits and pieces and/or technical documentation for repair.

Newsgroups	comp.sys.3b1
Date	2015-12-22 21:05 -0800
References	(1 earlier) <slrnn79ivu.nhp.BPdnicholsBP@Katana.d-and-d.com> <c86d2f5f-f461-4d3f-b0ad-1e395abb58d1@googlegroups.com> <slrnn7hidn.lon.BPdnicholsBP@Katana.d-and-d.com> <f088a5d3-0a8f-4dcb-a364-8205bd61206a@googlegroups.com> <slrnn7k5v6.4ih.BPdnicholsBP@Katana.d-and-d.com>
Message-ID	<007333c8-f7b6-49d0-94db-ea2008dc775e@googlegroups.com> (permalink)
Subject	Re: I could use a hand locating hardware bits and pieces and/or technical documentation for repair.
From	Chris Smith <protheus@byteorder.net>

Show all headers | View raw

On Tuesday, December 22, 2015 at 9:42:06 PM UTC-6, DoN. Nichols wrote:

> 	Anyway -- the MC6850 means that the longest data string would be
> one start bit, eight data bits, and two stop bits.

Which is interestingly close to what the PC/AT or PS/2 keyboard does anyway, now that you mention it.

> > The signals which seem to be connected externally -- based on the
> > schematic, are:
> 
> > KBRST (from the RST pin on the CPU -- probably used to reset the peripheral at boot.)
> > KBTXD (from the TXD line on the 6850)
> > KBRXD (to the RXD line on the 6850)
> 
> 	O.K.  Reasonable.
> 
> > There's a signal called 19.2Kbd going into the send and receive clocks
> > of the 6850, so it's probably a good guess that the peripherals operate
> > at 19.2kbps.  Page 260 also seems to indicate that VCC is +5v.
> 
> 	The 19.2k clock might be also sent to the keyboard so it does
> not have to be generated on the keyboard.
> 
> > I'm not sure how this works out at the keyboard port and a quick
> > glance at the manual doesn't seem to show this.  I suspect the keyboard
> > will need Vcc and ground signals on top of everything else.
> 
> 	Yes -- and maybe the clock, too.  (Are there five pins on the
> connector?)
> 
> >                                                              So perhaps
> > Vcc/Gnd/RX/TX/not connected -- in some order or another.
> 
> 	I would expect the VCC and Gnd to be two ends of the connector
> row of pins.  Just a matter of finding out which is which.
> 
> 	And I remember once finding where the connector is shown in the
> schematics.  But they are upstairs, and I am downstairs, nad it is
> getting close to time for my P.T. exercises, so I'll leave it to you to
> find that.

I may take another look later for the connector information.  I went ahead and hit the keyboard with a continuity tester just to see what I could find out.  There are two ICs of interest here.  First, there's a Signetics 8450.  I have no idea about this and Google doesn't know either, but I wonder whether it's a slightly modified 2650.  In that case, we've got a general purpose CPU there.  It's in a huge 40 pin DIP package, so that could certainly be the case.  I can't really find anything connected to the keyboard plug that far in -- at least not on the pins I'd expect if this were pin-compatible with the 2650 -- but there's a good chance I wouldn't find it by then, so...

There's also an SN7442AN, which is a pretty common BCD to decimal decoder, with a known pinout.  Some of the pins here are continuous to the port on the side of the keyboard.

When you look at the back of the keyboard, the connectors look  -- excuse the bad ASCII art --like this:

 __________
 | ------- | <- Cable shield contact.
1| . . . . |4
5| . . . . |8
 |    _    |
      -

More wires than I remember.  If you count the shielding plate, you have 9, but it doesn't seem to really use nearly that.   Both pins on the left side are continuous with Vcc on the decoder chip.  All the rest of the pins on the top are continuous with ground on the decoder chip.  I don't believe the cable shield _was_ continuous with ground on the chip, but it connects to a large trace that runs the perimeter of the board, so it goes somewhere.

What we have then is something like:

 __________
 | ------- | <- Cable shield contact.
1| + - - - |4
5| + x y z |8
 |    _    |
      -

Just enough space left over to hold rx, tx, and rst.  If I'm right, rst is what will make the keyboard flash its caps lock LED, so I may be able to locate that one by simply powering it at 5v and applying a signal to each pin in turn.  The logic level should pretty much be equivalent to vcc anyway, so there's not really much chance of breaking anything that way.  That would just leave me with two options for a complete pinout.

> > mean that the keyboard would need to handle the mouse as well and
> > somehow send the data through.
> 
> 	Yes -- it does.  I think that takes us up to six pins on the
> keyboard connector.  One of the data runs allows the computer to command
> the state of case lock and such, IIRC.
> 
> 	Note that the mouse plugs into the keyboard, and is routed
> through to the computer.

Right, that.  Given everything else that's going on here, I wonder whether the mouse isn't just another set of simple switches and some pulse encoders, more or less, that are handled by the keyboard directly.  This seems feasible, but I'm not sure how that would work, since I thought that the mouse could be attached to either side of the keyboard, which would mean the Vcc and ground would be fixed in both spots, and there would only be three other pins available.  Not quite as many as you want.  If I'm wrong though, and the mouse port is different than the one I was just poking at, we have more or less exactly the number of pins we need.  1 signal each for five switches or encoders (x,y,1,2,3), Vcc, ground, and that would leave us with one left over.

> 	The mouse likely generated the same codes as the cursor motion
> keys, plus three for the buttons.  Since there are 256 possible codes
> which could be sent by the MC6850, there should be plenty -- especially
> since it does not have as many special keys as the Sun does. :-)

Now that you mention it, that seems a reasonable assumption to start with, anyway.

Chris

Back to comp.sys.3b1 | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

csiph-web