OS/360 Object File Format

The OS/360 Object File Format is the standard object module file format for the IBM DOS/360, OS/360 and VM/370, Univac VS/9, and Fujitsu BS2000 mainframe operating systems. In the 1990s, the format was given an extension with the XSD-type record for the MVS Operating System to support longer module names in the C Programming Language. This format is still in use by the z/VSE operating system (the follow-on to the DOS/360 Operating System). In contrast, it has been superseded by the GOFF file format on the MVS Operating System (the follow-on to the OS/360 Operating System) and on the z/VM Operating System (the follow-on to the VM/370 Operating System). Since the MVS and z/VM loaders will still handle this older format, some compilers have chosen to continue to produce this format instead of the newer GOFF format.
Use.
This format provides for the description of a compiled application's object code, which can be fed to a linkage editor to be made into an executable program, or run directly through an object module loader. It is created by the Assembler or by a programming language compiler. For the rest of this article, unless a reason for being explicit in the difference between a language compiler and an assembler is required, the term "compile" includes "assemble" and "compiler" includes "assembler."
Weaknesses.
This format was considered adequate for the time it was originally developed, around 1964. Over time, it had a number of weaknesses, among which is that
These and other weaknesses caused this format to be superseded by the GOFF module file format. But, it was a good choice as it was satisfactory for the needs of programming languages being used at the time, it did work and was simple to implement (especially where machines at the time may have had as little as 8K of memory, many operating multiple concurrent or consecutive jobs with as little as 64K, and actually performing useful work), simple to use and for simple programs (object orientation and concepts like virtual methods would be decades in the future from when it was originally developed), can still be adequate. Also, the format is still satisfactory to continue to be used for older programs that either were never changed, or where the source code is unavailable and the object files are the only part of the program remaining.
Note that the GOFF file format merely superseded this format (and provided more information for a language compiler or the assembler), the format is still valid, may still continue to be used, and was not deprecated. This format has the advantage that it is easy and simple to create, and a compiler for a language that can live with its restrictions, which are maximum 8-character upper-case only module names, applications no larger than 2^24 in size (16 megabytes) for code and data, means that any programming language that can write 80-byte fixed-format binary files (basically anything including COBOL and FORTRAN, not just Assembler), can be used to create a compiler for this object format. In fact, the Australian Atomic Energy Commission's Pascal 8000 Compiler for the IBM 360/370, itself written in Pascal as a self-hosting compiler back in 1978–1980, directly created its own object files without using the Assembler as an intermediate step.
Record Types.
There are 6 different record types:
Format.
All records are exactly 80 bytes long; unused fields should be blank-filled. The first byte of every record is always the binary value 02. The next 3 bytes are always the record type. Character values are in EBCDIC. The remainder of each record's fields are dependent on the record type. By convention, if the module was named in the TITLE statement of an assembly language program (or the language compiler decides to give the module a name), its name appears left-justified in positions 73–80 of each record; if the name is shorter than 8 characters or no name was given, a sequence number (in characters, right justified with zero fill) appears for the remainder of each record. In actual practice, the sequence number field may be blank or contain anything the language translator wants to put there, and is essentially a comment field.
The assembler, (or compiler, in the case of a high-level language such as C, COBOL, Fortran, Pascal, PL/I or RPG III), would create an ESD record for each subroutine, function, or program, and for Common Blocks in the case of Fortran programs. Additional ESD entries in ESD records would be created for ENTRY statements (an alias for a module or an alternative entry point for a module), for additional subroutines, functions or Fortran named or blank COMMON blocks included as part of a compiled or assembled modules, and for names of external subroutines and functions called by a module.
Note that there are two kinds of public symbol types, ESDID entries and LDID entries. ESDID entries are CSECTS and DSECTS (Programs, Procedures and Functions, and possibly Record or Structure declarations) and LDID entries are ENTRY statements (alternative or alias entry points to a CSECT or DSECT). The ESDID numbering space is separate from the LDID numbering space, and thus two different named symbols, one an ESDID and one an LDID can both have the binary value of 0001.
The program's executable object code and data would be stored in TXT records. Calls to other subroutines, functions or COMMON blocks are resolved through RLD records, which modify the address as stored in a TXT record to determine the complete address of the subroutine or function. Optionally, a language can provide symbolic reference information such as object names and data type information or debugging symbols through SYM records, and then the END statement indicates the end of an Object module file and the optional start address for the subroutine, function or program that this file should be started at, if the starting address for the routine is not the first byte of the first routine (some routines may have non-executable data preceding their actual code or the first routine assembled or compiled is not the "main" program or "primary" module.) As has been reported, some people discovered because of the way older assemblers worked (circa 1968–1975), a program compiled faster if you put data "above" a program before the code for the program, once the assembler started to notice instructions, it was much slower, so, programmers would write routines where they put the data and constants first, then included code for the program. When assembling a program could take 30 minutes to an hour instead of a few seconds as now, this was a big difference.
Note that while not required, it is a convention that module and symbolic names are in all upper case, that the first character of a name field is a letter or the symbols @,# or $, and that subsequent characters of a name consist of those characters plus the character digits 0 through 9, although older software may or may not correctly process object module files which used lower-case identifiers. Most programming languages other than Assembly cannot call modules that have names containing @ or # (notably Fortran, which is why its run-time library has a name with a # in it so it would not conflict with any name chosen by a programmer), so most programs, subroutines, or functions were written to use only a letter for the first character, and if the name was longer than 1 character, to use only letters and digits for the 2nd through (up to) 8th character. While most non-assembler languages can't handle $ in the name, an exception is Fortran which can recognize subroutine names with $ in them. (Note that this choice not to use # @ or $ does not apply to a "main" program written in Assembler or any language that can use these identifiers, the program loader doesn't care what the name of the module is.) Also, modules written to be used as subroutines typically restricted themselves to 6 characters or less as versions of Fortran before about 1978 also can't use subroutines or modules using more than 6 characters in length. The COBOL compiler typically discards the dash character if it appears in a program's PROGRAM-ID or a CALL statement to an external module.
In the 1990s, a new record type, the XSD record was added to extend the use of this object module format to encompass longer module names than 8 characters and to permit mixed-case names, as required by the C programming language.


CCP.COM


Mystical Ninja Starring Goemon

