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

[Chris Smith]

Hey everybody,

I've had a 3B1 since the mid 90s, which I love, but recently it had to move out of the house for a while due to space constraints. This was bad news since apparently the storage area we were using became a nest for a small animal. Now, well, I've cleaned the system and popped the case apart again to double check everything. It's mostly fine (thankfully), but...

I believe the keyboard is not functioning properly. This is not a surpise since it was full of some liquid the origin of which I don't really want to know. It's clean now but corroded in spots. I've removed and discarded the metal shielding around the outside of the keyboard and the (now very musty) cardboard insulating panel between the keyboard and shielding. Caps lock light flashes when the system comes on, but I can't get the keyboard to do anything, even though the switches do seem to be making contact from what I can see with a multimeter. If you pull the cable and re-insert it, you can get some characters to show up on the screen, but they keyboard itself isn't doing much.

Nothing obviously wrong with it upon inspection except some corrosion and the switches are a little stiff. I've tried to clean any dust of corrosion that seemed to be located between traces or wires just in case. I strongly suspect I may need to rebuild all or part of the keyboard. I'm willing to try that if I must, but I'm not really sure where to start. I don't know the electrical specifications even, and I'd much rather if somebody could tell me what they are than have to prod the machine to figure it out. In fact, if anyone has a keyboard schematic, I'd love to see it.

All that said, does anyone happen to know if there are still keyboards for these things floating around somewhere? Also, does anyone have document describing the protocol that should be spoken to the keyboard port? I might not mind building a converter. I'd be very tempted to buy a spare keyboard at this point, even if the original can be recovered.

On another, similar note, the hard drive (which I pulled from a pile of parts and installed into the system in '95 when I got the machine) has finally given out. Not a bad run for a disk, at any rate, and who knows how old and well-used it was before I put it into service, but it's a lot harder to find these than it used to be. What does everyone else do for that problem? Is there a good source for these drives? A piece of modern replacement hardware? There has been some talk (and apparently some success) about emulating the old Shugart interface with a CPLD, though the price may be a bit high on such a device.

Anyway, if anyone has recommendations on how to proceed here, I'd love to hear them.


Thanks,


Chris

[DoN. Nichols]

On 2015-12-19, Chris Smith <prot...@byteorder.net> wrote:
> Hey everybody,

> I've had a 3B1 since the mid 90s, which I love, but recently it had to
> move out of the house for a while due to space constraints. This was
> bad news since apparently the storage area we were using became a nest
> for a small animal. Now, well, I've cleaned the system and popped the
> case apart again to double check everything. It's mostly fine
> (thankfully), but...

> I believe the keyboard is not functioning properly. This is not a
> surpise since it was full of some liquid the origin of which I don't
> really want to know. It's clean now but corroded in spots. I've
> removed and discarded the metal shielding around the outside of the
> keyboard and the (now very musty) cardboard insulating panel between the
> keyboard and shielding.

Have you washed it? Clean tap water can't do much damage to it
compared to what the "unspecified liquid" has already done. I did this
with a different keyboard which suffered from "unidentified liquid"
damage from a squirrel who was resident in the house. Luckily, I
discovered it rather quickly, so the wash and let dry worked well that
time.
Strip the case open.

Turn on warm to hot water in the shower. (Hot will be better,
but warm easier to control things by hand.)

Rinse it for quite a while, ending with water as hot as you can
manage, then shake it, and stand it on end for a day or two to let it
dry thoroughly.

You probably have some of that liquid under the chips, which is
why you want to rinse it quite a wile and then let it dry. (Rapid
drying could be done with a vacuum chamber, but most houses don't have
that. :-)

> Caps lock light flashes when the system comes
> on, but I can't get the keyboard to do anything, even though the
> switches do seem to be making contact from what I can see with a
> multimeter. If you pull the cable and re-insert it, you can get some
> characters to show up on the screen, but they keyboard itself isn't
> doing much.

Yes -- the rinse and dry should help greatly.

> Nothing obviously wrong with it upon inspection except some corrosion
> and the switches are a little stiff.

Operate the keys while the water is flowing, which may help to
free them up, too.

> I've tried to clean any dust of
> corrosion that seemed to be located between traces or wires just in
> case. I strongly suspect I may need to rebuild all or part of the
> keyboard. I'm willing to try that if I must, but I'm not really sure
> where to start. I don't know the electrical specifications even, and
> I'd much rather if somebody could tell me what they are than have to
> prod the machine to figure it out. In fact, if anyone has a keyboard
> schematic, I'd love to see it.

A couple of days ago there was a request for schematics of the
power supply, and I mentioned that the power supply and the video board
in the monitor assembly were purchased in rather than built as part of
the computer, and the vendors did not supply the schematics. I *think*
that they keyboard may be the same.

I note that there is someone on eBay selling a copy of the
_Technical Reference Manual_ (_TRM_) (Service Manual) -- for an
astounding $600.00. (I think that I paid something like $60.00 for mine
way back when.) But the article to which I was replying had the URL for
downloading the whole _TRM_ for free. IIRC, all the schematics are
single page, not foldouts, so that should print fairly well.

Can you back up about a week in this newsgroup and check for the
URL? I never noted it down, because I have the printed manual, but it
would be worth your while to download and print out.

O.K. A quick check of the _TRM_ shows no schematics for the
keyboard -- nor for the mouse, both of which are also purchased in
products like the power supply and the video card (which came with the
CRT itself, I believe.)

> All that said, does anyone happen to know if there are still keyboards
> for these things floating around somewhere?

Keep your eyes on eBay. Right now they have some software and
the _TRM_. but no hardware. You'll likely need to buy a whole computer
to get the keyboard, unless you are really lucky. (Note that there may
be some offered on eBay by someone who does not know that it is for the
3B1/7300/Unix-PC, so if you can get a model number off a label on the
bottom of the keyboard, you *might* find it that way.

Also -- depending on where you are -- you *might* find them at
hamfests (electronics flea markets held by radio amateur organizations),
more common in the summertime -- and I don't know how may are in your
area (wherever that is). There are about six or so every summer not too
far from Washington DC which I regularly attend -- fewer than there used
to be.

> Also, does anyone have
> document describing the protocol that should be spoken to the keyboard
> port?

I don't. I do know that it is common for keyboards to send one
code when the key is pressed, and a different one when it is released,
which is how it knows to repeat when you hold down a keycap. At a
guess, exclusive of the function keys and the like, I would expect the
plain ASCII code when the key is pressed, and perhaps the same but with
the parity bit set when released -- but I've never checked what these
keyboards do. And holding down the shift key probably does change the
codes sent by the other keys -- but tells the software in the system to
modify it appropriately.

Really old keyboards, such as the one for the Texas Instruments
Silent 700 printer actually sent the proper codes for the various mixes
of keypresses -- but that was before things were set up for keyboards at
the end of a skinny cable. :-)

> I might not mind building a converter. I'd be very tempted to
> buy a spare keyboard at this point, even if the original can be
> recovered.

Note that there were at least two versions of the keyboard. One
has the tactile modifications of the index finger home keys (F and J) as
vertical grooves to the left of the letter, and the other has similar
grooves under the letters. IIRC, one had a better feel than the other,
but you first want something which *works*.

> On another, similar note, the hard drive (which I pulled from a pile
> of parts and installed into the system in '95 when I got the machine)
> has finally given out. Not a bad run for a disk, at any rate, and who
> knows how old and well-used it was before I put it into service, but
> it's a lot harder to find these than it used to be. What does everyone
> else do for that problem? Is there a good source for these drives? A
> piece of modern replacement hardware? There has been some talk (and
> apparently some success) about emulating the old Shugart interface with
> a CPLD, though the price may be a bit high on such a device.

The emulation would be a trick with modern drives. (Hmm ...
perhaps easier using something like an Arduino and thumb drives. :-)

The old MFM drives sent a raw signal from the read head, and
depended on logic in the computer (the WD101 or for modified systems the
WD-2010 chip) to convert that into bytes for transfer to memory. You
first have to tell the drive which cylinder you want to step to and
which head within the cylinder.

Todays drives (IDE, SCSI and the like) accept a request for a
specific sector number (counting from zero at the beginning) and figures
out internally what cylinder and head to look for) and then spews out
the sector's contents as a sequence of bytes. I think that translating
between the two would require another controller chip like the WD-1010,
and a smart board (Arduino, Raspberry PI, or other) to ask the modern
drive for the data and make it look like the old MFM drive. Not a
trivial task.

A pity that there was only one SCSI interface board (a
prototype) ever made for the 3B1. Someone who was a regular here had
that prototype board and drivers after the company he worked for gave it
up as a product.

> Anyway, if anyone has recommendations on how to proceed here, I'd love
> to hear them.

You have my suggestions -- starting with the taking it into the
shower with you and giving it a good bath.

Once you get it working (or find another), then comes the trick
of observing it on a 'scope to try to figure out the encoding. If you
do find it -- please post it for future reference.

Good Luck,
DoN.

--
Remove oil spill source from e-mail
Email: <BPdnic...@d-and-d.com> | (KV4PH) Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

[Peter Schmidt]

I bought an MFM drive, a Seagate ST-4096, for $79 off eBay in 2009 to replace the one in my 3B1. Searching eBay now for "MFM hard drive" yields lots of options.

Do you have the floppies to reinstall it?

Good luck!

[Convergent MightyFrame]

Chris, I think you may have come to the right place with this forum/list.

Let me start with my input on your MFM hard drive. I personally, highly recommend David Gesswein's MFM Emulator. I've built many of these, and run them on UNIX PCs. They work fantastically. The only thing I miss is the loud noise that those old drives make. The emulators are completely silent, so it takes a bit away from the experience, but the functionality is excellent.

http://www.pdp8online.com/mfm/

They also allow for easy archiving and backup of the hard drive image.

Should you choose to go that route, I'd be glad to assist you in providing ready-installed emulator images that should just boot up and run on your UNIX PC.

Now, onto your keyboard. These are very tricky. It seems that this keyboard is proprietary to the UNIX PC/3b1/7300, and no other keyboard will work without modification. And, when you find these systems for sale, over half of those don't have the keyboard or mouse, so they are the most rare component of the system.

You've already heard from DoN here, who is by far more knowledgeable than I on the technicalities of these devices. His vast years of knowledge and experience on these is unparalleled. The only value that I could add, is that I experiment with these a lot in present day, and like to try new, different, and radical options.

I have several of these keyboards that work well, and I've done small things to make them work better. I, too, have thought about reverse engineering these, to get other keyboards to function with the UNIX PC, at least partially.

This might be something that works out better as a collaborative project between us, if you're interested. With a few skype sessions, we might be able to determine electrically, with an oscilloscope, logic analyzer, and other tools, exactly how your keyboard is be behaving differently compared to my functioning keyboards.

Send me an email to the address I show at http://mightyframe.blogspot.com/p/contact.html

And we can set up a time to discuss this in more detail.

Best, and happy holidays,
-AJ

[Convergent MightyFrame]

A keyboard logic analysis of something like this is what I propose.

https://youtu.be/JdZqm5C_YwE

A procedure like this could be the key to our keyboard success. I'm already doing some interesting work with logic analyzers on other projects, so this seems like an interesting challenge.

[Chris Smith]

On Friday, December 18, 2015 at 9:17:10 PM UTC-6, DoN. Nichols wrote:
> On 2015-12-19, Chris Smith <prot...@byteorder.net> wrote:
> Have you washed it? Clean tap water can't do much damage to it
> compared to what the "unspecified liquid" has already done. I did this
> with a different keyboard which suffered from "unidentified liquid"
> damage from a squirrel who was resident in the house. Luckily, I
> discovered it rather quickly, so the wash and let dry worked well that
> time.
> Strip the case open.
>
> Turn on warm to hot water in the shower. (Hot will be better,
> but warm easier to control things by hand.)
>
> Rinse it for quite a while, ending with water as hot as you can
> manage, then shake it, and stand it on end for a day or two to let it
> dry thoroughly.

Well, the answer is yes and no. I've cleaned the exposed and nearly exposed surfaces as well as I could with isopropyl, but I hadn't decided yet to try immersion or just spraying the thing down as you suggest. It has been on my list of things to attempt, because I thought the exact thing you did:

> You probably have some of that liquid under the chips, which is
> why you want to rinse it quite a wile and then let it dry. (Rapid
> drying could be done with a vacuum chamber, but most houses don't have
> that. :-)

Or if not liquid, perhaps some conductive left-overs. So... maybe I'll give that a shot to start with.

> A couple of days ago there was a request for schematics of the
> power supply, and I mentioned that the power supply and the video board
> in the monitor assembly were purchased in rather than built as part of
> the computer, and the vendors did not supply the schematics. I *think*
> that they keyboard may be the same.

I can tell you that the logo on the PCB is not an AT&T one, and it has somebody else's model number to go with it. :)

> Can you back up about a week in this newsgroup and check for the
> URL? I never noted it down, because I have the printed manual, but it
> would be worth your while to download and print out.

Thanks. This is something that will be great to have, even if it doesn't have the information I'm currently looking for.

> > I might not mind building a converter. I'd be very tempted to
> > buy a spare keyboard at this point, even if the original can be
> > recovered.
>
> Note that there were at least two versions of the keyboard. One
> has the tactile modifications of the index finger home keys (F and J) as
> vertical grooves to the left of the letter, and the other has similar
> grooves under the letters. IIRC, one had a better feel than the other,
> but you first want something which *works*.

I've only ever seen the one with the vertical troughs cut into the J and F keys, but I've seen perhaps less than a handful of keyboards for this thing.

> The emulation would be a trick with modern drives. (Hmm ...
> perhaps easier using something like an Arduino and thumb drives. :-)

> The old MFM drives sent a raw signal from the read head, and
> depended on logic in the computer (the WD101 or for modified systems the
> WD-2010 chip) to convert that into bytes for transfer to memory. You
> first have to tell the drive which cylinder you want to step to and
> which head within the cylinder.

> Todays drives (IDE, SCSI and the like) accept a request for a
> specific sector number (counting from zero at the beginning) and figures
> out internally what cylinder and head to look for) and then spews out
> the sector's contents as a sequence of bytes. I think that translating
> between the two would require another controller chip like the WD-1010,
> and a smart board (Arduino, Raspberry PI, or other) to ask the modern
> drive for the data and make it look like the old MFM drive. Not a
> trivial task.

