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?

  • 1
    Guess: keyboard controller on the Packard Bell is broken.
    – dirkt
    Jun 19, 2021 at 4:41
  • @dirkt Would that only prevent the keyboard from working from the os? It works fine from the bios. Jun 19, 2021 at 5:34
  • It's possible that the OS uses the part of the controller that is broken, for whatever reason, and the BIOS doesn't. Another possibility is that the keyboard controller is non- standard, and the BIOS uses it correctly, while an OS would need special drivers (which your Windows 95 maybe lost?). I don't know the hardware specs of the Packard Bell Multimedia 550, is it possible to somehow externally boot Linux (SystemRescue etc.) onto it, with remote network or serial port access? Then you could at least look around.
    – dirkt
    Jun 19, 2021 at 5:58
  • Installing MS-DOS 6.22 couldn't install the wrong keyboard driver, but it was pretty needless anyway, because both early-boot Windows 95 and MS-DOS 6.22 use BIOS interrupt services for keyboard access. Do you have a null-modem cable? Maybe it's possible to diagnose the problem over a serial connection. Jun 19, 2021 at 6:14
  • 3
    Is there also ps/2 mouse involved? A bogus mouse, or wrong PS/2 connector bracket will confuse the controller. Removing mouse should clarify that.
    – Vlad
    Jun 19, 2021 at 12:03

2 Answers 2


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 MODE.COM and 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 q command.

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 60 should then return 55. Any other value means a self-test error.
  • Toggle keyboard-enabling bits by issuing commands o 64 ae or 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.

  • I will try this, but I gotta go buy a null modem cable. I'll make an update once I try it. Jun 19, 2021 at 20:32
  • @DoggoYT Any progress? Aug 4, 2021 at 17:14

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

  • This would be extremely unlikely for a PC of this vintage, and the Packard Bell specifications for this model explicitly list two separate ports. Jun 19, 2021 at 13:05
  • @StephenKitt You may be right, though I cannot tell from the marketing specs you linked that just say "supports keyboard and mouse".
    – Brian H
    Jun 19, 2021 at 15:08
  • I’m going by “Ports include: Serial, Extended Capabilities Parallel Port (ECP), USB (Universal Serial Bus), Mouse, Keyboard, Game and VGA”. This is a 1997 PC, not even PC 97 compliant, with non-colour-coded ports, as seen for example on the 1998-vintage Packard Bell Multimedia 820 (see this photo of the connectors). Jun 19, 2021 at 15:30
  • 1
    To put this in historical context, shared PS/2 ports with splitter cables were documented in PC 97 1.1 in February 1997; prior to that, PC 97 required two separate ports, except on mobile PCs which could provide a single port for use either by a mouse or keyboard. Of course there’s a decent chance that some manufacturers used splitter cables before this, I can’t remember any but that doesn’t mean much. Jun 19, 2021 at 15:39
  • I can't find anything in the BIOS, at least nothing that stands out to me. The only jumpers that are on the board is near the CPU. If it helps, the pc was made to run WIndows 95, but there was a offer to upgrade to Windows 98, so the pc was made around the 98 era. Pics of the MB and the BIOS: here Jun 19, 2021 at 18:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .