ASCII Console in POST
US5193174A
System for automatically redirecting information to
alternate system console in response to the comparison of
present and default system configuration in personal
computer system General Flow of POST for ASCII Terminal Support
Console Redirection for ASCII Terminal Operation
Console Redirection
Video Calls under Console Mode
Software Support for ASCII Terminal
System Console Determination
ASCII Terminal Driver
Console Select Utility
Keyboardless Operation
General Flow of POST for ASCII Terminal Support
FIG. 3 shows the procedure used by POST to identify and establish a configuration for a personal computer system with a selectable system console. When the computer system is powered up, POST initializes and resets the CPU and performs some basic diagnostic checks (step 100). The configuration data stored in NVRAM are checked to ensure that they are valid (step 102). One method to determine the validity is to perform a checksum which is well known to those of ordinary skill in the art. If the data in NVRAM are valid then system console configuration data stored in the NVRAM are read (step 104). The system configuration data are stored into NVRAM through the use of a configuration program. If ASCII Terminal support is selected (step 106) then an ASCII console parameter, such as a bit, is set to indicate ASCII Terminal (step 122). Referring back to step 106, if ASCII Terminal support is not selected then the NVRAM system console configuration data are checked to determine the type of display available. One common type of display available for a personal computer system is known as a VGA display. A VGA display usually has a resolution of 640x480 pixels with a choice of 16 colors. If VGA is selected as the display (step 108) then a Display console parameter is initialized to show the VGA as the system display (step 124).
Referring back to step 102, if the data in NVRAM are not valid or if ASCII Terminal (step 106) or VGA (step 108) are not selected then the planar is checked for video support (step 110). If video support is on the planar then control transfers to step 124 which sets the appropriate configuration parameter for the display. If no video support is on the planar then the first Micro Channel slot is placed in Setup mode, step 112. In the setup mode, a Micro Channel I/O card will send back to the CPU a unique identification signal. This identification signal alerts the CPU as to the type of card connected to the I/O slot. The ID of the card in the slot which is currently in Setup mode is checked to determine if it is a VGA-type card (step 114). If the card is a VGA-type then control is passed to step 124. Here the display configuration parameter is set to enable the CPU to identify and address the VGA-type I/O card.
Referring back to step 114, if the card is not a VGA type card, then the card in the current slot is checked to see if it is another type of video display card, such as a ROMless video card (step 116). If it is then control is passed to step 124. As mentioned before, the display configuration parameter is set to reflect this type of card. Referring back to step 116, the card in the current slot is checked to determine whether it is another type of video display card, such as a video card with ROM (step 118). If it is, then control is passed to step 124 to configure the system display configuration parameter.
If the card in the current slot is none of these, then a test is performed to determine if all the slots have been checked (step 120). If all slots have not been searched then the next slot is placed in Setup mode (step 121) and control then transfers to step (114) to continue searching. When all slots have been scanned (step 120) then the system console parameter is set to a default indicating an ASCII Terminal. After the system console parameter is established because of step (122) or step (124) then POST is allowed to continue (step 130). At this point the system has selected either an ASCII terminal, the type of display, or a default condition.
Console Redirection for ASCII Terminal Operation
When the system is operated with an ASCII Terminal certain functions such as keyboard and video need to be managed. BIOS INT 10h for video and INT 16h for keyboard need to operate with the ASCII terminal rather than the traditional VGA/keyboard combination.
Note that BIOS is accessed by software interrupts. That is, each BIOS entry point is available through its own interrupt. For example, software interrupts INT 10h accesses the BIOS video routines, while INT 16h accesses the keyboard routine.
Returning to the previous discussion, the video is managed by a redirector and the keyboard is managed by the communications port interrupt handler which places keystrokes into a keyboard circular buffer. This keystroke management allows the INT 16h interface to operate normally.
Included in POST is a process for redirecting the PC keyboard inputs and video outputs to or from the ASCII terminal. This process is known as a Console Redirector. The function of the Console Redirector is to redirect video BIOS calls (INT 10H) to an ASCII terminal attached to a serial communications port. The console redirection function is only used when ASCII console support is required during POST. The Console Redirect function can be terminated at the completion of POST. The main purpose of the console redirection is to enable transparent user operation of POST. During this phase, the Console Redirector will only support ASCII text mode. The Console Redirector calls the Asynchronous Communications BIOS to transmit host commands and text to the terminal. These functions include: initialize and attach console device; console input; console output character; console output string; and remove console device.
When ASCII console support is required on the system, video BIOS (INT 10H) is intercepted by the Console Redirector in POST. The intercepting of the Video BIOS (INT 10H) to provide video redirection is accomplished by POST in conjunction with the Attach Console Device function. The Console Redirect function is detached by POST in conjunction with the Remove Console function before exiting POST. The serial communications port is also tested and initialized before any information is output to the console.
Console Redirection
Referring to FIG. 4, there is shown a flow chart of the Console Redirection POST code used to redirect POST input and output information to the ASCII terminal. Before the Console Redirection POST code is executed there is a section of POST code which has already executed (step 200). Next, the asynchronous communications port is tested (step 202) to determine if it is operational. If the test is positive, i.e. yes, (step 204), any errors are reported (step 206) and POST continues (step 213). Referring back to step 204, if there are no errors, then the system console parameter data are checked to determine whether an ASCII terminal is to be installed as the console (step 208). If it is, then the console is initialized (step 210) using the initialization and attach function call which performs terminal communication initialization. If an ASCII terminal is not indicated in step (208) then POST is allowed to continue (step 213). After the console is initialized in step (210) additional POST is executed (step 212) to perform test and initialization on other system components. Once the majority of POST has completed the console is detached (step 214) and POST continues (step 216) into the bootstrap phase.
Video Calls under Console Mode
Major Tom has conducted painful probulation and reports:
The console mode overrides all video calls (Int 10), using a special table that transforms it to some special serial port calls (undocumented Int 14 functions 60-64 - exclusively used by the serial console code), and they are doing some magic with keyboard buffers as well. I think the serial console mode should work fine in most "well behaved" text mode applications.
That's what I wanna test... It will also help me figure out meaning of some of the CMOS, NVRAM, and EBDA fields.
Quick & dirty list of the undocumented Int 14 functions:
Int 14 AH=60h - Initialize and attach CONSOLE Device
Int 14 AH=61h - CONSOLE Input
Int 14 AH=62h - CONSOLE Output Character (AL - char)
Int 14 AH=63h - CONSOLE Output String (ES:SI - string ptr)
Int 14 AH=64h - Remove CONSOLE Device
Incomplete and not quite confirmed yet, I will have to put more work into this. The serial console stuff is not a priority, and I'm just mapping what is what at this point.
Ed. Tom: This has since been confirmed by the US5193174 patent, names of the listed routines were modified to match the "official" ones.
Software Support for ASCII Terminal
To support an ASCII terminal as the system console, additional functions are added as internal interfaces along with an additional internal function call to BIOS System Services for system console determination. The Asynchronous Console Communications Device extension provides functions that allow the user to communicate with an ASCII terminal. The following functions are provided:
Initialize and attach Console Device
Console Input
Console Output Character
Console Output String
Remove Console Device
When called for installation, the line parameters used to establish a link with the ASCII terminal are displayed. Once installed, the interrupt handler checks for the Ctrl-C/Ctrl-A/Ctrl-D reboot sequence. If found, a word at a predetermined memory location, such as 40:72H, is initialized to a predetermined value and a system reboot is initiated.
System Console Determination
The System Console Determination function of BIOS allows the requesting software, such as an applications program, to determine the system console. The system console parameter is checked to determine the system console. For instance, one bit in the system console parameter could be used to determine the system console type. In this particular embodiment, the identification for the system console in the system console parameter could be reflected in the following configuration as follows:
Bit Identification
0 = VGA/keyboard
1 = ASCII Console
As is evident, more than one bit could be used for identifying other console system types.
ASCII Terminal Driver
FIG. 5 shows a block diagram illustrating the procedure for intercepting or hooking the normal PC key board and video BIOS INT 10h and INT 16h routines 302 with an ASCII terminal driver 300. The ASCII terminal driver 300 communicates through firmware console support code 302 contained in the BIOS module 304. The firmware support code interfaces to an ASCII terminal, such as the 3151/316X as shown in block 306. The ASCII terminal driver captures this data and converts it into video data for the ASCII terminal 306. When requesting software (shown as block 310) performs I/O to or from what it believes is the PC keyboard or display, the ASCII terminal driver intercepts this information and transfers it to the ASCII terminal 306. Specific requests to the ASCII terminal driver 300 are transferred directly from the requesting software. The objectives of the ASCII terminal driver are to:
Set up and maintain a virtual video buffer
Manage the interface between the virtual video buffer and the ASCII terminal
Redirect BIOS INT 10H (video) and provide equivalent functions
Redirect BIOS INT 16H (keyboard) and provide equivalent functions
The ASCII terminal driver does not directly manage the asynchronous communication port to which the ASCII terminal is attached, but instead uses the Asynchronous Console Communications Device extension to BIOS for all communications with the ASCII terminal.
A function call is used to access the following ASCII terminal device driver functions which are:
ASCII terminal attached - is ASCII terminal attached as system console ?
Diagnostic entry - used by DCP before calling each diagnostic module
Diagnostic exit - used by DCP after calling each diagnostic module
Refresh ASCII terminal - refresh screen with info written to virtual video buffer.
Return pointer to virtual video buffer - returns a pointer to the virtual video buffer
NOTE: If ASCII terminal is not attached as the system console, the "ASCII terminal attached" function is the only function available, all other function calls will return with no action taken.
* Diagnostics Control Program (DCP)
Since a physical video buffer is not available when the ASCII terminal is used as the system console, the ASCII terminal driver sets up and maintains a virtual video buffer. The virtual video buffer is a 4000 byte buffer which contains the character and corresponding attribute data for the information currently displayed on the 80x25 ASCII terminal screen. This buffer corresponds to the physical video buffer found on video adapter cards. After writing to the virtual video buffer, a call must be made to the ASCII terminal driver to refresh the ASCII terminal screen with the information written to the virtual buffer. This buffer is located within the device driver
When the ASCII terminal is used as the system console, BIOS INT 10H (video) is redirected to the ASCII terminal driver and the following functions are provided:
02H-Set cursor position
03H-Read cursor position
06H-Scroll active page up
07H-Scroll active page down
08H-Read attribute/character at cursor position
09H-Write attribute/character at cursor position
0AH-Write character at cursor position
0FH-Read current video state
13H-Write string
The following modified BIOS INT 10H functions are provided by the ASCII terminal driver:
00H-Set mode
01H-Set cursor type
The ASCII terminal driver supports only page 0 and video mode 3. An attempt to set any other page or video mode will result in no action being taken. Since the ASCII terminal supports only blink, reverse video, underscore, and high intensity attributes; therefore, the ASCII terminal driver uses an attribute conversion routine to convert mode 3 attributes to ASCII terminal supported attributes.
[NOTE: What is this attribute conversion routine? LFO]
When the ASCII terminal is used as the system console, BIOS INT 16H is redirected to the ASCII terminal driver. The ASCII terminal driver calls the console extension to the communications interface to return an ASCII character from its buffer. The ASCII terminal driver then looks up and attaches the appropriate scan code before returning to the caller.
The following BIOS INT 16H functions are provided:
00H-Keyboard read
01H-Keystroke status
The following BIOS INT 16H functions are provided, but return the same information as function 00H (keyboard read) and 01H (keyboard status):
10H-Extended keyboard read
11H-Extended keystroke status
Console Select Utility
The console select utility permits console configuration data to be entered into the system console parameter stored in NVRAM. This allows the user to select one of the following options for system console which is then stored in the system console configuration parameter:
VGA/keyboard is system console
ASCII terminal is system console
No system console
When the user selects the ASCII terminal as the system console, the utility allows the user to change the following line configuration parameters required to establish a link with the ASCII terminal:
baud rate
number of bits in character
parity
number of stop bits
The information for the line configuration is stored in the NVRAM. When the user selects the ASCII terminal as the system console, or when the user selects no system console, the console select utility allows for video adapters to be removed from the configuration
Keyboardless Operation
To implement keyboardless operation three problems arise. First, a keyboard must always be initialized if service is needed. This is necessary to allow the Customer Engineer to access the reference diskette or advanced diagnostics. Second, a missing keyboard and a defective keyboard may look alike from a software perspective. Third, more than one kind of system configuration needs keyboardless support. Both systems configured as servers and systems with an ASCII Console need the additional support provided by keyboard less operation.
POST must determine which port has a keyboard installed. Therefore, software must have the ability to differentiate between a keyboard and a mouse. This is accomplished by reading an ID from the keyboard and mouse. Since the IDs are similar for both keyboards and mice, the "READ ID' procedure must test for valid IDs and not invalid IDs. This is to circumvent the condition where a mouse looks like a defective keyboard, and/or a keyboard looks like a defective mouse. Since, this method uses the existence of a keyboard first and then the existence of a mouse to determine the configuration of the system, a default setup is not relied upon when a keyboard is not found. Physical port A is scanned first, and physical port B is scanned second. Therefore, both ports are truly switchable and the external configuration is solely responsible for the setup of the ports. This situation is different from previous switchable port implementations for the keyboard and mouse that used the presence or absence of the keyboard in the first connector as the sole test for setting the configuration. For a system that has a keyboard as a mandatory piece of equipment, the single test for a keyboard in port A and port B is sufficient to configure the system correctly.
POST initializes the keyboard controller to either the DEFAULT or the SWAP state. To determine the correct state, the following method is implemented. The physical keyboard port is tested and initialized. If a keyboard is found, POST sets the state as DEFAULT. If a keyboard is not found, the physical mouse port is tested and initialized. If a keyboard is found, POST sets the state as SWAP. If no keyboard is found in either port, the mouse determines the state of the port assignment. FIG. 6 illustration gives the complete flow for determining the port selection.
The procedure used to initialize the keyboard and mouse subsystems is shown in FIG. 6. Since this procedure is a portion of the overall POST this section occurs after other POST activities have already been completed (step 500).
Two states are defined to implement the swapability of the keyboard and mouse ports. The first state is the DEFAULT state. This state maps the logical keyboard port to the physical keyboard port. Likewise, the logical mouse port is mapped to the physical mouse port. The second state is the SWAP state. In this state, the logical ports are assigned to the opposite physical ports. The logical keyboard port accesses the physical mouse port directly and vice versa. The enhanced keyboard controller supports both the DEFAULT and the SWAP states.
Next, POST sets the Selector state to its DEFAULT setting (step 502). A "READ ID" command is issued to the logical keyboard port (step 504). Based on the ID returned, if any, a decision is made if there is in fact a keyboard attached to the current logical keyboard port (step 506). The test of step 506 is for a predetermined value returned as the first byte of an ID word. If no keyboard is identified then the Selector bit is tested to determine if it is in its SWAP state (step 508). If the Selector bit is not in the SWAP state then both physical ports have not yet been checked so the Selector bit is set to the SWAP state (step 510). With SWAP set the check for a keyboard is repeated.
If a keyboard is found in step (506) then the keyboard is tested (step 514). The result of the keyboard test is then checked (step 516). If the keyboard passes then the keyboard is initialized and marked as present (step 518). The keyboard is marked present by storing its ID in the extended BIOS data area (EBDA). If the check of the keyboard test in step (516) indicates that the keyboard is not functioning correctly then an error is reported (step 520).
If the Selector bit is set to SWAP in step 508 then a check for keyboardless operation is made (step 512). If keyboardless operation is not indicated by the system console parameter data then POST was expected to find a keyboard and did not so an error is reported (step 520). If keyboardless operation was allowed from step (512) then the procedure continues with no error.
The state of the SWAP bit is saved and called SWAPTMP (522). Next a READ ID command is is sued to the logical mouse port (step 530). The ID, if any, is then checked to determine if a mouse device is present (step 532). If a mouse is found then it is marked as present (step 534) and POST then continues (step 542). An IBM or IBM-compatible mouse is identified by a predetermined response, such as 0AAh followed by a value of 00h. Any other pointing device can return any value as a second byte as long as the first byte is 0xAA. If no mouse device was found in step (532) then a check is made if a keyboard had been found previously (step 536). If a keyboard has been found then it is already occupying the other physical port so no swap is necessary and POST is allowed to continue (step 542). If step 536 does not indicate that a keyboard had been previously found then the SWAP bit is compared against SWAPTMP (step 538) and if found to be different then control is passed to step (step 542) and POST continues. If step (538) determines that SWAP is equal to SWAPTMP then this indicates that the other physical port still needs to be checked for a mouse. The SWAP bit is toggled (step 540) and control is routed to again check for a mouse.
To facilitate the service requirements POST always looks for and initializes a keyboard if present. If keyboardless operation is selected, POST suppresses a keyboard error when it occurs. The reason for this is a defective keyboard may look like a missing keyboard to POST. Since POST always tests for a keyboard, the system initializes the keyboard if present. Thus, a Customer Engineer can attach a keyboard to service a machine that is configured as keyboardless.
To provide a mechanism where any system can be configured as keyboardless, POST uses a bit in NVRAM to determine if keyboardless operation is desired. The bit in NVRAM is set up by the set console utility on the reference diskette. This bit in NVRAM is independent of server configuration and independent of the ASCII Console support. Thus, any system can be configured as keyboardless.