IBM 1386887 (3179 terminal) keyboard conversion

[quadibloc]

This suggests to me that PS/2s might not support set 3 at all (perhaps designed not to),

That sounds really weird to me, because my understanding is that the first PS/2 computers actually came with keyboards that only handled Scan Code Set 3, and it was only later that IBM made 101-key keyboards that were compatible with their older computers like the AT after intense popular demand.

So really old computers would not support Scan Code Set 3. Also, some cheaper off-brand keyboards don't handle Scan Code Set 3 properly, which causes problems in Linux, because it tries to use Scan Code Set 3 by default (because it works more simply with a 101-key keyboard, without extra codes because the keyboard is pretending to be an 84-key AT keyboard).

[JohnElliott]

This suggests to me that PS/2s might not support set 3 at all (perhaps designed not to), and that we just happen to be lucky that modern equipment does by some odd fluke.

The thing is that the set 2 and set 3 codes are the same for all the alphanumeric keys. So unless OS/2 had switched the previous keyboard into set 1, I don't think that could account for the problems you were experiencing.

[quadibloc]

The thing is that the set 2 and set 3 codes are the same for all the alphanumeric keys.

Surprisingly enough, on a 122-key keyboard, they're the same for all keys. But that doesn't necessarily help, because if a computer doesn't recognize Scan Code Set 3, it isn't going to attempt to understand the codes - it would just give up on the basis that the attempt to get the keyboard to use a set it could recognize failed. The problem would not be giving the keyboard more codes, it would be getting it to acknowledge a request to change to Set 2.

[JohnElliott]

Surprisingly enough, on a 122-key keyboard, they're the same for all keys. But that doesn't necessarily help, because if a computer doesn't recognize Scan Code Set 3, it isn't going to attempt to understand the codes - it would just give up on the basis that the attempt to get the keyboard to use a set it could recognize failed. The problem would not be giving the keyboard more codes, it would be getting it to acknowledge a request to change to Set 2.

That wouldn't explain the phenomenon as reported (disconnect a working 102-key keyboard, connect a 122-key keyboard, keystrokes produce gibberish). The computer would have had to detect that the keyboard had been hotplugged, tried to reinitialise the keyboard and select set 2, failed, and decided to produce random characters in a fit of pique (rather than disabling the keyboard or reporting an error).

[o2dazone]

Just an FYI, on Windows based machines, I use KeyTweak and use ctrl+alt+del to login (on a 64 bit system). Because the scancodes were done via registry, I have no problems (for example, on a normal layout I rebound capslock to ctrl, logging in would require I hit capslock+alt+delete). I know you're referring to Key Mapper, but I thought I would share my experience

[kishy]

o2dazone, I'm more or less just preventing POSSIBLE issues (and sort of saying "you've been warned if it doesn't work")...the map I've provided is supposed to be applied during login so at the login screen it shouldn't be in effect (meaning your hopefully-also-connected USB keyboard will still work).

The pre-remap key combo for CTRL ALT DEL on this board is CapsLock + LeftCTRL + Numpad decimal. Though, since numpad decimal is one of the keys that does not send a break code, this might be problematic for some people (it isn't for me, but could be depending on variables that I don't even know about).