Right. I was hoping some of the cheap embedded ARM machines with GPIO included might be fast enough to fake the old protocol and read/write the result to a flash device. If you can spend $20 on a Raspberry Pi and some miscellaneous hardware instead of $90 on an antique drive that's maybe already going bad from ebay, it may be a good option. Though -- all other things being equal -- I do prefer actual hardware. :)

The closest I've seen is the emulator device AJ mentioned, and I hadn't seen it before now. Looks like it depends on having a small computer system hooked in and also some dedicated hardware.

> Once you get it working (or find another), then comes the trick
> of observing it on a 'scope to try to figure out the encoding. If you
> do find it -- please post it for future reference.

Well, I'm fortunately married to a woman who shares some of my hobbies. She has one (an entire second 3b1) that we actually managed to buy old stock from somebody many years back. Even still has the shipping container for it I think. She hasn't started hers up in a while either, but her keyboard is probably fine, and I could probably borrow it for a bit in a worst case. It wouldn't get my keyboard working, but it would allow me to interact with the computer and maybe poke at it with what tools I have available. Unfortunately I don't have an oscilloscope or a logic probe at the moment.

Thanks for the help. I'll try a more thorough cleaning and see how it goes. Not too much to lose.

Chris

[Chris Smith]

On Sunday, December 20, 2015 at 3:18:12 PM UTC-6, Convergent MightyFrame wrote:

> Let me start with my input on your MFM hard drive. I personally, highly recommend David Gesswein's MFM Emulator. I've built many of these, and run them on UNIX PCs. They work fantastically. The only thing I miss is the loud noise that those old drives make. The emulators are completely silent, so it takes a bit away from the experience, but the functionality is excellent.
>
> http://www.pdp8online.com/mfm/

Very cool looking, though I was hoping that somebody had eliminated either the need for specialized hardware or the need to throw a second general purpose computer in to handle storage. :) Even so, depending on whether I can dig up a new drive, that's a good option to have. How annoying is it to assemble one of them?

> I have several of these keyboards that work well, and I've done small things to make them work better. I, too, have thought about reverse engineering these, to get other keyboards to function with the UNIX PC, at least partially.
>
> This might be something that works out better as a collaborative project between us, if you're interested. With a few skype sessions, we might be able to determine electrically, with an oscilloscope, logic analyzer, and other tools, exactly how your keyboard is be behaving differently compared to my functioning keyboards.
>
> Send me an email to the address I show at http://mightyframe.blogspot.com/p/contact.html
>
> And we can set up a time to discuss this in more detail.

That might be a fun project, and I definitely think the world could use a keyboard (and mouse) adapter. I have some limited experience in translating things like joystick signals into mouse signals and various other stuff of that sort. It's very easy and very cheap with some of the modern microcontroller hardware available. Nothing quite as complicated as a keyboard yet. I'm not opposed to making the attempt, but with a protocol that I have no information on -- well, I'm not sure I have the right tools to figure out what to send to the machine myself, though I've been tempted to acquire them. Let me get back to you. :)

Chris

[Chris Smith]

On Saturday, December 19, 2015 at 11:19:19 AM UTC-6, Peter Schmidt wrote:
> I bought an MFM drive, a Seagate ST-4096, for $79 off eBay in 2009 to replace the one in my 3B1. Searching eBay now for "MFM hard drive" yields lots of options.
>
> Do you have the floppies to reinstall it?

Do I have the floppies? Do I have the floppies?! Well, that's actually a pretty good question, but yes I have the floppies. I also have image copies of the floppies from either before or after the last installation on a CD ROM somewhere in our huge mess of a garage. It's a good thing I managed to find the actual floppies and that they're still working. It would have taken me ages to track down that CD. :)

I have the following:

SysV R3.5 base system (diagnostics, floppy boot set, hard disk boot blocks, foundation set, telephone manager, async terminal emulator, EIA/RAM board driver -- I have the board, so that's good, curses/terminfo, encryption, gss drivers, and something which claims to hold a tar file called "LPI Fortran.")


SysVR3.0 utilities (development set, documentation, advanced editors)

Unfortunately I haven't had the matched system/dev kit. I've found that the 3.0 dev kit will install onto a 3.5 system and work mostly out of the box. Maybe requires a slight amount of hackery. I think CPP may have been in a different spot or something, but it's been ages since I did the install.

I can tell you that at least the diagnostic disk, floppy boot set, and hard drive boot disks, still boot the machine. All of the media have been stored together, so hopefully they'll install fine.

Chris

[DoN. Nichols]

On 2015-12-21, Chris Smith <prot...@byteorder.net> wrote:
> On Sunday, December 20, 2015 at 3:18:12 PM UTC-6, Convergent MightyFrame wrote:
>
>> Let me start with my input on your MFM hard drive. I personally, highly recommend David Gesswein's MFM Emulator. I've built many of these, and run them on UNIX PCs. They work fantastically. The only thing I miss is the loud noise that those old drives make. The emulators are completely silent, so it takes a bit away from the experience, but the functionality is excellent.
>>
>> http://www.pdp8online.com/mfm/

> Very cool looking, though I was hoping that somebody had eliminated

> either the need for specialized hardware or the need to throw a second
> general purpose computer in to handle storage. :) Even so, depending on
> whether I can dig up a new drive, that's a good option to have. How
> annoying is it to assemble one of them?

I've not done it -- but I think that the most difficult without
special tools would be the surface mounted devices (SMDs) (which he
offers to hand-solder for you for a price). The rest I would find quite
easy, so it depends on your experience in assembling boards.

To do the SMDs I would suggest that the things to have would be
at a minimum a stereo-zoom microscope (7X to 30X) and a good
well-regulated soldering iron with a tiny tip.

It looks as though the earlier version of the board was tested
with a 3B1 with the standard WD-1010 chip in it -- but no idea about the
modified ones with the WD-2010, which allows drives with more than eight
heads and more than 1024 cylinders to be used. My 3B1s have that
modification plus the modification to allow a second drive to be
connected externally. This takes the maximum drive size from something
like 67 MB (as seen by the 3B1) to IIRC 190 MB or so. (the biggest MFM
Maxtor and a Piram drive with the same parameters.)

[DoN. Nichols]

On 2015-12-21, Chris Smith <prot...@byteorder.net> wrote:

> On Friday, December 18, 2015 at 9:17:10 PM UTC-6, DoN. Nichols wrote:
>> On 2015-12-19, Chris Smith <prot...@byteorder.net> wrote:
>> Have you washed it? Clean tap water can't do much damage to it
>> compared to what the "unspecified liquid" has already done. I did this
>> with a different keyboard which suffered from "unidentified liquid"
>> damage from a squirrel who was resident in the house. Luckily, I
>> discovered it rather quickly, so the wash and let dry worked well that
>> time.
>> Strip the case open.
>>
>> Turn on warm to hot water in the shower. (Hot will be better,
>> but warm easier to control things by hand.)
>>
>> Rinse it for quite a while, ending with water as hot as you can
>> manage, then shake it, and stand it on end for a day or two to let it
>> dry thoroughly.

> Well, the answer is yes and no. I've cleaned the exposed and nearly
> exposed surfaces as well as I could with isopropyl, but I hadn't decided
> yet to try immersion or just spraying the thing down as you suggest. It
> has been on my list of things to attempt, because I thought the exact
> thing you did:

With the keyboard on end (so the pin rows on the chips run up
and down) spaying it with hot water can carry a lot of things from under
the chips. Mine is in a storage garage at the present, and I'm still
recovering from a broken arm a year ago, so digging it out to actually
look at is out of the question at the moment. (Second surgery to remove
the titanium plate and screws recently and back into Physical Therapy to
try to recover more range of motion.)

