I received a Packard Bell Multimedia 550 and it came with Windows 95. The problem is that keyboard input was not coming through. Before it attempts to boot into Windows 95, it shows the safemode screen, and I cannot go up or down with the arrow keys or press any of the function keys. Every key does not work. But before it boots, the keyboard works completely fine. I thought it was a problem with Windows 95 itself, so I installed MS-DOS 6.22 via VirtualBox onto the hard drive directly. After a few attempts, it worked. I can type through the prompt just fine on my PC, but when I plug the hard drive into the Packard Bell and boot into MS-DOS, it simply does not work. I have also tried with another PS/2 keyboard that I know works, but when booted into MS-DOS, it simply does not work. Is this a problem with the PC? OS? Did me installing MS-DOS through VirtualBox maybe mess it up or install the wrong keyboard driver?
One thing I can say for certain: installing an earlier version of MS-DOS could not have made anything worse (or better, anyway). Both MS-DOS 6.22 and 7.x (the version built into Windows 95) rely on BIOS interrupt service 0x16 to access the keyboard. But that same thing also makes the fact that the keyboard is fully functional during the POST stage particularly puzzling.
Nevertheless, we can at least try to diagnose the issue though a serial connection. You will need a null modem cable to connect the Packard Bell to another computer (if your other machine only has USB ports, you will also need a USB-to-serial adapter) and a specially prepared DOS environment, which you may set up either by modifying the DOS configuration on your hard drive or by creating a dedicated bootable floppy. For the latter, use
format /s or
sys to make a floppy bootable and copy
DEBUG.EXE from your DOS installation (from
C:\DOS for MS-DOS 6 or
C:\WINDOWS\COMMAND for Windows 9x).0 Either way, at the end of the AUTOEXEC.BAT file on the disk put those two lines:
mode com1: baud=9600 data=8 parity=n stop=1 ctty com1:
If you had kept the Windows 95 installation you had there previously, you would also need to disable the automatic launching of the graphical interface, by editing the MSDOS.SYS file and adding a
BootGUI=0 setting in the
[Options] section. (With the dedicated floppy, this step is optional.)
Plug the null modem cable into the faulty computer’s serial port. On the other end of the cable, launch a terminal program (say, picocom) and configure the serial port settings to agree with the MODE settings above: 9600 baud, 8 bits of data, no parity, 1 bit stop. Now power on the Packard Bell, enter BIOS settings and ensure the serial port is enabled and that boot sequence will select the disk where you set up your specially-prepared DOS environment. Then let it boot into your environment: when it does so, the terminal program on other machine should display a DOS prompt you should be able to interact with.
On to the diagnosis. If you didn’t even manage this far despite correctly following all the above instructions, you may start suspecting the interrupt controller to be at fault. I don’t really know what to do with that, however.
Otherwise, launch the
debug command at the DOS prompt in the terminal: you should get a
- prompt, which you can quit by typing in the
Now, with the debug prompt active, enter the command
d 40:80 83. This is just a sanity check verifying whether the keyboard buffer is in the expected location in memory; it should output
-d 40:80 83 0040:0080 1E 00 3E 00 - ..>.
If this is not the case, you can try the command
e 40:80 1e 00 3e 00 which should restore the proper values.
Now enter the command
e 40:1a 1e 00 1e 00 to empty the keyboard queue and press some keys on the Packard Bell’s keyboard. Then verify that the keys you pressed were detected and written into the queue, by entering the command
d 40:1a 1d. You should get something like this:
-d 40:1a 1d 0040:0010 - 1E 00 3C 00 ..<.
The first two bytes of the dump being
1E 00 mean no keys have been read from the queue. The latter two being the same mean no keys have been written into the queue. If any keys have been written, you should verify that they were correctly identified. Run the command
d 40:1e 3d:
-d 40:1e 3d 0040:0010 - 71 10 q. 0040:0020 77 11 65 12 72 13 74 14-79 15 75 16 69 17 6F 18 w.e.r.t.y.u.i.o. 0040:0030 70 19 61 1E 73 1F 64 20-66 21 67 22 00 00 p.a.s.d f!g"..
The first of each pair of numbers in the dump is a character code (with the characters also displayed directly in the column on the right), while the second is the scancode. Consult the keyboard scancode table to see if the codes match the keys you pressed.
If no keys (or wrong ones) have been written into the queue, you can try toying with the keyboard controller directly and see if this fixes the problem:
- Reset the keyboard controller by issuing the command
o 64 aa. Performing a read
i 60should then return
55. Any other value means a self-test error.
- Toggle keyboard-enabling bits by issuing commands
o 64 aeor
o 60 f4.
After trying these commands, clear the key queue again and see if any keys get written into the buffer.
If by doing the above you managed to get the keyboard working, you can quit the
debug session by running the
q command and then execute the command
ctty con: back at the regular DOS prompt, which should return the DOS session under the control of the regular keyboard. But where to go from here, I don’t have much of an idea.
0 If you wish, you can substitute an alternative for some or all of those: FreeDOS instead of MS-DOS, FreeCOM instead of Microsoft’s COMMAND.COM, FreeDOS MODE and FreeDOS DEBUG, or C. Masloch’s lDebug.
Many vintage PCs have a PS/2 port that can be configured (via jumpers, BIOS, or both) to work as either PS/2 keyboard, PS/2 mouse, or combined keyboard+mouse with a Y-cable adapter. Having the port configured differently than what is actually connected can confuse software and drivers and prevent the keyboard from working. However, the keyboard might still work correctly in the early boot phase when it defaults to keyboard only support.
Inspect the motherboard for jumpers and the BIOS for settings and ensure your PS/2 input devices match with the settings and connect to the appropriate PS/2 port (if more than one).