JohnElliott and quadibloc
The gibberish I typed was, just to be clear, not in any way accurate (so don't try to follow a pattern). It appeared on the screen for a very short time before it crashed so I couldn't see in detail what anything was. There were however several accented characters.

I don't know the technical details of...well...almost anything we're dealing with here. I guess I'll leave it to you guys to figure out exactly what it means when I discover something, lol.

[dw_junon]

OK. I'll write it up on my website, but in brief:

• Switches 1-6 control bits 5-0 of the first keyboard ID byte (bits 7-6 are always 1,0). So in their default position where they're all open, the first ID byte is 10111111 (0xBF). If you close one or more, the corresponding bit goes to 0. Close switch 1 and you get an ID of 0x9F 0xBF, and so on.
• Similarly, Switches 7 and 8 control bits 5 and 4 of the second keyboard ID byte.
• And therefore I'd guess that, with 12 sets of pins and 8 switches, the remaining four sets of pins are used to set the low 4 bits of the second ID byte.

I've now checked my 1390876 as well. The B2-B7 headers correspond to the low 6 bits of the second ID byte in the same way, and I'm sure if my board had headers on A2-A7 they'd affect the first byte too.

I had to leave abruptly last night, hence my previous silence.

Thank you so much, I've been wondering about this for some time.  So it should therefore be possible to set the "normal" ID of 0xAB 0x83 [10101011 10000011] with the following settings:

Code: [Select]

KBD ID A 2 - NO JUMPER [SW 1 OFF]
KBD ID A 3 - JUMPER    [SW 2 ON ]
KBD ID A 4 - NO JUMPER [SW 3 OFF]
KBD ID A 5 - JUMPER    [SW 4 ON ]
KBD ID A 6 - NO JUMPER [SW 5 OFF]
KBD ID A 7 - NO JUMPER [SW 6 OFF]

KBD ID B 2 - JUMPER    [SW 7 ON ]
KBD ID B 3 - JUMPER    [SW 8 ON ]
KBD ID B 4 - JUMPER
KBD ID B 5 - JUMPER
KBD ID B 6 - NO JUMPER
KBD ID B 7 - NO JUMPER

I will test various behaviours of the 1389260 and the 1387033 (any regulars with good memory and eagle eyes, yes it is that one) with this configuration versus without (I will have to borrow the cable from my AT as John E. did).

Note also that that area of the PCB looks identical on the 84-key Model F, down to the "KBDID A" and "KBDID B" markings, and the extra pair of pins beyond them. But on that model, the schematic at kbdbabel.org shows that pins B5, B6 and B7 are now used to drive the LED panel.

This is an interesting detail, I do recall seeing that on the PCB of my 6450225 but never considered this comparison.  I will have a play with that too since I will have to open the case.


~~~


For the record, I don't have low-level Windows programming experience.


~~~

Regarding 1386887 usage on a PS/2 56SX:

Code 301 on POST (keyboard not responding or stuck key)

I would consider blaming the 301 on the keyboard ID the 1386887 reports, particularly if both it and the Model 56 are otherwise working well.  See above...

Then, I swapped out the keyboard for the terminal board, and proceeded to type "This sentence is being typed on a 1986 1386887."

The problem was that the sentence came out looking something similar to "#R@#$T$^^*&^%*$&^&^%::::"'';;;';,..,,<>$#%", at which point it crashed (see blurry attachment).

This suggests to me that PS/2s might not support set 3 at all (perhaps designed not to), and that we just happen to be lucky that modern equipment does by some odd fluke.

I'm not sure that that's a logical conclusion.  From the evidence I don't see how we can tell for sure whether the gibberish is a hardware or software problem, never mind exactly what is failing, complaining or just plain going mad.  A comparison using a basic DOS boot disk with added EDIT.COM might help.  This said, I'm not sure I would recommend hotplugging the keyboard on a real PS/2.

There is also the history which suggests otherwise.  As we have been discussing, set 3 was already in use in terminal products prior to the PS/2 launch in '87; according to the "IBM 7531/7532 Industrial Computer Technical Reference System Unit", first edition July 1985, set 3 was supported by their 101 and 102 key 'boards, the design of which was then used on the 5170 AT proper, and then became the standard for the PS/2.  Not to say that there were definitely no changes; at some point the additional mode providing XT support was dropped from the 101/102s, whether this was with the introduction of the '401 or later is unclear.

That sounds really weird to me, because my understanding is that the first PS/2 computers actually came with keyboards that only handled Scan Code Set 3, and it was only later that IBM made 101-key keyboards that were compatible with their older computers like the AT after intense popular demand.

John Savard, wow, is that really you?

That's particularly interesting, I've never seen anything to suggest this with IBM 'boards.  I do however recall speaking someone in possession of two apparently non-working Compaq Enhanced II 'boards, which I believe were for the second generation of Compaq Deskpros; this may well have been the first machines to clone the PS/2 keyboard/mouse interface on-board (though they use the ISA bus and Compaq proprietary memory expansion).  If I remember correctly, when connected to a modern PC (possibly via USB) the LEDs would light but they would not function at all: that they used only scan code set 3 was my suggested explanation.  Unfortunately, I never did get my hands on one to test with my Deskpro 386s...


~~~

Reading through the above mentioned 7531/7532 tech ref's keyboard information, I have noticed something that may be significant: using the system-end command Select Alternate Scan Codes [0xF0] it is apparently "not possible to switch to set 3 from another set".  It may be possible for this event to occur when the 1386887 is hotplugged (as it likely supports only set 3) if set 2 was previously in use.

[kishy]

dw_junon

I will try those jumper settings; now that I know both keyboards are operational it wouldn't be the complete end of the world if something were to go wrong (but I doubt it would, since shorting those pins is the intention behind them existing to begin with). I don't imagine I would notice any difference on my Windows XP machine, but it is possible the PS/2 will detect it properly (with the right ID) so that'd be on the list of tests.

Logical conclusion it may not be, but like I said, it's how **I** took it...let's do please remember that I know nothing about this stuff except that which I'm learning via this thread. BTW I have now read at least one section on the link from a few posts back about keyboard signalling...while very helpful it doesn't correct my core lack of understanding of how the data actually gets sent and all that.

Will get back to you shortly about results with jumpers.

[JohnElliott]

Making the keyboard return a different ID may not help, if the PS/2 BIOS is (eg) testing the ability to select scancode sets...

[kishy]

Well, PS/2 POSTed just fine:)

Problem is, well, it's still typing gibberish.

XP desktop: no noticeable differences whatsoever, but it certainly doesn't hurt to be using "the correct" ID for the job so I'll put the jumpers on the second one as well.

http://img190.imageshack.us/img190/8563/1386887ps2gibberish.jpg

retrospective edit:
the find menu is open because a key combo opened it, for the record

[JohnElliott]

Problem is, well, it's still typing gibberish.

Is there any consistent pattern between what you type and what appears? For example, if you press Q does it always come out as (say) Y?

[quadibloc]

That wouldn't explain the phenomenon as reported

You're quite right. I should have reviewed the earlier posts more carefully.

However, it should be noted that hot-swapping a keyboard with a PS/2 connector is generally viewed as a good way to fry motherboards - and so it is very much not recommended.

[kishy]

Is there any consistent pattern between what you type and what appears? For example, if you press Q does it always come out as (say) Y?

There is a pattern, but the machine still hangs after hitting certain keys...determining a key-by-key map would be very difficult and time consuming. That said, I will do it if you think it will help in some way.

However, it should be noted that hot-swapping a keyboard with a PS/2 connector is generally viewed as a good way to fry motherboards - and so it is very much not recommended.

I'm very well aware of this, but until this "not working after boot" issue is resolved, it is impossible to use it otherwise.