And I think that water would carry away more of the results of
mouse visitation than alcohol would -- most of their leavings would be
water soluble, while the alcohol would do more to take away any
remaining rosin soldering flux from the production -- and most of that
is long gone anyway.

>> You probably have some of that liquid under the chips, which is
>> why you want to rinse it quite a wile and then let it dry. (Rapid
>> drying could be done with a vacuum chamber, but most houses don't have
>> that. :-)

> Or if not liquid, perhaps some conductive left-overs. So... maybe
> I'll give that a shot to start with.

Good.

>> A couple of days ago there was a request for schematics of the
>> power supply, and I mentioned that the power supply and the video board
>> in the monitor assembly were purchased in rather than built as part of
>> the computer, and the vendors did not supply the schematics. I *think*
>> that they keyboard may be the same.

> I can tell you that the logo on the PCB is not an AT&T one, and it has
> somebody else's model number to go with it. :)

*None* of the machine is AT&T, really. It was made by
Convergent Technologies under contract to AT&T, so it would be their
logos on the CPU board and the plug-in boards. However, the keyboard,
mouse, and the video card (at least) come from other vendors, just made
to match the decor of the 7300/3B1.

>> Can you back up about a week in this newsgroup and check for the
>> URL? I never noted it down, because I have the printed manual, but it
>> would be worth your while to download and print out.

> Thanks. This is something that will be great to have, even if it
> doesn't have the information I'm currently looking for.

It has a fairly large section detailing how it all works,
including signals. I did not look for whether that included the
keyboard communications or not.

>> > I might not mind building a converter. I'd be very tempted to
>> > buy a spare keyboard at this point, even if the original can be
>> > recovered.
>>
>> Note that there were at least two versions of the keyboard. One
>> has the tactile modifications of the index finger home keys (F and J) as
>> vertical grooves to the left of the letter, and the other has similar
>> grooves under the letters. IIRC, one had a better feel than the other,
>> but you first want something which *works*.

> I've only ever seen the one with the vertical troughs cut into the J
> and F keys, but I've seen perhaps less than a handful of keyboards for
> this thing.

And I really don't remember whether the horizontal or vertical
felt better, but there was a distinct difference in feel between them.

The BeagleBone he mentioned is yet another of the single board
computers designed as project controllers, and that is the board which
plugs into the board he sells. I've not read deeply enough in the site
to be sure whether he uses external drives of a more modern design, or
is using solid state drives on the board for storage. The latter would
be a very quiet way to run.

>> Once you get it working (or find another), then comes the trick
>> of observing it on a 'scope to try to figure out the encoding. If you
>> do find it -- please post it for future reference.

> Well, I'm fortunately married to a woman who shares some of my
> hobbies.

Great!

> She has one (an entire second 3b1) that we actually managed to
> buy old stock from somebody many years back. Even still has the
> shipping container for it I think. She hasn't started hers up in a
> while either, but her keyboard is probably fine, and I could probably
> borrow it for a bit in a worst case.

Hers, and yours both, likely have the coin cell soldered onto
the main board long dead, so it will prompt to set the clock every time
you power it up. :-) On mine, I found that coin cell holders for the
2032 coin cells fit nicely (with some care to get the polarity right
when you solder the holder in), and make subsequent replacement of the
cell a lot easier. (You *do* still have to to open the case, which is a
pain, of course -- but no need to get to the other side of the board for
soldering after that one time. :-)

> It wouldn't get my keyboard
> working, but it would allow me to interact with the computer and maybe
> poke at it with what tools I have available. Unfortunately I don't have
> an oscilloscope or a logic probe at the moment.

And a logic probe can only tell you whether there are
transitions on a pin where there should be some. A 'scope can look at
the pin carrying data to the computer from the keyboard and show you a
time diagram. Press a key and note the pattern, repeat with another key
and note again, and you are on your way to figuring out the coding
scheme. And a storage 'scope (screen remembers the trace for a while
before it blooms), or a digital 'scope (trace is captured in memory, and
can be transferred to a computer for later study) keeps you from having
to hit the key many times to try to sketch the trace. Hopefully, the
"how it works" part of the _TRM_ will describe the basic timing, so you
know how fast a sweep to set on the scope to capture a singe keypress,
so you have a starting point at least.

And AJ is the one who posted the URL of the downloadable PDF of
the _TRM_ -- so perhaps he will re-post it in this thread.

> Thanks for the help. I'll try a more thorough cleaning and see how it
> goes. Not too much to lose.

With that keyboard, likely so. And unless you get it *really*
clean, you will probably start having problems with it whenever the
humidity gets high. The really best way to clean the board would be
with an ultrasonic cleaner -- but one big enough for the keyboard is
about as likely to be found in the average house as the vacuum system I
mentioned earlier. :-) (I actually have both a vacuum system and an
ultrasonic cleaner -- but neither is large enough to handle the
keyboard. :-( )

[DoN. Nichols]

On 2015-12-21, Chris Smith <prot...@byteorder.net> wrote:

> On Saturday, December 19, 2015 at 11:19:19 AM UTC-6, Peter Schmidt wrote:
>> I bought an MFM drive, a Seagate ST-4096, for $79 off eBay in 2009 to replace the one in my 3B1. Searching eBay now for "MFM hard drive" yields lots of options.
>>
>> Do you have the floppies to reinstall it?

> Do I have the floppies? Do I have the floppies?! Well, that's
> actually a pretty good question, but yes I have the floppies. I also
> have image copies of the floppies from either before or after the last
> installation on a CD ROM somewhere in our huge mess of a garage. It's a
> good thing I managed to find the actual floppies and that they're still
> working. It would have taken me ages to track down that CD. :)

One thing which I encountered with my first "Foundation set" was
that a number of the floppies would not read reliably. I discovered
that the floppy (when rotated from the hub area) was quite difficult to
turn, and that what had apparently happened was the crease at one edge
had been squished so it was binding there. The solution was to
carefully (and with non-magnetic scissors) trim off about 1/16" of the
edge including the fold. I had planned to move the discs to new
jackets, but once that edge was removed, the disks rotated freely, and I
have used them as modified ever since. :-)

Slide the floppy from side to side using the hub and note which
edge is most difficult to move it to, and trip that side with the disc
slid as far as possible away from that edge.

> I have the following:

> SysV R3.5 base system (diagnostics, floppy boot set, hard disk boot
> blocks, foundation set, telephone manager, async terminal emulator,
> EIA/RAM board driver -- I have the board, so that's good,
> curses/terminfo, encryption, gss drivers, and something which claims to
> hold a tar file called "LPI Fortran.")

> SysVR3.0 utilities (development set, documentation, advanced editors)

> Unfortunately I haven't had the matched system/dev kit. I've found
> that the 3.0 dev kit will install onto a 3.5 system and work mostly out
> of the box. Maybe requires a slight amount of hackery. I think CPP may
> have been in a different spot or something, but it's been ages since I
> did the install.

The images for 3.51m (IIRC) are downloabable -- including the
matching development set -- IIRC from the same site as the _TRM_ PDF
file. However, I've never seen the "LPI Fortran".

> I can tell you that at least the diagnostic disk, floppy boot set, and
> hard drive boot disks, still boot the machine. All of the media have
> been stored together, so hopefully they'll install fine.

And if one or more turns out to be stiff -- you now know how to
relieve that.

> Chris

[Chris Smith]

On Monday, December 21, 2015 at 9:23:28 PM UTC-6, DoN. Nichols wrote:

> I've not done it -- but I think that the most difficult without
> special tools would be the surface mounted devices (SMDs) (which he
> offers to hand-solder for you for a price). The rest I would find quite
> easy, so it depends on your experience in assembling boards.
>
> To do the SMDs I would suggest that the things to have would be
> at a minimum a stereo-zoom microscope (7X to 30X) and a good
> well-regulated soldering iron with a tiny tip.

I'd be tempted to try it myself, depending on the surface mount parts. I'm not terrible at hand-soldering surface mount parts. Best I've done so far is 28 pins at .65mm pitch... on the soldering station at home, which has a not-too-small wedge tip. I'll probably buy something a bit higher precision for it at some point.

> It looks as though the earlier version of the board was tested
> with a 3B1 with the standard WD-1010 chip in it -- but no idea about the
> modified ones with the WD-2010, which allows drives with more than eight
> heads and more than 1024 cylinders to be used. My 3B1s have that
> modification plus the modification to allow a second drive to be
> connected externally. This takes the maximum drive size from something
> like 67 MB (as seen by the 3B1) to IIRC 190 MB or so. (the biggest MFM
> Maxtor and a Piram drive with the same parameters.)

I wasn't aware that these modifications existed. My system has been worked on before I got it, so I suppose I can't be absolutely sure whether it is modified in that respect. I think the cooling fans were replaced, though, and since you mention it -- I didn't double check when I had the system open the other day -- I also think there was a battery holder.


Chris

[Chris Smith]

On Monday, December 21, 2015 at 9:56:15 PM UTC-6, DoN. Nichols wrote:

> And I really don't remember whether the horizontal or vertical
> felt better, but there was a distinct difference in feel between them.

I tend to like keyboards in which you can feel the mechanism working, and the one I have with the vertical bars isn't that, unfortunately. If the other one has clicky switches I'd probably like it quite a lot better.

> The BeagleBone he mentioned is yet another of the single board
> computers designed as project controllers, and that is the board which
> plugs into the board he sells. I've not read deeply enough in the site
> to be sure whether he uses external drives of a more modern design, or
> is using solid state drives on the board for storage. The latter would
> be a very quiet way to run.

Right. I've never used one of those, but I'm familiar enough with it from technical documents. I got the impression that it it used whatever storage was hooked up (which might be something attached to USB on a BeagleBone I think, but could also be SD or probably eMMC on the Green model), and you just configure a sort of host service on that drives the emulator board to know where you've put the disk image files.

> With that keyboard, likely so. And unless you get it *really*
> clean, you will probably start having problems with it whenever the
> humidity gets high. The really best way to clean the board would be
> with an ultrasonic cleaner -- but one big enough for the keyboard is
> about as likely to be found in the average house as the vacuum system I
> mentioned earlier. :-) (I actually have both a vacuum system and an
> ultrasonic cleaner -- but neither is large enough to handle the
> keyboard. :-( )

I did spray it down with reasonably hot water. Didn't look like any goo was washed out in particular, but there were some rusty paint flakes from where the paint had come off of the metal frame in a couple sections of the keyboard while it was setting around. Those certainly seem like they might have been causing a problem, depending on where they were living. As an added bonus, the keys do seem to be less terrible now. I've got it propped up on a heater vent and we'll see what happens in another day or so. :)

Chris

[Chris Smith]

On Monday, December 21, 2015 at 10:07:08 PM UTC-6, DoN. Nichols wrote:


> One thing which I encountered with my first "Foundation set" was
> that a number of the floppies would not read reliably. I discovered
> that the floppy (when rotated from the hub area) was quite difficult to
> turn, and that what had apparently happened was the crease at one edge
> had been squished so it was binding there. The solution was to
> carefully (and with non-magnetic scissors) trim off about 1/16" of the
> edge including the fold. I had planned to move the discs to new
> jackets, but once that edge was removed, the disks rotated freely, and I
> have used them as modified ever since. :-)