Mystical Ninja Starring Goemon is a platform action-adventure video game released by Konami for the Nintendo 64 on August 7, 1997 in Japan and April 16, 1998 in North America as the fifth entry in the "Ganbare Goemon" series. The second "Goemon" game released in North America, it follows "The Legend of the Mystical Ninja" and features hybrid elements of platform games and action-adventure games.
The story follows Goemon's struggles to prevent the Peach Mountain Shoguns gang from turning Japan into a Westernized fine arts theater. The plot calls for three cinematic musical features and battles between giant robots; like other "Ganbare Goemon" games, it is peppered with surrealist humor and anachronisms.
"Mystical Ninja Starring Goemon" sold nearly 200,000 copies worldwide. Reviewers praised its graphics, gameplay, and humorous plot.
Gameplay.
Players navigate Goemon through forests, fields, dungeons, and other three-dimensional models of feudal Japanese places. Goemon and his friends can walk or run, jump, attack, and use special abilities to cross terrain, pick up money, and defeat adversaries. Players control only one of four characters at a time but can cycle through them with the press of a button. Hearts at the bottom of the screen show a character's health. If hit by an enemy and damage is taken, a character loses a heart. Some items and acts replenish strength, and a Maneki-neko (Luck Cat) adds a heart to the overall health. If all hearts are lost, the player restarts at the entrance to the field map they died in and the player's number of lives declines by one. If the player loses all lives, the game restarts at the last point saved or at the beginning of the game if a Controller Pak is not used.
Traveling through Japan, players visit towns and coffeehouses safe from enemies, where they can eat in restaurants or sleep in inns to refill strength and buy armor or riceballs—a self-acting item that refills health by itself. Many interactive non-player characters populate cities and talk with other characters to uncover plot devices or idle gossip. Players save their progress in towns with a Controller Pak at the inns or at the entrance to some dungeons. Some places are impassable barring the use of special abilities unlocked by completing minigames. For example, Ebisumaru must hide in a giant's cupboard to learn self-shrinking magic, an art that allows passing through small holes. The player has two wayfaring tools: a status screen shows found items, weapons, and player characters and a map screen shows where they are in Japan. In dungeons, the map screen shows the building's floorplan if they have the item "Mr. Elly Fant". At the end of each dungeon is a boss, a more difficult than normal enemy with hearts of its own.
Beating a boss can trigger a cutscene, after which Goemon appears outside the dungeon or helms his giant robot friend Impact to thwart an enemy robot (although not mentioned in the manual, these segments of gameplay support the Rumble Pak accessory). These sequences begin with a music video and a high-speed minigame in which Impact must smash structures and avoid hazards while racing across the countryside. The points gained by destroying buildings determine how many health points (measured in oil) Impact will have in the coming battle. Players control Impact from a cockpit behind his eyes where gauges show enemy and player health and ammunition. Impact can punch, kick, defend, reel in opponents with the chain pipe, and use projectile weaponry, including nasal bullets and a laser. Once a boss is defeated, a cutscene of the enemy exploding shows, and the game returns to normal exploration-based play. At the very end is the last boss whose defeat unlocks the ending. Collecting all the fortune cats and beating the game enables an Impact tournament mode with a special image of the robots as the prize for winning.
Plot.
Characters.
The protagonist of "Mystical Ninja" is Goemon, a hot-blooded, kiseru-wielding ninja with blue, bushy hair based loosely on the legendary thief Ishikawa Goemon. The lord of Oedo asks him to find those who maimed Oedo Castle. Goemon lives in Oedo Town and is friends with Ebisumaru, a strange, gluttonous fat man who wears a blue bandana. Ebisumaru is defined as lazy and perverted. Their kunai-throwing friend Sasuke is a mechanical ninja (made by the Wise Man of Iga) who enjoys hot baths and Japanese tea. Rounding out the heroes is Yae, a fierce sword-wielding kunoichi, who happens upon Goemon's band in Zazen Town. The villains of the game hail from the organization "Peach Mountain Shoguns" and include a gang of four "weirdos" led by Spring Breeze Dancin' (Danshin Harukaze) and Kitty Lily (Margaret Ranko). They intend to transform Japan into a stage for their talents.
Story.
While shopping in Oedo Town, Goemon and Ebisumaru feel the ground quake as a peach-shaped flying object sails overhead. The vessel fires a laser at Oedo Castle, turning it into a European-style castle with spires and flags. Worried for the safety of the Lord of Oedo and his daughter, Goemon and Ebisumaru retrieve a chain pipe from Mt. Fuji and assault the castle. Inside is Baron, a member of the fashion-loving Gang of Four who reveals he was sent to turn the castle into a stage. Goemon shrugs him off and defeats the King Robot Congo to free the Lord and find a "miracle item". The Lord asks Goemon to catch them and gives a Super Pass for access to the roads of Japan.
Goemon sets out to the Wise Man's house for assistance, but the house explodes as he approaches. A fuming Baron comes forth and mans his kabuki robot. Goemon finds a Triton shell in the rubble that can call Impact, who lays ruin to the kabuki robot. In Zazen Town, Goemon finds Yae, who claims the troublemakers responsible are Flake Gang members named the "Peach Mountain Shoguns." Yae joins Goemon, and they learn that children with dancing talent have been kidnapped around the region. Goemon and his friends must also fight against Benkei, a gatekeeper blocking the Gojo Ohashi Bridge leading out of Zazen Town. In order to defeat him, Goemon needs help from a young fisherman named Ushiwaka. It is hinted that Benkei and Ushiwaka are kind of rivals. Ashamed at his loss against Goemon and his friends, the man offers Goemon the mechanical robot Sasuke, thrown there by the explosion of the Wise Man's house. Goemon accepts the unconscious, powerless Sasuke and walks to Kii-Awaji island, where the dragon-powered passenger ferry has been stopped by the dragon's sudden craze. Goemon teleports to the dragon and finds a Gang of Four member named Colon who used the dragon to kidnap children; he then breaks Colon's mind-control device. The dragon turns back to human and crashes near a shrine.
The human calls himself Koryuta, son of the Dragon God, and apologizes for the kidnappings. He pledges help in transporting the heroes across Japan, and claims the kids are at the Dogo Hot Springs. Goemon travels to Iyo but finds the Hot Springs closed; the only entrance is a mouse hole. He learns from travelers that sweets in the Zazen Town shrine can make a person smaller. Ebisumaru offers to steal the sweets. With the dwarf power the group infiltrate the Ghost Toys Castle, a dark house of traps, toys, and a giant pool table. Colon faces Goemon with the robot Dharmanyo, but is crushed and lets go his miracle item. The hidden man aboard the peach ship at Oedo comes out calling himself "Spring Breeze Dancin'". He pokes fun at the group with nicknames and instructs Colon to retreat. With the children liberated, Goemon follows Colon to the Chu-goku Region, where he revives Sasuke with two batteries. They enter the Festival Temple, a Peach Mountain base.
They destroy a guard robot, prompting Gang of Four member Sharon to appear with Kitty Lily, the second leader of the Peach Mountain Shoguns. Lily boasts that Kyushu is a stage and asks Sharon to return to base after buying some foundation. Alarmed, Goemon and friends rush off to the bridge to Kyushu and find Omitsu on her way to deliver dumplings. Stunned by Omitsu's seeming ruggedness, Goemon forgets to warn her of danger, and the island rises into odd thunder clouds in the sky. A fortune teller instructs the group to set out north to Mount Fear to find a way to Kyushu. After necessary weight training to remove obstacles, Goemon finds the northeast Festival Village and learns of a psychic witch. The witch summons Wise Man, who tells Goemon to gather the fourth miracle items at the Stone Circle near Festival Village for passage into outer space and Kyushu. Goemon investigates reports of stolen food in the village while Yae undergoes training to become a mermaid. The two paths converge when Yae finds the Gourmet Submarine, a "Peach Mountain" vessel containing hordes of food. After sidestepping grills and swimming through gallons of soup, Goemon confronts Poron, the final weirdo, who jokes that he lost the last miracle item in Zazen Town.
Lily enters by hologram to ridicule the party, but is rudely interrupted by Dancin', who continues to call Goemon "Fernandez". Dancin' instructs Poron to activate the ship's self-destruct sequence. Goemon escapes by calling Impact and defeats a mermaid giant robot. In Zazen Town, a kappa named Kihachi desires to trade the miracle item for cucumber made by the priest's son. The son sits on a precipice inaccessible save through jumping training; Sasuke volunteers in the Chu-goku Region and acquires the miracle item. At the Stone Circle, the Pemopemo God awakens and asks the heroes if they have the courage to venture to outer space. Goemon affirms their decision and the group enters Kyushu through the Gorgeous Music Castle. They discover Sogen Town has been converted to a garden city with European architecture. Goemon locates Omitsu and learns that Dancin' and Lily can be found past a rigid gate—accessible only with the help of Wise Man.
Stunned to find him alive, Goemon learns that in exchange for building the Instant Stage Beam and mechanical robots, the Peach Mountain Shoguns gave Wise Man five car magazines and a muscle car poster. Enraged to learn of his home's demise, Wise Man helps Goemon enter the castle. Kitty Lily and Dancin' confront the heroes with the elaborate musical number "Gorgeous My Stage" before a self-destruct sequence begins. Goemon summons Impact to fly into outer space, where he thwarts the giant peach ship Balberra and duels Lily and Dancin' in their personal battle robot. Dancin' mocks Goemon in defeat, and Impact sends their robot's head far into outer space to reveal a picture of Dancin' and Lily smiling among the stars. Goemon returns to Japan to find a horde of girls rushing towards him, and awaits their praise for saving Japan. The group is shocked to find the girls angry over the apparent death of their idol, Spring Breeze Dancin'.
Humor.
The story of "Mystical Ninja Starring Goemon", a quest to thwart dancers in a peach-shaped spaceship from using laser weaponry to convert Japan to a giant stage and its citizens to loyal dancers, is steeped in surrealist and Japanese humor. Many reviewers and writers commented on the humor in the plot and dialogue. The game's dialogue is peppered with offbeat humor, and a few instances of sexual innuendo. In the Japanese version, Wise Man collected hentai magazines and pornographic posters rather than automotive publications. A laugh track punctuates certain jokes.
Development and audio.
"Mystical Ninja Starring Goemon" was developed by Konami Computer Entertainment Osaka. It was first titled "Ganbare Goemon 5", then "Legend of the Mystical Ninja". The Japanese producers wished to break the series' numerical naming pattern to stress that "Mystical Ninja" differed from its forefathers. Originally made with a two-player mode, this feature was scrapped months before the Japanese release. Early development pictures showed Impact battling in a modern city against a handgun-wielding foe. Later images touted the battle against the Wartime Kabuki Robot Kashiwagi taking place over a forest and village. Konami released many renders of Goemon posing and making faces for magazine previews. A 60–70% complete build of the game was featured at E3 in June 1997, suffering from graphical clipping and camera issues. Konami later presented a mostly finished build at the Tokyo Game Show in September 1997. Developers aimed to make the game "very visual" with new content, and the game's marketers echoed this by using large, colorful advertisements. Konami targeted children, among whom the series is popular in Japan, by scheduling appearances of a Goemon mascot at some elementary school gymnastics sessions. The game's later success prompted the production of an animated television show. The series followed Goemon as he struggled against evil after being transported to modern society, where he befriended an elementary school student. Its release in the United States was planned for winter 1997, then February 1998, but was ultimately delayed to two more months.
"Mystical Ninja" featured a cartridge size of 128 megabits, designed to be much larger than most of its peers and predecessor games to allow high quality musical numbers and voice samples. In total, there are three musical numbers—"Theme of Ganbare Goemon", "I Am Impact", and "Gorgeous My Stage". They feature the talents of Hironobu Kageyama, Ichirou Mizuki, and Toshihiro Tachibana and Etsuyo Ota respectively. The song's main soundtrack is composed of a mix of traditional Japanese and modern instruments integrated in original arrangements. The dungeons feature minimalistic songs which grow in complexity and length as the player proceeds deeper into the lair. The soundtrack on whole is a collaborative effort by four composers. The musical numbers, with forty tunes from the game and one remix of "I Am Impact", were released October 3, 1997 on CD. The soundtrack was later extracted from Read-only memory and presented in Nintendo Ultra 64 Sound Format on May 9, 2005; it is one of the most downloaded releases at USF Central.
In 2018, the 8-Bit Big Band recorded a cover of the song "I am Impact!"
Reception.
"Mystical Ninja Starring Goemon" sold 55,000 units in America and 141,000 units in Japan. American reviewers praised the game's story and setting for its quirky, unique flavor; "Nintendo Power" called "Mystical Ninja Starring Goemon" a "blend of history, fantasy, and science fiction," writing that the game "never failed to enchant or intrigue." Dialogue was considered likably memorable, whether relying on clever puns or surrealist humor. The Japanese songs in "Mystical Ninja"'s title and Impact sequences, unusual to Western audiences, augmented the bizarre humor. One Japanese reviewer claimed the Impact song cultivated a heroic atmosphere for ensuing battles. Gameplay was similar to that of "Super Mario 64" and "The Legend of Zelda" series, offering responsive play control and ability-driven progression. "Mystical Ninja" featured a simple controller setup and easy learning curve to this end. The minigames, Impact sequences, and secret tournament mode bolstered replay value, and reviewers praised the game's graphical finesse in animating characters creating the Japanese countryside in three dimensions. A reviewer for The News Tribune considered the presentation "a terrific upgrade from the Super Nintendo version". However, the game was found to be prone to slowdowns in detail-heavy areas, and one reviewer decried the inability to pause the game during Impact battles. Another found play control "not as fluid as it is in "Super Mario 64"".
Critics enjoyed the soundtrack's integration of pop and shamisen-laden traditional Japanese music. A writer for IGN declared that the songs would "permanently burn themselves into your brain...something that can't be said for most N64 titles"—echoed by Japanese reviewers who noted that the music would not grow tiresome. "Mystical Ninja" was also commended for high-quality voice samples and sound effects. Reviewers were divided concerning the efficiency of the camera system—most considered it inferior to "Super Mario 64"'s, citing instances of clipping issues and resulting in "extremely difficult" platform jumping sequences. The game features a few sequences of long travel between towns, regarded as dull and unenjoyable. Reviewers disapproved of the game's short play time, estimating that "Mystical Ninja" could be completed in only ten to fifteen hours. The objections came in spite of the developers anticipating the problem and trying to mitigate it by requiring players to return to certain locations. "Mystical Ninja Starring Goemon" requires a Controller Pak to save—a rarity in early Nintendo 64 titles which garnered negative attention from both American and Japanese critics. One reviewer decried not being able to save his progress inside castles, which become "harder and more complex" with time. Reviewers fluent with past "Ganbare Goemon" games argued that the absence of the series' usually intuitive minigames and a two-player mode hampered "Mystical Ninja"'s replay value, and a Japanese reviewer felt that the transition to three dimensions had deprived the game of the traditional Goemon feel.
"Mystical Ninjas localization was criticized often. The plot and poorly-translated jokes tended to confuse players. A critic for The Tampa Tribune wrote, "upon popping in the...cartridge and listening to the opening theme song, you'll realize something about this game. It's Japanese." He added, "attempts at humor often come across as rather inane. Early conversations with village residents only add to the confusion." Others countered that the strange localization often compounded the surrealist humor through the use of weird, unusual English and grammar. One critic stressed, "talk to everyone you meet... Everybody has something interesting to say." A writer from GameSpot remarked that the game was translated surprisingly well given the sheer number of Japanese jokes and amount of innuendo. "Next Generation" lamented that Konami had not polished it more, holding that it otherwise might have been the "best N64 action/RPG". IGN's reviewer cautioned that though "Mystical Ninja" was billed as a role-playing game, it would differ from the expectations of Western fans. Critics noted that it would hold over gamers until the release of '—provided they played it with an open mind to avoid culture shock. A contributor for The Dallas Morning News concluded that the game "will please N64 owners starving for a decent adventure game... But players should rent it before they buy." A reviewer for the Sentinel & Enterprise wrote in 2001 that while considered a "flawed 3D platformer", "Mystical Ninja" offered "quirky" fun "following the heels of "Super Mario 64"" by inviting players to "scale mountains, invade pagodas, and pilot giant robots in all-out fisticuffs to the rhythm of Japanese lyrics and pop tunes." The game is rated 73.8% at GameRankings and received an 8.4 out of 10 rating by players at GameSpot.
Sequels.
"Mystical Ninja Starring Goemon" was followed by a Game Boy game of the same name. Featuring gameplay similar to the Super Famicom title ', the game presented a story in which Yae had been kidnapped by the Black Ship Gang. In 1999, Konami released "Goemon's Great Adventure" on the Nintendo 64—a 2.5D side-scroller with multiplayer support. Reviewers gave it high marks for recreating the feel of the older, 16-bit "Goemon" games and considered it the best side-scroller for the Nintendo 64. The final "Goemon" title for the Nintendo 64 was "Goemon Mononoke Sugoroku", released in Japan on December 25, 1999. In "Mononoke Sugoroku", players must collect Ofuda cards while navigating a board game. After a spate of sequels on the PlayStation line of consoles, Konami returned to the medieval, quirky Japanese themes of "Mystical Ninja" and its brethren on June 23, 2005 with ' for the Nintendo DS.