I don't want to do anything with a switch/button like I've previously suggested until someone gives their opinion of interrupting the DATA line instead of the 5V line, pros and cons of either, etc. If it's functionally the same as hotplugging and still carries the risk of damage I see no point in modifying the keyboard case to accommodate it (yet).

[JohnElliott]

There is a pattern, but the machine still hangs after hitting certain keys...determining a key-by-key map would be very difficult and time consuming. That said, I will do it if you think it will help in some way.

It's mainly for curiosity's sake. My example, Q -> Y, is what you might get if the computer was expecting Set 1 codes and receiving Set 2 or Set 3.

I did manage to get Windows 2000 working with the 1390876 today, with no KVM switch. It involved building a custom version of the keyboard driver. Not ready for prime time yet, but who knows?

[kishy]

I'd be very interested in trying that driver (XP and 2k use identical driver models as I understand it).

Would you be willing to let me try it?

(as a result of your, in my opinion, HUGE success from that post I will not be attempting anything with any kind of button or switch because my goal has always been for this to be completely undoable and drilling a hole in the keyboard is certainly not undoable...I'll wait to see my own successes with your driver, assuming you will let me try it)

[JohnElliott]

PM sent.

[quadibloc]

I would just like to note that my 122-key keyboard, which worked with older versions of Windows, does work normally with Windows XP (I'm typing with it now), even though it is no longer possible, apparently, to replace the 101/102-key keyboard driver with a 122-key keyboard driver for it. So the problem is indeed with the conversion, and isn't a fundamental incompatibility between a normal 122-key keyboard and Windows XP.

[kishy]

I've been using John's modified driver for a couple hours now and...well...he might be a little mad about me releasing this info, but IT IS PERFECT.

(edit: actually, it's not perfect, since making the post I've learned from John exactly what the remaining issues are)

John, if you want this edited out for now, I will...just say the word.

(I suspect John knows about a bug I haven't discovered yet which is why he doesn't want to put it out there)

[dw_junon]

Making the keyboard return a different ID may not help, if the PS/2 BIOS is (eg) testing the ability to select scancode sets...

Indeed not, it could be considered analogous to be lying only to be found out (and in worse trouble) later.  This said, it has since occurred that it might be worth examining the effects of using of using IDs as used by compatible 122 keyboards such as 0xAB 0x85 and 0xAB 0x86 [source]; this may be helpful PS/2-wise since the Host Connected 'boards were supported products, though obviously there may be sufficient differences in the keyboards that this is in no way beneficial.

I did manage to get Windows 2000 working with the 1390876 today, with no KVM switch. It involved building a custom version of the keyboard driver. Not ready for prime time yet, but who knows?

That's fantastic.  Perhaps I am naive, but I'd suspect that this would ultimately be appreciated very much more widely than this forum topic.  Great news, thank you for your efforts!

Amusingly perhaps, I don't actually possess a machine running a Win NT family OS at the moment...


~~~

Here is an interesting piece from the Ardent Tool from which speculative conclusions could be drawn regarding scan code set 3:

Incompatible IBM Keyboard
From Charles Lasitter
   Part 84G2524 / FRU 84G2529, mfg date 09/28/99, vendor: Unicomp; IBM has managed to do the unthinkable.  It now makes PS/2 input devices that can't stand the sight of real PS/2 equipment.
   Specifically, keyboards made by this vendor for IBM work great in crAptivas, but don't like Model 77s, 95s, and so on.  Generates the "301" keyboard error right away in the Model 95 computers, and generates nonsense keyboard output attached to a Model 77.

Original source alas offers no further detail.


~~~


My testing has been somewhat limited due to some sort of protocol that requires the house not to be covered with bits of keyboard when visitors are present.

Here follows the results of the limited testing, which involved an elderly Dell Dimension XPS T-xxx, with a Dell version of the Intel 440BX chipset IIRC.  The machine was set up with a choice of xubuntu and Win 98SE selectable via grub, though the 98SE setup CD-ROM was used for the DOS testing.

Code: [Select]

P/N KBD ID Interface grub xubuntu login DOS 7
1387033 0xBF 0xBF * PS/2 ok?¹ did not function² good³
1387033 0xAB 0x8F § PS/2 ok?¹ did not function² good³
1387033 0xAB 0x8F § USB / PS/2 ¤ ok?¹ did not function² good³
1389260 0xAB 0x83 PS/2 good key up issue good
1389260 0xAB 0x83 USB / PS/2 ¤ good key up issue good
1389260 0xBF 0xBF PS/2 good key up issue good


* All DIP switches were off; ID is supposed from convention and in no way
tested or confirmed.

§ DIP switches were set as described [url=http://geekhack.org/showpost.php?p=109782&postcount=67]here[/url].  The remaining two pins were not
jumpered as they were very difficult to reach.

¤ Neither terminal keyboard would function via USB when the computer's
QuietKey 'board was also connected via PS/2, though the PS/2 connected
'board would function.  USB results therefore are for the terminal 'board
being the sole keyboard attached.

¹ Could not reach the grub command prompt due to lack of escape key for
complete character testing, however single keys command for the grub menu
functioned successfully.

² No response at all from any keypresses.

³ Ctrl, Alt and Caps Lock keys did not seem to function, though this may
be due only to layout / scan code differences.  Alphanumeric, shift and
function keys functioned as US 84 key AT.

The key up issue is the infinite repeat of characters from keystrokes as a result of lack of key up scan codes as previously described in this topic.

Testing on PS/2 models 70 and 95 will follow, I hope.  Testing on the 7531 AT is possible too.  All perfectly possible with sufficient spare time and moving of stuff.

I took some pics, mostly useless but at the very least serve as a personal reminder.
A source of jumpers...
Cable detached from the 6540225
Opening the 1389260
The AT's cable isn't going to fit through the cable hole on the 1389260...
...so I ran it through the blanked hole for the DIP switches.
1389260 okay at grub prompt...
..and in DOS EDIT.COM.
The chassis of the 1387033 is riveted...
...check the other side to be sure...
...so the PCB is effectively stuck, making the Berg strip difficult to reach.
1387033 in EDIT.COM

[kishy]

I would test with Win95 on my 56 SX if it weren't for the following complications:
-no easily accessible SCSI hard drive
-PITA to swap hard drives on a PS/2
-PITA to install Win95 from floppies
That would either solidify the "machine does not support Set 3" thing, or alternatively it could reveal that it is simply OS/2 which doesn't support it (not definitively, but close enough for our purposes I'd say).

Without any remapping, I found the following (going from memory, I didn't end up writing these down):
-caps lock functions as CTRL
-Left CTRL (aka Reset) functions as Left ALT
-Right CTRL (aka Enter) functions as Caps Lock
-Num Lock (aka no label) functions as Esc
-Numpad / (aka no label) functions as Num Lock
-Numpad . is the only delete key on the board
-Cursor can only be moved with numpad cursor keys;
    (and of course, left arrow is same as yours, backslash)

Seeing as yours is the, uh, "space saver" (if ever there was one) you obviously can't check out the numpad-related stuff, but I'd expect it to be the same (though again I don't know a whole lot in this area).

Yay, someone still has a VLB card out there.



Edit: hey John, I noticed something...you identify your keyboard(s) as being for a 3197, whereas mine are 3179. Is that a typo of yours or do 3197 and 3179 both use the same keyboard type?

[JohnElliott]

hey John, I noticed something...you identify your keyboard(s) as being for a 3197, whereas mine are 3179. Is that a typo of yours or do 3197 and 3179 both use the same keyboard type?

The page I got the pinout from says 3197. Google Images appears to think that both types of terminal exist, and look quite similar. At the moment, I'm inclined to believe that a lot of IBM's terminal keyboards are interchangeable at the electrical level, with the differences being restricted to things like the keyboard ID and keycaps.

[dw_junon]

I would test with Win95 on my 56 SX if it weren't for the following complications:
-no easily accessible SCSI hard drive
-PITA to swap hard drives on a PS/2
-PITA to install Win95 from floppies
That would either solidify the "machine does not support Set 3" thing, or alternatively it could reveal that it is simply OS/2 which doesn't support it (not definitively, but close enough for our purposes I'd say).

What about a DOS ("Windows 95") floppy?  That said, those aren't so trivial to make these days.

Another possible scan code set 3 test might be an SGI, IIRC.  Does any one reading this have any SGI boxes?

Without any remapping, I found the following (going from memory, I didn't end up writing these down):
-caps lock functions as CTRL
-Left CTRL (aka Reset) functions as Left ALT
-Right CTRL (aka Enter) functions as Caps Lock
-Num Lock (aka no label) functions as Esc
-Numpad / (aka no label) functions as Num Lock
-Numpad . is the only delete key on the board
-Cursor can only be moved with numpad cursor keys;
    (and of course, left arrow is same as yours, backslash)

Yeah, as I think has been mentioned, this mostly follows the layout of the 84 key AT keyboard (I'm afraid my picture is of the UK variant, though it is similar enough that your list is consistent).

Seeing as yours is the, uh, "space saver" (if ever there was one) you obviously can't check out the numpad-related stuff, but I'd expect it to be the same (though again I don't know a whole lot in this area).

I should have better clarified what I was using.  The "space saver" is the 104 key, part number 1387033, which is for the 3290 terminal.  The other keyboard I tested is the 122 key 1389260, for the 3179 terminal (though I believe it was used with the compatible 3180).  For what it's worth, there is a list of what I have available to test with here.

Indeed, not having the number pad on the 1387033 was very limiting in this case, however as I mentioned, the behaviour of other modifier keys was not consistent with either your, John E's, or my 122 key 'boards or consequently the 84 key AT layout.

Yay, someone still has a VLB card out there.

I was kindly offered that by a chap who sold me some 5¼" floppies.  I hope to be able to put it to its intended use some day...

Edit: hey John, I noticed something...you identify your keyboard(s) as being for a 3197, whereas mine are 3179. Is that a typo of yours or do 3197 and 3179 both use the same keyboard type?

The 3179 and 3197 are both real IBM system type numbers, I think this is correct.  Certainly confusing numbering though.

[dw_junon]

At the moment, I'm inclined to believe that a lot of IBM's terminal keyboards are interchangeable at the electrical level, with the differences being restricted to things like the keyboard ID and keycaps.

I have to agree.  The extensive list of types for the relevant kbdbabel adapter ["IBM 3151-3153/3179/318x/319x/34xx ---> PS2"] agrees more emphatically, though.

On reflection it seems like IBM was benefitting from standardised keyboards (in production) though the customers were not so much.

I will have to make time to go through the announcement letters one by one and make a record of exactly what exists (hopefully sooner rather than later while they still keep this old information on-line).

[kishy]

The page I got the pinout from says 3197. Google Images appears to think that both types of terminal exist, and look quite similar. At the moment, I'm inclined to believe that a lot of IBM's terminal keyboards are interchangeable at the electrical level, with the differences being restricted to things like the keyboard ID and keycaps.

Be sure to save that page for later reference if desired, Geocities is going byebye. Although your site might not be the best place for the info (since your pages focus on your hardware, not "compatible hardware") it would be nice ultimately to end up with some Google-accessible page somewhere that clearly indicates what is compatible with what and what is necessary to accomplish conversion.

What about a DOS ("Windows 95") floppy?  That said, those aren't so trivial to make these days.

Do you mean a boot floppy disk, or full bootable OS on floppies? (in the case of the second I didn't know they existed at all, the first is easy though...bootdisk.com)

Another possible scan code set 3 test might be an SGI, IIRC.  Does any one reading this have any SGI boxes?

I saw an SGI system on the local Kijiji classifieds sometime recently but didn't have IO making it appropriate for my hobbyist purposes so I passed on it.

Yeah, as I think has been mentioned, this mostly follows the layout of the 84 key AT keyboard (I'm afraid my picture is of the UK variant, though it is similar enough that your list is consistent).

That's my understanding, it does overlap very much. I figured instead of saying "well, it's a lot like the original AT board" and making you go reference the two together I'd just tell you some equivalent keys I found though

"space saver"

I've seen photos of that floating around the forum in my past looking around; I figured it was the one in question based on how short it looked in one or two photos from that list. I would LOVE that keyboard...I'd end up mapping numpad keys to the top cmd keys though, because a game I play frequently (Garry's Mod, check it out if you don't know it, fantastic fun physics game) uses numpad keys extensively for automated things you make in it (to some gamers, it's obscene...but I love buckling spring boards for gaming).

I was kindly offered that by a chap who sold me some 5¼" floppies.  I hope to be able to put it to its intended use some day...

If you need a VLB motherboard, I have one somewhere. Last I tried I couldn't get the jumpers set right, tricky to find info for, but I'll tell ya what...it's yours for the cost of shipping if you want it.


I have a pack of never opened 5.25" floppies with a lifetime replacement guarantee...I wonder if the manufacturer, Fujifilm, is prepared to follow through with that?

[Hak Foo]

What about a DOS ("Windows 95") floppy?  That said, those aren't so trivial to make these days.

Vista makes a WinME boot floppy, very easy.

[Rajagra]

Vista makes a WinME boot floppy, very easy.

Who says MS doesn't have a sense of humour?

[dw_junon]

Do you mean a boot floppy disk, or full bootable OS on floppies? (in the case of the second I didn't know they existed at all, the first is easy though...bootdisk.com)

The former; I neglected to include the word "boot".  Oops.  A whole DOS is feasible enough on multiple floppies with swapping on demand... a whole Win95 probably less so.

I was thinking more along the lines of "sys A:", and my concern was that most people probably don't have a 3.5" floppy drive and the requisite media any more.  Not that we count as most people in this respect...

That's my understanding, it does overlap very much. I figured instead of saying "well, it's a lot like the original AT board" and making you go reference the two together I'd just tell you some equivalent keys I found though

Ah, righto.

I've seen photos of that floating around the forum in my past looking around; I figured it was the one in question based on how short it looked in one or two photos from that list. I would LOVE that keyboard...

Yes, it is that exact same one I think, the seller reduced the price by 50%, I couldn't resist...  To think I only mentioned it here in the first place as an example of a weird obscure variant...  If you really want one, Argecy has them, fully refurbished with warranty, unlike mine; untested with cracks to the upper casing and two springs requiring reseating (though with all that said, it's fine).

(Garry's Mod, check it out if you don't know it, fantastic fun physics game)

Will do.

If you need a VLB motherboard, I have one somewhere. Last I tried I couldn't get the jumpers set right, tricky to find info for, but I'll tell ya what...it's yours for the cost of shipping if you want it.

That's very kind, but I think will have to pass.  If you have any spare time or space for sale, I might consider.

I have a pack of never opened 5.25" floppies with a lifetime replacement guarantee...I wonder if the manufacturer, Fujifilm, is prepared to follow through with that?

I think there should be a web site for this sort of thing.  I think I have some Inmac floppies with a similar guarantee.  Various antique warranty cards to send in...  I do recall someone on the PS/2 newsgroup trying to get such a warranty honoured on something or another, but as you can tell I can't remember the details.

Vista makes a WinME boot floppy, very easy.

As above, my concern is whether the typical Vista user has the floppy drive.

Who says MS doesn't have a sense of humour?

I expect we all know about this, but anyway: compare the output of ver in XP's command with command/c ver.

[kishy]

Vista makes a WinME boot floppy, very easy.

Eh...do we know how well Vista-generated boot floppies work? I for one have never messed with one.

Who says MS doesn't have a sense of humour?

Would be nice if Windows Fundamentals for Legacy PCs would actually work on legacy PCs...

Humourous in a sort of cynical way.

The former; I neglected to include the word "boot".  Oops.  A whole DOS is feasible enough on multiple floppies with swapping on demand... a whole Win95 probably less so.

I was thinking more along the lines of "sys A:", and my concern was that most people probably don't have a 3.5" floppy drive and the requisite media any more.  Not that we count as most people in this respect...

I didn't think such a thing as "bootable Windows 95 on floppies" existed, but of course I'd want it if it did.

3.5"? I hope you don't doubt me...
I have a stockpile of 5.25" drives ready for the future when they become incredibly rare...and a stack of disks as well. Never know where a hobby will take you, and some day I hope to track down an XT.

If you really want one

Well...generally speaking, my ideal price to pay is free. As you can see, that's a problem. I'm quite content with my two full sizers though.

In all seriousness, what do we think about painting the case black, putting silver paint in the little molded-in line that goes around the outside of the key area, putting blue backlighting under all the keys and then red backlighting for the lock keys (assuming I/we figure out how to get LEDs connected to the locks)?

That's very kind, but I think will have to pass.  If you have any spare time or space for sale, I might consider.

Two things I'm short on...well, tons of time, no patience, so the equivalent of no free time haha.

I think there should be a web site for this sort of thing.  I think I have some Inmac floppies with a similar guarantee.  Various antique warranty cards to send in...  I do recall someone on the PS/2 newsgroup trying to get such a warranty honoured on something or another, but as you can tell I can't remember the details.

More or less, I guess I'm wondering...is there a factory anywhere in the world that still produces 5.25" floppies?

If so, to what lengths would Fujifilm go to obtain those disks for me? lol.

As above, my concern is whether the typical Vista user has the floppy drive.

Valid concern; the majority of computers that ship with Vista do not have them. They either have a card reader or nothing; some don't even have externally accessible 3.5" bays. Tsk tsk; what if you had a Zip drive? Those aren't completely outdated, yet.

I expect we all know about this, but anyway: compare the output of ver in XP's command with command/c ver.

I don't know about it, but perhaps I've missed something / fallen for a prank: command /c automatically closes upon opening, thus you can't type a command in it.

[JohnElliott]

Spent some time experimenting with the 1390876 last night when I should have been sleeping.

I think what's making it hang with the standard Windows driver is that when it's reset, it sends AA like a standard keyboard, and then a little later sends BF BF.

The other thing, which is something of a nuisance: it looks as if it allows any given key to repeat, or send make/break codes, but not both at the same time.

[kishy]

Spent some time experimenting with the 1390876 last night when I should have been sleeping.

I think what's making it hang with the standard Windows driver is that when it's reset, it sends AA like a standard keyboard, and then a little later sends BF BF.

The other thing, which is something of a nuisance: it looks as if it allows any given key to repeat, or send make/break codes, but not both at the same time.

"Somewhat of a nuisance" seems to be an understatement; it seems to me there's no way to counteract that unless there was a way to make the computer interpret all keys as being typematic until it receives a break code (which apparently is not how it works already, otherwise typematic repeat would be working).

Problem with what I just proposed is that you would likely end up with accidentally repeated keys everywhere because it would instantly repeat with no real delay (at least so it seems to me).

[JohnElliott]

"Somewhat of a nuisance" seems to be an understatement; it seems to me there's no way to counteract that unless there was a way to make the computer interpret all keys as being typematic until it receives a break code (which apparently is not how it works already, otherwise typematic repeat would be working).

Problem with what I just proposed is that you would likely end up with accidentally repeated keys everywhere because it would instantly repeat with no real delay (at least so it seems to me).

You'd have to set all the keys to send make/break codes, and do typematic in software. Maintain a counter for each key, which gets set to a delay when a key is pressed. Every so often, subtract 1 from all the counters, and when one hits zero simulate another keypress and reset the counter.

[InSanCen]

I didn't think such a thing as "bootable Windows 95 on floppies" existed, but of course I'd want it if it did.

It does...

I'll see if I still have mine stashed away somewhere.

If I do, you're welcome to it, just pay shipping.

The Windows 1 (MS-DOS Executive!) however, is all mine! mwahahahaha...

[kishy]

You'd have to set all the keys to send make/break codes, and do typematic in software. Maintain a counter for each key, which gets set to a delay when a key is pressed. Every so often, subtract 1 from all the counters, and when one hits zero simulate another keypress and reset the counter.

It does sound to me like it'd work, doing it like that, but embarrassingly the only languages I really know are VB and Turing...the first being rather high-level (and I don't really know the hardware interaction part of it) and the second being rather useless.

It does...

I'll see if I still have mine stashed away somewhere.

If I do, you're welcome to it, just pay shipping.

The Windows 1 (MS-DOS Executive!) however, is all mine! mwahahahaha...

Are you sure we're talking about the same thing? I'm referring to somewhat of a RAMdrive-based Win95, no hard drive needed.

Would disk images be a possibility? I have tons and tons of floppy disks.

[JBert]

The more I read here, the more I start to think that a protocol converter could work more reliably. At least you could then let the uC handle all the weird protocol stuff instead of messing around with faulty Windows drivers.

It takes some guts and time to build one though...

[kishy]

The more I read here, the more I start to think that a protocol converter could work more reliably. At least you could then let the uC handle all the weird protocol stuff instead of messing around with faulty Windows drivers.

It takes some guts and time to build one though...

At some unknown point in the future I will be making a kbdbabel protocol converter, but before that is possible I need someone who knows about uC programming and all that...and of course parts.

I have a very low budget and while I'm completely willing (and wanting) to make one, I need to know every single step before I buy anything for it...I won't even try it until I'm confident I can do it.

[dw_junon]

In all seriousness, what do we think about painting the case black, putting silver paint in the little molded-in line that goes around the outside of the key area, putting blue backlighting under all the keys and then red backlighting for the lock keys (assuming I/we figure out how to get LEDs connected to the locks)?

Personally that sort of style doesn't appeal, but go for it.  You would have something unique even by this forum's standards.

More or less, I guess I'm wondering...is there a factory anywhere in the world that still produces 5.25" floppies?

Athana still manufacture 8" floppies.

Tsk tsk; what if you had a Zip drive? Those aren't completely outdated, yet.

I have an external Zip 250 from University only a few years ago, where the vast majority of PCs had the internal drives.  This was a useful method of data transfer between my account and my own PC which was not on the network.  I haven't used Zip since, though.

perhaps I've missed something / fallen for a prank: command /c automatically closes upon opening, thus you can't type a command in it.

It really wasn't intended as a prank (at least, not that sort of a prank).  In the command window you've just checked the output of ver in, command/c ver will open a secondary instance of command just to output ver and indeed, immediately exit.  This way the comparison is easy to make, too.

I think what's making it hang with the standard Windows driver is that when it's reset, it sends AA like a standard keyboard, and then a little later sends BF BF.

Thank you again for your investigative work.  Could this behaviour be upsetting the PS/2 perhaps?

"Somewhat of a nuisance" seems to be an understatement; it seems to me there's no way to counteract that unless there was a way to make the computer interpret all keys as being typematic until it receives a break code (which apparently is not how it works already, otherwise typematic repeat would be working).

Problem with what I just proposed is that you would likely end up with accidentally repeated keys everywhere because it would instantly repeat with no real delay (at least so it seems to me).

You'd have to set all the keys to send make/break codes, and do typematic in software. Maintain a counter for each key, which gets set to a delay when a key is pressed. Every so often, subtract 1 from all the counters, and when one hits zero simulate another keypress and reset the counter.

I wonder why nested quotes don't work with the automatic quote function...

Putting the typematic functionality into software is intruiging (and hey, you could really play with the repeat rate...).  On the face of it, it sounds like it could work to me, though alas I could not currently implement this myself either.

[keyb_gr]

I wonder why nested quotes don't work with the automatic quote function...

This is probably done to avoid quoting clutter, under the basic assumption that most people wouldn't be able to handle multiple quoting levels in a sensible way. Makes me wonder how I got along on Usenet then.

[kishy]

Personally that sort of style doesn't appeal, but go for it.  You would have something unique even by this forum's standards.

That's what I was aiming for
Black/silver would go with my desktop PC and monitor (as I am now using the monster keyboard as my main desktop keyboard; the lack of typematic repeat doesn't bother me).

Backlighting is just to make it competent with mods other people have done to boring rubber dome keyboards.

Athana still manufacture 8" floppies.

Oh my...

useful method of data transfer

Indeed, until the advent of large capacity cheap USB storage of course. Zip still has a valid use in certain legacy situations I think, but almost anything that can use a Zip drive could also use USB, so that I suppose is why it faded into obscurity. I have a Zip 100 drive, no disks, would sell it but I keep getting this weird feeling like someone is going to ask me to recover files from zip disks.

It really wasn't intended as a prank (at least, not that sort of a prank).  In the command window you've just checked the output of ver in, command/c ver will open a secondary instance of command just to output ver and indeed, immediately exit.  This way the comparison is easy to make, too.

OH I SEE WHAT YOU MEAN
Why did they do that; did they seriously not update command.com since MS-DOS 5?

Thank you again for your investigative work.

I second that; John you've been an amazing and I strongly suspect we'd have made very little progress without you (at least I would have been stuck clueless; I probably would have just opted to go head first into a kbdbabel build and say screw it halfway through).

I wonder why nested quotes don't work with the automatic quote function...

I've noticed this also, it's terribly annoying.

Putting the typematic functionality into software is intruiging (and hey, you could really play with the repeat rate...).  On the face of it, it sounds like it could work to me, though alas I could not currently implement this myself either.

I'll put it on the list of things to try at an unknown time in the future; anybody else who feels confident they can should by all means do it because I won't be trying any time soon (don't even have visual studio installed).

[quadibloc]

It does...

I'll see if I still have mine stashed away somewhere.

Bootable, not installable. Yes, Windows 95 could be installed from floppy disks (formatted in a nonstandard way which got more on the floppy, as well as preventing copying).

But Windows cannot be installed _to_ removable media so that you could actually run it from the floppies themselves instead of from a hard drive. (You click on "solitare", and the computer says "insert disk 7" so it can load and run solitaire.) That's what the other poster was talking about.

[kishy]

Bootable, not installable. Yes, Windows 95 could be installed from floppy disks (formatted in a nonstandard way which got more on the floppy, as well as preventing copying).

But Windows cannot be installed _to_ removable media so that you could actually run it from the floppies themselves instead of from a hard drive. (You click on "solitare", and the computer says "insert disk 7" so it can load and run solitaire.) That's what the other poster was talking about.

Other poster, sheesh, it's my thread

I did know there was a set of installation floppies; I have the disk images. Very irritating though because of the somewhat proprietary format. The disks I used for a Win95 install became pretty much useless upon being formatted back to 1.44 after; they just couldn't stand up to it.

Unrelated to terminal boards and win95:

My 1993 USA-built 1391401 has drainage channels and holes. It was not made by Lexmark. I've read some things floating around the forum which suggest drainage holes and channels were a Lexmark-introduced idea...but then why doesn't my keyboard say Lexmark?

My 1993 Mexican-built 1391401 has drainage channels but is in a case without holes (the bottom part of the channels were sliced off, apparently), and has a Lexmark sticker on the PCB. What gives?

[kishy]

1993 seems to be the year IBM decided to add drainage channels and holes to the Model M.  I also have a 1391401 with them.

Awesome, so I have just the right year then...my USA unit is still pre-Lexmark but has drainage channels. I don't plan to use them, of course, but I've been seriously tempted to pour a cup of water on it ever since discovering them...

The Mexican one not having holes is weird - I saw one with channels AND holes on clickykeyboards.

I called Unicomp before I got my 1386887s and asked if they had any info (I spoke with Jim, apparently that name is known around here)...he could find info on almost every terminal board there was but 1386887 was not in the list of part numbers (no record of it even existing, according to the documentation that got passed down to Unicomp).

During that call, I asked if there was anything special about Mexican Ms, and was told there wasn't...but that he believed the majority of units stamped as being from Mexico were probably factory refurbished since the bulk of the manufacturing was in the US.

The guts of my Mexican model M have a Lexmark sticker on them, but also a date indicating 1993 somewhere, I forget exactly what. I wonder if my unit was factory refurbished and they had to modify the guts to fit in the case because a case with holes was not available (keep in mind case itself is dated 1993 as well, so it would have to be pre-drainage-holes-introduction unless a new sticker was put on it).

Then again, it could be the school board who owned it before me, but I can't see why they would have done that.

[kishy]

Here's the link to the Mexican one.

Frankly, I find the Unicomp guys tend to talk down those "furriner" boards.  The one in the link looked mighty pretty to me.

At the point of bringing it up, he did kind of sound like "well why the hell would you care about those, just buy one from us" by his tone (did NOT say that directly and that is how I interpreted his tone; he easily could have not meant it that way).

Nice keyboard, nice nice. It doesn't look like the drainage channel design allows for very much liquid to be spilled all at the same time...let's say you slowly poured a cup of water on it, it would be fine...but if you just outright dumped it on it (as would happen if you knocked over a drink on your desk), it seems the water would come up and over the plastic tubes the keys fit in.

I've derailed my own thread.
Now about those mods...
For backlighting, what do we think works better:
a big EL strip run through the entire thing, or a piece of clear acrylic with holes drilled out for the keys covering the entire board then with LEDs along the sides?

[JohnElliott]

Just for the record, I've uploaded the source code for my driver patch to my 1390876 page. If you have a copy of the Windows 2000 DDK, this should let you build the modified driver.

There are no changes in functionality from the version kishy tested.

[kishy]

Just for the record, I've uploaded the source code for my driver patch to my 1390876 page. If you have a copy of the Windows 2000 DDK, this should let you build the modified driver.

There are no changes in functionality from the version kishy tested.

Thanks John, both for uploading it and for giving a hint at how to implement it.

Also for the record, the only issue I am finding (using XP Professional SP3 32-bit) is the lack of typematic repeat.

Then again, some people will consider the oddly-mapped keys an issue...I don't, because software remaps work fine. I'll be uploading (to this thread initially) my latest remap; it's much improved over the last one (someone somewhere might benefit from it being provided, so it will be).



edit:
Alright, I lied. There are other issues. I made some quick notes in notepad++ while testing all keys, found some things John might be interested in if he hasn't discovered them himself yet:

cmd24 = no break code

pressing cmd9 then cmd8 in that order is registered as "sleep" power key (by keyboardtest; windows doesnt react to it)

cmd9, 10, 11 behave oddly depending on the order you press them in - sometimes do not send break codes, sometimes do

"dup" key causes system beep; does not send break code
"ins" no break code

Please note - these were identified while using my remap
But the key names refer to the terminal layout

[JohnElliott]

F9 and F10 have scancodes 60 and 61, so on key-up they send E0 and E1. Windows is going to interpret those as extended keycodes. So:

F9-up F7 = E0 5E = power
F9-up F8 = E0 5F = sleep
F9-up F12 = E0 63 = wake

The solution (short of a wholesale rewrite of the keyboard driver) would be to have those keys not return break codes.

[kishy]

F9 and F10 have scancodes 60 and 61, so on key-up they send E0 and E1. Windows is going to interpret those as extended keycodes. So:

F9-up F7 = E0 5E = power
F9-up F8 = E0 5F = sleep
F9-up F12 = E0 63 = wake

The solution (short of a wholesale rewrite of the keyboard driver) would be to have those keys not return break codes.

Erm...don't you mean have them send break codes? I would expect that if they don't send a break code first they act like modifier keys, as you've described, but since they actually are not sending break codes as it stands that is why they behave like they do.

[Shawn Stanford]

I'd love to get a full set of those CMD (PF) keycaps if you have a set you will part with. PM me if interested.

[JohnElliott]

Erm...don't you mean have them send break codes? I would expect that if they don't send a break code first they act like modifier keys, as you've described, but since they actually are not sending break codes as it stands that is why they behave like they do.

No; it's the break code from F9 (and probably F10 as well) that's causing the trouble. Have them send make codes only and that particular conflict doesn't arise.

[kishy]

I'd love to get a full set of those CMD (PF) keycaps if you have a set you will part with. PM me if interested.

I don't even have two complete sets unfortunately (2 keyboards = desire for 2 sets) so I don't have any extras to spare. I'm sure somewhere out there someone does have some though.

No; it's the break code from F9 (and probably F10 as well) that's causing the trouble. Have them send make codes only and that particular conflict doesn't arise.

Odd...I believe you, but I find it odd. Those keys do not currently send break codes (intermittently, sometimes they do, it depends on the order you press the keys in) and it is when they don't send break codes that they serve the power functions.

Perhaps an example of theory not matching practice? idk.

[JohnElliott]

Odd...I believe you, but I find it odd. Those keys do not currently send break codes (intermittently, sometimes they do, it depends on the order you press the keys in) and it is when they don't send break codes that they serve the power functions.

They're sending the break codes, but Windows is getting to them before whatever program you're using does.