I've never quite had to resort to such drastic measures, but I have had floppies that bind against the jacket from setting around for too long. So far it's been easy enough to just spin them manually a turn or two. I'll keep that in mind though, just in case.

> The images for 3.51m (IIRC) are downloabable -- including the
> matching development set -- IIRC from the same site as the _TRM_ PDF
> file. However, I've never seen the "LPI Fortran".

That's great news. Maybe I should make another disk full of images. :) The LPI Fortram may be something I got from the internet (or somewhere else) back when I originally acquired the machine. It's not on AT&T disks, and the label is in my own handwriting. It claims to be a compressed tar file split across two floppies. Only solid reference I can find to it is in an old comp.sys.3b1 FAQ, which just says:

AT&T651209 LPI Fortran. Fortran 77 meeting ANSI X3.9-1978


Chris

[Chris Smith]

On Monday, December 21, 2015 at 9:56:15 PM UTC-6, DoN. Nichols wrote:

> It has a fairly large section detailing how it all works,
> including signals. I did not look for whether that included the
> keyboard communications or not.

Now that DoN mentions this, I see a section "keyboard controller" on page 142. It only deals with the CPU side of the interface, but it mentions "the 6850 serial keyboard controller" which should be "shown on sheet 14 of the schematics." It isn't easy to find, but "sheet 14" is actually on page 247 of the scanned manual. The part is labelled 13G.

There is a Motorola MC6850, which is an async serial controller, which looks a lot like what they show. http://pdf1.alldatasheet.com/datasheet-pdf/view/4161/MOTOROLA/MC6850.html So it's possible we're just looking at TTL serial, which is dead simple to produce with dirt cheap embedded hardware these days.

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)


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.

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. So perhaps Vcc/Gnd/RX/TX/not connected -- in some order or another. This would mean that the keyboard would need to handle the mouse as well and somehow send the data through. This might make sense, IIRC, since the mouse generated something that looked a whole lot like key-codes. Does anyone remember what they were? If we're lucky, that's exactly what the keyboard needs to provide to the TTL interface. That may be the key to building an adapter that can handle provide mouse support.

A quick look at the keyboard later may indicate where Vcc and Ground actually come in. That would be a fine start.

Chris

[DoN. Nichols]

On 2015-12-22, Chris Smith <prot...@byteorder.net> wrote:
> On Monday, December 21, 2015 at 9:23:28 PM UTC-6, DoN. Nichols wrote:

[ ... ]

>> To do the SMDs I would suggest that the things to have would be
>> at a minimum a stereo-zoom microscope (7X to 30X) and a good
>> well-regulated soldering iron with a tiny tip.

> I'd be tempted to try it myself, depending on the surface mount parts.
> I'm not terrible at hand-soldering surface mount parts. Best I've done
> so far is 28 pins at .65mm pitch... on the soldering station at home,
> which has a not-too-small wedge tip. I'll probably buy something a bit
> higher precision for it at some point.

O.K. One benefit of the stereo zoom microscope would be the
ability to examine for solder bridges between adjacent pins.

>> It looks as though the earlier version of the board was tested
>> with a 3B1 with the standard WD-1010 chip in it -- but no idea about the
>> modified ones with the WD-2010, which allows drives with more than eight
>> heads and more than 1024 cylinders to be used. My 3B1s have that
>> modification plus the modification to allow a second drive to be
>> connected externally. This takes the maximum drive size from something
>> like 67 MB (as seen by the 3B1) to IIRC 190 MB or so. (the biggest MFM
>> Maxtor and a Piram drive with the same parameters.)

> I wasn't aware that these modifications existed. My system has been
> worked on before I got it, so I suppose I can't be absolutely sure
> whether it is modified in that respect.