Command-line argument parsing

Different command-line argument parsing methods are used by different programming languages to parse command-line arguments.
Programming languages.
C.
C uses codice_1 to process command-line arguments.
An example of C argument parsing would be:
int main (int argc, char *argv[])
 int count;
 for (count=0; count<argc; count++)
 puts (argv[count]);
C also has functions called getopt and getopt_long.
Java.
An example of Java argument parsing would be:
public class Echo {
 public static void main (String[] args) {
 for (String s: args) {
 System.out.println(s);
Perl.
Perl uses codice_2.
foreach $arg (@ARGV)GT
 print $arg;
FT
or
foreach $argnum (0 .. $#ARGV)ST
 print $ARGV[$argnum];
AWK.
AWK uses codice_3 also.
BEGIN {
 for ( i = 0; i < ARGC; i++ )
 print ARGV[i]
PHP.
PHP uses codice_4 as a count of arguments and codice_1 as an array containing the values of the arguments. To create an array from command-line arguments in the codice_6 format, the following might be used:
$args = parseArgs($argv);
echo getArg($args, 'foo');
function parseArgs(array $args)
 foreach ($args as $arg) {
 $tmp = explode(':', $arg, 2);
 if ($arg[0] === '-') {
 $args[substr($tmp[0], 1)] = $tmp[1];
 return $args;
function getArg(array $args, string $arg)
 if (isset($args[$arg])) {
 return $args[$arg];
 return false;
PHP can also use codice_7.
Python.
Python uses codice_8, e.g.:
import sys
for arg in sys.argv:
 print arg
Python also has a module called codice_9 in the standard library for parsing command-line arguments.
Racket.
Racket uses a codice_10 parameter, and provides a codice_11 library for parsing these arguments. Example:
(command-line #:program "emoticon"
 #:once-any ; the following two are mutually exclusive
 [("-s" "--smile") "smile mode" (smile? #true)]
 [("-f" "--frown") "frown mode" (smile? #false)]
 #:once-each
 [("-n" "--nose") "add a nose" (nose? #true)]
 [("-e" "--eyes") char "use <char> for the eyes" (eyes char)])
(printf "~a~a~a\n"
 (eyes)
 (if (nose?) "-" "")
 (if (smile?) ")" "("))
The library parses long and short flags, handles arguments, allows combining short flags, and handles codice_12 and codice_13 automatically:
$ racket /tmp/c -nfe 8
8-(
Rexx.
Rexx uses codice_14, e.g.:
do i=1 to words(arg(1))
 say word(arg(1), i)
end
Node.js.
JavaScript programs written for Node.js use the codice_15 global variable.
// argv.js
console.log(process.argv);
$ node argv.js one two three four five
[ 'node',
 '/home/avian/argvdemo/argv.js',
 'one',
 'two',
 'three',
 'four',
 'five' ]
Node.js programs are invoked by running the interpreter node interpreter with a given file, so the first two arguments will be codice_16 and the name of the JavaScript source file. It is often useful to extract the rest of the arguments by slicing a sub-array from codice_15.
// process-args.js
console.log(process.argv.slice(2));
$ node process-args.js one two=three four
 'one',
 'two=three',
 'four' ]


Leading Edge Hardware Products

Leading Edge Hardware Products, Inc., was a computer manufacturer in the 1980s and the 1990s. It was based in Canton, Massachusetts.
History.
Leading Edge was founded in 1980 by Thomas Shane and Michael Shane. At the outset, they were a PC peripherals company selling aftermarket products such as Elephant Memory Systems brand floppy disk media ("Elephant. Never forgets") and printer ribbons, and acting as the sole North American distributor/reseller of printers from the Japanese manufacturer, C. Itoh, the most memorable being the popular low-end dot-matrix printer, "The Gorilla Banana". In 1984 the company sold the computer aftermarket product line and sales division to Dennison Computer Supplies, a division of Dennison Manufacturing. In 1984, they began to use Daewoo parts, and in 1989, they were acquired by Daewoo, as part of their recovery from Chapter 11 bankruptcy. (Shane declared that the costs of a legal dispute with Mitsubishi lead to its bankruptcy.) In January 1990, Daewoo hired Al Agbay, a veteran executive from Panasonic to lead the Company out of Chapter 11 Bankruptcy. In the three years that followed, Agbay and his executive team repaid dealers approximately $16 million and increased annual revenues to over $250 million before a contract dispute severed Agbay and Daewoo's relationship. In October, 1995, Daewoo sold the company to Manuhold Investment AG, a Swiss electronics company. Leading Edge had sold 185,000 of its PC clones in the United States in 1994, but in 1995 sales fell from 90,000 in the first half to almost none in the second half. By 1997 the company was defunct.
Products.
Hardware.
The first known computer to be produced by Leading Edge is the Model M, released in 1982. By 1986 it sold for $1695 (US) with a monitor and two floppy drives. It used an Intel 8088-2 processor, running at a maximum of 7.16 MHz on an 8 bit bus, compared to 6 MHz for the IBM PC-AT on a 16 bit bus. The 'M' stands for Mitsubishi, their parts provider.
They began producing the Leading Edge Model D in June, 1985, when they began to use Daewoo parts. That model was described as "the quality is good and the price is right." It was a Consumer Reports "Best Buy." It was IBM compatible, using the same Intel 8088 16 bit processor as the IBM PC, with two floppy disc drives, 256K of RAM, and an amber monitor. The machine sold for $1495 (US). They sold 125,000 in the first 13 months, then reduced the price to $1295 (US).
When IBM started supplying 20 MB hard drives as standard for its newer PC-XT's, Leading Edge supplied a 30 meg hard drive standard. They later released a Model D86 (an Intel 8086), Model D2 in 1988 with a 65 MB hard drive for $2495(US) and a 10 MHz processor (an Intel 80286) and Model D3 (an Intel 80386).
In 1993, Leading Edge marketed the WinPro Series of computers. These computers had then an i486 or Intel 80486 processors. The low end model had an i486 SX25 processor—which lacked an FPU. The i486 DX33 Processor had the FPU in. The computers had a 3.5 inch floppy, a 5.25 in floppy, 170MB hard drive, with 4MB of RAM, which could be expanded to 20MB if needed. Windows 3.1 and MS-DOS 5.0 were the operating systems. The cost of a Leading Edge Computer ranged from $1299.99 to $2199.99 during this time.
In 1994, Leading Edge marketed the Wintower 486 Multimedia PC, with 66 MHz processor, 8 MB ram, 340 MB hard drive, 2 floppies, CD ROM, modem, sound card and monitor for a "street price" of $2600 (US).
Software.
One of the programs offered on Leading Edge computers was the Leading Edge Word Processor. It was described as easy to use, created automatic backup copies, and loaded in 256 K of RAM, described as a "large" amount. With the program in memory, both floppy drives were available for storage. It was introduced in 1983, and sold in 1984 for $100. (U.S.) LEWP, as it was called, was a very easy to use word processor that had features that were bred into newer systems a great deal later. It automatically fixed transpositions on the run, a feature not seen in more sophisticated contemporary word processing programs.
In 1984, Leading Edge also released an innovative database application called Nutshell (developed by a company called Nashoba Systems and distributed by Leading Edge). Nutshell was an earlier form of a program later released as FileMaker and subsequently FileMaker Pro.


Load task register

The LTR x86 instruction stands for load task register and is used in operating systems that support multitasking. LTR is supported only in protected mode and long mode, not in real mode or virtual 8086 mode. It must be executed when the Current Privilege Level (CPL) is 0, and therefore cannot be used by application programs. LTR loads the special x86 task register with a segment selector that points to a task state segment (TSS). After executing the LTR instruction, the TSS pointed to by the argument is marked busy, but no hardware task switch occurs.
The opposite of the LTR instruction is the STR instruction, which means store task register and copies the value of the task register to the specified location. Note that the x86 task register is only accessible directly through the LTR and STR instructions.


List of downloadable PlayStation Portable games

This is a list of games for Sony's PlayStation Portable (PSP) handheld game console that are available to download from the PlayStation Store. It does not include PlayStation Minis or PSOne Classics.
PSP games.
List of the 807 PSP games available to download from the PlayStation Store. Almost all first-party PSP games released after October 1, 2009 will be available for download.


VIA Eden

VIA Eden is a name of a variant of VIA's C3/C7 x86 processors, designed to be used in embedded devices. They have smaller package sizes, lower power consumption, and somewhat lower computing performance than their C equivalents, due to reduced clock rates. They are often used in EPIA mini-ITX, nano-ITX, and Pico-ITX motherboards. In addition to x86 instruction decoding, the processors have a second undocumented Alternate Instruction Set.
The Eden is available in four main versions:
The Eden ULV 500 MHz was the first variant to achieve a TDP of 1W .


NTDOS.SYS


AT (form factor)

In the era of IBM compatible personal computers, the AT form factor referred to the dimensions and layout (form factor) of the motherboard for the IBM AT. Baby AT motherboards are a little smaller, measuring 8.5" by 13". Like the IBM PC and IBM XT models before it, many third-party manufacturers produced motherboards compatible with the IBM AT form factor, allowing end users to upgrade their computers for faster processors. The IBM AT became a widely copied design in the booming home computer market of the 1980s. IBM clones made at the time began using AT compatible designs, contributing to its popularity. In the 1990s many computers still used AT and its variants. Since 1997, the AT form factor has been largely supplanted by ATX.
Design.
The original AT motherboard, later known as "Full AT", is , which means it will not fit in "mini desktop" or "minitower cases". The board's size also means that it takes up space behind the drive bays, making installation of new drives more difficult. (In IBM's original heavy-gauge steel case, the two 5-1/4" full-height drive bays overhang the front of the motherboard. More precisely, the left bay overhangs the motherboard, while the right bay is subdivided into two half-height bays and additionally extends downward toward the bottom of the chassis, allowing a second full-height fixed disk to be installed below a single half-height drive.)
The power connectors for AT motherboards are two nearly identical 6-pin plugs and sockets. As designed by IBM, the connectors are mechanically keyed so that each can only be inserted in its correct position, but some clone manufacturers cut costs and used unkeyed (interchangeable) connectors. Unfortunately, the two power connectors it requires are not easily distinguishable, leading many people to damage their boards when they were improperly connected; when plugged in, the two black wires on each connector must be adjacent to each other, making a row of 4 consecutive black wires (out of the total 12). Technicians developed mnemonic devices to help assure proper installation, including "black wires together in the middle" and "red and red and you are dead."
Variants.
In 1987, the Baby AT form factor was introduced, based on the motherboard found in the IBM PC/XT 286 (5162) and soon after all computer makers abandoned AT for the cheaper and smaller Baby AT form factor, using it for computers that spanned several generations, from those that used 286 processors to the P5 Pentium and a limited number of Pentium II systems. These motherboards have similar mounting hole positions and the same eight card slot locations as those with the AT form factor, but are 8.5 in (216 mm) wide and marginally shorter than full-size AT boards, with a maximum length of 13 in (330 mm). However, Baby AT boards were mostly shorter than this, typically 9 to 10 in (229 to 254 mm). The size and flexibility of this kind of motherboard were the key to success of this format. The development of bigger CPU coolers—and the fact that they blocked full-length PCI and ISA cards—spelled the end of Baby AT and was the main impetus for its successor ATX. While the AT standard is now considered to be mostly obsolete, some industrial computers still use it.
In 1995, Intel introduced ATX, a form factor which gradually replaced older Baby AT motherboards. During the late 1990s, a great majority of boards were either Baby AT or ATX. Many motherboard manufacturers favored Baby AT over ATX as many computer cases and power supplies in the industry were still designed for AT boards and not ATX boards. Also, the lack of an eighth slot on ATX motherboards kept it from being used in some servers. Later Baby AT boards supported both AT and ATX power connectors in addition to ATX features such as standby power (allowing for a low voltage power switch, as well as Wake-on-LAN/Wake-on-Modem Ring) and USB by use of an ATX Form Card. After the industry shifted to ATX motherboard configurations, it became common to design cases and power supplies to support both Baby AT and ATX motherboards.
Power connector.
The connector at the board is two Molex 15-48-0106 connectors. This mates with a Molex 90331.


OS X Mountain Lion

OS X Mountain Lion (version 10.8) is the ninth major release of macOS, Apple Inc.'s desktop and server operating system for Macintosh computers. OS X Mountain Lion was released on July 25, 2012 for purchase and download through Apple's Mac App Store, as part of a switch to releasing OS X versions online and every year, rather than every two years or so. Named to signify its status as a refinement of the previous Mac OS X version, Lion, Apple's stated aims in developing Mountain Lion were to allow users to more easily manage and synchronise content between multiple Apple devices and to make the operating system more familiar.
The operating system gained the new malware-blocking system Gatekeeper and integration with Apple's online Game Center and iCloud services, while the Safari web browser was updated to version 6. As on iOS, Notes and Reminders became full applications, separate from Mail and Calendar, while the iChat application was replaced with a version of iOS's Messages. Mountain Lion also added a version of iOS's Notification Center, which groups updates from different applications in one place. Integrated links allowing the user to rapidly transfer content to Twitter were present in the operating system from launch. Facebook integration was also planned but unfinished at launch date. It was released as a downloadable update later.
OS X Mountain Lion received positive reviews, with critics praising Notification Center, Messages, and speed improvements over Mac OS X Lion, while criticizing iCloud for unreliability and Game Center for lack of games. Mountain Lion sold three million units in the first four days, and has sold 28 million units as of June 10, 2013, making it Apple's most popular OS X release. Mountain Lion was the last paid upgrade for an OS X major release, with OS X Mavericks and later being free.
History.
OS X Mountain Lion was officially announced by Apple on their website on February 16, 2012, as a successor to Mac OS X 10.7 Lion. It achieved golden master status on July 9, 2012. Following a soft transition started with Mac OS X Lion, Apple consistently refers to OS X Mountain Lion as "OS X" rather than "Mac OS X".
During the Apple Worldwide Developers Conference keynote on June 11, 2012, Apple announced a "near final" release version of Mountain Lion for developers, with the public version arriving in July 2012 at a price tag of US$19.99 (€15.99 in Europe, £13.99 in the UK, $20.99 in Australia and ￥128 in Mainland China). The third generation MacBook Pro, revised MacBook Air, iPad Smart Case, and third-generation AirPort Express were announced at the keynote as well.
The specific release date of July 25 was not confirmed until the day before, July 24, by Apple CEO, Tim Cook, as part of Apple's 2012 third-quarter earnings announcement. It was released to the Mac App Store on July 25, 2012, where it sold 3 million units in the first four days of release.
An update for Mountain Lion, version 10.8.1, was released on August 23, 2012. It resolved issues with iMessages, Migration Assistant, Safari, Microsoft Exchange Server, Mail, and many other applications. Tests of the update revealed that 10.8.1 also improved battery life on laptops, albeit gaining back only half of the battery life that was lost in updating to Mountain Lion. Although 10.8.1 improved battery life for some customers, others continue to complain about reduced battery life and a constant drop in battery health, ultimately resulting in a "Service Battery" message.
System requirements.
The official system requirements of OS X 10.8 are 2 GB RAM, 8 GB available storage, OS X 10.6.8 (Snow Leopard) or later, on any of the following Macs:
As in 10.7, the earliest models supporting AirDrop are the late-2008 MacBook Pro, late-2010 MacBook Air, late-2008 MacBook, mid-2010 Mac Mini, and early-2009 Mac Pro with an AirPort Extreme card. Any Mac released in or after 2011, except the MacBook, supports AirPlay Mirroring. Power Nap is supported on the mid-2011 or newer MacBook Air and the MacBook Pro with Retina display.
The technical basis for these requirements is incompatibility with 32-bit EFI and 32-bit kernel extensions (most importantly, drivers for GPUs shipped in some older Macs). In order to prevent potentially incompatible systems from installing 10.8, the installer contains a whitelist of supported motherboard IDs. Users have bypassed these limitations so that 10.8 may run with varying functionality on some officially unsupported computers.
New and changed features.
Notification Center.
Notification Center was added in the operating system. It provides an overview of alerts from applications and displays notifications until the user completes an associated action, rather than requiring instant resolution. Users may choose what applications appear in Notification Center, and how they are handled. There are three types of notifications: banners, alerts, and badges. Banners are displayed for a short period of time in the upper right corner of the Mac's screen, and then slide off to the right. The icon of the application is displayed on the left side of the banner, while the message from the application will be displayed on the right side. Alerts are the same as banners, but will not disappear from the screen until the user takes action. Badges are red notification icons that are displayed on the application's icon. They indicate the number of items available for the application.
Notification Center can be accessed by clicking the icon in the right corner of the menu bar. When open, the user can click a button to tweet, post status updates to Facebook, or view all notifications in the sidebar pane. Swiping up will reveal the option to disable Notification Center for one day. Many settings of Notification Center can be customized under the "Notifications" pane in System Preferences. Each application can have three ways to display notifications: none, banners, and alerts. Options to toggle the app icons and sounds are also available. Users can click and drag an app in the pane to change the order the applications are displayed within Notification Center.
Notes.
Notes, another transfer from iOS, is added. It is separate from Mail in its own application, with support for desktop notes added (syncs along with its iOS counterpart). Created notes are synced through all the user's Apple devices through the iCloud service. Notes can be arranged in folders, and pinned to the user's desktop. When the application is closed, the pinned note still remains.
Notes can be created in three different default fonts - Noteworthy, Marker Felt, and Helvetica. Users can add custom fonts by visiting the menu. The menu allows users to change text size, format lists, choose the alignment (left, center, justify, or right), assign a writing direction, and indent text. Attachments, images, and hyperlinks can also be added into a note. Attachments cannot be viewed on iOS devices.
Messages.
Messages, an instant messaging software application, is added in Mountain Lion. It was announced on February 16, 2012, as part of the OS X Mountain Lion developer preview. Starting with this release, Messages replaced iChat as the default OS X instant-messaging client. A free beta version of Messages was available to download for Mac OS X Lion from the Apple website until June 2012. The final version of Messages was included with the release version of OS X Mountain Lion.
As with its predecessor, Messages has text messaging, audio, and screen-sharing capabilities. Messages also contains native video conversation support, utilizing Apple's FaceTime video calling application where possible. However, it does retain video capabilities for interfacing with other instant messaging clients. Messages supports Apple's iMessage, a free instant messaging service previously only available on devices running iOS 5. It also supports both Extensible Messaging and Presence Protocol (XMPP) (shown in the application under its former name, Jabber) and the AOL Instant Messenger (AIM) OSCAR protocol. It also offers a direct connection to Yahoo! Messenger and Google Talk.
Game Center.
The Game Center application from iOS was added in OS X Mountain Lion. It is an online multiplayer social-gaming network, and allows users to invite friends to play a game, start a multiplayer game through matchmaking, track their achievements, and compare their high scores on a leader board. Points are awarded to players as a part of Game Center's achievement tracking system. Players can earn points by meeting specific in-game challenges.
A player must establish an Apple ID to associate with a Game Center nickname. A player has the option to create an Apple ID from within Game Center if they do not already have one. Only one nickname may be associated with an Apple ID at any given time. Each player is assigned a profile in Game Center. A profile consists of the player's nickname, the number of Game Center-compatible games the player owns, the number of friends the player has, the number of achievement points a player has, and an optional photo and player-defined status.
Application updates.
OS X Mountain Lion added updates for many applications on the operating system. The Chess app supports Game Center. Dashboard widgets can be managed in a UI similar to Launchpad. Mail adds new VIP feature to save frequent contacts. The Preview app gets an improved user interface. It is able to fill out forms in PDF documents that don't contain actual PDF form fields. Reminders is a new to-do list application, separate from Calendar in its own application that syncs along with its iOS counterpart. Safari 6 gets a new release and features a new address bar; a combination of the address bar and the search field. The address bar also has a "Reader" button, showing the user just the text of the article without advertisements and distraction. When the user is on a website with no article, the button is disabled. Safari 6 is available as a download for Mac OS X Lion. Time Machine is able to do rotating backups on more than one storage medium.
Other updates.
AirPlay Mirroring is added, which allows wireless mirroring of a Mac's screen to an Apple TV. System-wide integration of AirPlay audio transmission is added. There are many new features for Chinese users, including support for Baidu as an option for Safari search engine, QQ, 163.com and 126.com services for Mail, Contacts and Calendar, Youku, Tudou and Sina Weibo are integrated into share sheets. Dictation, new in Mountain Lion, is a system-wide voice input mechanism that requires a broadband Internet connection. Facebook gained full integration following an update in late 2012. Some of the features include single-sign on and integration in Notification Center, Contacts and Share Sheets. Gatekeeper, also new to Mountain Lion, is an anti-malware feature based on digital signatures and the Mac App Store.
Power Nap allows flash storage-based Macintoshes (late 2010 MacBook Air and later, or the MacBook Pro with Retina display) to synchronize with iCloud (Reminders, Calendars, Photo Stream, Notes, Mail, and Find My Mac) while sleeping and also allows a Mac to download App Store and OS X updates as well as make periodic Time Machine backups when it is plugged in and sleeping. Several new screensavers were added. Share Sheets, a "Share" button and dialog box in Safari and other applications, are added. Twitter was integrated with almost all of the applications, with single-sign on, tweeting from an app, Tweet Sheets, tweeting photos and links, using multiple Twitter accounts, Twitter notifications, profile picture integration, and Location Services available.
Application updates automatically install from the Mac App Store. The iCloud library User interface (UI) was integrated throughout the operating systems, which includes new Open and Save dialog boxes across built-in applications, iWork and third-party applications via an Application programming interface (API). Applications that make use of this API support a new user interface to view and manage documents in the cloud that are specific to the application being used. Documents can be renamed from the title bar. iWork documents automatically synchronize with iCloud. The full screen ability is on every display.
The Dock has received an updated look, emulating the appearance of the aluminum metal surface that much of Apple's current hardware line-up sports. Scroll bars widen when the mouse hovers over them. Finder displays a progress bar in the "size" column when copying a file, and on icons in Launchpad when downloading from the Mac App Store. Launchpad has Spotlight search for finding applications. Address Book was renamed "Contacts", and iCal was renamed "Calendar".
Reception.
Reception for OS X Mountain Lion has generally been positive, with users considering it to be a major improvement over 10.7 Lion. John Siracusa of Ars Technica said that 10.8 corrected and simplified UI changes made with Lion, saying that it had become "what 10.7 should've been" and that the faster speeds and features merit the upgrade, then adding that "If we'd had to wait for two years after 10.6 for the next major release of OS X, chances are good that the worst of the missteps in Lion would just be landing on our doorsteps today. I'll take 10.8, thanks." Many reviewers found that Mountain Lion was far more stable than its predecessor, including Jason Snell of "Macworld", who said "All told, I found Mountain Lion to be a stable, solid release. Even prerelease builds were far more stable than I've come to expect from OS X betas, leading me to wonder if Apple's new annual schedule is leading to more careful incremental updates (with fewer bugs) rather than great leaps (with more, nastier bugs)."
The general attitude towards Mountain Lion was that it was faster and smoother, including Brian Heater of Engadget, who said the following:
MG Siegler of TechCrunch said that the difference between Lion and Mountain Lion was not comparable to the difference between Leopard and Snow Leopard because Mountain Lion adds many new features that were not available in Lion. He also praised the application compatibility and said that the only updates needed were to add Notification Center features to applications. Jim Dalrymple of The Loop commented "there will be tens of thousands of words published on Wednesday when Mountain Lion hits the Mac App Store, but let's face it, what you really want to know is whether Mountain Lion is worth the upgrade. Let's get that out of the way now — yes, it is definitely worth it," and said that at $19.99, Mountain Lion was a "bargain". David Pogue of "The New York Times" said "Over all, then, Mountain Lion is a gentle, thoughtful upgrade. All 200 new features? No, not really. But 10 that you'll use every day? For $20? Yes."
While the operating system in general was well received, some reviewers dissented from that viewpoint. Jesus Diaz of Gizmodo felt that Apple was running out of ideas and that Microsoft's Windows 8 may out-innovate OS X. Apple also received criticism for failing to provide an official upgrade pathway for owners of 2006 Mac Pro workstation computers.
Game Center was the most criticised aspect of Mountain Lion. Reviewers criticized the service for the lack of games available, reliability issues and the lack of integration with iOS games. Scott Stein of CNET commented "Game Center-compatible titles will have achievements, leaderboard info...and, potentially, a way of playing cross-platform games. As of the time of this post, I could find only seven Game Center games featured the Mac App Store," and "Until Game Center becomes a complete portal for all games on the Mac, and a true method of cross-platform iOS/Mac play, I'm not sure many people will even bother checking it out." Matt Clark of "MacLife" also commented that if developers don't develop applications for Game Center, it is "likely doomed to sit unnoticed on your hard drive".
Mountain Lion sold 3 million units in the first four days, making it Apple's most successful OS X release to date. A report by Chitika Insights revealed that OS X Mountain Lion had been used by 3.2% of OS X users within the first 48 hours of release, and 10% penetration in the first month.
Release history.
Note: Combo updates include all previous releases (ex: 10.8 to 10.8.3). Individual update is a smaller package size and can be used if currently using the previous release (ex: 10.8.2 to 10.8.3).


PlayStation Multitap

The PlayStation Multitap is a peripheral for the PlayStation. It is an adapter that can be used to plug in up to four controllers and memory cards at the same time in a single controller port. With a second multitap, up to eight controllers and memory cards can be plugged at once.
Compatibility.
The PlayStation Multitap was originally available in gray (SCPH-1070 U) to match the original console's color, however it was later re-released in white as well (SCPH-1070 UH) to match the colors of the later PS one redesign. There was also a smaller version (SCPH-111). All three versions are compatible with the original PlayStation and the PS one, as well as all models of the PlayStation 2 prior to the SCPH-70000 series. Both versions of SCPH-1070 will only function with original PlayStation games, while multiplayer PS2 games required a separate multitap, the SCPH-10090. PlayStation 2 consoles after the SCPH-70000 series require the SCPH-70120 multitap, which is compatible with both PS and PS2 software.
Supported games.
1–3 Players
1–4 Players
1–5 Players
1–6 Players
1–8 Players


Master boot record

A master boot record (MBR) is a special type of boot sector at the very beginning of partitioned computer mass storage devices like fixed disks or removable drives intended for use with IBM PC-compatible systems and beyond. The concept of MBRs was publicly introduced in 1983 with PC DOS 2.0.
The MBR holds the information on how the logical partitions, containing file systems, are organized on that medium. The MBR also contains executable code to function as a loader for the installed operating system—usually by passing control over to the loader's second stage, or in conjunction with each partition's volume boot record (VBR). This MBR code is usually referred to as a boot loader.
The organization of the partition table in the MBR limits the maximum addressable storage space of a partitioned disk to 2 TiB . Approaches to slightly raise this limit assuming 33-bit arithmetics or 4096-byte sectors are not officially supported, as they fatally break compatibility with existing boot loaders and most MBR-compliant operating systems and system tools, and can cause serious data corruption when used outside of narrowly controlled system environments. Therefore, the MBR-based partitioning scheme is in the process of being superseded by the GUID Partition Table (GPT) scheme in new computers. A GPT can coexist with an MBR in order to provide some limited form of backward compatibility for older systems.
MBRs are not present on non-partitioned media such as floppies, superfloppies, or other storage devices configured to behave as such.
Overview.
Support for partitioned media, and thereby the master boot record (MBR), was introduced with IBM PC DOS 2.0 in March 1983 in order to support the 10 MB hard disk of the then-new IBM Personal Computer XT, still using the FAT12 file system. The original version of the MBR was written by David Litton of IBM in June 1982. The partition table supported up to four "primary partitions", of which DOS could only use one. This did not change when FAT16 was introduced as a new file system with DOS 3.0. Support for an "extended partition", a special primary partition type used as a container to hold other partitions, was added with DOS 3.2, and nested "logical drives" inside an extended partition came with DOS 3.30. Since MS-DOS, PC DOS, OS/2 and Windows were never enabled to boot off them, the MBR format and boot code remained almost unchanged in functionality, except for in some third-party implementations, throughout the eras of DOS and OS/2 up to 1996.
In 1996, support for logical block addressing (LBA) was introduced in Windows 95B and DOS 7.10 in order to support disks larger than 8 GB. "Disk timestamps" were also introduced. This also reflected the idea that the MBR is meant to be operating system and file system independent. However, this design rule was partially compromised in more recent Microsoft implementations of the MBR, which enforce CHS access for FAT16B and FAT32 partition types /, whereas LBA is used for /.
Despite sometimes poor documentation of certain intrinsic details of the MBR format (which occasionally caused compatibility problems), it has been widely adopted as a de facto industry standard, due to the broad popularity of PC-compatible computers and its semi-static nature over decades. This was even to the extent of being supported by computer operating systems for other platforms. Sometimes this was in addition to other pre-existing or cross-platform standards for bootstrapping and partitioning.
MBR partition entries and the MBR boot code used in commercial operating systems, however, are limited to 32 bits. Therefore, the maximum disk size supported on disks using 512-byte sectors (whether real or emulated) by the MBR partitioning scheme (without 33-bit arithmetic) is limited to 2 TiB. Consequently, a different partitioning scheme must be used for larger disks, as they have become widely available since 2010. The MBR partitioning scheme is therefore in the process of being superseded by the GUID Partition Table (GPT). The official approach does little more than ensuring data integrity by employing a "protective MBR". Specifically, it does not provide backward compatibility with operating systems that do not support the GPT scheme as well. Meanwhile, multiple forms of "hybrid MBRs" have been designed and implemented by third parties in order to maintain partitions located in the first physical 2 TiB of a disk in both partitioning schemes "in parallel" and/or to allow older operating systems to boot off GPT partitions as well. The present non-standard nature of these solutions causes various compatibility problems in certain scenarios.
The MBR consists of 512 or more bytes located in the first sector of the drive.
It may contain one or more of:
Disk partitioning.
IBM PC DOS 2.0 introduced the codice_1 utility to set up and maintain MBR partitions. When a storage device has been partitioned according to this scheme, its MBR contains a partition table describing the locations, sizes, and other attributes of linear regions referred to as partitions.
The partitions themselves may also contain data to describe more complex partitioning schemes, such as extended boot records (EBRs), BSD disklabels, or Logical Disk Manager metadata partitions.
The MBR is not located in a partition; it is located at a first sector of the device (physical offset 0), preceding the first partition. (The boot sector present on a non-partitioned device or within an individual partition is called a volume boot record instead.) In cases where the computer is running a DDO BIOS overlay or boot manager, the partition table may be moved to some other physical location on the device; e.g., Ontrack Disk Manager often placed a copy of the original MBR contents in the second sector, then hid itself from any subsequently booted OS or application, so the MBR copy was treated as if it were still residing in the first sector.
Sector layout.
By convention, there are exactly four primary partition table entries in the MBR partition table scheme, although some operating systems and system tools extended this to five (Advanced Active Partitions (AAP) with PTS-DOS 6.60 and DR-DOS 7.07), eight (AST and NEC MS-DOS 3.x as well as Storage Dimensions SpeedStor), or even sixteen entries (with Ontrack Disk Manager).
Partition table entries.
An artifact of hard disk technology from the era of the PC XT, the partition table subdivides a storage medium using units of cylinders, heads, and sectors (CHS addressing). These values no longer correspond to their namesakes in modern disk drives, as well as being irrelevant in other devices such as solid-state drives, which do not physically have cylinders or heads.
In the CHS scheme, sector indices have (almost) always begun with sector 1 rather than sector 0 by convention, and due to an error in all versions of MS-DOS/PC DOS up to including 7.10, the number of heads is generally limited to 255 instead of 256. When a CHS address is too large to fit into these fields, the tuple (1023, 254, 63) is typically used today, although on older systems, and with older disk tools, the cylinder value often wrapped around modulo the CHS barrier near 8 GB, causing ambiguity and risks of data corruption. (If the situation involves a "protective" MBR on a disk with a GPT, Intel's Extensible Firmware Interface specification requires that the tuple (1023, 255, 63) be used.) The 10-bit cylinder value is recorded within two bytes in order to facilitate making calls to the original/legacy INT 13h BIOS disk access routines, where 16 bits were divided into sector and cylinder parts, and not on byte boundaries.
Due to the limits of CHS addressing, a transition was made to using LBA, or logical block addressing. Both the partition length and partition start address are sector values stored in the partition table entries as 32-bit quantities. The sector size used to be considered fixed at 512 (29) bytes, and a broad range of important components including chipsets, boot sectors, operating systems, database engines, partitioning tools, backup and file system utilities and other software had this value hard-coded. Since the end of 2009, disk drives employing 4096-byte sectors (4Kn or Advanced Format) have been available, although the size of the sector for some of these drives was still reported as 512 bytes to the host system through conversion in the hard-drive firmware and referred to as 512 emulation drives (512e).
Since block addresses and sizes are stored in the partition table of an MBR using 32 bits, the maximum size, as well as the highest start address, of a partition using drives that have 512-byte sectors (actual or emulated) cannot exceed 2 TiB−512 bytes ( bytes or (232−1) sectors × 512 (29) bytes per sector). Alleviating this capacity limitation was one of the prime motivations for the development of the GPT.
Since partitioning information is stored in the MBR partition table using a beginning block address and a length, it may in theory be possible to define partitions in such a way that the allocated space for a disk with 512-byte sectors gives a total size approaching 4 TiB, if all but one partition are located below the 2 TiB limit and the last one is assigned as starting at or close to block 232−1 and specify the size as up to 232−1, thereby defining a partition that requires 33 rather than 32 bits for the sector address to be accessed. However, in practice, only certain LBA-48-enabled operating systems, including Linux, FreeBSD and Windows 7 that use 64-bit sector addresses internally actually support this. Due to code space constraints and the nature of the MBR partition table to only support 32 bits, boot sectors, even if enabled to support LBA-48 rather than LBA-28, often use 32-bit calculations, unless they are specifically designed to support the full address range of LBA-48 or are intended to run on 64-bit platforms only. Any boot code or operating system using 32-bit sector addresses internally would cause addresses to wrap around accessing this partition and thereby result in serious data corruption over all partitions.
For disks that present a sector size other than 512 bytes, such as USB external drives, there are limitations as well. A sector size of 4096 results in an eight-fold increase in the size of a partition that can be defined using MBR, allowing partitions up to 16 TiB (232 × 4096 bytes) in size. Versions of Windows more recent than Windows XP support the larger sector sizes, as well as Mac OS X, and Linux has supported larger sector sizes since 2.6.31 or 2.6.32, but issues with boot loaders, partitioning tools and computer BIOS implementations present certain limitations, since they are often hard-wired to reserve only 512 bytes for sector buffers, causing memory to become overwritten for larger sector sizes. This may cause unpredictable behaviour as well, and therefore should be avoided when compatibility and standard conformity is an issue.
Where a data storage device has been partitioned with the GPT scheme, the master boot record will still contain a partition table, but its only purpose is to indicate the existence of the GPT and to prevent utility programs that understand only the MBR partition table scheme from creating any partitions in what they would otherwise see as free space on the disk, thereby accidentally erasing the GPT.
System bootstrapping.
On IBM PC-compatible computers, the bootstrapping firmware (contained within the ROM BIOS) loads and executes the master boot record. The PC/XT (type 5160) used an Intel 8088 microprocessor. In order to remain compatible, all x86 architecture systems start with the microprocessor in an operating mode referred to as real mode. The BIOS reads the MBR from the storage device into physical memory, and then it directs the microprocessor to the start of the boot code. Since the BIOS runs in real mode, the processor is in real mode when the MBR program begins to execute, and so the beginning of the MBR is expected to contain real-mode machine code.
Since the BIOS bootstrap routine loads and runs exactly one sector from the physical disk, having the partition table in the MBR with the boot code simplifies the design of the MBR program. It contains a small program that loads the Volume Boot Record (VBR) of the targeted partition. Control is then passed to this code, which is responsible for loading the actual operating system. This process is known as chain loading.
Popular MBR code programs were created for booting PC DOS and MS-DOS, and similar boot code remains in wide use. These boot sectors expect the codice_1 partition table scheme to be in use and scans the list of partitions in the MBR's embedded partition table to find the only one that is marked with the "active flag". It then loads and runs the volume boot record (VBR) of the active partition.
There are alternative boot code implementations, some of which are installed by boot managers, which operate in a variety of ways. Some MBR code loads additional code for a boot manager from the first track of the disk, which it assumes to be "free" space that is not allocated to any disk partition, and executes it. A MBR program may interact with the user to determine which partition on which drive should boot, and may transfer control to the MBR of a different drive. Other MBR code contains a list of disk locations (often corresponding to the contents of files in a filesystem) of the remainder of the boot manager code to load and to execute. (The first relies on behavior that is not universal across all disk partitioning utilities, most notably those that read and write GPTs. The last requires that the embedded list of disk locations be updated when changes are made that would relocate the remainder of the code.)
On machines that do not use x86 processors, or on x86 machines with non-BIOS firmware such as Open Firmware or Extensible Firmware Interface (EFI) firmware, this design is unsuitable, and the MBR is not used as part of the system bootstrap. EFI firmware is instead capable of directly understanding the GPT partitioning scheme and the FAT filesystem format, and loads and runs programs held as files in the EFI System partition. The MBR will be involved only insofar as it might contain a partition table for compatibility purposes if the GPT partition table scheme has been used.
There is some MBR replacement code that emulates EFI firmware's bootstrap, which makes non-EFI machines capable of booting from disks using the GPT partitioning scheme. It detects a GPT, places the processor in the correct operating mode, and loads the EFI compatible code from disk to complete this task.
Disk identity.
In addition to the bootstrap code and a partition table, master boot records may contain a disk signature. This is a 32-bit value that is intended to identify uniquely the disk medium (as opposed to the disk unit—the two not necessarily being the same for removable hard disks).
The disk signature was introduced by Windows NT version 3.5, but it is now used by several operating systems, including the Linux kernel version 2.6 and later. Linux tools can use the NT disk signature to determine which disk the machine booted from.
Windows NT (and later Microsoft operating systems) uses the disk signature as an index to all the partitions on any disk ever connected to the computer under that OS; these signatures are kept in Windows Registry keys, primarily for storing the persistent mappings between disk partitions and drive letters. It may also be used in Windows NT BOOT.INI files (though most do not), to describe the location of bootable Windows NT (or later) partitions. One key (among many), where NT disk signatures appear in a Windows 2000/XP registry, is:
 HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices\
If a disk's signature stored in the MBR was (in that order) and its first partition corresponded with logical drive C: under Windows, then the codice_3 data under the key value codice_4 would be:
 A8 E1 B9 D2 00 7E 00 00 00 00 00 00
The first four bytes are said disk signature. (In other keys, these bytes may appear in reverse order from that found in the MBR sector.) These are followed by eight more bytes, forming a 64-bit integer, in little-endian notation, which are used to locate the byte offset of this partition. In this case, corresponds to the hexadecimal value (). Under the assumption that the drive in question reports a sector size of 512 bytes, then dividing this byte offset by 512 results in 63, which is the physical sector number (or LBA) containing the first sector of the partition (unlike the "sector count" used in the sectors value of CHS tuples, which counts from one, the absolute or LBA sector value starts counting from "zero").
If this disk had another partition with the values following the disk signature (under, e.g., the key value codice_5), it would begin at byte offset (), which is also the first byte of physical sector .
Starting with Windows Vista, the disk signature is also stored in the Boot Configuration Data (BCD) store, and the boot process depends on it. If the disk signature changes, cannot be found or has a conflict, Windows is unable to boot. Unless Windows is forced to use the overlapping part of the LBA address of the Advanced Active Partition entry as pseudo-disk signature, Windows' usage is conflictive with the Advanced Active Partition feature of PTS-DOS 7 and DR-DOS 7.07, in particular if their boot code is located outside the first 8 GB of the disk, so that LBA addressing must be used.
Programming considerations.
The MBR originated in the PC XT. IBM PC-compatible computers are little-endian, which means the processor stores numeric values spanning two or more bytes in memory least significant byte first. The format of the MBR on media reflects this convention. Thus, the MBR signature will appear in a disk editor as the sequence codice_6.
The bootstrap sequence in the BIOS will load the first valid MBR that it finds into the computer's physical memory at address :. The last instruction executed in the BIOS code will be a "jump" to that address in order to direct execution to the beginning of the MBR copy. The primary validation for most BIOSes is the signature at offset , although a BIOS implementer may choose to include other checks, such as verifying that the MBR contains a valid partition table without entries referring to sectors beyond the reported capacity of the disk.
To the BIOS, removable (e.g. floppy) and fixed disks are essentially the same. For either, the BIOS reads the first physical sector of the media into RAM at absolute address , checks the signature in the last two bytes of the loaded sector, and then, if the correct signature is found, transfers control to the first byte of the sector with a jump (JMP) instruction. The only real distinction that the BIOS makes is that (by default, or if the boot order is not configurable) it attempts to boot from the first removable disk before trying to boot from the first fixed disk. From the perspective of the BIOS, the action of the MBR loading a volume boot record into RAM is exactly the same as the action of a floppy disk volume boot record loading the object code of an operating system loader into RAM. In either case, the program that the BIOS loaded is going about the work of chain loading an operating system.
While the MBR boot sector code expects to be loaded at physical address :, all the memory from physical address : (address : is the last one used by a Phoenix BIOS) to :, later relaxed to : (and sometimes up to :)the end of the first 640 KBis available in real mode. The codice_7 BIOS interrupt call may help in determining how much memory can be allocated safely (by default, it simply reads the base memory size in KB from segment:offset location :, but it may be hooked by other resident pre-boot software like BIOS overlays, RPL code or viruses to reduce the reported amount of available memory in order to keep other boot stage software like boot sectors from overwriting them).
The last 66 bytes of the 512-byte MBR are reserved for the partition table and other information, so the MBR boot sector program must be small enough to fit within 446 bytes of memory or less.
The MBR code examines the partition table, selects a suitable partition and loads the program that will perform the next stage of the boot process, usually by making use of INT 13h BIOS calls. The MBR bootstrap code loads and runs (a boot loader- or operating system-dependent) volume boot record code that is located at the beginning of the "active" partition. The volume boot record will fit within a 512-byte sector, but it is safe for the MBR code to load additional sectors to accommodate boot loaders longer than one sector, provided they do not make any assumptions on what the sector size is. In fact, at least 1 KB of RAM is available at address in every IBM XT- and AT-class machine, so a 1 KB sector could be used with no problem. Like the MBR, a volume boot record normally expects to be loaded at address :. This derives from the fact that the volume boot record design originated on unpartitioned media, where a volume boot record would be directly loaded by the BIOS boot procedure; as mentioned above, the BIOS treats MBRs and volume boot records (VBRs) exactly alike. Since this is the same location where the MBR is loaded, one of the first tasks of an MBR is to relocate itself somewhere else in memory. The relocation address is determined by the MBR, but it is most often : (for MS-DOS/PC DOS, OS/2 and Windows MBR code) or : (most DR-DOS MBRs). (Even though both of these segmented addresses resolve to the same physical memory address in real mode, for Apple Darwin to boot, the MBR must be relocated to : instead of :, since the code depends on the DS:SI pointer to the partition entry provided by the MBR, but it erroneously refers to it via :SI only.) It is important not to relocate to other addresses in memory because many VBRs will assume a certain standard memory layout when loading their boot file.
The "Status" field in a partition table record is used to indicate an active partition. Standard-conformant MBRs will allow only one partition marked active and use this as part of a sanity-check to determine the existence of a valid partition table. They will display an error message, if more than one partition has been marked active. Some non-standard MBRs will not treat this as an error condition and just use the first marked partition in the row.
Traditionally, values other than (not active) and (active) were invalid and the bootstrap program would display an error message upon encountering them. However, the Plug and Play BIOS Specification and BIOS Boot Specification (BBS) allowed other devices to become bootable as well since 1994. Consequently, with the introduction of MS-DOS 7.10 (Windows 95B) and higher, the MBR started to treat a set bit 7 as active flag and showed an error message for values .. only. It continued to treat the entry as physical drive unit to be used when loading the corresponding partition's VBR later on, thereby now also accepting other boot drives than as valid, however, MS-DOS did not make use of this extension by itself. Storing the actual physical drive number in the partition table does not normally cause backward compatibility problems, since the value will differ from "only" on drives other than the first one (which have not been bootable before, anyway). However, even with systems enabled to boot off other drives, the extension may still not work universally, for example, after the BIOS assignment of physical drives has changed when drives are removed, added or swapped. Therefore, per the BIOS Boot Specification (BBS), it is best practice for a modern MBR accepting bit 7 as active flag to pass on the DL value originally provided by the BIOS instead of using the entry in the partition table.
BIOS to MBR interface.
The MBR is loaded at memory location : and with the following CPU registers set up when the prior bootstrap loader (normally the IPL in the BIOS) passes execution to it by jumping to : in the CPU's real mode.
Systems with Plug-and-Play BIOS or BBS support will provide a pointer to PnP data in addition to DL:
MBR to VBR interface.
By convention, a standard conformant MBR passes execution to a successfully loaded VBR, loaded at memory location :, by jumping to : in the CPU's real mode with the following registers maintained or specifically set up:
The MBR code passes additional information to the VBR in many implementations:
Under DR-DOS 7.07 an extended interface may be optionally provided by the extended MBR and in conjunction with LOADER:
In conjunction with GPT, an "Enhanced Disk Drive Specification" (EDD) 4 Hybrid MBR proposal recommends another extension to the interface:
Editing and replacing contents.
Though it is possible to manipulate the bytes in the MBR sector directly using various disk editors, there are tools to write fixed sets of functioning code to the MBR. Since MS-DOS 5.0, the program codice_1 has included the switch codice_19, which will rewrite the MBR code. Under Windows 2000 and Windows XP, the Recovery Console can be used to write new MBR code to a storage device using its codice_20 command. Under Windows Vista and Windows 7, the Recovery Environment can be used to write new MBR code using the codice_21 command.
Some third-party utilities may also be used for directly editing the contents of partition tables (without requiring any knowledge of hexadecimal or disk/sector editors), such as MBRWizard.
codice_22 is also a commonly used POSIX command to read or write to any location on a storage device, MBR included. In Linux, ms-sys may be used to install a Windows MBR. The GRUB and LILO projects have tools for writing code to the MBR sector, namely codice_23 and codice_24. The GRUB Legacy interactive console can write to the MBR, using the codice_25 and codice_26 commands, but GRUB2 currently requires codice_23 to be run from within an operating system.
Various programs are able to create a "backup" of both the primary partition table and the logical partitions in the extended partition.
Linux codice_28 (on a SystemRescueCD) is able to save a backup of the primary and extended partition table. It creates a file that can be read in a text editor, or this file can be used by sfdisk to restore the primary/extended partition table. An example command to back up the partition table is codice_29 and to restore is codice_30. It is possible to copy the partition table from one disk to another this way, useful for setting up mirroring, but sfdisk executes the command without prompting/warnings using codice_31.


Death Duel (video game)

Death Duel is a First person perspective scrolling shooter developed by Razor Soft for the Sega Genesis in 1992. In it, players have to strategically shoot nine alien enemies one at a time using all the weapons they could afford.
Story.
Taking place in the future year 2140, the nine of the ten Galactic Federations had gained unwarranted control over galaxy flight traffic and territory. This has caused the one remaining Federation to suffer a loss of supplies and space pirate attacks. The dispute can only be settled through a warranted duel with the Federation's one duelist to fight against the collective nine alien duelists representing the nine Galactic Federations in control of the space traffic ways, otherwise known as The Super 9's. The player assumes the role of Barrett Jade, a mecha pilot to win back the space ways and duel against the nine other duelists.
Gameplay.
Players started the game off with their first duel with a set number of ammunition for their weapons; the player's robot had a total of three weapons indicated by all three buttons on the controller. Once the player completed the duel, they would go through a type of Bonus Stage that would qualify them for the next duel as well as increase their score and money. Players could then purchase more ammunition or even new weapons for their robot at a local shop.
Players had to time their attacks and aim precisely for key locations of their opponents body. Some enemies could regenerate missing parts of their body (including their head) while some enemies depended on particular mechanical parts to evade fire.
If the player ran out of ammunition for all their weapons before the duel was over, they would lose a life and restart the duel over (with the same amount of ammunition they started the duel with). If the duel timer ran out before the duel was over, the player would also lose a life and restart the duel.


Group identifier

In Unix-like systems, multiple users can be put into "groups". POSIX and conventional Unix file system permissions are organized into three classes, "user", "group", and "others". The use of groups allows additional abilities to be delegated in an organized fashion, such as access to disks, printers, and other peripherals. This method, among others, also enables the superuser to delegate some administrative tasks to normal users, similar to the "Administrators" group on Microsoft Windows NT and its derivatives.
A group identifier, often abbreviated to GID, is a numeric value used to represent a specific group. The range of values for a GID varies amongst different systems; at the very least, a GID can be between 0 and 32,767, with one restriction: the login group for the superuser must have GID 0. This numeric value is used to refer to groups in the codice_1 and codice_2 files or their equivalents. Shadow password files and Network Information Service also refer to numeric GIDs. The group identifier is a necessary component of Unix file systems and processes.
Supplementary groups.
In Unix systems, every user must be a member of at least one group, the primary group, which is identified by the numeric GID of the user's entry in the passwd database, which can be viewed with the command codice_3 (usually stored in codice_1 or LDAP). This group is referred to as the "primary group ID". A user may be listed as member of additional groups in the relevant entries in the group database, which can be viewed with codice_5 (usually stored in codice_2 or LDAP); the IDs of these groups are referred to as "supplementary group IDs".
Effective vs. real.
Unix processes have an effective (EUID, EGID), a real (UID, GID) and a saved (SUID, SGID) ID. Normally these are identical, but in codice_7 and codice_8 processes they are different.
Conventions.
Type.
Originally, a signed 16-bit integer was used. Since the sign was not necessary – negative numbers do not make valid group IDs – an unsigned integer is now used instead, allowing group IDs between 0 and 65,535. Modern operating systems usually use unsigned 32-bit integers, which allow for group IDs between 0 and 4,294,967,295.
Reserved ranges.
Many Linux systems reserve the GID number range 0 to 99 for statically allocated groups, and either 100−499 or 100−999 for groups dynamically allocated by the system in post-installation scripts. These ranges are often specified in codice_9, for codice_10, codice_11 and similar tools.
On FreeBSD, porters who need a GID for their package can pick a free one from the range 50 to 999 and then register this static allocation in ports/GIDs.
Personal groups.
Many system administrators allocate for each user also a personal primary group that has the same name as the user's login name, and often also has the same numeric GID as the user's UID. Such personal groups have no other members and make collaboration with other users in shared directories easier, by allowing users to habitually work with codice_13. This way, newly created files can have by default write permissions enabled for group members, because this will normally only enable write access for members of the personal group, that is only for the file's owner. However, if a file is created in a shared directory that belongs to another group and has the setgid bit set, then the created file will automatically become writable to members of that directory's group as well.
On many Linux systems, the codice_14 variable in codice_9 controls whether commands like codice_10 or codice_17 automatically add or delete an associated personal group.


Datapath

A datapath is a collection of functional units such as arithmetic logic units or multipliers that perform data processing operations, registers, and buses. Along with the control unit it composes the central processing unit (CPU). A larger datapath can be made by joining more than one datapaths using multiplexers.
A data path is the ALU, the set of registers, and the CPU's internal bus(es) that allow data to flow between them.
The simplest design for a CPU uses one common internal bus.
Efficient addition requires a slightly more complicated three-internal-bus structure.
Many relatively simple CPUs have a 2-read, 1-write register file
connected to the 2 inputs and 1 output of the ALU.
During the late 1990s, there was growing research in the area of reconfigurable datapaths—datapaths that may be re-purposed at run-time using programmable fabric—as such designs may allow for more efficient processing as well as substantial power savings.


List of AMD A microprocessors


Madden NFL 2002

Madden NFL 2002 (also known as Madden 2002) is an American football video game. It features former Minnesota Vikings quarterback Daunte Culpepper on the cover. Pat Summerall and John Madden are the commentators. The "Madden NFL 2002" commercial first aired during Super Bowl XXXVI, three days after "Madden NFL 2002" started selling in Japan by Electronic Arts Square. Notably, it does not feature the Super Bowl MVP Tom Brady, who is included on later editions of the game as a roster update. It is also the first game to be developed by Budcat Creations.
Features.
"Madden NFL 2002" features play now, season, franchise, tournament, create-a-player and create-a-team modes. It also has the Madden Card feature. Along with being a GameCube and Xbox launch title, it was one of the last releases for the Nintendo 64 and Game Boy Color. This is the first "Madden" game to feature the Houston Texans in the team select (although they did not begin play for another year after the game's debut). It was bundled with "NBA Live 2002" and "NASCAR Thunder 2002" as part of the EA 2002 collector's edition for the PlayStation. Also the game featured the 2002 Expansion Draft where the player can add the 32nd team into the league, but it will force the Seattle Seahawks to move into the NFC (which will occur in the second season of the 30-season Franchise mode).
The Baltimore Ravens had the best team overall in the game with the score of 99. The worst team in the game belongs to the Houston Texans with the score of 39. The best offense in the game belongs to the St. Louis Rams with the score of 96. The best defense in the game belongs to the Baltimore Ravens with the score of 96. The best special teams in the game belongs to seven different teams (Minnesota Vikings, Tennessee Titans, Baltimore Ravens, Detroit Lions, Indianapolis Colts, San Diego Chargers, and Denver Broncos) all with scores of 99.
Also included as an extra is a version of "Madden NFL '94" (except for the N64 port, which has "Madden NFL '93" from the Sega Genesis), albeit with an updated roster due to licensing issues.
Reception.
In the United States, "Madden NFL 2002"s computer version sold 310,000 copies and earned $9.7 million by August 2006, after its release in August 2001. It was the country's 59th best-selling computer game between January 2000 and August 2006. Combined sales of all "Madden NFL" computer games released between January 2000 and August 2006 had reached 1.9 million units in the United States by the latter date.
The game was met with nearly universal acclaim. GameRankings and Metacritic gave it a score of 92.32% and 94 out of 100 for the PlayStation 2 version; 90.39% and 89 out of 100 for the GameCube version; 88.72% and 90 out of 100 for the Xbox version; 85.08% and 88 out of 100 for the PlayStation version; 79.83% and 78 out of 100 for the Nintendo 64 version; 72.27% and 71 out of 100 for the PC version; 68.67% for the Game Boy Color version; and 62.67% and 76 out of 100 for the Game Boy Advance version. In Japan, "Famitsu" gave the PS2 version a score of 33 out of 40.
"GameSpot" named "Madden NFL 2002" a runner-up in its annual award categories for the best Xbox game, best Nintendo 64 game, and best traditional sports console game.