In digital logic, a don't-care term[1][2] (abbreviated DC, historically also known as redundancies,[2] irrelevancies,[2] optional entries,[3][4] invalid combinations,[5][4] vacuous combinations,[6][4] forbidden combinations,[7][2] unused states or logical remainders[8]) for a function is an input-sequence (a series of bits) for which the function output does not matter. An input that is known to never occur is a can't-happen term.[9][10][11][12] Both these types of conditions are treated the same way in logic design and may be referred to collectively as don't-care conditions for brevity.[13] The designer of a logic circuit to implement the function need not care about such inputs, but can choose the circuit's output arbitrarily, usually such that the simplest circuit results (minimization).
Don't-care terms are important to consider in minimizing logic circuit design, including graphical methods like Karnaugh–Veitch maps and algebraic methods such as the Quine–McCluskey algorithm. In 1958, Seymour Ginsburg proved that minimization of states of a finite-state machine with don't-care conditions does not necessarily yield a minimization of logic elements. Direct minimization of logic elements in such circuits was computationally impractical (for large systems) with the computing power available to Ginsburg in 1958.[14]
https://en.wikipedia.org/wiki/Don%27t-care_term
Examples
ba dc |
00 | 01 | 11 | 10 |
|---|---|---|---|---|
| 00 | 1 | 0 | 0 | 1 |
| 01 | 0 | 0 | 0 | 1 |
| 11 | 0 | 0 | 0 | 1 |
| 10 | 1 | 0 | 0 | 1 |
ba dc |
00 | 01 | 11 | 10 |
|---|---|---|---|---|
| 00 | 1 | 0 | 0 | 1 |
| 01 | 0 | 0 | 0 | 1 |
| 11 | x | x | x | x |
| 10 | 1 | 0 | x | x |
ba dc |
00 | 01 | 11 | 10 |
|---|---|---|---|---|
| 00 | 
|
|
|
|
| 01 | 
|
|
|
|
| 11 |
|
|
|
|
| 10 | 
|
|
|
|
Examples of don't-care terms are the binary values 1010 through 1111 (10 through 15 in decimal) for a function that takes a binary-coded decimal (BCD) value, because a BCD value never takes on such values (so called pseudo-tetrades); in the pictures, the circuit computing the lower left bar of a 7-segment display can be minimized to a b + a c by an appropriate choice of circuit outputs for dcba = 1010…1111.
Write-only registers, as frequently found in older hardware, are often a consequence of don't-care optimizations in the trade-off between functionality and the number of necessary logic gates.[15]
Don't-care states can also occur in encoding schemes and communication protocols.[nb 1]
X value
"Don't care" may also refer to an unknown value in a multi-valued logic system, in which case it may also be called an X value or don't know.[16] In the Verilog hardware description language such values are denoted by the letter "X". In the VHDL hardware description language such values are denoted (in the standard logic package) by the letter "X" (forced unknown) or the letter "W" (weak unknown).[17]
An X value does not exist in hardware. In simulation, an X value can result from two or more sources driving a signal simultaneously, or the stable output of a flip-flop not having been reached. In synthesized hardware, however, the actual value of such a signal will be either 0 or 1, but will not be determinable from the circuit's inputs.[17]
Power-up states
Further considerations are needed for logic circuits that involve some feedback. That is, those circuits that depend on the previous output(s) of the circuit as well as its current external inputs. Such circuits can be represented by a state machine. It is sometimes possible that some states that are nominally can't-happen conditions can accidentally be generated during power-up of the circuit or else by random interference (like cosmic radiation, electrical noise or heat). This is also called forbidden input.[18] In some cases, there is no combination of inputs that can exit the state machine into a normal operational state. The machine remains stuck in the power-up state or can be moved only between other can't-happen states in a walled garden of states. This is also called a hardware lockup or soft error. Such states, while nominally can't-happen, are not don't-care, and designers take steps either to ensure that they are really made can't-happen, or else if they do happen, that they create a don't-care alarm indicating an emergency state[18] for error detection, or they are transitory and lead to a normal operational state.[19][20][21]
See also
- Decision table
- Side effect
- Short-circuit evaluation
- Incomplete address decoding
- Incomplete opcode decoding
- Logic redundancy
- Undefined behaviour
- Undefined variable
- Uninitialized variable
- Four-valued logic
- Nine-valued logic
Notes
https://en.wikipedia.org/wiki/Don%27t-care_term
https://en.wikipedia.org/wiki/Category:Logic
In computing and electronic systems, binary-coded decimal (BCD) is a class of binary encodings of decimal numbers where each digit is represented by a fixed number of bits, usually four or eight. Sometimes, special bit patterns are used for a sign or other indications (e.g. error or overflow).
In byte-oriented systems (i.e. most modern computers), the term unpacked BCD[1] usually implies a full byte for each digit (often including a sign), whereas packed BCD typically encodes two digits within a single byte by taking advantage of the fact that four bits are enough to represent the range 0 to 9. The precise 4-bit encoding, however, may vary for technical reasons (e.g. Excess-3).
The ten states representing a BCD digit are sometimes called tetrades[2][3] (the nibble typically needed to hold them is also known as a tetrade) while the unused, don't care-states are named pseudo-tetrad(e)s,[4][5][6][7][8] pseudo-decimals[3] or pseudo-decimal digits.[9][10][nb 1]
BCD's main virtue, in comparison to binary positional systems, is its more accurate representation and rounding of decimal quantities, as well as its ease of conversion into conventional human-readable representations. Its principal drawbacks are a slight increase in the complexity of the circuits needed to implement basic arithmetic as well as slightly less dense storage.
BCD was used in many early decimal computers, and is implemented in the instruction set of machines such as the IBM System/360 series and its descendants, Digital Equipment Corporation's VAX, the Burroughs B1700, and the Motorola 68000-series processors. BCD per se is not as widely used as in the past, and is unavailable or limited in newer instruction sets (e.g., ARM; x86 in long mode). However, decimal fixed-point and decimal floating-point formats are still important and continue to be used in financial, commercial, and industrial computing, where the subtle conversion and fractional rounding errors that are inherent in binary floating point formats cannot be tolerated.[11]
https://en.wikipedia.org/wiki/Binary-coded_decimal#Pseudo-tetrade
Zoned decimal
Some implementations, for example IBM mainframe systems, support zoned decimal numeric representations. Each decimal digit is stored in one byte, with the lower four bits encoding the digit in BCD form. The upper four bits, called the "zone" bits, are usually set to a fixed value so that the byte holds a character value corresponding to the digit. EBCDIC systems use a zone value of 1111 (hex F); this yields bytes in the range F0 to F9 (hex), which are the EBCDIC codes for the characters "0" through "9". Similarly, ASCII systems use a zone value of 0011 (hex 3), giving character codes 30 to 39 (hex).
For signed zoned decimal values, the rightmost (least significant) zone nibble holds the sign digit, which is the same set of values that are used for signed packed decimal numbers (see above). Thus a zoned decimal value encoded as the hex bytes F1 F2 D3 represents the signed decimal value −123:
F1 F2 D3 1 2 −3
EBCDIC zoned decimal conversion table
| BCD digit | Hexadecimal | EBCDIC character | ||||||
|---|---|---|---|---|---|---|---|---|
| 0+ | C0 | A0 | E0 | F0 | { (*) | \ (*) | 0 | |
| 1+ | C1 | A1 | E1 | F1 | A | ~ (*) | 1 | |
| 2+ | C2 | A2 | E2 | F2 | B | s | S | 2 |
| 3+ | C3 | A3 | E3 | F3 | C | t | T | 3 |
| 4+ | C4 | A4 | E4 | F4 | D | u | U | 4 |
| 5+ | C5 | A5 | E5 | F5 | E | v | V | 5 |
| 6+ | C6 | A6 | E6 | F6 | F | w | W | 6 |
| 7+ | C7 | A7 | E7 | F7 | G | x | X | 7 |
| 8+ | C8 | A8 | E8 | F8 | H | y | Y | 8 |
| 9+ | C9 | A9 | E9 | F9 | I | z | Z | 9 |
| 0− | D0 | B0 | } (*) | ^ (*) | ||||
| 1− | D1 | B1 | J | |||||
| 2− | D2 | B2 | K | |||||
| 3− | D3 | B3 | L | |||||
| 4− | D4 | B4 | M | |||||
| 5− | D5 | B5 | N | |||||
| 6− | D6 | B6 | O | |||||
| 7− | D7 | B7 | P | |||||
| 8− | D8 | B8 | Q | |||||
| 9− | D9 | B9 | R | |||||
(*) Note: These characters vary depending on the local character code page setting.
Fixed-point zoned decimal
Some languages (such as COBOL and PL/I) directly support fixed-point zoned decimal values, assigning an implicit decimal point at some location between the decimal digits of a number. For example, given a six-byte signed zoned decimal value with an implied decimal point to the right of the fourth digit, the hex bytes F1 F2 F7 F9 F5 C0 represent the value +1,279.50:
F1 F2 F7 F9 F5 C0 1 2 7 9. 5 +0
BCD in computers
IBM
IBM used the terms Binary-Coded Decimal Interchange Code (BCDIC, sometimes just called BCD), for 6-bit alphanumeric codes that represented numbers, upper-case letters and special characters. Some variation of BCDIC alphamerics is used in most early IBM computers, including the IBM 1620 (introduced in 1959), IBM 1400 series, and non-Decimal Architecture members of the IBM 700/7000 series.
The IBM 1400 series are character-addressable machines, each location being six bits labeled B, A, 8, 4, 2 and 1, plus an odd parity check bit (C) and a word mark bit (M). For encoding digits 1 through 9, B and A are zero and the digit value represented by standard 4-bit BCD in bits 8 through 1. For most other characters bits B and A are derived simply from the "12", "11", and "0" "zone punches" in the punched card character code, and bits 8 through 1 from the 1 through 9 punches. A "12 zone" punch set both B and A, an "11 zone" set B, and a "0 zone" (a 0 punch combined with any others) set A. Thus the letter A, which is (12,1) in the punched card format, is encoded (B,A,1). The currency symbol $, (11,8,3) in the punched card, was encoded in memory as (B,8,2,1). This allows the circuitry to convert between the punched card format and the internal storage format to be very simple with only a few special cases. One important special case is digit 0, represented by a lone 0 punch in the card, and (8,2) in core memory.[43]
The memory of the IBM 1620 is organized into 6-bit addressable digits, the usual 8, 4, 2, 1 plus F, used as a flag bit and C, an odd parity check bit. BCD alphamerics are encoded using digit pairs, with the "zone" in the even-addressed digit and the "digit" in the odd-addressed digit, the "zone" being related to the 12, 11, and 0 "zone punches" as in the 1400 series. Input/Output translation hardware converted between the internal digit pairs and the external standard 6-bit BCD codes.
In the Decimal Architecture IBM 7070, IBM 7072, and IBM 7074 alphamerics are encoded using digit pairs (using two-out-of-five code in the digits, not BCD) of the 10-digit word, with the "zone" in the left digit and the "digit" in the right digit. Input/Output translation hardware converted between the internal digit pairs and the external standard 6-bit BCD codes.
With the introduction of System/360, IBM expanded 6-bit BCD alphamerics to 8-bit EBCDIC, allowing the addition of many more characters (e.g., lowercase letters). A variable length Packed BCD numeric data type is also implemented, providing machine instructions that perform arithmetic directly on packed decimal data.
On the IBM 1130 and 1800, packed BCD is supported in software by IBM's Commercial Subroutine Package.
Today, BCD data is still heavily used in IBM processors and databases, such as IBM Db2, mainframes, and Power6. In these products, the BCD is usually zoned BCD (as in EBCDIC or ASCII), Packed BCD (two decimal digits per byte), or "pure" BCD encoding (one decimal digit stored as BCD in the low four bits of each byte). All of these are used within hardware registers and processing units, and in software. To convert packed decimals in EBCDIC table unloads to readable numbers, you can use the OUTREC FIELDS mask of the JCL utility DFSORT.[44]
Other computers
The Digital Equipment Corporation VAX-11 series includes instructions that can perform arithmetic directly on packed BCD data and convert between packed BCD data and other integer representations.[41] The VAX's packed BCD format is compatible with that on IBM System/360 and IBM's later compatible processors. The MicroVAX and later VAX implementations dropped this ability from the CPU but retained code compatibility with earlier machines by implementing the missing instructions in an operating system-supplied software library. This is invoked automatically via exception handling when the defunct instructions are encountered, so that programs using them can execute without modification on the newer machines.
The Intel x86 architecture supports a unique 18-digit (ten-byte) BCD format that can be loaded into and stored from the floating point registers, from where computations can be performed.[45]
The Motorola 68000 series had BCD instructions.[46]
In more recent computers such capabilities are almost always implemented in software rather than the CPU's instruction set, but BCD numeric data are still extremely common in commercial and financial applications. There are tricks for implementing packed BCD and zoned decimal add–or–subtract operations using short but difficult to understand sequences of word-parallel logic and binary arithmetic operations.[47] For example, the following code (written in C) computes an unsigned 8-digit packed BCD addition using 32-bit binary operations:
uint32_t BCDadd(uint32_t a, uint32_t b)
{
uint32_t t1, t2; // unsigned 32-bit intermediate values
t1 = a + 0x06666666;
t2 = t1 ^ b; // sum without carry propagation
t1 = t1 + b; // provisional sum
t2 = t1 ^ t2; // all the binary carry bits
t2 = ~t2 & 0x11111110; // just the BCD carry bits
t2 = (t2 >> 2) | (t2 >> 3); // correction
return t1 - t2; // corrected BCD sum
}
BCD in electronics
 |