The first thing to check would be the chip in the socket for the
WD-1010. If it is a WD-2010, then the board has at least been modified
to allow more than 1024 cylinders (a limitation on the WD-1010 chip).
If there are also extra wires in the area near where the data and
control cables plug in from the hard drive, then it is likely that it
was also modified to allow more than 8 heads, and a second drive. (Look
for the ICUS modification data in the download sources to find out how,
but details can vary from system to system. I avoided using a board
with extra parts, and instead located a spare 20-pin socket layout on
the board (different locations with different versions of the board),
and with a bit of trace surgery was able to use the existing
differential driver and receiver chips for data to/from the second
drive. (I also did a bit of other tricky work to get both data paths
through a single ribbon cable, and put both drives in an external
housing (originally for a 3B2 computer, so the color scheme matched).
Also a little tricky bit to use the 5V for the internal drive to turn on
the power supply in the external housing, so I did not have to switch it
separately. Obviously, for systems modified the way I did it, the
location of the spare 20-pin socket lead layout would be somewhat
different for different versions of the motherboard.

> I think the cooling fans were
> replaced, though,

Different versions of the machine (at least different between
the 7300 and the 3B1 (half-height vs full-height hard drive) have
different fan setups. IIRC, the 7300 came with two fans, and the 3B1
had one fan replaced with a block of foam rubber.

> and since you mention it -- I didn't double check when
> I had the system open the other day -- I also think there was a battery
> holder.

That makes life easier. Of course, the existing date(1)
program would not allow setting the date to beyond the last day of 1999.
My work-around when I had to deal with it for a while after that period
(helping recover data from someone else's failing disk drives) was to
write two simple programs -- one on a Sun workstation which printed the
date in the numeric format (the 32-bit number which keeps the number of
seconds since the first moment of 1970 GMT), and the other on the 3B1
which sets the time by force-feeding it that same number.

The first one is run like this:

======================================================================
Katana:csu 21:50:27 # ./int-date
1450839186
======================================================================

and the second wants the number from the first on the command line to
set it in the 3B1.

The first looks like this:

======================================================================
/* print the date in raw integer format */
#include <stdio.h>
#include <sys/types.h>
#include <time.h>

main ()
{

time_t now,
time();

time(&now);

printf ("%d\n", now);

}
======================================================================

and the second, like this:

======================================================================
/*
* program to set the system time from an integer string from the time
of
* another system until I can build a date command on this ancient
system
* which understands Y2K values.
*
* DoN. -- Sun May 13 21:29:45 EDT 2007
*/

#include <stdio.h>
int stime();

main (argc, argv)
int argc;
char *argv[];
{
long newtime,
*tp,
resultcode;

tp = &newtime;

if ( argc < 2 ) {
fprintf( stderr, "I need a time integer string\!\n");
exit (-1);
}

resultcode = sscanf (argv[1], "%d", tp);
if (resultcode == 1) {
stime (tp);
} else {
fprintf (stderr, "Conversion failed\!");
exit (1);
}
}
======================================================================

These allow you to set the current time onto the system, even
though you are well into Y2K. However, the libraries will have things
like the start and end of DAT wrong, since they have been changed at
least twice since the system was made. :-)

An older version of the "localtime" libraries could be compiled
on the 3B1 and used to fix all locally-compiled programs. To fix the
rest would require re-building the shared libs to include the new
routines. I seem to remember that more recent versions of the
localtime libs would not compile on the 3B1, but the old ones would.
THe ones which I have a copy of are from 1991, and would need updating
in the database, but otherwise should work.

And -- since it was purely on an internal net, I was willing to
enable rsh and the like on the 3B1, so this script would set the time:

======================================================================
#!/bin/zsh
#
# First -- compile idate on the 3B1, and install it in the
/usr/local/bin
# directory -- or elsewhere with proper adjustment to the command line.
#
# Second -- compile int-date on the time donor system, and put it somewhere
# in your path. (Sources for both are present here.)
#
# Third -- make sure that the donor system and user are in /.rhosts
# on the 3B1.
#
echo -n "The old date on Feis is: "
rsh feis date
#
# Then execute the following script to set the correct date/time on the
# 3B1:
rsh feis /usr/local/bin/idate `int-date`
#
# And the following (optional) command to verify that the date took correctly.
#
echo -n "The new date on Feis is: "
rsh feis date
#
# And this one (on the local system to show how much time skew there is
# from leapseconds treatment and such.
#
echo -n "And the current date on the current host is: "
date
======================================================================

Note, BTW, that there is no way to compile the "ping" command to
work on the 3B1, even if you have the ethernet board and software.
There is no micro-time call in the system, and that is needed for ping
to work :-(

[DoN. Nichols]

On 2015-12-22, Chris Smith <prot...@byteorder.net> wrote:

> On Monday, December 21, 2015 at 9:56:15 PM UTC-6, DoN. Nichols wrote:
>
>> And I really don't remember whether the horizontal or vertical
>> felt better, but there was a distinct difference in feel between them.

> I tend to like keyboards in which you can feel the mechanism working,
> and the one I have with the vertical bars isn't that, unfortunately. If
> the other one has clicky switches I'd probably like it quite a lot
> better.

That sounds like the difference which I remember.

>> The BeagleBone he mentioned is yet another of the single board
>> computers designed as project controllers, and that is the board which
>> plugs into the board he sells. I've not read deeply enough in the site
>> to be sure whether he uses external drives of a more modern design, or
>> is using solid state drives on the board for storage. The latter would
>> be a very quiet way to run.

> Right. I've never used one of those, but I'm familiar enough with it
> from technical documents. I got the impression that it it used whatever
> storage was hooked up (which might be something attached to USB on a
> BeagleBone I think, but could also be SD or probably eMMC on the Green
> model), and you just configure a sort of host service on that drives the
> emulator board to know where you've put the disk image files.

Sounds reasonable.

>> With that keyboard, likely so. And unless you get it *really*
>> clean, you will probably start having problems with it whenever the
>> humidity gets high. The really best way to clean the board would be
>> with an ultrasonic cleaner -- but one big enough for the keyboard is
>> about as likely to be found in the average house as the vacuum system I
>> mentioned earlier. :-) (I actually have both a vacuum system and an
>> ultrasonic cleaner -- but neither is large enough to handle the
>> keyboard. :-( )

> I did spray it down with reasonably hot water. Didn't look like any
> goo was washed out in particular, but there were some rusty paint flakes
> from where the paint had come off of the metal frame in a couple
> sections of the keyboard while it was setting around. Those certainly
> seem like they might have been causing a problem, depending on where
> they were living. As an added bonus, the keys do seem to be less
> terrible now. I've got it propped up on a heater vent and we'll see
> what happens in another day or so. :)

Hopefully that will make a difference.

[DoN. Nichols]

On 2015-12-22, Chris Smith <prot...@byteorder.net> wrote:

> On Monday, December 21, 2015 at 9:56:15 PM UTC-6, DoN. Nichols wrote:
>
>> It has a fairly large section detailing how it all works,
>> including signals. I did not look for whether that included the
>> keyboard communications or not.

> Now that DoN mentions this, I see a section "keyboard controller" on
> page 142. It only deals with the CPU side of the interface, but it
> mentions "the 6850 serial keyboard controller"

Ah yes -- the MC6850 ACIA asynchronous serial port chip -- with
TTL level. Normally used with 1488 and 1489 chips for RS-232 level
transmission and reception (I forget which number goes with which
direction. :-)

> which should be "shown on
> sheet 14 of the schematics." It isn't easy to find, but "sheet 14" is
> actually on page 247 of the scanned manual. The part is labelled 13G.

> There is a Motorola MC6850, which is an async serial controller, which
> looks a lot like what they show.

That is it.

> http://pdf1.alldatasheet.com/datasheet-pdf/view/4161/MOTOROLA/MC6850.html
> So it's possible we're just looking at TTL serial, which is dead simple
> to produce with dirt cheap embedded hardware these days.

And perhaps level translator chips to get to full RS-232 levels.

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

> 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.

Note that there are three sets of schematics there. One for the
system with only 512 K of RAM on the system board, one for 1 MB, and one
for 2 MB. Both the 512 K and the 2 MB use all the chip locations (with
different jumpering for the different chip sizes), and the 1 MB has lots
of empty spaces for more chips -- and driver chips.

> This would
> 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.

> This might make sense, IIRC, since the
> mouse generated something that looked a whole lot like key-codes. Does
> anyone remember what they were? If we're lucky, that's exactly what the
> keyboard needs to provide to the TTL interface. That may be the key to
> building an adapter that can handle provide mouse support.

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. :-)

> A quick look at the keyboard later may indicate where Vcc and Ground
> actually come in. That would be a fine start.

Right. Most TTL chips have the VCC and ground on diagonally
opposite corner pins -- but look up the chip to be sure.

[Chris Smith]

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

[Chris Smith]

On Tuesday, December 22, 2015 at 9:13:53 PM UTC-6, DoN. Nichols wrote:
> On 2015-12-22, Chris Smith <prot...@byteorder.net> wrote:
> > I'd be tempted to try it myself, depending on the surface mount parts.
> > I'm not terrible at hand-soldering surface mount parts. Best I've done
> > so far is 28 pins at .65mm pitch... on the soldering station at home,
> > which has a not-too-small wedge tip. I'll probably buy something a bit
> > higher precision for it at some point.
>
> O.K. One benefit of the stereo zoom microscope would be the
> ability to examine for solder bridges between adjacent pins.

Yeah, it sounds like something I may want to put on the list of things to get eventually, now that you mention it.

> The first thing to check would be the chip in the socket for the
> WD-1010. If it is a WD-2010, then the board has at least been modified
> to allow more than 1024 cylinders (a limitation on the WD-1010 chip).
> If there are also extra wires in the area near where the data and
> control cables plug in from the hard drive, then it is likely that it
> was also modified to allow more than 8 heads, and a second drive. (Look
> for the ICUS modification data in the download sources to find out how,
> but details can vary from system to system. I avoided using a board
> with extra parts, and instead located a spare 20-pin socket layout on
> the board (different locations with different versions of the board),
> and with a bit of trace surgery was able to use the existing
> differential driver and receiver chips for data to/from the second
> drive. (I also did a bit of other tricky work to get both data paths
> through a single ribbon cable, and put both drives in an external
> housing (originally for a 3B2 computer, so the color scheme matched).
> Also a little tricky bit to use the 5V for the internal drive to turn on
> the power supply in the external housing, so I did not have to switch it
> separately. Obviously, for systems modified the way I did it, the
> location of the spare 20-pin socket lead layout would be somewhat
> different for different versions of the motherboard.

I don't believe there's any extra cabling around the drive, but I'll need to check on the controller chip next time I have it open.

> Different versions of the machine (at least different between
> the 7300 and the 3B1 (half-height vs full-height hard drive) have
> different fan setups. IIRC, the 7300 came with two fans, and the 3B1
> had one fan replaced with a block of foam rubber.

Ours are both 7300s technically. Two fans, but I remember the fans in mine being significantly different-looking than the ones in hers, and they've got some connector splices that look aftermarket.

> That makes life easier. Of course, the existing date(1)
> program would not allow setting the date to beyond the last day of 1999.
> My work-around when I had to deal with it for a while after that period
> (helping recover data from someone else's failing disk drives) was to
> write two simple programs -- one on a Sun workstation which printed the
> date in the numeric format (the 32-bit number which keeps the number of
> seconds since the first moment of 1970 GMT), and the other on the 3B1
> which sets the time by force-feeding it that same number.

That's not a bad idea. Simple enough and it does get the clock up to the right time. I'm not absolutely sure my battery is dead yet, on the other hand. Guess we'll find out when I get the drive replaced. :) Keyboard is basically dry, so I may leave it on the heater register again overnight and throw it back on tomorrow. We'll see if that helps.

Chris

[Peter Schmidt]

Sorry I don't have it handy to paste in right now, but I wrote a shell script to set the date semi-automatically.

The trick is, the system is perfectly happy to roll the date over from 1999-12-31-23:59 to 2000-01-01-00:00, and to do that again from 2000-12-31-23:59 to 2001-01-01-00:00, etc. And, you can change the date within a given year by not specifying the year value.

So the shell script takes a single argument, an integer which is the last two digits of the current year in the 21st century, sets the date to 1999-12-31:23:59, sleeps for 62 seconds to ensure the rollover (since the 3.51m date command doesn't allow specifying the seconds), and then loops through the process of setting the date to the last minute of the year, sleeping for 62s, and doing it again until we get to the current year.

Whereupon I manually set the current day and time.

Someday I'll put a new RTC battery in it...

--Peter

[Chris Smith]

On Tuesday, December 22, 2015 at 11:05:11 PM UTC-6, Chris Smith wrote:


> 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.

To answer my own question, the mouse is not a primitive device. There's a reasonably beefy looking IC in there, Motorola. It's in a 28 pin DIP. Labelled SC87347P. I'm not sure exactly what that means it is, but it appears to have a 4Mhz oscillator circuit attached to a couple of its pins, so I'm thinking CPU again in context. There are only 5 lines connected into the mouse, including the cable shielding.

It only connects one power line -- the one on the bottom of the sketch in the previous post -- and one ground line, on the very far opposite end. The other two wires, which I assume are RX and TX, are on what would have been the far right corner of the picture, so it looks like this with respect to the port:

___________
| ------ | <- Shield plate
1 | x x x - | 4
5 | + x ? ? | 8
----__----


The x are unconnected. The ? are either TX or RX.


Which means that -- assuming the ports are identical, which is a good assumption now -- we've found RST, and the port looks like this:

_________________
| ------ | <- Shield plate

1 | + - - - | 4

5 | + Rst ? ? | 8
-------__-------

I'd bet the mouse and keyboard are both supposed to produce TTL serial on those last two pins.


Chris

[Chris Smith]

On Wednesday, December 23, 2015 at 1:49:23 PM UTC-6, Chris Smith wrote:

> ___________
> | ------ | <- Shield plate
> 1 | x x x - | 4
> 5 | + x ? ? | 8
> ----__----
>
>
> The x are unconnected. The ? are either TX or RX.
>
>
> Which means that -- assuming the ports are identical, which is a good assumption now -- we've found RST, and the port looks like this:
>
> _________________
> | ------ | <- Shield plate
> 1 | + - - - | 4
> 5 | + Rst ? ? | 8
> -------__-------
>
> I'd bet the mouse and keyboard are both supposed to produce TTL serial on those last two pins.

Err, correction. Apparently the top positive line is connected in the mouse and not the bottom, so:

___________
| ------ | <- Shield plate

1 | + x x - | 4
5 | x x ? ? | 8
----__----


I can also tell you that my FTDI adapter behaves most reasonably when it expects the system to be transmitting on what is labelled pin 8 above and the device to the system on pin 7 next to it, so the port pinout in full is:

______________
| ------ | <- Shield plate
1 | + - - - | 4

5 | + RST Rx Tx | 8
-----__------


That is, Tx and Rx with respect to the system transmitting or receiving.


Haven't really been able to get any data through yet, but -- if you set your serial port to 19200, and if you power the mouse at 5v according to the diagram (3.3v will definitely not work; I thought I'd try it since my FTDI board can produce 3.3v on its own) you get garbage data from the mouse every time you send a break, or if you leave the tx line disconnected. I assume it's using this for flow control and perhaps some other stuff -- who knows.

So I guess the next question is, how many data bits, stop bits, and what's the parity? If we can figure that out, it's looking really easy to interface with this thing. I mean, I had its mouse plugged into my Linux box today and pushing data in, which is a reasonable start.


Chris

[Chris Smith]

On Wednesday, December 23, 2015 at 4:25:34 PM UTC-6, Chris Smith wrote:

> Haven't really been able to get any data through yet, but -- if you set your serial port to 19200, and if you power the mouse at 5v according to the diagram (3.3v will definitely not work; I thought I'd try it since my FTDI board can produce 3.3v on its own) you get garbage data from the mouse every time you send a break, or if you leave the tx line disconnected. I assume it's using this for flow control and perhaps some other stuff -- who knows.
>
> So I guess the next question is, how many data bits, stop bits, and what's the parity? If we can figure that out, it's looking really easy to interface with this thing. I mean, I had its mouse plugged into my Linux box today and pushing data in, which is a reasonable start.

Slight addition. My keyboard isn't working properly yet, but if I boot to the diagnostic disk, and place the mouse directly into the keyboard port on the machine, each button produces a different ascii letter when I hit it and produces an f when I release it. ... this may not be the whole story but it might provide a clue as to what ought to be going on as far as the computer system is concerned. Now that aside, when I hook the keyboard up to my computer in the same way, there's a constant hum of activity. It's doing _something over the serial port, but it's as if it doesn't know it's supposed to shut up until I drop tx, or doesn't care. Also it seems I need a larger 5v power supply to make this test, which I won't hook up just now, nor probably for a few days. :)

Chris

[Convergent MightyFrame]

Chris & All,

This has turned into one of the most active threads on comp.sys.3b1 that I've seen in a long time. This is great.

On the MFM Emulator hardware: How annoying is it to assemble one of them? It's time consuming to do it right, and I would say that a moderate level of soldering is desired. However, I believe that David even will sell a fully-build version now, so that may be your best option.

Please keep me in the loop if you choose to go that route. I'd love to hear your progress and help you through any 3b1 specific issues. Another guy just emailed me and asked for my emulator image, so if you join in, there will be a small growing group of 3 people running UNIX PCs on MFM emulators.

I see there's been a good deal of subsequent technical discussion between you and DoN, so I hope you get that to work. It will take me more time to review all that has been said, and provide any meaningful comment, but just by skimming it, it all appears to be good progress. Getting your original keyboard to work is by far the most ideal solution, in my opinion.

As far as the keyboard manufacturer, when I tore one of mine apart, I see that it was built by CORTRON, but you may have seen this already while inspecting your keyboard. See a picture at http://bit.ly/1NDkg32 (hosted on Google Drive, sorry, DoN)

Given the world's shortage of these proprietary keyboards and mice for this machine, I still would like to pursue the "building the adapter" idea at some point. It wouldn't be as elegant, but it could at least be functional, and allow many different options for hobbyists like us who like these machines.

Given the amount of activity here and emails I've received lately on parts or follow-up on my MFM Emulator usage success, there is still interest in these machines among at least a select few.

Anway, all the best, and happy holidays.
-AJ

[DoN. Nichols]

On 2015-12-23, Chris Smith <prot...@byteorder.net> wrote:
> 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.

Probably different speeds and such, of course. :-)

>> > 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)

IIRC, there is a section of the manual listing which pages each
named signal appears on. Likely, these signals go through some kind of
driver chips and change name there, but I don't remember for sure.

It may be a keyboard encoder chip -- which does thinks like
drive signals to the horizontal rows of keys and look for which vertical
row sees the pulse. Then, inside, it is programmed to generate a
specific code for each unique keypress.

> 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:

Worked fine until it was quoted. AT least we are both using
fixed pitch fonts for our newsreaders. One trick to help avoid problems
is to never use the TAB key, but instead enter just the number of spaces
needed.

> __________
> | ------- | <- 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.

The shield connects to chassis ground, which is a safety trace
around the board edge, and is grounded to the metal chassis by all the
screws which mount the board (except perhaps ones in the middle).

> 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.

Note that the pins may be high for zero, so you ground them to
send a signal. (If there is a bar over the signal name, it is zero when
high, and true when low.)

>> > 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.

IIRC, the keyboard cable plugs into the connector to the right
of the keyboard shelf on the computer, and to the connector on the left
of the keyboard, so the coiled cable is hidden under the keyboard when
it is at rest. This leaves the right-hand connector on the keyboard for
the mouse.

>> 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.

I'm not answering many tonight. Time spent over at a friend's
for Christmas.

[Chris Smith]

On Wednesday, December 23, 2015 at 7:31:20 PM UTC-6, Convergent MightyFrame wrote:

> On the MFM Emulator hardware: How annoying is it to assemble one of them? It's time consuming to do it right, and I would say that a moderate level of soldering is desired. However, I believe that David even will sell a fully-build version now, so that may be your best option.

I'm not at all opposed to soldering a large project; I'm just wondering what I'd be getting into. :)

> I see there's been a good deal of subsequent technical discussion between you and DoN, so I hope you get that to work. It will take me more time to review all that has been said, and provide any meaningful comment, but just by skimming it, it all appears to be good progress. Getting your original keyboard to work is by far the most ideal solution, in my opinion.

Well, the good news is that I can receive signals from the keyboard and mouse with a standard TTL serial hookup. I can power them with a 5v supply, and nothing explodes. This is good, but I haven't figured out what they're saying yet. :) No work on it over the last week or so either.

> As far as the keyboard manufacturer, when I tore one of mine apart, I see that it was built by CORTRON, but you may have seen this already while inspecting your keyboard. See a picture at http://bit.ly/1NDkg32 (hosted on Google Drive, sorry, DoN)

Yep. I haven't seen any indication that these things are available elsewhere either, although I have a slight suspicion that some 3b2 keyboards may have been very similarly designed -- perhaps to the point of being internally compatible with a different plug.

> Given the world's shortage of these proprietary keyboards and mice for this machine, I still would like to pursue the "building the adapter" idea at some point. It wouldn't be as elegant, but it could at least be functional, and allow many different options for hobbyists like us who like these machines.

Not to mention that some of the newer mechanical keyboards are very nice to use. As much as I like the layout of the Unix PC keyboard, the key-switches are not quite what I'd want in an ideal world.

Chris

[Chris Smith]

On Friday, December 25, 2015 at 10:32:43 PM UTC-6, DoN. Nichols wrote:
> On 2015-12-23, Chris Smith <prot...@byteorder.net> wrote:

> > 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...

> It may be a keyboard encoder chip -- which does thinks like
> drive signals to the horizontal rows of keys and look for which vertical
> row sees the pulse. Then, inside, it is programmed to generate a
> specific code for each unique keypress.

Well, that seems like a good bet maybe. :)

