• Please review our updated Terms and Rules here

IBM PC ROM Dumps to Complete Collection

Manufacturer tests

Manufacturer tests

ziloo said:
Would you please elaborate more on this feature! I read somewhere that it is possible to do data-acquisition in the background on a PC via keyboard buffer
Click to expand...
The following info is sourced from the March '86 revision of the 5160 Technical Reference manual.

In the initial part of the power-on-self-test (POST), POST codes are sent to the keyboard port. These are commented in the source code like "<><><> CHECKPOINT 2 <><><>". The page showing the I/O map of the 8255A has them labeled as "Diagnostic Outputs".

At a certain point, the POST resets the keyboard port. If a keyboard is plugged in, it will return AAh, however if certain other values are returned, the POST does the following:

Byte 65H returned

The POST jumps to code which does the following, quote: "Load a block of test code through the keyboard port for manufacturing test. This routine will load a test (max length = FAFFH) through the keyboard port. Code will be loaded at location 0000:0500. After loading, control will be transferred to location 0000:0500. Stack will be located just below the test code. This routine assumes that the first 2 bytes transferred contain the count of bytes to be loaded."

Byte 00H returned

POST does something to the keyboard lines, waits a bit, then looks to see if the data line was grounded. If it was grounded, the POST sets the 'manufacturing test flag' in memory (in the BIOS Data Area, at offset 12h). Some code associated with the 'manufacturing test flag' refers to it as the "mfg run-in tests".
The POST then continues.
Irrespective of the state of the 'manufacturing test flag', POST codes are no longer sent to the keyboard port, but instead are placed in memory (in the BIOS Data Area, at offset 15h).

The 'manufacturing test flag' is used in later parts of the POST, eg.
1. If set, the timer is set up to periodically run a routine (via an interrupt) that toggles a LED. By the code, it looks like the LED must be something attached to the keyboard port.
2. The routine that beeps the speaker on error, examines the 'manufacturing test flag'. If set, a jump is made to code that fetches the POST code from memory, then outputs that to the keyboard port, then halts the CPU.
.
 
Manufacturer tests

Manufacturer tests

Note that the 'manufacturing test' code is also present in the 5150.
I can see it in the listing of the first BIOS for the 5150 (dated 04/24/81, as shown in the July'82 revision of the 5150 Technical Reference).
 
Thank you for your prompt response modem7 :) !

What I like to know is how to

...Load a block of test code through the keyboard port...
Click to expand...

Who or What is doing the loading and how is it going through the
keyboard port/buffer ?

ziloo
 
ziloo said:
What I like to know is how to "...Load a block of test code through the keyboard port... "
Who or What is doing the loading and how is it going through the keyboard port/buffer ?
Click to expand...

First, some background, which is 5150/5160 only:

When you press a key (and it is still down), the keyboard sends the 'make' byte associated with that key on the data line. A clock is also sent (on the clock line). The motherboard uses the clock to clock the data (9 bits with the first bit being a start bit) into a 74LS322 shift register. When the entire 9 bits has been clocked in, the 74LS322 triggers interrupt 1 (IRQ1). The CPU pauses whatever it is doing and runs the code associated with interrupt 1. The first thing that code will be doing is to read the byte presented by the 74LS322 (which is read via the 8255 chip).

ziloo said:
Who or What is doing the loading and how is it going through the keyboard port/buffer ?
Click to expand...
I'm sure that IBM (or the board maker) would have used a purpose built device.
And so the sequence would be:

1. Maker attaches 'purpose built device' to keyboard port.
2. Maker powers up motherboard - the POST on motherboard starts.
3. At a certain point during the POST, the POST resets the keyboard device (which presently is the 'purpose built device').
4. The 'purpose built device' responds with 65h.
5. Because of the 65h, the POST jumps to 'special code' (in ROM).
6. The 'special code' monitors interrupt 1, which when it occurs indicates that the 'purpose built device' has sent a byte, which (now stored in the 74LS322) then can be read via the 8255.
7. The 'purpose built device' sends two bytes, being the count of bytes that are to follow.
8. The 'special code' reads the two bytes (via the 8255, and thus knows how many bytes (of code) are to follow.
9. The 'purpose built device' starts to send the remaining bytes. As each byte is sent, the 'special code' reads it and stores it in a particular area of RAM.
10. After the 'special code' has processed the last byte, it jumps to the code it has just stored in RAM.


Now in relation to your earlier, "I read somewhere that it is possible to do data-acquisition in the background on a PC via keyboard buffer". Whilst it may be possible, I'd chose to do background data collection of serial data via an RS-232 port over the keyboard port any day. So one problem of using the keyboard port springs to mind:

1. Power on computer (with keyboard attached so that you don't get a 301 error).
2. At DOS prompt, run data acquisition program (which presumably stores acquired data to disk).
3. Remove keyboard, substituting it with a line from the data source.

Now at the end of the data collection time, you need to inform the data acquisition program to stop capturing (so it can write out any buffered data to the disk file and close the file). Without a keyboard, how do you do that? If you remove the data source and put the keyboard back in, your data acquisition program is simply going to interpret keyboard data as more data to be acquired.

Another issue. Your data source will also need to supply a separate clock signal.

These issues can be overcome, but it seems to me to be much simpler to capture asynchronous serial data via an RS-323 port (or RS-422).
 
Last edited:
modem7 said:
Now at the end of the data collection time, you need to inform the data acquisition program to stop capturing (so it can write out any buffered data to the disk file and close the file). Without a keyboard, how do you do that? If you remove the data source and put the keyboard back in, your data acquisition program is simply going to interpret keyboard data as more data to be acquired.
Click to expand...

If you got a mouse, a right click could close the program, or if you got a light-pen (and CGA), you could use that maybe. OR if you got a Game Adaptor with a joystick.
 
Last edited:
Well, it would be possible to have a 'real' keyboard in parallel with the data acquisition device and define a special sequence to end collection (like '+++' in the old modem days to switch from data to keyboard), and there are devices to convert contact closures, RS-232 etc. to the keyboard protocol, but I do have to ask 'WHY'?

This sort of thing is often done with arcade game emulators, where folks build a more or less authentic cabinet with buttons, joysticks, etc. and connect it all to the emulator through the keyboard port, but as modem7 says, for most normal data collection there are much easier ways.

m
 
It is great that we have such a wealth of knowledgeable people on our
forum whose output makes you search more to learn more. Now that
I had brought up the subject, I had to go and dig-up the source of my
inquiry and after going through a few boxes of books (and several
layers of inch-thick dirt) I found a 10 year old ad about a software
for data-acquisition purposes. This is what the description said:

The "blahblah" software is a TSR program that collects data from
any RS-232 device, and after manipulating it, sends it to the
keyboard buffer without affecting normal keyboard functions. The
foreground application accepts the data as if it was entered manually
via the keyboard. All of this takes place transparrently in the
background without interfering with normal operation of the
application program.

The windblows version of this software allows the user to have a
spreadsheet program, a graphic program, and/or other programs
open in several windows, and each one can take the collected data
from an RS-232 device (through the keyboard buffer) and display
it in real-time in the corresponding window.

Any comment regarding how the "blahblah" software works is highly
appreciated!

ziloo
 
Well, that's something a little different. You're talking about a 'wedge' TSR - in fact one of the more common programs to do this is called WEDGE.COM. Windows also has provisions for reading keyboard (and mouse) input from the serial port, BTW.

The difference is that this kind of software redirection is at a higher level, so it only works for software that reads its data from the keyboard buffer in memory; anything that reads the keyboard port directly would be unaware of the redirection.

DOS also has the ability to get its input from the serial port (CTTY), but that operates at an even higher level (and therefore with even fewer apps).

Is this just general curiosity, or do you have a specific application in mind?

mike
 
The question that I brought up earlier was based on what I had read almost
ten years ago, and some of the details had not been registered or had been
forgotten through time. After modem7 and your comments, I was able to
understand what was behind it all. Thank you very much for your help!

ziloo
 
08/16/82 BIOS for the 5160

08/16/82 BIOS for the 5160

modem7 said:
And so I'm convinced now that there are 4 versions of the 5160 BIOS. However, noting that the 5000026 chip was replaced by the 1501512 in very late 1982, and that the 5160 was released in March 1983, a question is, did the 5000026 chip make it into released 5160s? Maybe it didn't, and that is why Mueller doesn't list it.
Click to expand...
Does anyone have a copy of the first edition Technical Reference for the 5160?
Expect to see something like "First Edition (????? 1983)" in the first few pages.
It will be interesting to see if the 08/16/82 dated BIOS appears in that.
 
I have a "Revised Edition (April 1983)" that does not mention any other BIOS other than an 11/08/82 BIOS. I would suggest that any earlier XT BIOS would be merely a time stamp difference.
 
I have a "Revised Edition (April 1983)" that does not mention any other BIOS other than an 11/08/82 BIOS.
Click to expand...
I have that manual too.
I've just discovered via site http://www.emsps.com/oldtools/ibm.htm that the first edition will be dated "January 1983".

I would suggest that any earlier XT BIOS would be merely a time stamp difference.
Click to expand...
We've already determined that the difference (besides part number and datestamp) is a minor change to some code that only IBM themselves would have used.


Whether or not the BIOS listing in the first edition Technical Reference is the 08/16/82 one, that's not evidence either way that the BIOS made it to the streets.
Having said that, if the listing is the 11/08/82 one, I think that is a pretty good indicator that the earlier 08/16/82 BIOS didn't make it to the streets.
 
Great Hierophant said:
Would be nice to actually share these files:

http://www.mediafire.com/?2iyijya4iwu

Here you go, enjoy!
Click to expand...

Aww, you got yourself the corrupted dump of the 286 XT BIOS. I can tell it by that each 2K Chunck of the dump repeats. It would be nice if anybody with a working 286 XT coud dump the BIOS through Debug (I have programs for splitting it up in even/odd byte files).

*Edit*
And:
1501512.bin: 3270 BIOS ROM, visible in memory at F8000
Click to expand...
should be "1501512.bin: 3270 rest of BASIC & BIOS ROM, visible in memory at F8000" :p , but that really doesn't matter.
 
Last edited:
One thing I forgot, I don't have a dump of the Keyboard Controller ROM used in the 8642 microcontroller on the AT and XT/286 boards. I think the later AT ROMs may also be corrupted.
 
Great Hierophant said:
One thing I forgot, I don't have a dump of the Keyboard Controller ROM used in the 8642 microcontroller on the AT and XT/286 boards. I think the later AT ROMs may also be corrupted.
Click to expand...

The AT ROMs looks all right to me. When I combine the bytes (hi and lo bytes shuffeled together), they make out understandable code, with no duplicates, and readable ascii data (where present).

The only thing I want to say is that the AWARD genetic AT BIOS is overdumped. It is actually only 16 Kb * 2 [32Kb if dumped in DEBUG] (hence if you cut the files on the middle, you get a pair of two equal files).

The reason the 286 BIOS is corrupted is because each 4K segement is repeated. what might have caused this is just a bad address connecor on the dumping device maybe.
 
You must log in or register to reply here.
Back
Top