This section has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these template messages)
|
BCD is very common in electronic systems where a numeric value is to be displayed, especially in systems consisting solely of digital logic, and not containing a microprocessor. By employing BCD, the manipulation of numerical data for display can be greatly simplified by treating each digit as a separate single sub-circuit. This matches much more closely the physical reality of display hardware—a designer might choose to use a series of separate identical seven-segment displays to build a metering circuit, for example. If the numeric quantity were stored and manipulated as pure binary, interfacing with such a display would require complex circuitry. Therefore, in cases where the calculations are relatively simple, working throughout with BCD can lead to an overall simpler system than converting to and from binary. Most pocket calculators do all their calculations in BCD.
The same argument applies when hardware of this type uses an embedded microcontroller or other small processor. Often, representing numbers internally in BCD format results in smaller code, since a conversion from or to binary representation can be expensive on such limited processors. For these applications, some small processors feature dedicated arithmetic modes, which assist when writing routines that manipulate BCD quantities.[48][49]
Operations with BCD
Addition
It is possible to perform addition by first adding in binary, and then converting to BCD afterwards. Conversion of the simple sum of two digits can be done by adding 6 (that is, 16 − 10) when the five-bit result of adding a pair of digits has a value greater than 9. The reason for adding 6 is that there are 16 possible 4-bit BCD values (since 24 = 16), but only 10 values are valid (0000 through 1001). For example:
1001 + 1000 = 10001 9 + 8 = 17
10001 is the binary, not decimal, representation of the desired result, but the most significant 1 (the "carry") cannot fit in a 4-bit binary number. In BCD as in decimal, there cannot exist a value greater than 9 (1001) per digit. To correct this, 6 (0110) is added to the total, and then the result is treated as two nibbles:
10001 + 0110 = 00010111 => 0001 0111 17 + 6 = 23 1 7
The two nibbles of the result, 0001 and 0111, correspond to the digits "1" and "7". This yields "17" in BCD, which is the correct result.
This technique can be extended to adding multiple digits by adding in groups from right to left, propagating the second digit as a carry, always comparing the 5-bit result of each digit-pair sum to 9. Some CPUs provide a half-carry flag to facilitate BCD arithmetic adjustments following binary addition and subtraction operations. The Intel 8080, the Zilog Z80[50] and the CPUs of the x86 family[51] provide the opcode DAA (Decimal Adjust Accumulator).
Subtraction
Subtraction is done by adding the ten's complement of the subtrahend to the minuend. To represent the sign of a number in BCD, the number 0000 is used to represent a positive number, and 1001 is used to represent a negative number. The remaining 14 combinations are invalid signs. To illustrate signed BCD subtraction, consider the following problem: 357 − 432.
In signed BCD, 357 is 0000 0011 0101 0111. The ten's complement of 432 can be obtained by taking the nine's complement of 432, and then adding one. So, 999 − 432 = 567, and 567 + 1 = 568. By preceding 568 in BCD by the negative sign code, the number −432 can be represented. So, −432 in signed BCD is 1001 0101 0110 1000.
Now that both numbers are represented in signed BCD, they can be added together:
0000 0011 0101 0111 0 3 5 7 + 1001 0101 0110 1000 9 5 6 8 = 1001 1000 1011 1111 9 8 11 15
Since BCD is a form of decimal representation, several of the digit sums above are invalid. In the event that an invalid entry (any BCD digit greater than 1001) exists, 6 is added to generate a carry bit and cause the sum to become a valid entry. So, adding 6 to the invalid entries results in the following:
1001 1000 1011 1111 9 8 11 15 + 0000 0000 0110 0110 0 0 6 6 = 1001 1001 0010 0101 9 9 2 5
Thus the result of the subtraction is 1001 1001 0010 0101 (−925). To confirm the result, note that the first digit is 9, which means negative. This seems to be correct since 357 − 432 should result in a negative number. The remaining nibbles are BCD, so 1001 0010 0101 is 925. The ten's complement of 925 is 1000 − 925 = 75, so the calculated answer is −75.
If there are a different number of nibbles being added together (such as 1053 − 2), the number with the fewer digits must first be prefixed with zeros before taking the ten's complement or subtracting. So, with 1053 − 2, 2 would have to first be represented as 0002 in BCD, and the ten's complement of 0002 would have to be calculated.
Comparison with pure binary
Advantages
- Many non-integral values, such as decimal 0.2, have an infinite place-value representation in binary (.001100110011...) but have a finite place-value in binary-coded decimal (0.0010). Consequently, a system based on binary-coded decimal representations of decimal fractions avoids errors representing and calculating such values. This is useful in financial calculations.
- Scaling by a power of 10 is simple.
- Rounding at a decimal digit boundary is simpler. Addition and subtraction in decimal do not require rounding.[dubious ]
- The alignment of two decimal numbers (for example 1.3 + 27.08) is a simple, exact shift.
- Conversion to a character form or for display (e.g., to a text-based format such as XML, or to drive signals for a seven-segment display) is a simple per-digit mapping, and can be done in linear (O(n)) time. Conversion from pure binary involves relatively complex logic that spans digits, and for large numbers, no linear-time conversion algorithm is known (see Binary numeral system § Conversion to and from other numeral systems).
Disadvantages
- Some operations are more complex to implement. Adders require extra logic to cause them to wrap and generate a carry early. 15 to 20 per cent more circuitry is needed for BCD add compared to pure binary.[citation needed] Multiplication requires the use of algorithms that are somewhat more complex than shift-mask-add (a binary multiplication, requiring binary shifts and adds or the equivalent, per-digit or group of digits is required).
- Standard BCD requires four bits per digit, roughly 20 per cent more space than a binary encoding (the ratio of 4 bits to log210 bits is 1.204). When packed so that three digits are encoded in ten bits, the storage overhead is greatly reduced, at the expense of an encoding that is unaligned with the 8-bit byte boundaries common on existing hardware, resulting in slower implementations on these systems.
- Practical existing implementations of BCD are typically slower than operations on binary representations, especially on embedded systems, due to limited processor support for native BCD operations.[52]
Representational variations
Various BCD implementations exist that employ other representations for numbers. Programmable calculators manufactured by Texas Instruments, Hewlett-Packard, and others typically employ a floating-point BCD format, typically with two or three digits for the (decimal) exponent. The extra bits of the sign digit may be used to indicate special numeric values, such as infinity, underflow/overflow, and error (a blinking display).
Signed variations
Signed decimal values may be represented in several ways. The COBOL programming language, for example, supports five zoned decimal formats, with each one encoding the numeric sign in a different way:
| Type | Description | Example |
|---|---|---|
| Unsigned | No sign nibble | F1 F2 F3
|
| Signed trailing (canonical format) | Sign nibble in the last (least significant) byte | F1 F2 C3
|
| Signed leading (overpunch) | Sign nibble in the first (most significant) byte | C1 F2 F3
|
| Signed trailing separate | Separate sign character byte ('+' or '−') following the digit bytes
|
F1 F2 F3 2B
|
| Signed leading separate | Separate sign character byte ('+' or '−') preceding the digit bytes
|
2B F1 F2 F3
|
Telephony binary-coded decimal (TBCD)
3GPP developed TBCD,[53] an expansion to BCD where the remaining (unused) bit combinations are used to add specific telephony characters,[54][55] with digits similar to those found in telephone keypads original design.
| Decimal digit |
TBCD 8 4 2 1 |
|---|---|
| * | 1 0 1 0 |
| # | 1 0 1 1 |
| a | 1 1 0 0 |
| b | 1 1 0 1 |
| c | 1 1 1 0 |
| Used as filler when there is an odd number of digits | 1 1 1 1 |
The mentioned 3GPP document defines TBCD-STRING with swapped nibbles in each byte. Bits, octets and digits indexed from 1, bits from the right, digits and octets from the left.
bits 8765 of octet n encoding digit 2n
bits 4321 of octet n encoding digit 2(n – 1) + 1
Meaning number 1234, would become 21 43 in TBCD.
Alternative encodings
If errors in representation and computation are more important than the speed of conversion to and from display, a scaled binary representation may be used, which stores a decimal number as a binary-encoded integer and a binary-encoded signed decimal exponent. For example, 0.2 can be represented as 2×10−1.
This representation allows rapid multiplication and division, but may require shifting by a power of 10 during addition and subtraction to align the decimal points. It is appropriate for applications with a fixed number of decimal places that do not then require this adjustment—particularly financial applications where 2 or 4 digits after the decimal point are usually enough. Indeed, this is almost a form of fixed point arithmetic since the position of the radix point is implied.
The Hertz and Chen–Ho encodings provide Boolean transformations for converting groups of three BCD-encoded digits to and from 10-bit values[nb 1] that can be efficiently encoded in hardware with only 2 or 3 gate delays. Densely packed decimal (DPD) is a similar scheme[nb 1] that is used for most of the significand, except the lead digit, for one of the two alternative decimal encodings specified in the IEEE 754-2008 floating-point standard.
Application
The BIOS in many personal computers stores the date and time in BCD because the MC6818 real-time clock chip used in the original IBM PC AT motherboard provided the time encoded in BCD. This form is easily converted into ASCII for display.[56][57]
The Atari 8-bit family of computers used BCD to implement floating-point algorithms. The MOS 6502 processor has a BCD mode that affects the addition and subtraction instructions. The Psion Organiser 1 handheld computer's manufacturer-supplied software also entirely used BCD to implement floating point; later Psion models used binary exclusively.
Early models of the PlayStation 3 store the date and time in BCD. This led to a worldwide outage of the console on 1 March 2010. The last two digits of the year stored as BCD were misinterpreted as 16 causing an error in the unit's date, rendering most functions inoperable. This has been referred to as the Year 2010 problem.
Legal history
In the 1972 case Gottschalk v. Benson, the U.S. Supreme Court overturned a lower court's decision that had allowed a patent for converting BCD-encoded numbers to binary on a computer. The decision noted that a patent "would wholly pre-empt the mathematical formula and in practical effect would be a patent on the algorithm itself".[58] This was a landmark judgement that determining the patentability of software and algorithms.
See also
- Bi-quinary coded decimal
- Binary-coded ternary (BCT)
- Binary integer decimal (BID)
- Bitmask
- Chen–Ho encoding
- Decimal computer
- Densely packed decimal (DPD)
- Double dabble, an algorithm for converting binary numbers to BCD
- Year 2000 problem
Notes
- In a similar fashion, multiple characters were often packed into machine words on minicomputers, see IBM SQUOZE and DEC RADIX 50.
References
[…] Die nicht erlaubten 0/1-Muster nennt man auch Pseudodezimalen. […](320 pages)
[…] The last column [of Table II], labeled "Best," gives the maximum fraction possible with any code—namely 0.60—half again better than any conventional code. This extremal is reached with the ten [heavily-marked vertices of the graph of Fig. 4 for n = 4, or, in fact, with any set of ten code combinations which include all eight with an even (or all eight with an odd) number of "1's." The second and third rows of Table II list the average and peak decimal change per undetected single binary error, and have been derived using the equations of Sec. II for Δ1 and δ1. The confusion index for decimals using the criterion of "decimal change," is taken to be cij = |i − j| i,j = 0, 1, … 9. Again, the "Best" arrangement possible (the same for average and peak), one of which is shown in Fig. 4, is substantially better than the conventional codes. […] Fig. 4 Minimum-confusion code for decimals. […] δ1=2 Δ1=15 […][1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] (11 pages) (NB. Besides the combinatorial set of 4-bit BCD "minimum-confusion codes for decimals", of which the author illustrates only one explicitly (here reproduced as code I) in form of a 4-bit graph, the author also shows a 16-state 4-bit "binary code for analog data" in form of a code table, which, however, is not discussed here. The code II shown here is a modification of code I discussed by Berger.)
[…] The cyclic code is advantageous mainly in the use of relay circuits, for then a sticky relay will not give a false state as it is delayed in going from one cyclic number to the next. There are many other cyclic codes that have this property. […][12] (xxiv+835+1 pages) (NB. Ledley classified the described cyclic code as a cyclic decimal-coded binary code.)
[…] When operating on BCD integers in general-purpose registers, the BCD values can be unpacked (one BCD digit per byte) or packed (two BCD digits per byte). The value of an unpacked BCD integer is the binary value of the low halfbyte (bits 0 through 3). The high half-byte (bits 4 through 7) can be any value during addition and subtraction, but must be zero during multiplication and division. Packed BCD integers allow two BCD digits to be contained in one byte. Here, the digit in the high half-byte is more significant than the digit in the low half-byte. […] When operating on BCD integers in x87 FPU data registers, BCD values are packed in an 80-bit format and referred to as decimal integers. In this format, the first 9 bytes hold 18 BCD digits, 2 digits per byte. The least-significant digit is contained in the lower half-byte of byte 0 and the most-significant digit is contained in the upper half-byte of byte 9. The most significant bit of byte 10 contains the sign bit (0 = positive and 1 = negative; bits 0 through 6 of byte 10 are don't care bits). Negative decimal integers are not stored in two's complement form; they are distinguished from positive decimal integers only by the sign bit. The range of decimal integers that can be encoded in this format is −1018 + 1 to 1018 − 1. The decimal integer format exists in memory only. When a decimal integer is loaded in an x87 FPU data register, it is automatically converted to the double-extended-precision floating-point format. All decimal integers are exactly representable in double extended-precision format. […][13]
- Gottschalk v. Benson, 409 U.S. 63, 72 (1972).
Further reading
- Mackenzie, Charles E. (1980). Coded Character Sets, History and Development. The Systems Programming Series (1 ed.). Addison-Wesley Publishing Company, Inc. p. xii. ISBN 0-201-14460-3. LCCN 77-90165. Retrieved 2016-05-22. [14]
- Richards, Richard Kohler (1955). Arithmetic Operations in Digital Computers. New York, USA: van Nostrand. pp. 397–.
- Schmid, Hermann (1974). Decimal Computation (1 ed.). Binghamton, New York, USA: John Wiley & Sons. ISBN 0-471-76180-X. and Schmid, Hermann (1983) [1974]. Decimal Computation (1 (reprint) ed.). Malabar, Florida, USA: Robert E. Krieger Publishing Company. ISBN 0-89874-318-4. (NB. At least some batches of the Krieger reprint edition were misprints with defective pages 115–146.)
- Massalin, Henry (October 1987). Katz, Randy (ed.). "Superoptimizer: A Look at the Smallest Program" (PDF). Proceedings
of the Second International Conference on Architectural Support for
Programming Languages and Operating Systems ACM SIGOPS Operating Systems
Review. 21 (4): 122–126. doi:10.1145/36204.36194. ISBN 0-8186-0805-6. Archived (PDF) from the original on 2017-07-04. Retrieved 2012-04-25. (Also: ACM SIGPLAN Notices, Vol. 22 #10, IEEE Computer Society Press #87CH2440-6, October 1987)
- "GNU Superoptimizer". HP-UX.
- Shirazi, Behrooz; Yun, David Y. Y.; Zhang, Chang N. (March 1988). VLSI designs for redundant binary-coded decimal addition. IEEE Seventh Annual International Phoenix Conference on Computers and Communications, 1988. IEEE. pp. 52–56.
- Brown; Vranesic (2003). Fundamentals of Digital Logic.
- Thapliyal, Himanshu; Arabnia, Hamid R. (November 2006). Modified Carry Look Ahead BCD Adder With CMOS and Reversible Logic Implementation. Proceedings of the 2006 International Conference on Computer Design (CDES'06). CSREA Press. pp. 64–69. ISBN 1-60132-009-4.
- Kaivani, A.; Alhosseini, A. Zaker; Gorgin, S.; Fazlali, M. (December 2006). Reversible Implementation of Densely-Packed-Decimal Converter to and from Binary-Coded-Decimal Format Using in IEEE-754R. 9th International Conference on Information Technology (ICIT'06). IEEE. pp. 273–276.
- Cowlishaw, Mike F. (2009) [2002, 2008]. "Bibliography of material on Decimal Arithmetic – by category". General Decimal Arithmetic. IBM. Retrieved 2016-01-02.
External links
- Cowlishaw, Mike F. (2014) [2000]. "A Summary of Chen-Ho Decimal Data encoding". General Decimal Arithmetic. IBM. Retrieved 2016-01-02.
- Cowlishaw, Mike F. (2007) [2000]. "A Summary of Densely Packed Decimal encoding". General Decimal Arithmetic. IBM. Retrieved 2016-01-02.
- Convert BCD to decimal, binary and hexadecimal and vice versa
- BCD for Java
https://en.wikipedia.org/wiki/Binary-coded_decimal#Pseudo-tetrade
https://en.wikipedia.org/wiki/Logical_shift
https://en.wikipedia.org/wiki/Endianness
https://en.wikipedia.org/wiki/Signed_overpunch
IBM 80-column format and character codes
By the late 1920s, customers wanted to store more data on each punched card. Thomas J. Watson Sr., IBM's head, asked two of his top inventors, Clair D. Lake and J. Royden Pierce, to independently develop ways to increase data capacity without increasing the size of the punched card. Pierce wanted to keep round holes and 45 columns, but allow each column to store more data. Lake suggested rectangular holes, which could be spaced more tightly, allowing 80 columns per punched card, thereby nearly doubling the capacity of the older format.[45] Watson picked the latter solution, introduced as The IBM Card, in part because it was compatible with existing tabulator designs and in part because it could be protected by patents and give the company a distinctive advantage.[46]
This IBM card format, introduced in 1928,[47] has rectangular holes, 80 columns, and 10 rows.[48] Card size is 7+3⁄8 by 3+1⁄4 inches (187 by 83 mm). The cards are made of smooth stock, 0.007 inches (180 μm) thick. There are about 143 cards to the inch (56/cm). In 1964, IBM changed from square to round corners.[49] They come typically in boxes of 2000 cards[50] or as continuous form cards. Continuous form cards could be both pre-numbered and pre-punched for document control (checks, for example).[51]
Initially designed to record responses to yes–no questions, support for numeric, alphabetic and special characters was added through the use of columns and zones. The top three positions of a column are called zone punching positions, 12 (top), 11, and 0 (0 may be either a zone punch or a digit punch).[52] For decimal data the lower ten positions are called digit punching positions, 0 (top) through 9.[52] An arithmetic sign can be specified for a decimal field by overpunching the field's rightmost column with a zone punch: 12 for plus, 11 for minus (CR). For Pound sterling pre-decimalization currency a penny column represents the values zero through eleven; 10 (top), 11, then 0 through 9 as above. An arithmetic sign can be punched in the adjacent shilling column.[53]: 9 Zone punches had other uses in processing, such as indicating a master card.[54]
Diagram:[55] Note: The 11 and 12 zones were also called the X and Y zones, respectively.
_______________________________________________ / &-0123456789ABCDEFGHIJKLMNOPQR/STUVWXYZ 12| x xxxxxxxxx 11| x xxxxxxxxx 0| x xxxxxxxxx 1| x x x x 2| x x x x 3| x x x x 4| x x x x 5| x x x x 6| x x x x 7| x x x x 8| x x x x 9| x x x x |________________________________________________
In 1931, IBM began introducing upper-case letters and special characters (Powers-Samas had developed the first commercial alphabetic punched card representation in 1921).[56][57][nb 1] The 26 letters have two punches (zone [12,11,0] + digit [1–9]). The languages of Germany, Sweden, Denmark, Norway, Spain, Portugal and Finland require up to three additional letters; their punching is not shown here.[58]: 88–90 Most special characters have two or three punches (zone [12,11,0, or none] + digit [2–7] + 8); a few special characters were exceptions: "&" is 12 only, "-" is 11 only, and "/" is 0 + 1). The Space character has no punches.[58]: 38 The information represented in a column by a combination of zones [12, 11, 0] and digits [0–9] is dependent on the use of that column. For example, the combination "12-1" is the letter "A" in an alphabetic column, a plus signed digit "1" in a signed numeric column, or an unsigned digit "1" in a column where the "12" has some other use. The introduction of EBCDIC in 1964 defined columns with as many as six punches (zones [12,11,0,8,9] + digit [1–7]). IBM and other manufacturers used many different 80-column card character encodings.[59][60] A 1969 American National Standard defined the punches for 128 characters and was named the Hollerith Punched Card Code (often referred to simply as Hollerith Card Code), honoring Hollerith.[58]: 7
For some computer applications, binary formats were used, where each hole represented a single binary digit (or "bit"), every column (or row) is treated as a simple bit field, and every combination of holes is permitted.
For example, on the IBM 701[61] and IBM 704,[62] card data was read, using an IBM 711, into memory in row binary format. For each of the twelve rows of the card, 72 of the 80 columns would be read into two 36-bit words; a control panel was used to select the 72 columns to be read. Software would translate this data into the desired form. One convention was to use columns 1 through 72 for data, and columns 73 through 80 to sequentially number the cards, as shown in the picture above of a punched card for FORTRAN. Such numbered cards could be sorted by machine so that if a deck was dropped the sorting machine could be used to arrange it back in order. This convention continued to be used in FORTRAN, even in later systems where the data in all 80 columns could be read.
As an aid to humans who had to deal with the punched cards, the IBM 026 and later 029 and 129 key punch machines could print human-readable text above each of the 80 columns.
As a prank, punched cards could be made where every possible punch position had a hole. Such "lace cards" lacked structural strength, and would frequently buckle and jam inside the machine.[63]
The IBM 80-column punched card format dominated the industry, becoming known as just IBM cards, even though other companies made cards and equipment to process them.[64]
One of the most common punched card formats is the IBM 5081 card format, a general purpose layout with no field divisions. This format has digits printed on it corresponding to the punch positions of the digits in each of the 80 columns. Other punched card vendors manufactured cards with this same layout and number.
IBM Stub card and Short card formats
Long cards were available with a scored stub on either end which, when torn off, left an 80 column card. The torn off card is called a stub card.
80-column cards were available scored, on either end, creating both a short card and a stub card when torn apart. Short cards can be processed by other IBM machines.[51][65] A common length for stub cards was 51 columns. Stub cards were used in applications requiring tags, labels, or carbon copies.[51]
IBM 40-column Port-A-Punch card format
According to the IBM Archive: IBM's Supplies Division introduced the Port-A-Punch in 1958 as a fast, accurate means of manually punching holes in specially scored IBM punched cards. Designed to fit in the pocket, Port-A-Punch made it possible to create punched card documents anywhere. The product was intended for "on-the-spot" recording operations—such as physical inventories, job tickets and statistical surveys—because it eliminated the need for preliminary writing or typing of source documents.[66]
IBM Port-A-Punch
FORTRAN Port-A-Punch card. Compiler directive "SQUEEZE" removed the alternating blank columns from the input.
Port-a-punch
IBM 96-column format
In 1969 IBM introduced a new, smaller, round-hole, 96-column card format along with the IBM System/3 low-end business computer. These cards have tiny, 1 mm diameter circular holes, smaller than those in paper tape. Data are stored in 6-bit BCD, with three rows of 32 characters each, or 8-bit EBCDIC. In this format, each column of the top tiers are combined with two punch rows from the bottom tier to form an 8-bit byte, and the middle tier is combined with two more punch rows, so that each card contains 64 bytes of 8-bit-per-byte binary coded data.[67] As in the 80 column card, readable text was printed in the top section of the card. There was also a 4th row of 32 characters that could be printed. This format was never widely used; it was IBM-only, but they did not support it on any equipment beyond the System/3, where it was quickly superseded by the 1973 IBM 3740 Data Entry System using 8-inch floppy disks.
Powers/Remington Rand/UNIVAC 90-column format
The Powers/Remington Rand card format was initially the same as Hollerith's; 45 columns and round holes. In 1930, Remington Rand leap-frogged IBM's 80 column format from 1928 by coding two characters in each of the 45 columns – producing what is now commonly called the 90-column card.[31]: 142 There are two sets of six rows across each card. The rows in each set are labeled 0, 1/2, 3/4, 5/6, 7/8 and 9. The even numbers in a pair are formed by combining that punch with a 9 punch. Alphabetic and special characters use 3 or more punches.[68][69]
Powers-Samas formats
The British Powers-Samas company used a variety of card formats for their unit record equipment. They began with 45 columns and round holes. Later 36, 40 and 65 column cards were provided. A 130 column card was also available – formed by dividing the card into two rows, each row with 65 columns and each character space with 5 punch positions. A 21 column card was comparable to the IBM Stub card.[53]: 47–51
Mark sense format
Mark sense (electrographic) cards, developed by Reynold B. Johnson at IBM,[70] have printed ovals that could be marked with a special electrographic pencil. Cards would typically be punched with some initial information, such as the name and location of an inventory item. Information to be added, such as quantity of the item on hand, would be marked in the ovals. Card punches with an option to detect mark sense cards could then punch the corresponding information into the card.
Aperture format
Aperture cards have a cut-out hole on the right side of the punched card. A piece of 35 mm microfilm containing a microform image is mounted in the hole. Aperture cards are used for engineering drawings from all engineering disciplines. Information about the drawing, for example the drawing number, is typically punched and printed on the remainder of the card.
Manufacturing
IBM's Fred M. Carroll[71] developed a series of rotary presses that were used to produce punched cards, including a 1921 model that operated at 460 cards per minute (cpm). In 1936 he introduced a completely different press that operated at 850 cpm.[22][72] Carroll's high-speed press, containing a printing cylinder, revolutionized the company's manufacturing of punched cards.[73] It is estimated that between 1930 and 1950, the Carroll press accounted for as much as 25 percent of the company's profits.[21]
Discarded printing plates from these card presses, each printing plate the size of an IBM card and formed into a cylinder, often found use as desk pen/pencil holders, and even today are collectible IBM artifacts (every card layout[74] had its own printing plate).
In the mid-1930s a box of 1,000 cards cost $1.05 (equivalent to $21 in 2021).[75]
Cultural impact
.jpg)
While punched cards have not been widely used for generations, the impact was so great for most of the 20th century that they still appear from time to time in popular culture. For example:
- Accommodation of people's names: The Man Whose Name Wouldn't Fit[76][77]
- Artist and architect Maya Lin in 2004 designed a public art installation at Ohio University, titled "Input", that looks like a punched card from the air.[78]
- Tucker Hall at the University of Missouri – Columbia features architecture that is rumored to be influenced by punched cards. Although there are only two rows of windows on the building, a rumor holds that their spacing and pattern will spell out "M-I-Z beat k-U!" on a punched card, making reference to the university and state's rivalry with neighboring state Kansas.[79]
- At the University of Wisconsin – Madison, the exterior windows of the Engineering Research Building[80] were modeled after a punched card layout, during its construction in 1966.
- At the University of North Dakota in Grand Forks, a portion of the exterior of Gamble Hall (College of Business and Public Administration), has a series of light-colored bricks that resembles a punched card spelling out "University of North Dakota."[81]
- In the 1964–1965 Free Speech Movement, punched cards became a
metaphor... symbol of the "system"—first the registration system and then bureaucratic systems more generally ... a symbol of alienation ... Punched cards were the symbol of information machines, and so they became the symbolic point of attack. Punched cards, used for class registration, were first and foremost a symbol of uniformity. .... A student might feel "he is one of out of 27,500 IBM cards" ... The president of the Undergraduate Association criticized the University as "a machine ... IBM pattern of education."... Robert Blaumer explicated the symbolism: he referred to the "sense of impersonality... symbolized by the IBM technology."...
- — Steven Lubar[28]
- A legacy of the 80 column punched card format is that a display of 80 characters per row was a common choice in the design of character-based terminals.[82][83] As of September 2014, some character interface defaults, such as the command prompt window's width in Microsoft Windows, remain set at 80 columns and some file formats, such as FITS, still use 80-character card images.
- In Arthur C. Clarke's early short story "Rescue Party", the alien explorers find a "... wonderful battery of almost human Hollerith analyzers and the five thousand million punched cards holding all that could be recorded on each man, woman and child on the planet".[84] Writing in 1946, Clarke, like almost all SF authors, had not then foreseen the development and eventual ubiquity of the computer.
- In "I.B.M.", the final track of her album This Is a Recording, comedian Lily Tomlin gives instructions that, if followed, would purportedly shrink the holes on a punch card (used by AT&T at the time for customer billing), making it unreadable.
Do Not Fold, Spindle or Mutilate
A common example of the requests often printed on punched cards which were to be individually handled, especially those intended for the public to use and return is "Do Not Fold, Spindle or Mutilate" (in the UK "Do not bend, spike, fold or mutilate").[28]: 43–55 Coined by Charles A. Phillips,[85] it became a motto[86] for the post–World War II era (even though many people had no idea what spindle meant), and was widely mocked and satirized. Some 1960s students at Berkeley wore buttons saying: "Do not fold, spindle or mutilate. I am a student".[87] The motto was also used for a 1970 book by Doris Miles Disney[88] with a plot based around an early computer dating service and a 1971 made-for-TV movie based on that book, and a similarly titled 1967 Canadian short film, Do Not Fold, Staple, Spindle or Mutilate.
Standards
- ANSI INCITS 21-1967 (R2002), Rectangular Holes in Twelve-Row Punched Cards (formerly ANSI X3.21-1967 (R1997)) Specifies the size and location of rectangular holes in twelve-row 3+1⁄4-inch-wide (83 mm) punched cards.
- ANSI X3.11-1990 American National Standard Specifications for General Purpose Paper Cards for Information Processing
- ANSI X3.26-1980 (R1991) Hollerith Punched Card Code
- ISO 1681:1973 Information processing – Unpunched paper cards – Specification
- ISO 6586:1980 Data processing – Implementation of the ISO 7- bit and 8- bit coded character sets on punched cards. Defines ISO 7-bit and 8-bit character sets on punched cards as well as the representation of 7-bit and 8-bit combinations on 12-row punched cards. Derived from, and compatible with, the Hollerith Code, ensuring compatibility with existing punched card files.
Punched card devices
Processing of punched cards was handled by a variety of machines, including:
- Keypunches—machines with a keyboard that punched cards from operator entered data.
- Unit record equipment—machines that process data on punched cards. Employed prior to the widespread use of digital computers. Includes card sorters, tabulating machines and a variety of other machines
- Computer punched card reader—a computer input device used to read executable computer programs and data from punched cards under computer control.
- Computer card punch—a computer output device that punches holes in cards under computer control.
- Voting machines—used into the 21st century
See also
- Aperture card
- Card image
- Computer programming in the punched card era
- Edge-notched card
- History of computing hardware
- Kimball tag—punched card price tags
- Paper data storage
- Punched card input/output
- Punched tape
- Lace card
Notes
- Special characters are non-alphabetic, non-numeric, such as "&#,$.-/@%*?"
References
semiautomatic
At this early stage, the corresponding playback mechanism, the Mélotrope, was permanently installed inside the same harmonium used for the recording process, but by 1887 Carpentier had modified both devices, restricting the range to three octaves, allowing for the Mélotrope to be attached to any style of keyboard instrument, and designing and constructing an automatic perforating machine for mass production.
After some initial trials with paper tape, he settled on punched cards...
1962: 20th year […] producing savings bonds […] 1964: $75 savings bond […] produce
Security checks issued starting in 1936 […](13 pages); Lubar, Steven (May 1991). "Do not fold, spindle or mutilate: A cultural history of the punch card". Smithsonian Institution. Archived from the original on 2006-08-30. (NB. An earlier version of this paper was presented to the Bureau of the Census's Hollerith Machine Centennial Celebration on 1990-06-20.)
Once the cards were assembled in order in a deck, the programmer would usually draw a long diagonal line across the top edges of the cards, so that if ever one got out of order it would easily be noticed
An important function in IBM Accounting is the automatic preparation of IBM cards.
The IBM 1402 Card Read-Punch provides the system with simultaneous punched-card input and output. This unit has two card feeds.
Master Card: The first card of a group containing fixed or indicative information for that group
The variable-length card feed feature on the 24 or 26 allows the processing of 51-, 60-, 66-, and 80-column cards (Figure 20)
Edward Ziegler […] an editor at the Reader's Digest […] wrote a science fiction novel, The Man Whose Name Wouldn't Fit, under the pen name Theodore Tyler
At the bottom of the bill, it said […] and Jane, in her anger, […]
- Disney, Doris Miles (1970). Do Not Fold, Spindle or Mutilate. Doubleday Crime Club. p. 183.
Further reading
- Fierheller, George A. (2014-02-07). Do not Fold, Spindle or Mutilate: The "hole" story of punched cards (PDF). Markham, Ontario, Canada: Stewart Publishing & Printing. ISBN 978-1-894183-86-4. Archived (PDF) from the original on 2022-07-09. Retrieved 2018-04-03. (NB. An accessible book of recollections (sometimes with errors), with photographs and descriptions of many unit record machines.)
- How to Succeed At Cards (Film). IBM. 1963. (NB. An account of how IBM Cards are manufactured, with special emphasis on quality control.)
- Murray, Francis Joseph (1961). "Chapter 6 Punched Cards". Mathematical Machines: Digital Computers. Vol. 1. Columbia University Press. (NB. Includes a description of Samas punched cards and illustration of an Underwood Samas punched card.)
- Solomon, Jr., Martin B.; Lovan, Nora Geraldine (1967). Annotated Bibliography of Films in Automation, Data Processing, and Computer Science. University of Kentucky.
- Dyson, George (1999-03-01). "The Undead". Wired. Vol. 7, no. 3. Archived from the original on 2022-07-09. Retrieved 2017-07-04. (NB. Article about use of punched cards in the 1990s (Cardamation).)
- Williams, Robert V. (2002). "Punched Cards: A Brief Tutorial". IEEE Annals of the History of Computing: Web Extra. IEEE. 24 (2). Archived from the original on 2018-06-13. Retrieved 2015-03-26.
External links
- An Emulator for Punched cards
- Cardamation at the Wayback Machine (archived 2011-10-17) – a U.S. company that supplied punched card equipment and supplies until 2011.
- Collected Information on Punched Card Codes, Atlas Computer Laboratory, 1960
- Brian De Palma (Director) (1961). 660124: The Story of an IBM Card (Film).
- Jones, Douglas W. "Punched Cards". Retrieved 2006-10-20. (Collection shows examples of left, right, and no corner cuts.)
- Punched Cards – a collection at Gesellschaft für Software mbH
- UNIVAC Punch Card Gallery (Shows examples of both left and right corner cuts.)
- VintageTech – a U.S. company that converts punched cards to conventional media
https://en.wikipedia.org/wiki/Punched_card#IBM_80-column_format_and_character_codes
https://en.wikipedia.org/wiki/Category:Computer-related_introductions_in_1887
https://en.wikipedia.org/wiki/Method_of_complements
https://en.wikipedia.org/wiki/Write-only_memory_(engineering)
https://en.wikipedia.org/wiki/Antithesis
https://en.wikipedia.org/wiki/Read-only_memory
https://en.wikipedia.org/wiki/Write-only_memory_(joke)
https://en.wikipedia.org/wiki/Read-only_memory
Apple
In 1982, Apple published their official Apple IIe Reference Manual (part number A2L2005),[9] which included two references to write-only memory:
On page 233:
- bit bucket: The final resting place of all information; see write-only memory.
On page 250:
- write-only memory: A form of computer memory into which information can be stored but never, ever retrieved, developed under government contract in 1975 by Professor Homberg T. Farnsfarfle. Farnsfarfle's original prototype, approximately one inch on each side, has so far been used to store more than 100 trillion words of surplus federal information. Farnsfarfle's critics have denounced his project as a six-million-dollar boondoggle, but his defenders point out that this excess information would have cost more than 250 billion dollars to store in conventional media.
Originally written by Bruce Tognazzini, the write-only memory definition was unfortunately set upon by certain editors lacking a sense of humor. The second sentence originally read, "Approximately one inch on each side, Farnsfarfle's original prototype has so far been used...." The editors insisted the original contained a misplaced modifier whereas Tognazzini was equally adamant that Farnsfarfle was a very small man. The editors won.[10][11]
https://en.wikipedia.org/wiki/Write-only_memory_(joke)
A ROM cartridge, usually referred to in context simply as a cartridge, cart, or card, is a replaceable part designed to be connected to a consumer electronics device such as a home computer, video game console or, to a lesser extent, electronic musical instruments.[1]
ROM cartridges allow users to rapidly load and access programs and data alongside a floppy drive in a home computer; in a video game console, the cartridges are standalone. At the time around their release, ROM cartridges provided security against unauthorised copying of software. However, the manufacturing of ROM cartridges was more expensive than floppy disks, and the storage capacity was smaller.[2] ROM cartridges and slots were also used for various hardware accessories and enhancements.
The widespread usage of the ROM cartridge in video gaming applications has led it to be often colloquially called a game cartridge.
https://en.wikipedia.org/wiki/ROM_cartridge
https://en.wikipedia.org/wiki/Edge_connector
https://en.wikipedia.org/wiki/Bus_(computing)
In computer architecture, a bus[1] (shortened form of the Latin omnibus, and historically also called data highway[2] or databus) is a communication system that transfers data between components inside a computer, or between computers. This expression covers all related hardware components (wire, optical fiber, etc.) and software, including communication protocols.[3]
Early computer buses were parallel electrical wires with multiple hardware connections, but the term is now used for any physical arrangement that provides the same logical function as a parallel electrical busbar. Modern computer buses can use both parallel and bit serial connections, and can be wired in either a multidrop (electrical parallel) or daisy chain topology, or connected by switched hubs, as in the case of Universal Serial Bus (USB).
Background and nomenclature
Computer systems generally consist of three main parts:
- The central processing unit (CPU) that processes data,
- The memory that holds the programs and data to be processed, and
- I/O (input/output) devices as peripherals that communicate with the outside world.
An early computer might contain a hand-wired CPU of vacuum tubes, a magnetic drum for main memory, and a punch tape and printer for reading and writing data respectively. A modern system might have a multi-core CPU, DDR4 SDRAM for memory, a solid-state drive for secondary storage, a graphics card and LCD as a display system, a mouse and keyboard for interaction, and a Wi-Fi connection for networking. In both examples, computer buses of one form or another move data between all of these devices.
In most traditional computer architectures, the CPU and main memory tend to be tightly coupled. A microprocessor conventionally is a single chip which has a number of electrical connections on its pins that can be used to select an "address" in the main memory and another set of pins to read and write the data stored at that location. In most cases, the CPU and memory share signalling characteristics and operate in synchrony. The bus connecting the CPU and memory is one of the defining characteristics of the system, and often referred to simply as the system bus.
It is possible to allow peripherals to communicate with memory in the same fashion, attaching adapters, either on the motherboard or in the form of expansion cards, directly to the system bus. This is commonly accomplished through some sort of standardized electrical connector, several of these forming the expansion bus or local bus. However, as the performance differences between the CPU and peripherals varies widely, some solution is generally needed to ensure that peripherals do not slow overall system performance. Many CPUs feature a second set of pins similar to those for communicating with memory, but able to operate at very different speeds and using different protocols (Examples include UART, SPI, and Ethernet). Others use smart controllers to place the data directly in memory, a concept known as direct memory access. Most modern systems combine both solutions, where appropriate.
As the number of potential peripherals grew, using an expansion card for every peripheral became increasingly untenable. This has led to the introduction of bus systems designed specifically to support multiple peripherals. Common examples are the SATA ports in modern computers, which allow a number of hard drives to be connected without the need for a card. However, these high-performance systems are generally too expensive to implement in low-end devices, like a mouse. This has led to the parallel development of a number of low-performance bus systems for these solutions, the most common example being the standardized Universal Serial Bus (USB). All such examples may be referred to as peripheral buses, although this terminology is not universal.
In modern systems the performance difference between the CPU and main memory has grown so great that increasing amounts of high-speed memory is built directly into the CPU, known as a cache. In such systems, CPUs communicate using high-performance buses that operate at speeds much greater than memory, and communicate with memory using protocols similar to those used solely for peripherals in the past. These system buses are also used to communicate with most (or all) other peripherals, through adaptors, which in turn talk to other peripherals and controllers. Such systems are architecturally more similar to multicomputers, communicating over a bus rather than a network. In these cases, expansion buses are entirely separate and no longer share any architecture with their host CPU (and may in fact support many different CPUs, as is the case with PCI). What would have formerly been a system bus is now often known as a front-side bus.
Given these changes, the classical terms "system", "expansion" and "peripheral" no longer have the same connotations. Other common categorization systems are based on the bus's primary role, connecting devices internally or externally, PCI vs. SCSI for instance. However, many common modern bus systems can be used for both; SATA and the associated eSATA are one example of a system that would formerly be described as internal, while certain automotive applications use the primarily external IEEE 1394 in a fashion more similar to a system bus. Other examples, like InfiniBand and I²C were designed from the start to be used both internally and externally.
Internal buses
The internal bus, also known as internal data bus, memory bus, system bus or front-side bus, connects all the internal components of a computer, such as CPU and memory, to the motherboard. Internal data buses are also referred to as local buses, because they are intended to connect to local devices. This bus is typically rather quick and is independent of the rest of the computer operations.
External buses
The external bus, or expansion bus, is made up of the electronic pathways that connect the different external devices, such as printer etc., to the computer.
Address bus
An address bus is a bus that is used to specify a physical address. When a processor or DMA-enabled device needs to read or write to a memory location, it specifies that memory location on the address bus (the value to be read or written is sent on the data bus). The width of the address bus determines the amount of memory a system can address. For example, a system with a 32-bit address bus can address 232 (4,294,967,296) memory locations. If each memory location holds one byte, the addressable memory space is 4 GiB.
Address multiplexing
Early processors used a wire for each bit of the address width. For example, a 16-bit address bus had 16 physical wires making up the bus. As the buses became wider and lengthier, this approach became expensive in terms of the number of chip pins and board traces. Beginning with the Mostek 4096 DRAM, address multiplexing implemented with multiplexers became common. In a multiplexed address scheme, the address is sent in two equal parts on alternate bus cycles. This halves the number of address bus signals required to connect to the memory. For example, a 32-bit address bus can be implemented by using 16 lines and sending the first half of the memory address, immediately followed by the second half memory address.
Typically two additional pins in the control bus -- a row-address strobe (RAS) and the column-address strobe (CAS) -- are used to tell the DRAM whether the address bus is currently sending the first half of the memory address or the second half.
Implementation
Accessing an individual byte frequently requires reading or writing the full bus width (a word) at once. In these instances the least significant bits of the address bus may not even be implemented - it is instead the responsibility of the controlling device to isolate the individual byte required from the complete word transmitted. This is the case, for instance, with the VESA Local Bus which lacks the two least significant bits, limiting this bus to aligned 32-bit transfers.
Historically, there were also some examples of computers which were only able to address words -- word machines.
Memory bus
The memory bus is the bus which connects the main memory to the memory controller in computer systems. Originally, general-purpose buses like VMEbus and the S-100 bus were used, but to reduce latency, modern memory buses are designed to connect directly to DRAM chips, and thus are designed by chip standards bodies such as JEDEC. Examples are the various generations of SDRAM, and serial point-to-point buses like SLDRAM and RDRAM. An exception is the Fully Buffered DIMM which, despite being carefully designed to minimize the effect, has been criticized for its higher latency.
Implementation details
Buses can be parallel buses, which carry data words in parallel on multiple wires, or serial buses, which carry data in bit-serial form. The addition of extra power and control connections, differential drivers, and data connections in each direction usually means that most serial buses have more conductors than the minimum of one used in 1-Wire and UNI/O. As data rates increase, the problems of timing skew, power consumption, electromagnetic interference and crosstalk across parallel buses become more and more difficult to circumvent. One partial solution to this problem has been to double pump the bus. Often, a serial bus can be operated at higher overall data rates than a parallel bus, despite having fewer electrical connections, because a serial bus inherently has no timing skew or crosstalk. USB, FireWire, and Serial ATA are examples of this. Multidrop connections do not work well for fast serial buses, so most modern serial buses use daisy-chain or hub designs.
Network connections such as Ethernet are not generally regarded as buses, although the difference is largely conceptual rather than practical. An attribute generally used to characterize a bus is that power is provided by the bus for the connected hardware. This emphasizes the busbar origins of bus architecture as supplying switched or distributed power. This excludes, as buses, schemes such as serial RS-232, parallel Centronics, IEEE 1284 interfaces and Ethernet, since these devices also needed separate power supplies. Universal Serial Bus devices may use the bus supplied power, but often use a separate power source. This distinction is exemplified by a telephone system with a connected modem, where the RJ11 connection and associated modulated signalling scheme is not considered a bus, and is analogous to an Ethernet connection. A phone line connection scheme is not considered to be a bus with respect to signals, but the Central Office uses buses with cross-bar switches for connections between phones.
However, this distinction—that power is provided by the bus—is not the case in many avionic systems, where data connections such as ARINC 429, ARINC 629, MIL-STD-1553B (STANAG 3838), and EFABus (STANAG 3910) are commonly referred to as “data buses” or, sometimes, "databuses". Such avionic data buses are usually characterized by having several equipments or Line Replaceable Items/Units (LRI/LRUs) connected to a common, shared media. They may, as with ARINC 429, be simplex, i.e. have a single source LRI/LRU or, as with ARINC 629, MIL-STD-1553B, and STANAG 3910, be duplex, allow all the connected LRI/LRUs to act, at different times (half duplex), as transmitters and receivers of data.[4]
Bus multiplexing
The simplest system bus has completely separate input data lines, output data lines, and address lines. To reduce cost, most microcomputers have a bidirectional data bus, re-using the same wires for input and output at different times.[5]
Some processors use a dedicated wire for each bit of the address bus, data bus, and the control bus. For example, the 64-pin STEbus is composed of 8 physical wires dedicated to the 8-bit data bus, 20 physical wires dedicated to the 20-bit address bus, 21 physical wires dedicated to the control bus, and 15 physical wires dedicated to various power buses.
Bus multiplexing requires fewer wires, which reduces costs in many early microprocessors and DRAM chips. One common multiplexing scheme, address multiplexing, has already been mentioned. Another multiplexing scheme re-uses the address bus pins as the data bus pins,[5] an approach used by conventional PCI and the 8086. The various "serial buses" can be seen as the ultimate limit of multiplexing, sending each of the address bits and each of the data bits, one at a time, through a single pin (or a single differential pair).
History
Over time, several groups of people worked on various computer bus standards, including the IEEE Bus Architecture Standards Committee (BASC), the IEEE "Superbus" study group, the open microprocessor initiative (OMI), the open microsystems initiative (OMI), the "Gang of Nine" that developed EISA, etc.[citation needed]
First generation
Early computer buses were bundles of wire that attached computer memory and peripherals. Anecdotally termed the "digit trunk",[6] they were named after electrical power buses, or busbars. Almost always, there was one bus for memory, and one or more separate buses for peripherals. These were accessed by separate instructions, with completely different timings and protocols.
One of the first complications was the use of interrupts. Early computer programs performed I/O by waiting in a loop for the peripheral to become ready. This was a waste of time for programs that had other tasks to do. Also, if the program attempted to perform those other tasks, it might take too long for the program to check again, resulting in loss of data. Engineers thus arranged for the peripherals to interrupt the CPU. The interrupts had to be prioritized, because the CPU can only execute code for one peripheral at a time, and some devices are more time-critical than others.
High-end systems introduced the idea of channel controllers, which were essentially small computers dedicated to handling the input and output of a given bus. IBM introduced these on the IBM 709 in 1958, and they became a common feature of their platforms. Other high-performance vendors like Control Data Corporation implemented similar designs. Generally, the channel controllers would do their best to run all of the bus operations internally, moving data when the CPU was known to be busy elsewhere if possible, and only using interrupts when necessary. This greatly reduced CPU load, and provided better overall system performance.
To provide modularity, memory and I/O buses can be combined into a unified system bus.[7] In this case, a single mechanical and electrical system can be used to connect together many of the system components, or in some cases, all of them.
Later computer programs began to share memory common to several CPUs. Access to this memory bus had to be prioritized, as well. The simple way to prioritize interrupts or bus access was with a daisy chain. In this case signals will naturally flow through the bus in physical or logical order, eliminating the need for complex scheduling.
Minis and micros
Digital Equipment Corporation (DEC) further reduced cost for mass-produced minicomputers, and mapped peripherals into the memory bus, so that the input and output devices appeared to be memory locations. This was implemented in the Unibus of the PDP-11 around 1969.[8]
Early microcomputer bus systems were essentially a passive backplane connected directly or through buffer amplifiers to the pins of the CPU. Memory and other devices would be added to the bus using the same address and data pins as the CPU itself used, connected in parallel. Communication was controlled by the CPU, which read and wrote data from the devices as if they are blocks of memory, using the same instructions, all timed by a central clock controlling the speed of the CPU. Still, devices interrupted the CPU by signaling on separate CPU pins.
For instance, a disk drive controller would signal the CPU that new data was ready to be read, at which point the CPU would move the data by reading the "memory location" that corresponded to the disk drive. Almost all early microcomputers were built in this fashion, starting with the S-100 bus in the Altair 8800 computer system.
In some instances, most notably in the IBM PC, although similar physical architecture can be employed, instructions to access peripherals (in and out) and memory (mov
and others) have not been made uniform at all, and still generate
distinct CPU signals, that could be used to implement a separate I/O
bus.
These simple bus systems had a serious drawback when used for general-purpose computers. All the equipment on the bus had to talk at the same speed, as it shared a single clock.
Increasing the speed of the CPU becomes harder, because the speed of all the devices must increase as well. When it is not practical or economical to have all devices as fast as the CPU, the CPU must either enter a wait state, or work at a slower clock frequency temporarily,[9] to talk to other devices in the computer. While acceptable in embedded systems, this problem was not tolerated for long in general-purpose, user-expandable computers.
Such bus systems are also difficult to configure when constructed from common off-the-shelf equipment. Typically each added expansion card requires many jumpers in order to set memory addresses, I/O addresses, interrupt priorities, and interrupt numbers.
Second generation
"Second generation" bus systems like NuBus addressed some of these problems. They typically separated the computer into two "worlds", the CPU and memory on one side, and the various devices on the other. A bus controller accepted data from the CPU side to be moved to the peripherals side, thus shifting the communications protocol burden from the CPU itself. This allowed the CPU and memory side to evolve separately from the device bus, or just "bus". Devices on the bus could talk to each other with no CPU intervention. This led to much better "real world" performance, but also required the cards to be much more complex. These buses also often addressed speed issues by being "bigger" in terms of the size of the data path, moving from 8-bit parallel buses in the first generation, to 16 or 32-bit in the second, as well as adding software setup (now standardised as Plug-n-play) to supplant or replace the jumpers.
However, these newer systems shared one quality with their earlier cousins, in that everyone on the bus had to talk at the same speed. While the CPU was now isolated and could increase speed, CPUs and memory continued to increase in speed much faster than the buses they talked to. The result was that the bus speeds were now very much slower than what a modern system needed, and the machines were left starved for data. A particularly common example of this problem was that video cards quickly outran even the newer bus systems like PCI, and computers began to include AGP just to drive the video card. By 2004 AGP was outgrown again by high-end video cards and other peripherals and has been replaced by the new PCI Express bus.
An increasing number of external devices started employing their own bus systems as well. When disk drives were first introduced, they would be added to the machine with a card plugged into the bus, which is why computers have so many slots on the bus. But through the 1980s and 1990s, new systems like SCSI and IDE were introduced to serve this need, leaving most slots in modern systems empty. Today there are likely to be about five different buses in the typical machine, supporting various devices.[citation needed]
Third generation
"Third generation" buses have been emerging into the market since about 2001, including HyperTransport and InfiniBand. They also tend to be very flexible in terms of their physical connections, allowing them to be used both as internal buses, as well as connecting different machines together. This can lead to complex problems when trying to service different requests, so much of the work on these systems concerns software design, as opposed to the hardware itself. In general, these third generation buses tend to look more like a network than the original concept of a bus, with a higher protocol overhead needed than early systems, while also allowing multiple devices to use the bus at once.
Buses such as Wishbone have been developed by the open source hardware movement in an attempt to further remove legal and patent constraints from computer design.
The Compute Express Link (CXL) is an open standard interconnect for high-speed CPU-to-device and CPU-to-memory, designed to accelerate next-generation data center performance.[10]
Examples of internal computer buses
Parallel
- Asus Media Bus proprietary, used on some Asus Socket 7 motherboards
- Computer Automated Measurement and Control (CAMAC) for instrumentation systems
- Extended ISA or EISA
- Industry Standard Architecture or ISA
- Low Pin Count or LPC
- MBus
- MicroChannel or MCA
- Multibus for industrial systems
- NuBus or IEEE 1196
- OPTi local bus used on early Intel 80486 motherboards.[11]
- Peripheral Component Interconnect or Conventional PCI
- Parallel ATA (also known as Advanced Technology Attachment, ATA, PATA, IDE, EIDE, ATAPI, etc.), Hard disk drive, optical disk drive, tape drive peripheral attachment bus
- S-100 bus or IEEE 696, used in the Altair 8800 and similar microcomputers
- SBus or IEEE 1496
- SS-50 Bus
- Runway bus, a proprietary front side CPU bus developed by Hewlett-Packard for use by its PA-RISC microprocessor family
- GSC/HSC, a proprietary peripheral bus developed by Hewlett-Packard for use by its PA-RISC microprocessor family
- Precision Bus, a proprietary bus developed by Hewlett-Packard for use by its HP3000 computer family
- STEbus
- STD Bus (for STD-80 [8-bit] and STD32 [16-/32-bit]), FAQ Archived 2012-02-27 at the Wayback Machine
- Unibus, a proprietary bus developed by Digital Equipment Corporation for their PDP-11 and early VAX computers.
- Q-Bus, a proprietary bus developed by Digital Equipment Corporation for their PDP and later VAX computers.
- VESA Local Bus or VLB or VL-bus
- VMEbus, the VERSAmodule Eurocard bus
- PC/104
- PC/104-Plus
- PCI-104
- PCI/104-Express
- PCI/104
- Zorro II and Zorro III, used in Amiga computer systems
Serial
- 1-Wire
- HyperTransport
- I²C
- I3C (bus)
- SLIMbus
- PCI Express or PCIe
- Serial ATA (SATA), Hard disk drive, solid state drive, optical disc drive, tape drive peripheral attachment bus
- Serial Peripheral Interface (SPI) bus
- UNI/O
- SMBus
Examples of external computer buses
Parallel
- HIPPI High Performance Parallel Interface
- IEEE-488 (also known as GPIB, General-Purpose Interface Bus, and HPIB, Hewlett-Packard Instrumentation Bus)
- PC Card, previously known as PCMCIA, much used in laptop computers and other portables, but fading with the introduction of USB and built-in network and modem connections
Serial
Many field buses are serial data buses (not to be confused with the parallel "data bus" section of a system bus or expansion card), several of which use the RS-485 electrical characteristics and then specify their own protocol and connector:
- CAN bus ("Controller Area Network")
- Modbus
- ARINC 429
- MIL-STD-1553
- IEEE 1355
Other serial buses include:
Examples of internal/external computer buses
- Futurebus
- InfiniBand
- PCI Express External Cabling
- QuickRing
- Scalable Coherent Interface (SCI)
- Small Computer System Interface (SCSI), Hard disk drive and tape drive peripheral attachment bus
- Serial Attached SCSI (SAS) and other serial SCSI buses
- Thunderbolt
- Yapbus, a proprietary bus developed for the Pixar Image Computer
See also
References
The internal computer bus is a parallel transmission scheme; within the computer....
- "Odds & Ends: Opti Local Bus, Aria sound cards". 2015-07-21. Retrieved 2021-02-19.
External links
| Authority control: National |
|---|
https://en.wikipedia.org/wiki/Bus_(computing)
https://en.wikipedia.org/wiki/Bus_(computing)
https://en.wikipedia.org/wiki/Vacuum_tube
https://en.wikipedia.org/wiki/Drum_memory
https://en.wikipedia.org/wiki/Punched_tape
https://en.wikipedia.org/wiki/Printer_(computing)
https://en.wikipedia.org/wiki/Lead_(electronics)
https://en.wikipedia.org/wiki/Electrical_connector
https://en.wikipedia.org/wiki/Synchronization_(computer_science)
https://en.wikipedia.org/wiki/System_bus
https://en.wikipedia.org/wiki/Expansion_card
https://en.wikipedia.org/wiki/Adapter_(computing)
https://en.wikipedia.org/wiki/Busbar
https://en.wikipedia.org/wiki/Parallel_communication
https://en.wikipedia.org/wiki/Serial_communication
https://en.wikipedia.org/wiki/Multidrop_bus
https://en.wikipedia.org/wiki/USB
https://en.wikipedia.org/wiki/Category:Motherboard
https://en.wikipedia.org/wiki/Write-only_memory_(joke)
https://en.wikipedia.org/wiki/Read-only_memory
https://en.wikipedia.org/wiki/Write-only_memory_(engineering)
Notes
The board is installed so that its memory chip is at the same address location as a location in ROM. A write to that address goes both to ROM and to the board, but the read-only memory is unaffected. However a read returns only the contents of ROM since the board hardware does not respond to an external read command.[6]
https://en.wikipedia.org/wiki/Write-only_memory_(engineering)
https://en.wikipedia.org/wiki/Phonautograph
https://en.wikipedia.org/wiki/Null_device
https://en.wikipedia.org/wiki/Framebuffer
https://en.wikipedia.org/wiki/Shader
https://en.wikipedia.org/wiki/BIOS
https://en.wikipedia.org/wiki/Megabyte
https://en.wikipedia.org/wiki/Bank_switching
https://en.wikipedia.org/wiki/Device_driver
https://en.wikipedia.org/wiki/Method_of_complements
https://en.wikipedia.org/wiki/Endianness
https://en.wikipedia.org/wiki/Circular_shift
https://en.wikipedia.org/wiki/Logical_shift
https://en.wikipedia.org/wiki/Endianness
In some operating systems, the null device is a device file that discards all data written to it but reports that the write operation succeeded. This device is called /dev/null on Unix and Unix-like systems, NUL: (see TOPS-20) or NUL on CP/M and DOS (internally \DEV\NUL), nul on OS/2 and newer Windows systems[1] (internally \Device\Null on Windows NT), NIL: on Amiga operating systems,[2] and NL: on OpenVMS.[3] In Windows Powershell, the equivalent is $null.[4] It provides no data to any process that reads from it, yielding EOF immediately.[5] In IBM operating systems DOS/360 and successors[a] and also in OS/360 and successors[b] such files would be assigned in JCL to DD DUMMY.
In programmer jargon, especially Unix jargon, it may also be called the bit bucket[6] or black hole.
History
According to the Berkeley UNIX man page, Version 4 Unix, which AT&T released in 1973, included a null device.[7][8]
Usage
The null device is typically used for disposing of unwanted output streams of a process, or as a convenient empty file for input streams. This is usually done by redirection.
The /dev/null device is a special file, not a directory, so one cannot move a whole file or directory into it with the Unix mv command.
References in computer culture
This entity is a common inspiration for technical jargon expressions and metaphors by Unix programmers, e.g. "please send complaints to /dev/null", "my mail got archived in /dev/null", and "redirect to /dev/null"—being jocular ways of saying, respectively: "don't bother sending complaints", "my mail was deleted", and "go away". The iPhone Dev Team commonly uses the phrase "send donations to /dev/null", meaning they do not accept donations.[9] The fictitious person name "Dave (or Devin) Null" is sometimes similarly used (e.g., "send complaints to Dave Null").[10] In 1996, Dev Null was an animated virtual reality character created by Leo Laporte for MSNBC's computer and technology TV series The Site. Dev/null is also the name of a vampire hacker in the computer game Vampire: The Masquerade – Redemption. A 2002 advertisement for the Titanium PowerBook G4 reads The Titanium Powerbook G4 Sends other UNIX boxes to /dev/null.[11]
The null device is also a favorite subject of technical jokes,[12] such as warning users that the system's /dev/null is already 98% full. The 1995 April Fool's issue of the German magazine c't reported on an enhanced /dev/null chip that would efficiently dispose of the incoming data by converting it to a flicker on an internal glowing LED.
See also
- Filesystem Hierarchy Standard
- Memory hole
- rm (Unix)
- Standard streams
- Unix philosophy
- Write-only memory
- Device file
- /dev/zero
- /dev/full
Notes
- The most recent being z/OS.
References
- "The FreeBSD Funnies". Freebsd.org. Retrieved 2012-11-28.
https://en.wikipedia.org/wiki/Null_device
The null device is also a favorite subject of technical jokes,[12] such as warning users that the system's /dev/null is already 98% full. The 1995 April Fool's issue of the German magazine c't reported on an enhanced /dev/null chip that would efficiently dispose of the incoming data by converting it to a flicker on an internal glowing LED.
https://en.wikipedia.org/wiki/Null_device
https://en.wikipedia.org/wiki/Category:CP/M_technology
https://en.wikipedia.org/wiki/Null_coalescing_operator
https://en.wikipedia.org/wiki/Memory_hole
https://en.wikipedia.org/wiki/Rm_(Unix)
https://en.wikipedia.org/wiki//dev/zero
rm (short for remove) is a basic command on Unix and Unix-like operating systems used to remove objects such as computer files, directories and symbolic links from file systems and also special files such as device nodes, pipes and sockets, similar to the del command in MS-DOS, OS/2, and Microsoft Windows. The command is also available in the EFI shell.[1]
https://en.wikipedia.org/wiki/Rm_(Unix)
The command generally does not destroy file data, since its purpose is really merely to unlink references, and the filesystem space freed may still contain leftover data from the removed file. This can be a security concern in some cases, and hardened versions sometimes provide for wiping out the data as the last link is being cut, and programs such as shred and srm are available which specifically provide data wiping capability.
https://en.wikipedia.org/wiki/Rm_(Unix)
A memory hole is any mechanism for the deliberate alteration or disappearance of inconvenient or embarrassing documents, photographs, transcripts or other records, such as from a website or other archive, particularly as part of an attempt to give the impression that something never happened.[1][2] The concept was first popularized by George Orwell's 1949 dystopian novel Nineteen Eighty-Four, where the Party's Ministry of Truth systematically re-created all potentially embarrassing historical documents, in effect, re-writing all of history to match the often-changing state propaganda. These changes were complete and undetectable.
https://en.wikipedia.org/wiki/Memory_hole
https://en.wikipedia.org/wiki/Censorship_of_images_in_the_Soviet_Union
https://en.wikipedia.org/wiki/Safe_navigation_operator
A File Control Block (FCB) is a file system structure in which the state of an open file is maintained. A FCB is managed by the operating system, but it resides in the memory of the program that uses the file, not in operating system memory. This allows a process to have as many files open at one time as it wants, provided it can spare enough memory for an FCB per file.
The FCB originates from CP/M and is also present in most variants of DOS, though only as a backwards compatibility measure in MS-DOS versions 2.0 and later. A full FCB is 36 bytes long; in early versions of CP/M, it was 33 bytes. This fixed size, which could not be increased without breaking application compatibility, led to the FCB's eventual demise as the standard method of accessing files.
The meanings of several of the fields in the FCB differ between CP/M and DOS, and also depending on what operation is being performed. The following fields have consistent meanings:[1]
| Offset | Byte size |
Contents |
|---|---|---|
| 0x00 | 1 | Drive number — 0 for default, 1 for A:, 2 for B:, ... |
| 0x01 | 8 | File name and extension — together these form a 8.3 file name. |
| 0x09 | 3 | |
| 0x0C | 20 | Implementation dependent — should be initialised to zero before the FCB is opened. |
| 0x20 | 1 | Record number in the current section of the file — used when performing sequential access. |
| 0x21 | 3 | Record number to use when performing random access. |
The 20-byte-long field starting at offset 0x0C contained fields which (among others) provided further information about the file:[2]
| Offset | Byte size |
Contents |
|---|---|---|
| 0x0E | 2 | File's record length in bytes. |
| 0x10 | 4 | Total file size in bytes. |
| 0x14 | 2 | Date of last modification to file contents. |
| 0x16 | 2 | Time of last modification. |
Further values were used by newer versions of DOS until new information could no longer fit in these 20 bytes. Some preceding "negative offset" bytes were squeezed from reserved spaces in CP/M Zero Page and DOS Program Segment Prefix for storing file attributes.[1]
Usage
In CP/M, 86-DOS and PC DOS 1.x/MS-DOS 1.xx, the FCB was the only method of accessing files. Under DOS a few INT 21h subfunctions provided the interface to operate on files using the FCB.[1][3][4] When, with MS-DOS 2, preparations were made to support multiple processes or users,[3][4] use other filesystems[3][4] than FAT or to share files[4] over networks in the future, FCBs were felt to be too small to handle the extra data required for such features[4] and therefore FCBs were seen as inadequate for various future expansion paths.[3] Also, they didn't provide a field to specify sub-directories.[3] Exposing file system related data to user-space was also seen as a security risk.[4] FCBs were thus superseded by file handles, as used on UNIX and its derivatives.[3] File handles are simply consecutive integer numbers associated with specific open files.
If a program uses the newer file handle API to open a file, the operating system will manage its internal data structure associated with that file in its own memory area. This has the great advantage that these structures can grow in size in later operating system versions without breaking compatibility with application programs; its disadvantage is that, given the rather simplistic memory management of DOS, space for as many of these structures as the most "file-hungry" program is likely to use has to be reserved at boot time and cannot be used for any other purpose while the computer is running. Such memory reservation is done using the FILES= directive in the CONFIG.SYS file. This problem does not occur with FCBs in DOS 1 or in CP/M, since the operating system stores all that it needs to know about an open file inside the FCB and thus does not need to use any per-file memory in operating system memory space. When using FCBs in MS-DOS 3 or later, the FCB format depends on whether SHARE.EXE is loaded and whether the FCB refers to a local or remote file and often refers to a SFT entry. Because of this, the number of FCBs which can be kept open at once in DOS 3 or higher is limited as well, usually to 4; using the FCBS= directive in the CONFIG.SYS file, it may be increased beyond that number if necessary. Under DR-DOS, both FILES and FCBS come from the same internal pool of available handles structures and are assigned dynamically as needed.[5]
FCBs were supported in all versions of MS-DOS and Windows until the introduction of the FAT32 filesystem. Windows 95, Windows 98 and Windows Me do not support the use of FCBs on FAT32 drives due to its 32-bit cluster numbers,[4] except to read the volume label. This caused some old DOS applications, including WordStar, to fail under these versions of Windows.
The FCB interface does not work properly on Windows NT, 2000, etc. either – WordStar does not function properly on these operating systems. DOS emulators DOSEMU and DOSBox implement the FCB interface properly, thus they are a way to run older DOS programs that need FCBs on modern operating systems.
Disk Transfer Area
A companion data structure used together with the FCB was the Disk Transfer Area (DTA).[2] This is the name given to the buffer where file contents (records) would be read into/written from. File access functions in DOS that used the FCB assumed a fixed location for the DTA, initially pointing to a part of the PSP (see next section); this location could be changed by calling a DOS function, with subsequent file accesses implicitly using the new location.
With the deprecation of the FCB method, the new file access functions which used file handles also provided a means to specify a memory buffer for file contents with every function call, such that maintaining concurrent, independent buffers (either for different files or for the same file) became much more practical.
Program Segment Prefix & Program Initialisation
Every DOS executable started from the shell (COMMAND.COM) was provided with a pre-filled 256-byte long data structure called the Program Segment Prefix (PSP). Relevant fields within this structure include:[2]
| Offset | Byte size |
Contents |
|---|---|---|
| 0x02 | 2 | Available memory for the program in 16-byte chunks. |
| 0x2C | 2 | Segment address containing the program's environment variables. |
| 0x5C | 16 | Prepared FCB for first command line argument (unopened). |
| 0x6C | 20 | Prepared FCB for second command line argument (unopened). |
| 0x80 | 1 | Length of command line. |
| 0x81 | 127 | Command line contents. |
This data structure could be found at the beginning of the data segment whose address was provided by DOS at program start in the DS and ES segment registers. Besides providing the program's command line verbatim at address 0x81, DOS also tried to construct two FCB's corresponding to the first two words in the command line, the purpose being to save work for the programmer in the common case where these words were filenames to operate on. Since these FCB's remained unopened, no problem would ensue even if these command line words did not refer to files.
The initial address for the DTA was set to overlay the area in the PSP (at address 0x80) where the command line arguments were stored, such that a program needed to parse this area for command line arguments before invoking DOS functions that made use of the DTA (such as reading in a file record), unless the program took care to change the address of the DTA to some other memory region (or not use the DTA/FCB functions altogether, which soon became deprecated in favour of file handles).
See also
References
- Paul, Matthias R. (1997-07-30). NWDOS-TIPs — Tips & Tricks rund um Novell DOS 7, mit Blick auf undokumentierte Details, Bugs und Workarounds. MPDOSTIP. Release 157 (in German) (3 ed.). Archived from the original on 2017-08-23. Retrieved 2012-01-11. (NB. NWDOSTIP.TXT is a comprehensive work on Novell DOS 7 and OpenDOS 7.01, including the description of many undocumented features and internals. It is part of the author's yet larger MPDOSTIP.ZIP collection maintained up to 2001 and distributed on many sites at the time. The provided link points to a HTML-converted older version of the NWDOSTIP.TXT file.)
Further reading
- Brown, Ralf D., ed. (2000-07-17). "210F: DOS 1+ - OPEN FILE USING FCB". Ralf Brown's Interrupt List 61. ctyme.com. Archived from the original on 2016-06-19. [7]
- Elliott, John C. (2002-12-29). "CP/M File Control Block". Seasip.info. Archived from the original on 2017-08-23. Retrieved 2017-08-23.
- "CP/M Internals". 2017-08-23. Archived from the original on 2017-08-23. Retrieved 2017-08-23. - In-depth description of CP/M FCB
https://en.wikipedia.org/wiki/File_Control_Block
In Unix-like operating systems, a device file or special file is an interface to a device driver that appears in a file system as if it were an ordinary file. There are also special files in DOS, OS/2, and Windows. These special files allow an application program to interact with a device by using its device driver via standard input/output system calls. Using standard system calls simplifies many programming tasks, and leads to consistent user-space I/O mechanisms regardless of device features and functions.
Overview
Device files usually provide simple interfaces to standard devices (such as printers and serial ports), but can also be used to access specific unique resources on those devices, such as disk partitions. Additionally, device files are useful for accessing system resources that have no connection with any actual device, such as data sinks and random number generators.
There are two general kinds of device files in Unix-like operating systems, known as character special files and block special files. The difference between them lies in how much data is read and written by the operating system and hardware. These together can be called device special files in contrast to named pipes, which are not connected to a device but are not ordinary files either.
MS-DOS borrowed the concept of special files from Unix but renamed them devices.[1] Because early versions of MS-DOS did not support a directory hierarchy, devices were distinguished from regular files by making their names reserved words, for example: the infamous CON. These were chosen for a degree of compatibility with CP/M and are still present in modern Windows for backwards compatibility.
In some Unix-like systems, most device files are managed as part of a virtual file system traditionally mounted at /dev,
possibly associated with a controlling daemon, which monitors hardware
addition and removal at run time, making corresponding changes to the device file system
if that's not automatically done by the kernel, and possibly invoking
scripts in system or user space to handle special device needs. The FreeBSD, DragonFly BSD and Darwin have a dedicated file system devfs; device nodes are managed automatically by this file system, in kernel space. Linux used to have a similar devfs implementation, but it was abandoned later, and then removed since version 2.6.17;[2] Linux now primarily uses a user space implementation known as udev, but there are many variants.
In Unix systems which support chroot process isolation, such as Solaris Containers, typically each chroot environment needs its own /dev;
these mount points will be visible on the host OS at various nodes in
the global file system tree. By restricting the device nodes populated
into chroot instances of /dev, hardware isolation can be
enforced by the chroot environment (a program can not meddle with
hardware that it can neither see nor name—an even stronger form of access control than Unix file system permissions).
MS-DOS managed hardware device contention (see terminate-and-stay-resident program) by making each device file exclusive open. An application attempting to access a device already in use would discover itself unable to open the device file node. A variety of device driver semantics are implemented in Unix and Linux concerning concurrent access.[3]
Unix and Unix-like systems
Device nodes correspond to resources that an operating system's kernel has already allocated. Unix identifies those resources by a major number and a minor number,[4] both stored as part of the structure of a node. The assignment of these numbers occurs uniquely in different operating systems and on different computer platforms. Generally, the major number identifies the device driver and the minor number identifies a particular device (possibly out of many) that the driver controls:[5] in this case, the system may pass the minor number to a driver. However, in the presence of dynamic number allocation, this may not be the case (e.g. on FreeBSD 5 and up).
As with other special file types, the computer system accesses device nodes using standard system calls and treats them like regular computer files. Two standard types of device files exist; unfortunately their names are rather counter-intuitive for historical reasons, and explanations of the difference between the two are often incorrect as a result.
Character devices
Character special files or character devices provide unbuffered, direct access to the hardware device. They do not necessarily allow programs to read or write single characters at a time; that is up to the device in question. The character device for a hard disk, for example, will normally require that all reads and writes be aligned to block boundaries and most certainly will not allow reading a single byte.
Character devices are sometimes known as raw devices to avoid the confusion surrounding the fact that a character device for a piece of block-based hardware will typically require programs to read and write aligned blocks.
Block devices
Block special files or block devices provide buffered access to hardware devices, and provide some abstraction from their specifics.[6] Unlike character devices, block devices will always allow the programmer to read or write a block of any size (including single characters/bytes) and any alignment. The downside is that because block devices are buffered, the programmer does not know how long it will take before written data is passed from the kernel's buffers to the actual device, or indeed in what order two separate writes will arrive at the physical device. Additionally, if the same hardware exposes both character and block devices, there is a risk of data corruption due to clients using the character device being unaware of changes made in the buffers of the block device.
Most systems create both block and character devices to represent hardware like hard disks. FreeBSD and Linux notably do not; the former has removed support for block devices,[7] while the latter creates only block devices. In Linux, to get a character device for a disk, one must use the "raw" driver, though one can get the same effect as opening a character device by opening the block device with the Linux-specific O_DIRECT flag.
Pseudo-devices
Device nodes on Unix-like systems do not necessarily have to correspond to physical devices. Nodes that lack this correspondence form the group of pseudo-devices. They provide various functions handled by the operating system. Some of the most commonly used (character-based) pseudo-devices include:
- /dev/null – accepts and discards all input written to it; provides an end-of-file indication when read from.
- /dev/zero – accepts and discards all input written to it; produces a continuous stream of null characters (zero-value bytes) as output when read from.
- /dev/full – produces a continuous stream of null characters (zero-value bytes) as output when read from, and generates an ENOSPC ("disk full") error when attempting to write to it.
- /dev/random – produces bytes generated by the kernel's cryptographically secure pseudorandom number generator. Its exact behavior varies by implementation, and sometimes variants such as /dev/urandom or /dev/arandom are also provided.
- /dev/stdin, /dev/stdout, /dev/stderr – access the process's standard streams.
- /dev/fd/n – accesses the process's file descriptor n.
Additionally, BSD-specific pseudo-devices with an ioctl interface may also include:
- /dev/pf – allows userland processes to control PF through an ioctl interface.
- /dev/bio – provides ioctl access to devices otherwise not found as /dev nodes, used by bioctl to implement RAID management in OpenBSD and NetBSD.
- /dev/sysmon – used by NetBSD's envsys framework for hardware monitoring, accessed in the userland through proplib(3) by the envstat utility.[8]
Node creation
Nodes are created by the mknod system call. The command-line program for creating nodes is also called mknod. Nodes can be moved or deleted by the usual filesystem system calls (rename, unlink) and commands (mv, rm).
Some Unix versions include a script named makedev or MAKEDEV to create all necessary devices in the directory /dev. It only makes sense on systems whose devices are statically assigned major numbers (e.g., by means of hardcoding it in their kernel module).
While some other Unix systems such as FreeBSD, used kernel-based device node management via devfs only, and not supporting manual node creation. mknod(2) system call and mknod(8) command exist to keep compatibility with POSIX, but manually created device nodes outside devfs will not function at all.[9]
Naming conventions
The following prefixes are used for the names of some devices in the /dev hierarchy, to identify the type of device:
- lp: line printers (compare lp)
- pt: pseudo-terminals (virtual terminals)
- tty: terminals
Some additional prefixes have come into common use in some operating systems:
- fb: frame buffer
- fd: (platform) floppy disks, though this same abbreviation is also commonly used to refer to file descriptor
- hd: ("classic") IDE driver (previously used for ATA hard disk drive, ATAPI optical disc drives, etc.)
- hda: the master device on the first ATA channel (usually identified by major number 3 and minor number 0)
- hdb: the slave device on the first ATA channel
- hdc: the master device on the second ATA channel
- hdd: the slave device on the second ATA channel
- parport, pp: parallel ports
- mem: Main memory (character device)
- NVMe driver:
- nvme0: first registered device's device controller (character device)
- nvme0n1: first registered device's first namespace (block device)
- nvme0n1p1: first registered device's first namespace's first partition (block device)
- MMC driver:
- SCSI driver, also used by libATA (modern PATA/SATA driver), USB, IEEE 1394, etc.:
- sd: mass-storage driver (block device)
- sda: first registered device
- sdb, sdc, etc.: second, third, etc. registered devices
- ses: Enclosure driver
- sg: generic SCSI layer
- sr: "ROM" driver (data-oriented optical disc drives; scd is just a secondary alias)
- st: magnetic tape driver
- sd: mass-storage driver (block device)
- tty: terminals
- ttyS: (platform) serial port driver
- ttyUSB: USB serial converters, modems, etc.
The canonical list of the prefixes used in Linux can be found in the Linux Device List, the official registry of allocated device numbers and /dev directory nodes for the Linux operating system.[10]
For most devices, this prefix is followed by a number uniquely identifying the particular device. For hard drives, a letter is used to identify devices and is followed by a number to identify partitions. Thus a file system may "know" an area on a disk as /dev/sda3, for example, or "see" a networked terminal session as associated with /dev/pts/14.
On disks using the typical PC master boot record, the device numbers of primary and the optional extended partition are numbered 1 through 4, while the indexes of any logical partitions are 5 and onwards, regardless of the layout of the former partitions (their parent extended partition does not need to be the fourth partition on the disk, nor do all four primary partitions have to exist).
Device names are usually not portable between different Unix-like system variants, for example, on some BSD systems, the IDE devices are named /dev/wd0, /dev/wd1, etc.
devfs
devfs is a specific implementation of a device file system on Unix-like operating systems, used for presenting device files. The underlying mechanism of implementation may vary, depending on the OS.
Maintaining these special files on a physically-implemented file system such as a hard drive is inconvenient, and as it needs kernel assistance anyway, the idea arose of a special-purpose logical file system that is not physically stored.
Defining when devices are ready to appear is not trivial. The devfs approach is for the device driver to request creation and deletion of devfs entries related to the devices it enables and disables.
PC DOS, TOS, OS/2, and Windows
A device file is a reserved keyword used in PC DOS, TOS, OS/2, and Windows systems to allow access to certain ports and devices.
MS-DOS borrowed the concept of special files from Unix but renamed them devices.[1] Because early versions of MS-DOS did not support a directory hierarchy, devices were distinguished from regular files by making their names reserved words. This means that certain file names were reserved for devices, and should not be used to name new files or directories.[11]
The reserved names themselves were chosen to be compatible with "special files" handling of PIP command in CP/M.
There were two kinds of devices in DOS: Block Devices (used for disk
drives) and Character Devices (generally all other devices, including
COM and PRN devices).[12]
DOS uses device files for accessing printers and ports. Most
versions of Windows also contain this support, which can cause confusion
when trying to make files and folders of certain names, as they cannot
have these names.[13] Versions 2.x of MS-DOS provide the AVAILDEV CONFIG.SYS parameter that, if set to FALSE, makes these special names only active if prefixed with \DEV\, thus allowing ordinary files to be created with these names.[14]
GEMDOS, the DOS-like part of Atari TOS, supported similar device names to DOS, but unlike DOS it required a trailing ":" character (on DOS, this is optional) to identify them as devices as opposed to normal filenames (thus "CON:" would work on both DOS and TOS, but "CON" would name an ordinary file on TOS but the console device on DOS). In MiNT and MagiC, a special UNIX-like unified filesystem view accessed via the "U:" drive letter also placed device files in "U:\DEV".
| Device keyword[13] | Use as input | Use as output |
|---|---|---|
| CON | Receives typed data until ^Z (Ctrl-Z) is pressed. | Prints data to the console. |
| PRN[15] | — | Prints text to the printer, usually redirected to LPT1 or LST. Sometimes reconfigurable to other devices.[16][17][18] |
| AUX (not in OS/2[15]) | Reads data from an auxiliary device, usually a serial device like COM1. Sometimes reconfigurable to other devices.[16][17][18] | Sends data to an auxiliary device, usually a serial device like COM1. Sometimes reconfigurable to other devices.[16][17][18] |
| NUL | Returns null or no data. | Discards received data. |
| CLOCK$ (still named CLOCK in some versions of MS-DOS 2.11[19][16][17]) | — | — |
| KEYBD$ (only in multitasking MS-DOS) | ? | ? |
| KBD$ (only in OS/2[15]) | ? | ? |
| SCREEN$ (only in multitasking MS-DOS and OS/2[15]) | ? | ? |
| POINTER$ (only in OS/2[15]) | ? | ? |
| MOUSE$ (only in OS/2[15]) | ? | ? |
| $IDLE$ (only in DR-DOS (since 5.0) and Multiuser DOS (since Concurrent DOS 386) families) | — | — |
| CONFIG$ (only in MS-DOS 7.0 and higher) | — | — |
| LST (only in 86-DOS and DOS 1.x, also in Hewlett-Packard's MS-DOS 2.11 for the HP Portable Plus[16][17]) | Returns no data. | Sends data to the line printer. (LPT2 for Hewlett-Packard's MS-DOS 2.11[16][17]) |
| PLT (only in Hewlett-Packard's MS-DOS 2.11 for the HP Portable Plus[16][17]) | Returns no data. | Sends data to the assigned plotter. The attached plotter device is reconfigurable.[16][17] |
| LPT1, LPT2, LPT3, and sometimes LPT4 (in DR-DOS 7.02 and higher and some versions of Multiuser DOS) | — | Sends data to the selected parallel port. |
| COM1, COM2, COM3, COM4 | Reads data from the selected serial port. | Sends data to the selected serial port. |
| 82164A (only in Hewlett-Packard's MS-DOS 2.11 for the HP Portable Plus[16][17]) | Redirects to COM2. | Redirects to COM2. |
Using shell redirection and pipes, data can be sent to or received from a device. For example, typing the following will send the file c:\data.txt to the printer:
TYPE c:\data.txt > PRN
PIPE, MAILSLOT, and MUP are other standard Windows devices.[20]
IOCS
The 8-bit operating system of Sharp pocket computers like the PC-E500, PC-E500S etc. consists of a BASIC interpreter, a DOS 2-like File Control System (FCS) implementing a rudimentary 12-bit FAT-like filesystem, and a BIOS-like Input/Output Control System (IOCS) implementing a number of standard character and block device drivers as well as special file devices including STDO:/SCRN: (display), STDI:/KYBD: (keyboard), COM: (serial I/O), STDL:/PRN: (printer), CAS: (cassette tape), E:/F:/G: (memory file), S1:/S2:/S3: (memory card), X:/Y: (floppy), SYSTM: (system), and NIL: (function).[21]
Implementations
| Operating System | Filesystem or managing software | Standard mount point | Author | Notes |
|---|---|---|---|---|
| Linux 2.3.46pre5–2.6.17 | devfs[22] and devfsd | /dev
|
Richard Gooch | Implemented fully in the kernel, with optional daemon devfsd to handle device node events in user space.[23] Obsolete – users are encouraged to migrate to udev and/or devtmpfs. |
| Linux 2.5– | udev on any fs, but usually tmpfs | /dev
|
Greg Kroah-Hartman, Kay Sievers and Dan Stekloff | Implemented largely in user space, device information is gathered from sysfs. Device files can be stored on a conventional general-purpose file system, or in a memory file system (tmpfs). |
| Linux 2.6.32– | devtmpfs with or without udev | /dev
|
Kay Sievers, Jan Blunck, Greg Kroah-Hartman | A hybrid kernel/userspace approach of a device filesystem to provide nodes before udev runs for the first time[24] |
| Solaris | devfs[25] | /devices
|
Sun Microsystems | Introduced with dynamic loaded drivers in Solaris-2.1 |
| FreeBSD 2.0– | devfs | /dev
|
Poul-Henning Kamp | Implemented fully in the kernel. |
| DragonFly BSD 2.3.2– | devfs | /dev
|
Alex Hornung | Implemented fully in the kernel. |
| macOS | devfs | /dev
|
Apple Inc. | Implemented fully in the kernel. |
| HP-UX B.11.31 | devfs | /dev
|
HP | Implemented fully in the kernel. |
| Plan 9 |
|
#
|
Bell Labs | Implemented in the kernel. |
| RISC OS | DeviceFS | Devices:
|
Acorn Computers | DeviceFS was started in 1991[26] and first appeared in RISC OS 3. It manages several device like special files, most commonly: Parallel, Serial, FastParallel, and USB. The SystemDevices module implements the pseudo devices such as: Vdu, Kbd, Null and Printer. |
| MS-DOS, PC DOS, DR-DOS | FAT | \DEV (and /DEV)
|
various | As implemented in the kernel, character devices appear in the virtual \DEV directory and any disk directory. Under MS-DOS/PC DOS 2.x, the CONFIG.SYS AVAILDEV=FALSE directive can be used to force devices to exist only in \DEV. |
| MagiC, MiNT, MultiTOS |
|
U:\DEV[27][28]
|
Application Systems Heidelberg, Eric R. Smith, Atari Corp. | The special U: drive contains a virtual DEV directory, inside which one can find device files. |
| Windows 9x |
|
\\devices\
|
Microsoft |
|
| Windows NT |
|
\Device
|
Microsoft | The \Device directory is a part of Windows NT object namespace.
|
| Windows NT Win32 Subsystem |
|
\\.\
|
Microsoft | The \\.\ prefix makes supporting APIs access the Win32
device namespace instead of the Win32 file namespace. The Win32 device
names are symbolic links to device names under Windows NT \Device directory.
|
See also
References
The next step beyond a single-open device is to let a single user open a device in multiple processes but allow only one user to have the device open at a time.
- "envstat -- utility to handle environmental sensors". NetBSD System Manager's Manual. Archived from the original on 2019-03-23.
Devfsd provides configurable management of device nodes using the Linux Device Filesystem.
- "FreeMiNT-Portal - mint.doc". 2000-04-27. Archived from the original on 2017-01-15. Retrieved 2017-01-09.
Further reading
- Philip Streck (2002-09-24). "devfs for Management and Administration". Linux Journal.
- Daniel Robbins (2001-10-01). "Part 4: Introduction to devfs". Common threads: Advanced filesystem implementor's guide. IBM.
- Daniel Robbins (2001-10-01). "Part 5: Setting up devfs". Common threads: Advanced filesystem implementor's guide. IBM.
- Daniel Robbins (2001-10-01). "Part 6: Implementing devfs (using the init wrapper)". Common threads: Advanced filesystem implementor's guide. IBM.
- Doug Gilbert (2001-01-22). "DEVFS and SCSI".
- "3.3. Device Names in devfs". The Linux 2.4 SCSI subsystem HOWTO: Chapter 3. Names and Addresses. Linux Documentation Project.
- "Device File System Guide". Gentoo Linux Documentation. Gentoo Foundation, Inc. Archived from the original on 2008-05-21. Retrieved 2008-06-19.
- Mark Ellis (2003-09-23). "How to use kernel module autoloading with devfs and devfsd". Linux From Scratch Hints.
- Martial Daumas (2003-09-18). "How to create a basic mk_initrd command that works nice with LFS and devfs". Linux From Scratch Hints.
- Jeroen Coumans (2003-04-19). "How to setup devfs with your current LFS-configuration using devfsd. How you can use devfs from scratch". Linux From Scratch Hints.
- Tushar Teredesai (2003-03-05). "Using devfs and devfsd". Linux From Scratch Hints.
https://en.wikipedia.org/wiki/Device_file
https://en.wikipedia.org/wiki/Category:Disk_file_systems
https://en.wikipedia.org/wiki/Zero_page_(CP/M)
https://en.wikipedia.org/wiki/Category:Special-purpose_file_systems
https://en.wikipedia.org/wiki/Filesystem-level_encryption
https://en.wikipedia.org/wiki/Deniable_encryption
Plausible deniability is the ability of people, typically senior officials in a formal or informal chain of command, to deny knowledge of or responsibility for actions committed by members of their organizational hierarchy. They may do so because of a lack or absence of evidence that can confirm their participation, even if they were personally involved in or at least willfully ignorant of the actions. If illegal or otherwise disreputable and unpopular activities become public, high-ranking officials may deny any awareness of such acts to insulate themselves and shift the blame onto the agents who carried out the acts, as they are confident that their doubters will be unable to prove otherwise. The lack of evidence to the contrary ostensibly makes the denial plausible (credible), but sometimes, it makes any accusations only unactionable.
The term typically implies forethought, such as intentionally setting up the conditions for the plausible avoidance of responsibility for one's future actions or knowledge. In some organizations, legal doctrines such as command responsibility exist to hold major parties responsible for the actions of subordinates who are involved in actions and nullify any legal protection that their denial of involvement would carry.
In politics and espionage, deniability refers to the ability of a powerful player or intelligence agency to pass the buck and to avoid blowback by secretly arranging for an action to be taken on its behalf by a third party that is ostensibly unconnected with the major player. In political campaigns, plausible deniability enables candidates to stay clean and denounce third-party advertisements that use unethical approaches or potentially libelous innuendo.
Although plausible deniability has existed throughout history, the term was coined by the CIA in the early 1960s to describe the withholding of information from senior officials to protect them from repercussions if illegal or unpopular activities became public knowledge.[1]
https://en.wikipedia.org/wiki/Plausible_deniability
See also
- Chaffing and winnowing – cryptographic technique to achieve confidentiality without using encryption
- Deniable authentication – message authentication between a set of participants where the participants themselves can be confident in the authenticity of the messages, but it cannot be proved to a third party after the event
- dm-crypt – disk encryption software
- Key disclosure law – Legislation that requires individuals to surrender cryptographic keys to law enforcement
- Plausible deniability – Ability to deny responsibility
- Rubber-hose cryptanalysis – Extraction of cryptographic secrets by coercion or torture
- Steganography – Hiding messages in other messages
- Unicity distance – Length of ciphertext needed to unambiguously break a cipher
https://en.wikipedia.org/wiki/Deniable_encryption
https://en.wikipedia.org/wiki/Edit_distance
https://en.wikipedia.org/wiki/Regular_grammar
https://en.wikipedia.org/wiki/Time_Warp_Edit_Distance
https://en.wikipedia.org/wiki/Deniable_encryption
https://en.wikipedia.org/wiki/String-to-string_correction_problem
https://en.wikipedia.org/wiki/Time_Warp_Edit_Distance
https://en.wikipedia.org/wiki/Pseudorandom_permutation
https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator
https://en.wikipedia.org/wiki/Chaff_(countermeasure)
https://en.wikipedia.org/wiki/Watermarking_attack
https://en.wikipedia.org/wiki/Deniable_authentication
https://en.wikipedia.org/wiki/Off-the-Record_Messaging
https://en.wikipedia.org/wiki/HMAC
https://en.wikipedia.org/wiki/Forward_secrecy
https://en.wikipedia.org/wiki/Vanish_(computer_science)
https://en.wikipedia.org/wiki/Chaffing_and_winnowing
https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis
https://en.wikipedia.org/wiki/Steganography
https://en.wikipedia.org/wiki/Entropy
https://en.wikipedia.org/wiki/Rm_(Unix)
https://en.wikipedia.org/wiki/Context-free_language
https://en.wikipedia.org/wiki/Bit_numbering#Least_significant_byte
No comments:
Post a Comment