> Worked fine until it was quoted. AT least we are both using
> fixed pitch fonts for our newsreaders. One trick to help avoid problems
> is to never use the TAB key, but instead enter just the number of spaces
> needed.

Yeah, I kind of hate having to resort to ASCII drawings, but it's probably better than attaching images and marking them up with a paint program.

> The shield connects to chassis ground, which is a safety trace
> around the board edge, and is grounded to the metal chassis by all the
> screws which mount the board (except perhaps ones in the middle).

Yep, seems like it is.

> Note that the pins may be high for zero, so you ground them to
> send a signal. (If there is a bar over the signal name, it is zero when
> high, and true when low.)

I had considered this -- even if it's mostly a standard serial signal, perhaps the state is inverted in which case we'd be looking at a binary complement of the actual data. Haven't been able to determine whether that's the case.

> IIRC, the keyboard cable plugs into the connector to the right
> of the keyboard shelf on the computer, and to the connector on the left
> of the keyboard, so the coiled cable is hidden under the keyboard when
> it is at rest. This leaves the right-hand connector on the keyboard for
> the mouse.

Generally that seems to be the right way, but I'm not sure it's required. As I said, the mouse seems to send signals that are compatible enough that you can plug it straight into the port. The routing troughs for the mouse cable (to adjust whether it sets on the right or left of the machine) do both come from the plug on the right side of the keyboard, though. If you got those plugs backwards, I'm not certain it should be expected to work correctly. On the other hand, I'm not certain it couldn't.

With respect to my own keyboard, I can't help but notice that it's misbehaving in exactly the way it should be expected to misbehave -- assuming that the keyboard and mouse protocol are the same -- if the tx line were cut somewhere. I may need to double check the connectivity through my cable and trace that particular line out on the board.


Chris

[DoN. Nichols]

On 2016-01-05, Chris Smith <prot...@byteorder.net> wrote:
> On Wednesday, December 23, 2015 at 7:31:20 PM UTC-6, Convergent MightyFrame wrote:

[ ... ]

> Well, the good news is that I can receive signals from the keyboard
> and mouse with a standard TTL serial hookup. I can power them with a 5v
> supply, and nothing explodes. This is good, but I haven't figured out
> what they're saying yet. :) No work on it over the last week or so
> either.

No oscilloscope to watch it with? You need to set it up for
single-shot triggered by the beginning of the output pulses.

>> As far as the keyboard manufacturer, when I tore one of mine apart, I
>> see that it was built by CORTRON, but you may have seen this already
>> while inspecting your keyboard. See a picture at http://bit.ly/1NDkg32
>> (hosted on Google Drive, sorry, DoN)

> Yep. I haven't seen any indication that these things are available
> elsewhere either, although I have a slight suspicion that some 3b2
> keyboards may have been very similarly designed -- perhaps to the point
> of being internally compatible with a different plug.

Consider that the 3B1 was *really* made for AT&T by Convergent
Technologies -- while they were making other 68000-family unix boxen for
their own name.

The 3B2 *may* have actually been made by AT&T -- or some other
contractor, and there is not much chance that the keyboards would be
interchangeable.

[Aharon Robbins]

In article <slrnn8ooo2.g1...@Katana.d-and-d.com>,

DoN. Nichols <BPdnic...@d-and-d.com> wrote:
>On 2016-01-05, Chris Smith <prot...@byteorder.net> wrote:
> The 3B2 *may* have actually been made by AT&T -- or some other
>contractor, and there is not much chance that the keyboards would be
>interchangeable.

The 3B2 was made by AT&T. It definitely had a Western Electric
processor in it. It was one of the first true 32 bit microprocessor
systems.

But I agree that it's doubtful that keyboards for it would work
in a 3B1 / 7300.
--
Aharon (Arnold) Robbins arnold AT skeeve DOT com

[Chris Smith]

On Tuesday, January 5, 2016 at 6:42:55 PM UTC-6, DoN. Nichols wrote:
> On 2016-01-05, Chris Smith <prot...@byteorder.net> wrote:
> > On Wednesday, December 23, 2015 at 7:31:20 PM UTC-6, Convergent MightyFrame wrote:
>
> [ ... ]
>
> > Well, the good news is that I can receive signals from the keyboard
> > and mouse with a standard TTL serial hookup. I can power them with a 5v
> > supply, and nothing explodes. This is good, but I haven't figured out
> > what they're saying yet. :) No work on it over the last week or so
> > either.
>
> No oscilloscope to watch it with? You need to set it up for
> single-shot triggered by the beginning of the output pulses.

Not at the moment, but I believe we have one around here somewhere, which will help if I can find it and hook it up.

In other news, I went ahead and traced the tx line from the computer side back through the cable and into the keyboard all the way to a pin on one of the latch ICs. Seems it's still connected to somewhere reasonable. Re-heated the solder around that IC and a couple others. No change in the behavior unfortunately.

Chris

[DoN. Nichols]

On 2016-01-06, Aharon Robbins <arn...@skeeve.com> wrote:
> In article <slrnn8ooo2.g1...@Katana.d-and-d.com>,
> DoN. Nichols <BPdnic...@d-and-d.com> wrote:
>>On 2016-01-05, Chris Smith <prot...@byteorder.net> wrote:
>> The 3B2 *may* have actually been made by AT&T -- or some other
>>contractor, and there is not much chance that the keyboards would be
>>interchangeable.
>
> The 3B2 was made by AT&T. It definitely had a Western Electric
> processor in it. It was one of the first true 32 bit microprocessor
> systems.

O.K. Since I never had one, I was not sure.

Though the 68000 family was 32-bit internally. The original
68000, and the 68010 in the 3B1 were limited to a 16-bit wide data bus,
but internally it was 32-bits. (A problem for the Mac when the system
was upgraded from the original 24-bit address to a full 32-bit address
with the 68020 (I believe), and third-party software suppliers had been
using the upper 8-bits of addresses to store data flags, and when the
full 32-bit external address came around, those packages broke
spectacularly. :-)

> But I agree that it's doubtful that keyboards for it would work
> in a 3B1 / 7300.

And there was a PC as well, about the same period. That was made by
Olivetti for AT&T. Trying to remember the model name. Something like
the 6300 -- so similar to the 7300. It would have yet another keyboard.
(and also -- it had the hardware time-of-day clock having only an
eight-year span, so you had to patch the MS-DOS OS every so many years
to get the proper date to show. :-)

Enjoy,

[Dave Brower]

I to am in the middle of resuscitating a 7300; I've been mostly able to salvage the content of my ST4096 using the pdp8/Gesswein emulator, which is working well enough.

I can recommend that highly!

I have a version of GCC that I ported back in the day on that ST4096 disk and can make it available on request.

For the keyboard problem, I think a clever thing to do would be to get a $5 "orange PI", plug a USB keyboard into that, and then have it drive the 3b1 connector.

I'm hoping to use a serial port out of the BeagleBone on the MFM drive emulator to plug into the serial port on the back of the machine -- then I can ssh to the 'bone, and talk to the 3b1 as a serial TTY over the network rather than staring at it physically. The display was never a strong point for the machine, which I blame on the non-square pixels.

-dB

[Chris Smith]

On Friday, January 8, 2016 at 1:25:54 AM UTC-6, Dave Brower wrote:

> For the keyboard problem, I think a clever thing to do would be to get a $5 "orange PI", plug a USB keyboard into that, and then have it drive the 3b1 connector.

I was thinking a cheaper microcontroller would do the trick, but that's the direction I may be going with it if only I can figure out how the protocol works.

> I'm hoping to use a serial port out of the BeagleBone on the MFM drive emulator to plug into the serial port on the back of the machine -- then I can ssh to the 'bone, and talk to the 3b1 as a serial TTY over the network rather than staring at it physically. The display was never a strong point for the machine, which I blame on the non-square pixels.

I always kind of liked the display. It wasn't great, but it definitely wasn't bad.


Chris

[Chris Smith]

I've also just noticed that Philip Pemberton has started on a 3b1 emulator. http://www.philpem.me.uk/code/3b1emu/

It has a keyboard driver. Haven't reviewed it yet, but the scan-codes at least are all listed in here and maybe some other important things:

https://bitbucket.org/philpem/freebee/src/51402e8ead7336de395f1c0ed2beda55e0a57fca/src/keyboard.c?at=default&fileviewer=file-view-default

Chris

[Chris Smith]

Not much news on this recently, but I did finally manage to borrow the other keyboard so that I could attempt to recover the machine. Reformatted the drive -- had to adjust the geometry slightly, but it seems to have formatted and tested ok. Installed the OS again, which went reasonably well except that my dev kit seems to be completely messed up. Still, dd is working and while this may not recover the floppies for me, it may allow me to download images from another dev kit and install them. Once that's done I'll see what I can do about figuring the keyboard out. Since the system is up and running, it should be easier, I hope.

Chris

[Chris Smith]

Let's try this mall again.

In other news related to the keyboard, I just impulse bought a Convergent/Bull/Burroughs/Unisys K-1 keyboard which was to be used with the B-25 series of machines. The look of it was close enough to that of the AT&T systems to catch my attention, and it appears not to be a coincidence. The plugs (of which there are two) seem like modular 8 pin jobs, and you can see in this thread ( https://deskthority.net/photos-f62/burroughs-b25-k1-ab-t12757.html ) that is made by Cortron, and the model number is even quite close to that of the Unix PC keyboard. Honestly, even the PCB layout looks remarkably similar.

Now these are rare too, and even if the architecture is more or less similar there's no guarantee that the key codes are similar at all, but I just happened to find one on eBay for 30 USD, and there's not a 3B1 keyboard in sight. It's worth a shot, and in a worst case, we'll have some information on compatibility and I'll have a keyboard for a B-25 if I ever manage to get one. In a best case, we learn that these two machines can share keyboards, I'll let everyone know what the pin map looks like, and I can give the other AT&T keyboard back while I try to figure out the protocol. :)

Chris

[Bill Gunshannon]

On 2/19/16 5:15 PM, Chris Smith wrote:
> Not much news on this recently, but I did finally manage to borrow the other keyboard so that I could attempt to recover the machine. Reformatted the drive -- had to adjust the geometry slightly, but it seems to have formatted and tested ok. Installed the OS again, which went reasonably well except that my dev kit seems to be completely messed up. Still, dd is working and while this may not recover the floppies for me, it may allow me to download images from another dev kit and install them. Once that's done I'll see what I can do about figuring the keyboard out. Since the system is up and running, it should be easier, I hope.
>
> Chris
>

Funny you should mention it. In sorting through all my junk trying
to get out of the old house so I can sell it I one of the things I
found is a development kit still in the shrink wrap. Anybody have
any idea what something like this is worth today? I think there
is another one floating around here somewhere. As for me, I only
have one 3B1 left and the disk on that crashed the last time I
used it so it is just sitting in a corner waiting to see what happens
next.

bill

[Chris Smith]

I have no idea what people pay for that kind of thing myself, (I can tell you that people seem to pay about the same for the floppies themselves as they always have... not that I don't have a few laying around, but I've been looking for clean ones to make new 3b1 media recently) but if my experience with the disk is any indication you might actually be able to press the thing back into service, depending. I had forgotten how resilient those old drives actually are.

Chris

[Bill Gunshannon]

On 2/20/16 2:39 PM, Chris Smith wrote:
> I have no idea what people pay for that kind of thing myself, (I can tell you that people seem to pay about the same for the floppies themselves as they always have... not that I don't have a few laying around, but I've been looking for clean ones to make new 3b1 media recently) but if my experience with the disk is any indication you might actually be able to press the thing back into service, depending. I had forgotten how resilient those old drives actually are.
>
> Chris
>

Hey, Here's another interesting idea. Anybody here have examples of
device driver code for the 3B1? I have these cool little serial disk
drive modules that might be fun to write a driver for. Anything to
get more usable disk space on the machine that isn't going to go south
any day now.

bill

[Chris Smith]

Haven't looked at the other keyboard yet, but did receive it. It's actually got a nice feel to it. If it will work, it will be a fine replacement for the original one. Did get the computer hooked up to another system with UUCP configured so that I can grab replacement images of the dev kit from the internet and blast them over the serial line at a blazing 9600bps before writing them back out to the floppy device. :) We'll see how that goes once I dig up some decent blank floppies.

Chris

[Chris Smith]

Based on some more work, I've decided the following:

I may have not had my power wired in properly and the data I've had so far may have been noise. I'll give this another shot in a bit and maybe get more interesting data.

Now that the machine is running, I can tell you that the port does generate 5v where I expect it to, so that's at least something.

The Burroughs/Unisys keyboard, once open, starts looking a _whole_ lot like the AT&T one. Based on continuity tests at the plugs (which are also 8 pins) I find that three of them are connected together and two of the others are connected together, leaving three other lines. It would make a whole lot of sense for these to be negative, +5v, and (rx, tx, rst) respectively, exactly as in the other keyboard. I'm kind of wondering how difficult it would be to just wire it in and try it. Perhaps not much.


Interestingly, when the bad keyboard is plugged into the machine with a mouse on the other side, the mouse works fine. This suggests to me that there must be some logic in there that's working properly. Perhaps whatever runs the keyboard matrix is the only thing that's not functional.


Chris

[DoN. Nichols]

On 2016-03-05, Chris Smith <prot...@byteorder.net> wrote:
> Based on some more work, I've decided the following:

> I may have not had my power wired in properly and the data I've had so
> far may have been noise. I'll give this another shot in a bit and maybe
> get more interesting data.

> Now that the machine is running, I can tell you that the port does
> generate 5v where I expect it to, so that's at least something.

Good.

> The Burroughs/Unisys keyboard, once open, starts looking a _whole_ lot
> like the AT&T one. Based on continuity tests at the plugs (which are
> also 8 pins) I find that three of them are connected together and two of
> the others are connected together, leaving three other lines. It would
> make a whole lot of sense for these to be negative, +5v, and (rx, tx,
> rst) respectively, exactly as in the other keyboard.

Agreed -- with likely "negative" ('ground') as the three wires,
and the +5V being the two together. But verify this with the original
keyboard plugged into the computer -- don't go by what I guess is
correct. :-)

> I'm kind of
> wondering how difficult it would be to just wire it in and try it.
> Perhaps not much.

What are the connectors like on the new keyboard? If something
other than the one for the 3B1, I would suggest making an adaptor rather
than modifying the cable. This could make it easier to swap wires
around at need.)

> Interestingly, when the bad keyboard is plugged into the machine with
> a mouse on the other side, the mouse works fine. This suggests to me
> that there must be some logic in there that's working properly. Perhaps
> whatever runs the keyboard matrix is the only thing that's not
> functional.

I *think* that 5V, ground, and the txd are simply routed through
the keyboard. Maybe the reset, too. I've never tried holding down a
key for repeats while moving the mouse to see whether they interfere
with each other.

Good Luck,

[300watt...@gmail.com]

On Friday, March 4, 2016 at 9:17:12 PM UTC-6, DoN. Nichols wrote:
> On 2016-03-05, Chris Smith <prot...@byteorder.net> wrote:

> > The Burroughs/Unisys keyboard, once open, starts looking a _whole_ lot
> > like the AT&T one. Based on continuity tests at the plugs (which are
> > also 8 pins) I find that three of them are connected together and two of
> > the others are connected together, leaving three other lines. It would
> > make a whole lot of sense for these to be negative, +5v, and (rx, tx,
> > rst) respectively, exactly as in the other keyboard.
>
> Agreed -- with likely "negative" ('ground') as the three wires,
> and the +5V being the two together. But verify this with the original
> keyboard plugged into the computer -- don't go by what I guess is
> correct. :-)

I'll poke around a bit at it next week hopefully. This is true of the Unix PC keyboard. I can't plug the other one in since I don't currently have the computer for it. :)

> > wondering how difficult it would be to just wire it in and try it.
> > Perhaps not much.
>
> What are the connectors like on the new keyboard? If something
> other than the one for the 3B1, I would suggest making an adaptor rather
> than modifying the cable. This could make it easier to swap wires
> around at need.)

That's the plan. I believe the connector is something called sdl. The old pc keyboard used a six pin connector to hook the cable up to the keyboard. This one uses an 8 pin one. It's something like a modular plug with contact edges along the top, but also a shielded shell. It's flatter and wider than an RJ, with catches on the sides instead of on the bottom. I'm not absolutely sure of this but I can order a couple of the connectors and try it. Not yet sure how I'll get them crimped on to a cable, though. I don't have the original cable that went to the computer, but in pictures they look D-shaped on the system end.

> > Interestingly, when the bad keyboard is plugged into the machine with
> > a mouse on the other side, the mouse works fine. This suggests to me
> > that there must be some logic in there that's working properly. Perhaps
> > whatever runs the keyboard matrix is the only thing that's not
> > functional.
>
> I *think* that 5V, ground, and the txd are simply routed through
> the keyboard. Maybe the reset, too. I've never tried holding down a
> key for repeats while moving the mouse to see whether they interfere
> with each other.

How would that work if there's only one data line going out of the keyboard? I mean, wouldn't there be some multiplexing going on in there, or am I missing something? Or maybe you mean tx from the computer into the keyboard...? That would make some sense.

Chris

[DoN. Nichols]

On 2016-03-06, 300watt...@gmail.com <300watt...@gmail.com> wrote:
> On Friday, March 4, 2016 at 9:17:12 PM UTC-6, DoN. Nichols wrote:
>> On 2016-03-05, Chris Smith <prot...@byteorder.net> wrote:
>
>> > The Burroughs/Unisys keyboard, once open, starts looking a _whole_ lot
>> > like the AT&T one. Based on continuity tests at the plugs (which are
>> > also 8 pins) I find that three of them are connected together and two of
>> > the others are connected together, leaving three other lines. It would
>> > make a whole lot of sense for these to be negative, +5v, and (rx, tx,
>> > rst) respectively, exactly as in the other keyboard.
>>
>> Agreed -- with likely "negative" ('ground') as the three wires,
>> and the +5V being the two together. But verify this with the original
>> keyboard plugged into the computer -- don't go by what I guess is
>> correct. :-)

> I'll poke around a bit at it next week hopefully. This is true of the
> Unix PC keyboard. I can't plug the other one in since I don't currently
> have the computer for it. :)

O.K. I've gone to _The Reference Manual_, and found that the
serial chip for the keyboard is on sheet 14 of the system board
schematics. It gives the following pin functions:

KBDTXD --> JK-7
GROUND --> JK-1,2,3
+5V --> JK-4,8
KBDRST --> JK-5
KBDRD <-- JK-6
Chassis Ground to JK-shield

with "JK" being the jack on the system board into which the keyboard
plugs.

And that covers all eight pins. Now, it remains to determine the pin
numbering on the connector.

At a guess it is something like this:

5 6 7 8
: : : :
1 2 3 4

Making the GROUNDs a row along one side (bottom as I show it here, but
check which three are shorts together -- perhaps examine the underside
of the keyboard PC board under the connectors) and the +5V is the two
together at the end past the GROUND pins. That would make the KBDRST
the one adjacent to the first ground pin, the KBDRD the middle of the
three, and the KBDTXD adjacent to one of the +5V pins.

Look on the jack for a small triangle molded into the plastic.
This should mark pin 1.

Note that read and transmit are from the point of view of the
computer, not the keyboard.

>> > wondering how difficult it would be to just wire it in and try it.
>> > Perhaps not much.
>>
>> What are the connectors like on the new keyboard? If something
>> other than the one for the 3B1, I would suggest making an adaptor rather
>> than modifying the cable. This could make it easier to swap wires
>> around at need.)

> That's the plan. I believe the connector is something called sdl.
> The old pc keyboard used a six pin connector to hook the cable up to the
> keyboard. This one uses an 8 pin one. It's something like a modular
> plug with contact edges along the top, but also a shielded shell. It's
> flatter and wider than an RJ, with catches on the sides instead of on
> the bottom. I'm not absolutely sure of this but I can order a couple of
> the connectors and try it. Not yet sure how I'll get them crimped on to
> a cable, though. I don't have the original cable that went to the
> computer, but in pictures they look D-shaped on the system end.

So -- this is a female connector on the keyboard itself, instead
of on a cable.

>> > Interestingly, when the bad keyboard is plugged into the machine with
>> > a mouse on the other side, the mouse works fine. This suggests to me
>> > that there must be some logic in there that's working properly. Perhaps
>> > whatever runs the keyboard matrix is the only thing that's not
>> > functional.
>>
>> I *think* that 5V, ground, and the txd are simply routed through
>> the keyboard. Maybe the reset, too. I've never tried holding down a
>> key for repeats while moving the mouse to see whether they interfere
>> with each other.

> How would that work if there's only one data line going out of the
> keyboard? I mean, wouldn't there be some multiplexing going on in
> there, or am I missing something? Or maybe you mean tx from the
> computer into the keyboard...? That would make some sense.

I'm thinking that the transmit bursts are short enough (high
baud rate) so the chances of a collision with the mouse signals is
minimal. Perhaps the mouse signal is sent through a gate which is
turned off when the keyboard is about to transmit a keystroke. (Likely
turned off just long enough before so a mouse signal could complete or
time out before the keyboard character or characters were sent.)

Anyway -- you should expect the keyboard end of the 3B1 cable to
be the same as the computer end -- no crossing of pins between the ends.

[Chris Smith]

On Sunday, March 6, 2016 at 10:25:12 PM UTC-6, DoN. Nichols wrote:

> > I'll poke around a bit at it next week hopefully. This is true of the
> > Unix PC keyboard. I can't plug the other one in since I don't currently
> > have the computer for it. :)

> O.K. I've gone to _The Reference Manual_, and found that the
> serial chip for the keyboard is on sheet 14 of the system board
> schematics. It gives the following pin functions:
>
> KBDTXD --> JK-7
> GROUND --> JK-1,2,3
> +5V --> JK-4,8
> KBDRST --> JK-5
> KBDRD <-- JK-6
> Chassis Ground to JK-shield
>
> with "JK" being the jack on the system board into which the keyboard
> plugs.

Thanks. It's good to have this from a somewhat authoritative source, and it agrees with what I've found so far.

> At a guess it is something like this:
>
> 5 6 7 8
> : : : :
> 1 2 3 4
>
> Making the GROUNDs a row along one side (bottom as I show it here, but
> check which three are shorts together -- perhaps examine the underside
> of the keyboard PC board under the connectors) and the +5V is the two
> together at the end past the GROUND pins. That would make the KBDRST
> the one adjacent to the first ground pin, the KBDRD the middle of the
> three, and the KBDTXD adjacent to one of the +5V pins.

Not looking at it just now, but yes it's something very much like that. The grounds are a row and the +5v lines are a column on one side, leaving RST and the tx/rx pair in one corner of the connector.

> > That's the plan. I believe the connector is something called sdl.
> > The old pc keyboard used a six pin connector to hook the cable up to the
> > keyboard. This one uses an 8 pin one. It's something like a modular
> > plug with contact edges along the top, but also a shielded shell. It's
> > flatter and wider than an RJ, with catches on the sides instead of on
> > the bottom. I'm not absolutely sure of this but I can order a couple of
> > the connectors and try it. Not yet sure how I'll get them crimped on to
> > a cable, though. I don't have the original cable that went to the
> > computer, but in pictures they look D-shaped on the system end.
>
> So -- this is a female connector on the keyboard itself, instead
> of on a cable.

Unfortunately so. :)

> I'm thinking that the transmit bursts are short enough (high
> baud rate) so the chances of a collision with the mouse signals is
> minimal. Perhaps the mouse signal is sent through a gate which is
> turned off when the keyboard is about to transmit a keystroke. (Likely
> turned off just long enough before so a mouse signal could complete or
> time out before the keyboard character or characters were sent.)
>
> Anyway -- you should expect the keyboard end of the 3B1 cable to
> be the same as the computer end -- no crossing of pins between the ends.

Previous experiments also show this to be the case.

Chris

[Convergent MightyFrame]

Chris, or all:

Thank you for your contribution here!

> KBDTXD --> JK-7
> GROUND --> JK-1,2,3
> +5V --> JK-4,8
> KBDRST --> JK-5
> KBDRD <-- JK-6

Now, on an older-skool PS2 keyboard, there is a clock and a data pin. I'm wondering if you might have some insight onto how these translate:

I'm guessing that KBDTXT is equivalent to the "Data" pin on the PS2.

But what about KBDRST and KBDRD? Would either of those be equivalent to the PS2's clock signal?

I'm just starting to dive into "mapping" what one of these keyboards sends on each keypress, with the hope of emulating one of these for a UNIX PC if one gets a UNIX PC without the more rare factory keyboard.

http://unixpc.blogspot.com/2017/03/at-unix-pc-keyboard-signal-decoding.html

As soon as I can get some experiments of my own going, I'll report back here also.

Thanks again!
-AJ

[DoN. Nichols]

On 2017-03-29, Convergent MightyFrame <mighty...@gmail.com> wrote:
> Chris, or all:
>
> Thank you for your contribution here!
>

>> KBDTXD --> JK-7 # keyboard transmit data (from kdb to comp)
>> GROUND --> JK-1,2,3 # Ground
>> +5V --> JK-4,8 # and Power
>> KBDRST --> JK-5 # Keyboard reset
>> KBDRD <-- JK-6 # Keyboard read data (from computer to keyboard)

> Now, on an older-skool PS2 keyboard, there is a clock and a data pin.
> I'm wondering if you might have some insight onto how these translate:

> I'm guessing that KBDTXT is equivalent to the "Data" pin on the PS2.

You mean KBDTX*D*, not *T*. Yes, it is the data from keypresses
to the computer.

> But what about KBDRST and KBDRD?

Keyboard reset -- returns things like caps-lock and num-lock
to default conditions.

Keyboard *read* -- data from the computer to the keyboard. can
be used for setting CAPS and NUMLOCK automatically, or to make sure that
they are as a program expects. And, can be used to force a key to send
a different code, sometimes.

> Would either of those be equivalent
> to the PS2's clock signal?

Nope!

The keyboard signals which you listed are sent out at a constant
data rate, set to match what the computer expects.

In the PS-2 (and some other devices) you get a pulse out of the
clock pin with each data bit -- and this clocks the data into a shift
register, so once enough pulses have occurred, the whole byte is in the
register, and can be read at a single computer operation. The other
keyboard has serial port interface chips -- a 1602 UART (or similar) on
older systems, or a Motorola ACIA chip (MC6850) on some systems. UART
stands for Universal Asynchronous Receiver/Transmitter, and ACIA I forget
the expansion for -- but it is for serial ports, just as the UART is.
I've used both for various systems. I forget whether the 7300 has a
MC68650 ACIA or a 1601 UART, but either could be used for the task with
somewhat different wiring in the computer.

> I'm just starting to dive into "mapping" what one of these keyboards
> sends on each keypress, with the hope of emulating one of these for a
> UNIX PC if one gets a UNIX PC without the more rare factory keyboard.

For the PS/2 keyboard, you will need to get a shift register of
the proper number of bits (8, 10, 16?, not sure) and wire it so the clock
pulses out of the keyboard clock the data into the shift register.

And for the other direction -- I *think* (but don't know for
sure) that the computer needs to provide the clock pulses after writing
the necessary data into the shift register. The, with the right codes
written, you will see the CAPS-LOCk LED or the NUM-LOCK LED turn on or
off.

You could then set up the shift register to transfer data to a
UART (the ACIA would need a small computer to run it) and send that to
the 7300. Now, you may need a ROM to translate the codes from the PS/2
keyboard to what the 7300 wants, if it is possible at all.

You might be able to use something like a Rasberry Pi to do the
whole conversion, but that happens to have much more modern Linux system
inside it, so is truly overkill. :-)

Or -- for that matter, you could plug a USB keyboard into the
Rasberry Pi and let it do the necessary translation and emulation.
(Beware to change the default password for the default user "Pi",
because it is the same everywhere, and if you connect it to the net,
someone *will* break in eventually. I see such attacks from time to
time -- and did even before I Had a Raspberry Pi.

> http://unixpc.blogspot.com/2017/03/at-unix-pc-keyboard-signal-decoding.html

> As soon as I can get some experiments of my own going, I'll report
> back here also.

O.K. Do you have an oscilloscope? Ideally a two-channel one?
You can look at the clock pulses on one channel and the data pulses on
another. Set the trigger to channel A (or 1) and connect that to the
clock pin, and connect the data to channel B (or 2). Set the timebase
so the burst of clock pulses is about the width of the screen, and be
sure to set up the two channels for "chop" mode, not "alt" mode, so you
see the clock pulses and the data pulses. You can then count data
pulses related to the clock to work out what code is sent by which key.

Good luck,