This is link to the latest report from TNB--->Click
As electrical engineering, we should take a note about this annual report. It will give us a general view of the usage of the electricity in our country (Malaysia). For more report just visit http://www.tnb.com.my.
Tuesday, July 17, 2007
Thursday, July 12, 2007
Motorola 68000
The Motorola 68000 is a 32-bit CISC microprocessor core designed and marketed by Freescale Semiconductor (formerly Motorola Semiconductor Products Sector). As the first member of the successful m68k family of microprocessors, its software is generally forward compatible with the rest of the line. After twenty-seven years in production, the 68000 architecture, which economically combines several 16-bit datapaths, remains a popular choice for new designs.
History
The 68000 grew out of the MACSS (Motorola Advanced Computer System on Silicon) project, begun in 1976. One of the early decisions made was to develop a new "no compromise" architecture that paid little attention to backward compatibility. This was a gamble because it would mean adopters of the chip would have to learn the new system entirely from scratch. In the end, the only concession to backward compatibility was a hardware one: the 68k could interface to existing 6800 peripheral devices, but could not run 6800 code. However, the designers built in a tremendous amount of forward compatibility, which paid off once 68k expertise had been gained by end users. For instance, the CPU registers were 32-bits wide, though address and data buses outside the CPU were initially narrower. In contrast the Intel 8086/8088 were 16-bits wide internally. The MACSS team drew heavily on the influence of minicomputer processor design, such as the PDP-11 and VAX systems. The instruction set was developed with software development in mind more than hardware limitations; the idea was that developers familiar with these older systems would be comfortable programming the new microprocessor.
As the new design reached production a trade name had to be selected. The name "68000" was selected largely to provide some naming and marketing continuity with the earlier 6800, although there was little in common between the two designs. The name was justified by claiming the chip featured about 68,000 transistors, but in fact the count was closer to 70,000.
At the time, there was fierce competition among several of the then established manufacturers of 8-bit processors to bring out 16-bit designs. National Semiconductor had been first with its IMP-16 and PACE processors in 1973-1975, but these had issues with speed caused by their hole-doped MOS architecture. Texas Instruments was next, with its TMS9900, but its CPU was not widely accepted. Next came Intel with the Intel 8086/8088 in 1977/78. However, Motorola marketing stressed the (true) point that the 68000 was a much more complete 16-bit design than the others. This was reflected in its complexity. The transistor cell count, which was then a fairly direct measure of power in that era, was more than twice that of the 29,000 of the 8086.
The simplest 68000 instructions took four clock cycles, but the most complex ones required many more. An 8 MHz 68000 had an average performance of roughly 1 MIPS.
On average, the 68000's instructions in typical program code did more work per instruction than competing Intel processors, which meant that 68000 designs both needed less RAM to store machine code and were faster.[citation needed] Additionally, the 68000 offered a "flat" 24-bit addressing system supporting up to 16 MB of memory; at the time, this was a very large memory space. Intel chips instead used a segmented system which was much more difficult to program. Only in 1986 the 80386 allowed flat addressing. Thus the 68000 was easier to learn and work with, which led many engineers to prefer it to the Intel designs.
The original MC68000 was fabricated using an HMOS process with a 3.5-micron feature size. Initial engineering samples were released in late 1979. Production chips were available by 1980, with initial speed grades of 4, 6, and 8 MHz. 10 MHz chips became available during 1981, and 12.5 MHz chips during 1982. The 16.67 MHz "12F" version of the MC68000, the fastest version of the original HMOS chip, was not produced until the late 1980s.
To support low-cost systems with smaller memory sizes, Motorola introduced the MC68008 in 1982. This was a 68000 with an 8-bit data bus and a smaller (20 bits) address bus. The 68012 later brought a 32 bit address bus.
The 68HC000, the CMOS version of the 68000, was jointly introduced by Motorola and Hitachi in 1985.[1] Motorola's version was called the MC68HC000, while Hitachi's was the HD68HC000. The 68HC000 was eventually offered at speeds from 8 MHz to 20 MHz. Except for using CMOS circuitry, it behaved identically to the HMOS MC68000, but the change to CMOS greatly reduced its power consumption. The original HMOS MC68000 consumed around 1.35 watts at an ambient temperature of 25 °C, regardless of clock speed, while the MC68HC000 consumed only 0.13 watts at 8 MHz and 0.38 watts at 20 MHz. (Unlike CMOS circuits, HMOS circuits draw power whether they are switching or idle, so their power consumption varies little with clock rate, but it does vary with temperature.)
Motorola introduced the MC68HC001 in 1990.[2] This chip resembled the 68HC000 in most respects, but its data bus could operate in either 16-bit or 8-bit mode, depending on the value of an input pin at reset. Thus, like the 68008, it could be used in systems with cheaper 8-bit memories.
Several other companies were second-source manufacturers of the HMOS 68000. These included Hitachi (HD68000), Mostek (MK68000), Rockwell (R68000), Signetics (SCN68000), Thomson/SGS-Thomson (originally EF68000 and later TS68000), and Toshiba (TMP68000). Toshiba was also a second-source maker of the CMOS 68HC000 (TMP68HC000).
The 68000 became the foundation for a large number of microcontrollers and embedded processors. In 1989, Motorola introduced the MC68302 communications processor,[3] its first microcontroller to use a 68000 CPU core. This core was based on the CMOS 68HC000 but removed support for 8-bit 6800 peripherals. In 1991 Motorola introduced a separate processor chip based on this core, the MC68EC000.[4]
Motorola went on to make several additional microcontrollers with the 68EC000 core, including the MC68306 and MC68307 general-purpose microcontrollers, the MC68322 "Bandit" printer controller, the MC68356 modem data pump, and the MC68328 DragonBall, designed for portable devices. Other microcontrollers in the 683XX family used the more powerful CPU32 processor core.
Several of the 68EC000-based 683XX microcontrollers used a static version of the 68EC000 core; the processor clock of this core could be slowed or stopped to save power. In 1996 Motorola introduced this static core as a separate processor, the MC68SEC000.[5]
Motorola ceased production of the HMOS MC68000 and MC68008 in 1996,[6] but its spin-off company, Freescale Semiconductor, is still producing the MC68HC000, MC68HC001, MC68EC000, and MC68SEC000, as well as the MC68302 and MC68306 microcontrollers and later versions of the DragonBall family. The 68000's architectural descendants, the 680x0, CPU32, and Coldfire families, are also still in production.
Applications
The 68000 was first used during the early 1980s in high-priced systems, including multiuser microcomputers like the WICAT 150 [[1]], Tandy TRS-80 Model 16, and Fortune 32:16; single-user workstations such as Hewlett-Packard's HP 9000 Series 200 systems, the first Apollo/Domain systems, Sun Microsystems' Sun-1, and the Corvus Concept; and graphics terminals like Digital Equipment Corporation's VAXstation 100 and Silicon Graphics' IRIS 1000 and 1200. While Unix systems soon abandoned the original 68000 due to limitations of the processor, its derivatives remained popular in the Unix market throughout the 1980s.
During the mid 1980s, the 68000 was first used in personal and home computers, starting with the Apple Lisa and Macintosh, and followed by the Commodore Amiga, Atari ST, and Sharp X68000. The 68008, on the other hand, was only used in one home computer system, the Sinclair QL (though the QL was a sister machine to the ICL One Per Desk, which also used a 68008).
The 68000 eventually saw its greatest success as a controller. As early as 1981, laser printers such as the Imagen Imprint-10 were driven by external controllers using the 68000 as the CPU. The first HP LaserJet, introduced in 1984, used an 8 MHz 68000 in its built-in controller. Similar 68000-based integrated controllers were subsequently used in many other laser printers, including the Apple LaserWriter, the first PostScript laser printer, introduced in 1985. The 68000 continued to be widely used in laser printers throughout the rest of the 1980s, persisting well into the 1990s in low-end printers.
Outside traditional commercial or domestic computing applications, the 68000 also saw success in the field of industrial control systems. Among the systems which benefited from having a 68000 or derivative as their microprocessor were families of Programmable Logic Controllers (PLCs) manufactured by Allen-Bradley, Texas Instruments and subsequently, following the acquisition of that division of TI, by Siemens. Users of such systems do not accept product obsolescence at the same rate as domestic users and it is entirely likely that despite having been installed over 20 years ago, many 68000-based controllers will continue in reliable service well into the 21st century.
As technological advances obsoleted the 68000 from use in the standalone computing market, its use grew in consumer and embedded applications. Video game manufacturers used the 68000 as the backbone of many arcade games and home game consoles. Atari's Food Fight, from 1983, was one of the first 68000-based arcade games. The 68000 was the main CPU of many arcade systems during the late 1980s and early 1990s, such as Sega's System 16, Capcom's CPS-1 and CPS-2, and SNK's Neo Geo. A number of arcade systems used two 68000s; some even used three. During the 1990s, as arcade systems switched to more powerful processors for the main CPU, they often continued to use the 68000 as a sound controller.
The 68000 was also the central processor in several home game consoles of the late 1980s/early 1990s, including the Sega Mega Drive (Sega Genesis), the Sega Mega-CD (Sega CD), and the console version of the Neo Geo. Some later game consoles still included the 68000: the Sega Saturn used it as a dedicated sound controller, and in the Atari Jaguar it co-ordinated the activities of the other specialized graphics and sound chips.
The 68000-based 683XX microcontrollers have been utilized in a wide variety of applications, including networking and telephone equipment, television set-top boxes, and laboratory and medical instruments, among others. The MC68302 and its derivatives have been used in many communication products from Cisco, 3com, Ascend, Marconi and others. The DragonBall family was used in Palm Computing's popular Palm PDAs and in the Handspring Visor series, until Palm gradually phased out the architecture in favor of ARM processors. AlphaSmart uses the DragonBall family in later versions of its portable word processors.
Texas Instruments uses the 68000 in its high-end graphing calculators, the TI-89 and TI-92 series and Voyage 200. Early versions of these used a specialized microcontroller with a static 68EC000 core; later versions use a standard MC68SEC000 processor.
Architecture
Address bus
The 68000 was a clever compromise. When the 68000 was introduced, 16-bit buses were really the most practical size. However, the 68000 was designed with 32-bit registers and address spaces, on the assumption that hardware prices would fall.
Even though the 68000 had 16-bit ALUs, addresses were always stored as 32-bit quantities, i.e. it had a flat 32-bit address space. This meant that the 68000 was, and is, a 32-bit microprocessor. Contrast this to the 8086, which had 20-bit address space, but could only access 16-bit (64 kilobyte) chunks without manipulating segment registers. The 68000 achieved this functionality using three 16-bit ALUs. In normal operation, two 16-bit ALUs are chained together to perform an address operation, while the third executes the 16-bit arithmetic. For example, a 32-bit address register postincrement on a 16-bit ADD.W (An)+,Dn runs without speed penalty.
The original 68000 was internally a 16-bit part, but it was executing and existing within the parameters of a 32-bit ISA, as its instruction set describes a 32-bit architecture. The importance of architecture cannot be emphasized enough. Throughout history, addressing pains have not been hardware implementation problems, but always architectural problems (instruction set problems, i.e. software compatibility problems). The successor 68020 with 32-bit ALU and 32-bit databus runs unchanged 68000 software at "32-bit speed", manipulating data up to 4 gigabytes, far beyond what software of other "16-bit" CPUs (for example, the 8086) could do. Contrast this with the problems posed by segmented architectures such as the 80286 which eventually had to be emulated entirely in software. It is seen as an act of great foresight for the 68000 series to have been 32-bit from the beginning.
However, forwards-incompatible software sometimes resulted from programmers storing data in the address bits (24 through 31) that weren't implemented on the bus. When such code was executed on a machine with a wider address bus, bus errors resulted. Software upgrades were required before Macintosh computers could use over 8 MB RAM. This software usually remained backwards compatible. Many applications were written with more foresight, and never had such problems.
The 68000 required word and longword data items to be aligned to an even byte boundary. An attempt to access them at an odd address caused an exception. This restriction was lifted in the 32-bit 68020, although a performance penalty was still inflicted.
Internal registers
The CPU had eight 32-bit general-purpose data registers (D0-D7), and eight address registers (A0-A7). The last address register was also the standard stack pointer, and could be called either A7 or SP. This was a good number of registers in many ways. It was small enough to allow the 68000 to respond quickly to interrupts (because only 15 or 16 had to be saved), and yet large enough to make most calculations fast.
Having two types of registers was mildly annoying at times, but not hard to use in practice. Reportedly, it allowed the CPU designers to achieve a higher degree of parallelism, by using an auxiliary execution unit for the address registers.
Integer representation in the 68000 family is big-endian.
Status register
The 68000 comparison, arithmetic and logic operations set bits in a status register to record their results for use by later conditional jumps. The bits were "Z"ero, "C"arry, o"V"erflow, e"X"tend, and "N"egative. The e"X"tend bit deserves special mention, because it was separated from the Carry. This permitted the extra bit from arithmetic, logic and shift operations to be separated from the carry for flow-of-control and linkage.
The instruction set
The designers attempted to make the assembly language orthogonal. That is, instructions were divided into operations and address modes, and almost all address modes were available for almost all instructions. Many programmers disliked the "near" orthogonality, while others were grateful for the attempt.
At the bit level, the person writing the assembler would clearly see that these "instructions" could become any of several different op-codes. It was quite a good compromise because it gave almost the same convenience as a truly orthogonal machine, and yet also gave the CPU designers freedom to fill in the op-code table.
With only 56 instructions the minimal instruction size was huge for its day at 16 bits. Furthermore, many instructions and addressing modes added extra words on the back for addresses, more address-mode bits, etc.
Many designers believed that the MC68000 architecture had compact code for its cost, especially when produced by compilers. This belief in more compact code led to many of its design wins, and much of its longevity as an architecture.
This belief (or feature, depending on the designer) continued to make design wins for the instruction set (with updated CPUs) up until the ARM architecture introduced the Thumb instruction set that was similarly compact.
Privilege levels
The CPU, and later the whole family, implemented exactly two levels of privilege. User mode gave access to everything except the interrupt level control. Supervisor privilege gave access to everything. An interrupt always became supervisory. The supervisor bit was stored in the status register, and visible to user programs.
A real advantage of this system was that the supervisor level had a separate stack pointer. This permitted a multitasking system to use very small stacks for tasks, because the designers did not have to allocate the memory required to hold the stack frames of a maximum stack-up of interrupts.
Interrupts
The CPU recognized 7 interrupt levels. Levels 1 through 7 were strictly prioritized. That is, a higher-numbered interrupt could always interrupt a lower-numbered interrupt. In the status register, a privileged instruction allowed one to set the current minimum interrupt level, blocking lower priority interrupts. Level 7 was not maskable - in other words, an NMI. Level 1 could be interrupted by any higher level. Level 0 means no interrupt. The level was stored in the status register, and was visible to user-level programs.
Hardware interrupts are signalled to the CPU using three inputs that encode the highest pending interrupt priority. A separate interrupt controller is usually required to encode the interrupts, though for systems that do not require more than three hardware interrupts it is possible to connect the interrupt signals directly to the encoded inputs at the cost of additional software complexity. The interrupt controller can be as simple as a 74LS148 priority encoder, or may be part of a VLSI peripheral chip such as the MC68901 Multi-Function Peripheral, which also provided a UART, timer, and parallel I/O.
The "exception table" (interrupt vector addresses) was fixed at addresses 0 through 1023, permitting 256 32-bit vectors. The first vector was the starting stack address, and the second was the starting code address. Vectors 3 through 15 were used to report various errors: bus error, address error, illegal instruction, zero division, CHK & CHK2 vector, privilege violation, and some reserved vectors that became line 1010 emulator, line 1111 emulator, and hardware breakpoint. Vector 24 started the real interrupts: spurious interrupt (no hardware acknowledgement), and level 1 through level 7 autovectors, then the 15 TRAP vectors, then some more reserved vectors, then the user defined vectors.
Since at a minimum the starting code address vector must always be valid on reset, systems commonly included some nonvolatile memory (e.g. ROM) starting at address zero to contain the vectors and bootstrap code. However, for a general purpose system it is desirable for the operating system to be able to change the vectors at runtime. This was often accomplished by either pointing the vectors in ROM to a jump table in RAM, or through use of bank-switching to allow the ROM to be replaced by RAM at runtime.
The 68000 did not meet the Popek and Goldberg virtualization requirements for full processor virtualization because it had a single unprivileged instruction "MOVE from SR", which allowed user-mode software read-only access to a small amount of privileged state.
The 68000 was also unable to easily support virtual memory, which requires the ability to trap and recover from a failed memory access. The 68000 does provide a bus error exception which can be used to trap, but it does not save enough processor state to resume the faulted instruction once the operating system has handled the exception. Several companies did succeed in making 68000 based Unix workstations with virtual memory that worked, by using two 68000 chips running in parallel on different phased clocks. When the "leading" 68000 encountered a bad memory access, extra hardware would interrupt the "main" 68000 to prevent it from also encountering the bad memory access. This interrupt routine would handle the virtual memory functions and restart the "leading" 68000 in the correct state to continue properly synchronized operation when the "main" 68000 returned from the interrupt.
These problems were fixed in the next major revision of the 68K architecture, with the release of the MC68010. The Bus Error and Address Error exceptions pushed a large amount of internal state onto the supervisor stack in order to facilitate recovery, and the MOVE from SR instruction was made privileged. A new unprivileged "MOVE from CCR" instruction was provided for use in its place by user mode software; an operating system could trap and emulate user-mode MOVE from SR instructions if desired.
Article is taken from Wikipedia, the free encyclopedia
For direct link --> Click
History
The 68000 grew out of the MACSS (Motorola Advanced Computer System on Silicon) project, begun in 1976. One of the early decisions made was to develop a new "no compromise" architecture that paid little attention to backward compatibility. This was a gamble because it would mean adopters of the chip would have to learn the new system entirely from scratch. In the end, the only concession to backward compatibility was a hardware one: the 68k could interface to existing 6800 peripheral devices, but could not run 6800 code. However, the designers built in a tremendous amount of forward compatibility, which paid off once 68k expertise had been gained by end users. For instance, the CPU registers were 32-bits wide, though address and data buses outside the CPU were initially narrower. In contrast the Intel 8086/8088 were 16-bits wide internally. The MACSS team drew heavily on the influence of minicomputer processor design, such as the PDP-11 and VAX systems. The instruction set was developed with software development in mind more than hardware limitations; the idea was that developers familiar with these older systems would be comfortable programming the new microprocessor.
As the new design reached production a trade name had to be selected. The name "68000" was selected largely to provide some naming and marketing continuity with the earlier 6800, although there was little in common between the two designs. The name was justified by claiming the chip featured about 68,000 transistors, but in fact the count was closer to 70,000.
At the time, there was fierce competition among several of the then established manufacturers of 8-bit processors to bring out 16-bit designs. National Semiconductor had been first with its IMP-16 and PACE processors in 1973-1975, but these had issues with speed caused by their hole-doped MOS architecture. Texas Instruments was next, with its TMS9900, but its CPU was not widely accepted. Next came Intel with the Intel 8086/8088 in 1977/78. However, Motorola marketing stressed the (true) point that the 68000 was a much more complete 16-bit design than the others. This was reflected in its complexity. The transistor cell count, which was then a fairly direct measure of power in that era, was more than twice that of the 29,000 of the 8086.
The simplest 68000 instructions took four clock cycles, but the most complex ones required many more. An 8 MHz 68000 had an average performance of roughly 1 MIPS.
On average, the 68000's instructions in typical program code did more work per instruction than competing Intel processors, which meant that 68000 designs both needed less RAM to store machine code and were faster.[citation needed] Additionally, the 68000 offered a "flat" 24-bit addressing system supporting up to 16 MB of memory; at the time, this was a very large memory space. Intel chips instead used a segmented system which was much more difficult to program. Only in 1986 the 80386 allowed flat addressing. Thus the 68000 was easier to learn and work with, which led many engineers to prefer it to the Intel designs.
The original MC68000 was fabricated using an HMOS process with a 3.5-micron feature size. Initial engineering samples were released in late 1979. Production chips were available by 1980, with initial speed grades of 4, 6, and 8 MHz. 10 MHz chips became available during 1981, and 12.5 MHz chips during 1982. The 16.67 MHz "12F" version of the MC68000, the fastest version of the original HMOS chip, was not produced until the late 1980s.
To support low-cost systems with smaller memory sizes, Motorola introduced the MC68008 in 1982. This was a 68000 with an 8-bit data bus and a smaller (20 bits) address bus. The 68012 later brought a 32 bit address bus.
The 68HC000, the CMOS version of the 68000, was jointly introduced by Motorola and Hitachi in 1985.[1] Motorola's version was called the MC68HC000, while Hitachi's was the HD68HC000. The 68HC000 was eventually offered at speeds from 8 MHz to 20 MHz. Except for using CMOS circuitry, it behaved identically to the HMOS MC68000, but the change to CMOS greatly reduced its power consumption. The original HMOS MC68000 consumed around 1.35 watts at an ambient temperature of 25 °C, regardless of clock speed, while the MC68HC000 consumed only 0.13 watts at 8 MHz and 0.38 watts at 20 MHz. (Unlike CMOS circuits, HMOS circuits draw power whether they are switching or idle, so their power consumption varies little with clock rate, but it does vary with temperature.)
Motorola introduced the MC68HC001 in 1990.[2] This chip resembled the 68HC000 in most respects, but its data bus could operate in either 16-bit or 8-bit mode, depending on the value of an input pin at reset. Thus, like the 68008, it could be used in systems with cheaper 8-bit memories.
Several other companies were second-source manufacturers of the HMOS 68000. These included Hitachi (HD68000), Mostek (MK68000), Rockwell (R68000), Signetics (SCN68000), Thomson/SGS-Thomson (originally EF68000 and later TS68000), and Toshiba (TMP68000). Toshiba was also a second-source maker of the CMOS 68HC000 (TMP68HC000).
The 68000 became the foundation for a large number of microcontrollers and embedded processors. In 1989, Motorola introduced the MC68302 communications processor,[3] its first microcontroller to use a 68000 CPU core. This core was based on the CMOS 68HC000 but removed support for 8-bit 6800 peripherals. In 1991 Motorola introduced a separate processor chip based on this core, the MC68EC000.[4]
Motorola went on to make several additional microcontrollers with the 68EC000 core, including the MC68306 and MC68307 general-purpose microcontrollers, the MC68322 "Bandit" printer controller, the MC68356 modem data pump, and the MC68328 DragonBall, designed for portable devices. Other microcontrollers in the 683XX family used the more powerful CPU32 processor core.
Several of the 68EC000-based 683XX microcontrollers used a static version of the 68EC000 core; the processor clock of this core could be slowed or stopped to save power. In 1996 Motorola introduced this static core as a separate processor, the MC68SEC000.[5]
Motorola ceased production of the HMOS MC68000 and MC68008 in 1996,[6] but its spin-off company, Freescale Semiconductor, is still producing the MC68HC000, MC68HC001, MC68EC000, and MC68SEC000, as well as the MC68302 and MC68306 microcontrollers and later versions of the DragonBall family. The 68000's architectural descendants, the 680x0, CPU32, and Coldfire families, are also still in production.
Applications
The 68000 was first used during the early 1980s in high-priced systems, including multiuser microcomputers like the WICAT 150 [[1]], Tandy TRS-80 Model 16, and Fortune 32:16; single-user workstations such as Hewlett-Packard's HP 9000 Series 200 systems, the first Apollo/Domain systems, Sun Microsystems' Sun-1, and the Corvus Concept; and graphics terminals like Digital Equipment Corporation's VAXstation 100 and Silicon Graphics' IRIS 1000 and 1200. While Unix systems soon abandoned the original 68000 due to limitations of the processor, its derivatives remained popular in the Unix market throughout the 1980s.
During the mid 1980s, the 68000 was first used in personal and home computers, starting with the Apple Lisa and Macintosh, and followed by the Commodore Amiga, Atari ST, and Sharp X68000. The 68008, on the other hand, was only used in one home computer system, the Sinclair QL (though the QL was a sister machine to the ICL One Per Desk, which also used a 68008).
The 68000 eventually saw its greatest success as a controller. As early as 1981, laser printers such as the Imagen Imprint-10 were driven by external controllers using the 68000 as the CPU. The first HP LaserJet, introduced in 1984, used an 8 MHz 68000 in its built-in controller. Similar 68000-based integrated controllers were subsequently used in many other laser printers, including the Apple LaserWriter, the first PostScript laser printer, introduced in 1985. The 68000 continued to be widely used in laser printers throughout the rest of the 1980s, persisting well into the 1990s in low-end printers.
Outside traditional commercial or domestic computing applications, the 68000 also saw success in the field of industrial control systems. Among the systems which benefited from having a 68000 or derivative as their microprocessor were families of Programmable Logic Controllers (PLCs) manufactured by Allen-Bradley, Texas Instruments and subsequently, following the acquisition of that division of TI, by Siemens. Users of such systems do not accept product obsolescence at the same rate as domestic users and it is entirely likely that despite having been installed over 20 years ago, many 68000-based controllers will continue in reliable service well into the 21st century.
As technological advances obsoleted the 68000 from use in the standalone computing market, its use grew in consumer and embedded applications. Video game manufacturers used the 68000 as the backbone of many arcade games and home game consoles. Atari's Food Fight, from 1983, was one of the first 68000-based arcade games. The 68000 was the main CPU of many arcade systems during the late 1980s and early 1990s, such as Sega's System 16, Capcom's CPS-1 and CPS-2, and SNK's Neo Geo. A number of arcade systems used two 68000s; some even used three. During the 1990s, as arcade systems switched to more powerful processors for the main CPU, they often continued to use the 68000 as a sound controller.
The 68000 was also the central processor in several home game consoles of the late 1980s/early 1990s, including the Sega Mega Drive (Sega Genesis), the Sega Mega-CD (Sega CD), and the console version of the Neo Geo. Some later game consoles still included the 68000: the Sega Saturn used it as a dedicated sound controller, and in the Atari Jaguar it co-ordinated the activities of the other specialized graphics and sound chips.
The 68000-based 683XX microcontrollers have been utilized in a wide variety of applications, including networking and telephone equipment, television set-top boxes, and laboratory and medical instruments, among others. The MC68302 and its derivatives have been used in many communication products from Cisco, 3com, Ascend, Marconi and others. The DragonBall family was used in Palm Computing's popular Palm PDAs and in the Handspring Visor series, until Palm gradually phased out the architecture in favor of ARM processors. AlphaSmart uses the DragonBall family in later versions of its portable word processors.
Texas Instruments uses the 68000 in its high-end graphing calculators, the TI-89 and TI-92 series and Voyage 200. Early versions of these used a specialized microcontroller with a static 68EC000 core; later versions use a standard MC68SEC000 processor.
Architecture
Address bus
The 68000 was a clever compromise. When the 68000 was introduced, 16-bit buses were really the most practical size. However, the 68000 was designed with 32-bit registers and address spaces, on the assumption that hardware prices would fall.
Even though the 68000 had 16-bit ALUs, addresses were always stored as 32-bit quantities, i.e. it had a flat 32-bit address space. This meant that the 68000 was, and is, a 32-bit microprocessor. Contrast this to the 8086, which had 20-bit address space, but could only access 16-bit (64 kilobyte) chunks without manipulating segment registers. The 68000 achieved this functionality using three 16-bit ALUs. In normal operation, two 16-bit ALUs are chained together to perform an address operation, while the third executes the 16-bit arithmetic. For example, a 32-bit address register postincrement on a 16-bit ADD.W (An)+,Dn runs without speed penalty.
The original 68000 was internally a 16-bit part, but it was executing and existing within the parameters of a 32-bit ISA, as its instruction set describes a 32-bit architecture. The importance of architecture cannot be emphasized enough. Throughout history, addressing pains have not been hardware implementation problems, but always architectural problems (instruction set problems, i.e. software compatibility problems). The successor 68020 with 32-bit ALU and 32-bit databus runs unchanged 68000 software at "32-bit speed", manipulating data up to 4 gigabytes, far beyond what software of other "16-bit" CPUs (for example, the 8086) could do. Contrast this with the problems posed by segmented architectures such as the 80286 which eventually had to be emulated entirely in software. It is seen as an act of great foresight for the 68000 series to have been 32-bit from the beginning.
However, forwards-incompatible software sometimes resulted from programmers storing data in the address bits (24 through 31) that weren't implemented on the bus. When such code was executed on a machine with a wider address bus, bus errors resulted. Software upgrades were required before Macintosh computers could use over 8 MB RAM. This software usually remained backwards compatible. Many applications were written with more foresight, and never had such problems.
The 68000 required word and longword data items to be aligned to an even byte boundary. An attempt to access them at an odd address caused an exception. This restriction was lifted in the 32-bit 68020, although a performance penalty was still inflicted.
Internal registers
The CPU had eight 32-bit general-purpose data registers (D0-D7), and eight address registers (A0-A7). The last address register was also the standard stack pointer, and could be called either A7 or SP. This was a good number of registers in many ways. It was small enough to allow the 68000 to respond quickly to interrupts (because only 15 or 16 had to be saved), and yet large enough to make most calculations fast.
Having two types of registers was mildly annoying at times, but not hard to use in practice. Reportedly, it allowed the CPU designers to achieve a higher degree of parallelism, by using an auxiliary execution unit for the address registers.
Integer representation in the 68000 family is big-endian.
Status register
The 68000 comparison, arithmetic and logic operations set bits in a status register to record their results for use by later conditional jumps. The bits were "Z"ero, "C"arry, o"V"erflow, e"X"tend, and "N"egative. The e"X"tend bit deserves special mention, because it was separated from the Carry. This permitted the extra bit from arithmetic, logic and shift operations to be separated from the carry for flow-of-control and linkage.
The instruction set
The designers attempted to make the assembly language orthogonal. That is, instructions were divided into operations and address modes, and almost all address modes were available for almost all instructions. Many programmers disliked the "near" orthogonality, while others were grateful for the attempt.
At the bit level, the person writing the assembler would clearly see that these "instructions" could become any of several different op-codes. It was quite a good compromise because it gave almost the same convenience as a truly orthogonal machine, and yet also gave the CPU designers freedom to fill in the op-code table.
With only 56 instructions the minimal instruction size was huge for its day at 16 bits. Furthermore, many instructions and addressing modes added extra words on the back for addresses, more address-mode bits, etc.
Many designers believed that the MC68000 architecture had compact code for its cost, especially when produced by compilers. This belief in more compact code led to many of its design wins, and much of its longevity as an architecture.
This belief (or feature, depending on the designer) continued to make design wins for the instruction set (with updated CPUs) up until the ARM architecture introduced the Thumb instruction set that was similarly compact.
Privilege levels
The CPU, and later the whole family, implemented exactly two levels of privilege. User mode gave access to everything except the interrupt level control. Supervisor privilege gave access to everything. An interrupt always became supervisory. The supervisor bit was stored in the status register, and visible to user programs.
A real advantage of this system was that the supervisor level had a separate stack pointer. This permitted a multitasking system to use very small stacks for tasks, because the designers did not have to allocate the memory required to hold the stack frames of a maximum stack-up of interrupts.
Interrupts
The CPU recognized 7 interrupt levels. Levels 1 through 7 were strictly prioritized. That is, a higher-numbered interrupt could always interrupt a lower-numbered interrupt. In the status register, a privileged instruction allowed one to set the current minimum interrupt level, blocking lower priority interrupts. Level 7 was not maskable - in other words, an NMI. Level 1 could be interrupted by any higher level. Level 0 means no interrupt. The level was stored in the status register, and was visible to user-level programs.
Hardware interrupts are signalled to the CPU using three inputs that encode the highest pending interrupt priority. A separate interrupt controller is usually required to encode the interrupts, though for systems that do not require more than three hardware interrupts it is possible to connect the interrupt signals directly to the encoded inputs at the cost of additional software complexity. The interrupt controller can be as simple as a 74LS148 priority encoder, or may be part of a VLSI peripheral chip such as the MC68901 Multi-Function Peripheral, which also provided a UART, timer, and parallel I/O.
The "exception table" (interrupt vector addresses) was fixed at addresses 0 through 1023, permitting 256 32-bit vectors. The first vector was the starting stack address, and the second was the starting code address. Vectors 3 through 15 were used to report various errors: bus error, address error, illegal instruction, zero division, CHK & CHK2 vector, privilege violation, and some reserved vectors that became line 1010 emulator, line 1111 emulator, and hardware breakpoint. Vector 24 started the real interrupts: spurious interrupt (no hardware acknowledgement), and level 1 through level 7 autovectors, then the 15 TRAP vectors, then some more reserved vectors, then the user defined vectors.
Since at a minimum the starting code address vector must always be valid on reset, systems commonly included some nonvolatile memory (e.g. ROM) starting at address zero to contain the vectors and bootstrap code. However, for a general purpose system it is desirable for the operating system to be able to change the vectors at runtime. This was often accomplished by either pointing the vectors in ROM to a jump table in RAM, or through use of bank-switching to allow the ROM to be replaced by RAM at runtime.
The 68000 did not meet the Popek and Goldberg virtualization requirements for full processor virtualization because it had a single unprivileged instruction "MOVE from SR", which allowed user-mode software read-only access to a small amount of privileged state.
The 68000 was also unable to easily support virtual memory, which requires the ability to trap and recover from a failed memory access. The 68000 does provide a bus error exception which can be used to trap, but it does not save enough processor state to resume the faulted instruction once the operating system has handled the exception. Several companies did succeed in making 68000 based Unix workstations with virtual memory that worked, by using two 68000 chips running in parallel on different phased clocks. When the "leading" 68000 encountered a bad memory access, extra hardware would interrupt the "main" 68000 to prevent it from also encountering the bad memory access. This interrupt routine would handle the virtual memory functions and restart the "leading" 68000 in the correct state to continue properly synchronized operation when the "main" 68000 returned from the interrupt.
These problems were fixed in the next major revision of the 68K architecture, with the release of the MC68010. The Bus Error and Address Error exceptions pushed a large amount of internal state onto the supervisor stack in order to facilitate recovery, and the MOVE from SR instruction was made privileged. A new unprivileged "MOVE from CCR" instruction was provided for use in its place by user mode software; an operating system could trap and emulate user-mode MOVE from SR instructions if desired.
Article is taken from Wikipedia, the free encyclopedia
For direct link --> Click
Wednesday, July 11, 2007
News from MIT
MIT team experimentally demonstrates wireless power transfer, potentially useful for powering laptops, cell phones without cords
Franklin Hadley, Institute for Soldier Nanotechnologies
June 7, 2007
Imagine a future in which wireless power transfer is feasible: cell phones, household robots, mp3 players, laptop computers and other portable electronics capable of charging themselves without ever being plugged in, freeing us from that final, ubiquitous power wire. Some of these devices might not even need their bulky batteries to operate.
A team from MIT's Department of Physics, Department of Electrical Engineering and Computer Science, and Institute for Soldier Nanotechnologies (ISN) has experimentally demonstrated an important step toward accomplishing this vision of the future.
The team members are Andre Kurs, Aristeidis Karalis, Robert Moffatt, Prof. Peter Fisher, and Prof. John Joannopoulos (Francis Wright Davis Chair and director of ISN), led by Prof. Marin Soljacic.
Realizing their recent theoretical prediction, they were able to light a 60W light bulb from a power source seven feet (more than two meters) away; there was no physical connection between the source and the appliance. The MIT team refers to its concept as "WiTricity" (as in wireless electricity). The work will be reported in the June 7 issue of Science Express, the advance online publication of the journal Science.
Late-night beeps
The story starts one late night a few years ago, with Soljacic (pronounced Soul-ya-cheech) standing in his pajamas, staring at his cell phone on the kitchen counter. "It was probably the sixth time that month that I was awakened by my cell phone beeping to let me know that I had forgotten to charge it. It occurred to me that it would be so great if the thing took care of its own charging." To make this possible, one would have to have a way to transmit power wirelessly, so Soljacic started thinking about which physical phenomena could help make this wish a reality.
Radiation methods
Various methods of transmitting power wirelessly have been known for centuries. Perhaps the best known example is electromagnetic radiation, such as radio waves. While such radiation is excellent for wireless transmission of information, it is not feasible to use it for power transmission. Since radiation spreads in all directions, a vast majority of power would end up being wasted into free space.
One can envision using directed electromagnetic radiation, such as lasers, but this is not very practical and can even be dangerous. It requires an uninterrupted line of sight between the source and the device, as well as a sophisticated tracking mechanism when the device is mobile.
The key: Magnetically coupled resonance
In contrast, WiTricity is based on using coupled resonant objects. Two resonant objects of the same resonant frequency tend to exchange energy efficiently, while interacting weakly with extraneous off-resonant objects. A child on a swing is a good example of this. A swing is a type of mechanical resonance, so only when the child pumps her legs at the natural frequency of the swing is she able to impart substantial energy.
Another example involves acoustic resonances: Imagine a room with 100 identical wine glasses, each filled with wine up to a different level, so they all have different resonant frequencies. If an opera singer sings a sufficiently loud single note inside the room, a glass of the corresponding frequency might accumulate sufficient energy to even explode, while not influencing the other glasses. In any system of coupled resonators there often exists a so-called "strongly coupled" regime of operation. If one ensures to operate in that regime in a given system, the energy transfer can be very efficient.
While these considerations are universal, applying to all kinds of resonances (e.g., acoustic, mechanical, electromagnetic, etc.), the MIT team focused on one particular type: magnetically coupled resonators. The team explored a system of two electromagnetic resonators coupled mostly through their magnetic fields; they were able to identify the strongly coupled regime in this system, even when the distance between them was several times larger than the sizes of the resonant objects. This way, efficient power transfer was enabled.
Magnetic coupling is particularly suitable for everyday applications because most common materials interact only very weakly with magnetic fields, so interactions with extraneous environmental objects are suppressed even further. "The fact that magnetic fields interact so weakly with biological organisms is also important for safety considerations," Kurs, a graduate student in physics, points out.
The investigated design consists of two copper coils, each a self-resonant system. One of the coils, attached to the power source, is the sending unit. Instead of irradiating the environment with electromagnetic waves, it fills the space around it with a non-radiative magnetic field oscillating at MHz frequencies. The non-radiative field mediates the power exchange with the other coil (the receiving unit), which is specially designed to resonate with the field. The resonant nature of the process ensures the strong interaction between the sending unit and the receiving unit, while the interaction with the rest of the environment is weak.
Moffatt, an MIT undergraduate in physics, explains: "The crucial advantage of using the non-radiative field lies in the fact that most of the power not picked up by the receiving coil remains bound to the vicinity of the sending unit, instead of being radiated into the environment and lost." With such a design, power transfer has a limited range, and the range would be shorter for smaller-size receivers.
Still, for laptop-sized coils, power levels more than sufficient to run a laptop can be transferred over room-sized distances nearly omni-directionally and efficiently, irrespective of the geometry of the surrounding space, even when environmental objects completely obstruct the line-of-sight between the two coils. Fisher points out: "As long as the laptop is in a room equipped with a source of such wireless power, it would charge automatically, without having to be plugged in. In fact, it would not even need a battery to operate inside of such a room." In the long run, this could reduce our society's dependence on batteries, which are currently heavy and expensive.
At first glance, such a power transfer is reminiscent of relatively commonplace magnetic induction, such as is used in power transformers, which contain coils that transmit power to each other over very short distances. An electric current running in a sending coil induces another current in a receiving coil. The two coils are very close, but they do not touch. However, this behavior changes dramatically when the distance between the coils is increased. As Karalis, a graduate student in electrical engineering and computer science, points out, "Here is where the magic of the resonant coupling comes about. The usual non-resonant magnetic induction would be almost 1 million times less efficient in this particular system."
Old physics, new demand
WiTricity is rooted in such well-known laws of physics that it makes one wonder why no one thought of it before. "In the past, there was no great demand for such a system, so people did not have a strong motivation to look into it," points out Joannopoulos, adding, "Over the past several years, portable electronic devices, such as laptops, cell phones, iPods and even household robots have become widespread, all of which require batteries that need to be recharged often."
As for what the future holds, Soljacic adds, "Once, when my son was about three years old, we visited his grandparents' house. They had a 20-year-old phone and my son picked up the handset, asking, 'Dad, why is this phone attached with a cord to the wall?' That is the mindset of a child growing up in a wireless world. My best response was, 'It is strange and awkward, isn't it? Hopefully, we will be getting rid of some more wires, and also batteries, soon.'"
This work was funded by the Army Research Office (Institute for Soldier Nanotechnologies), National Science Foundation (Center for Materials Science and Engineering), and the Department of Energy.
This artical is taken from massachusetts institute of technology.
Direct link to the artical --> Click
Franklin Hadley, Institute for Soldier Nanotechnologies
June 7, 2007
Imagine a future in which wireless power transfer is feasible: cell phones, household robots, mp3 players, laptop computers and other portable electronics capable of charging themselves without ever being plugged in, freeing us from that final, ubiquitous power wire. Some of these devices might not even need their bulky batteries to operate.
A team from MIT's Department of Physics, Department of Electrical Engineering and Computer Science, and Institute for Soldier Nanotechnologies (ISN) has experimentally demonstrated an important step toward accomplishing this vision of the future.
The team members are Andre Kurs, Aristeidis Karalis, Robert Moffatt, Prof. Peter Fisher, and Prof. John Joannopoulos (Francis Wright Davis Chair and director of ISN), led by Prof. Marin Soljacic.
Realizing their recent theoretical prediction, they were able to light a 60W light bulb from a power source seven feet (more than two meters) away; there was no physical connection between the source and the appliance. The MIT team refers to its concept as "WiTricity" (as in wireless electricity). The work will be reported in the June 7 issue of Science Express, the advance online publication of the journal Science.
Late-night beeps
The story starts one late night a few years ago, with Soljacic (pronounced Soul-ya-cheech) standing in his pajamas, staring at his cell phone on the kitchen counter. "It was probably the sixth time that month that I was awakened by my cell phone beeping to let me know that I had forgotten to charge it. It occurred to me that it would be so great if the thing took care of its own charging." To make this possible, one would have to have a way to transmit power wirelessly, so Soljacic started thinking about which physical phenomena could help make this wish a reality.
Radiation methods
Various methods of transmitting power wirelessly have been known for centuries. Perhaps the best known example is electromagnetic radiation, such as radio waves. While such radiation is excellent for wireless transmission of information, it is not feasible to use it for power transmission. Since radiation spreads in all directions, a vast majority of power would end up being wasted into free space.
One can envision using directed electromagnetic radiation, such as lasers, but this is not very practical and can even be dangerous. It requires an uninterrupted line of sight between the source and the device, as well as a sophisticated tracking mechanism when the device is mobile.
The key: Magnetically coupled resonance
In contrast, WiTricity is based on using coupled resonant objects. Two resonant objects of the same resonant frequency tend to exchange energy efficiently, while interacting weakly with extraneous off-resonant objects. A child on a swing is a good example of this. A swing is a type of mechanical resonance, so only when the child pumps her legs at the natural frequency of the swing is she able to impart substantial energy.
Another example involves acoustic resonances: Imagine a room with 100 identical wine glasses, each filled with wine up to a different level, so they all have different resonant frequencies. If an opera singer sings a sufficiently loud single note inside the room, a glass of the corresponding frequency might accumulate sufficient energy to even explode, while not influencing the other glasses. In any system of coupled resonators there often exists a so-called "strongly coupled" regime of operation. If one ensures to operate in that regime in a given system, the energy transfer can be very efficient.
While these considerations are universal, applying to all kinds of resonances (e.g., acoustic, mechanical, electromagnetic, etc.), the MIT team focused on one particular type: magnetically coupled resonators. The team explored a system of two electromagnetic resonators coupled mostly through their magnetic fields; they were able to identify the strongly coupled regime in this system, even when the distance between them was several times larger than the sizes of the resonant objects. This way, efficient power transfer was enabled.
Magnetic coupling is particularly suitable for everyday applications because most common materials interact only very weakly with magnetic fields, so interactions with extraneous environmental objects are suppressed even further. "The fact that magnetic fields interact so weakly with biological organisms is also important for safety considerations," Kurs, a graduate student in physics, points out.
The investigated design consists of two copper coils, each a self-resonant system. One of the coils, attached to the power source, is the sending unit. Instead of irradiating the environment with electromagnetic waves, it fills the space around it with a non-radiative magnetic field oscillating at MHz frequencies. The non-radiative field mediates the power exchange with the other coil (the receiving unit), which is specially designed to resonate with the field. The resonant nature of the process ensures the strong interaction between the sending unit and the receiving unit, while the interaction with the rest of the environment is weak.
Moffatt, an MIT undergraduate in physics, explains: "The crucial advantage of using the non-radiative field lies in the fact that most of the power not picked up by the receiving coil remains bound to the vicinity of the sending unit, instead of being radiated into the environment and lost." With such a design, power transfer has a limited range, and the range would be shorter for smaller-size receivers.
Still, for laptop-sized coils, power levels more than sufficient to run a laptop can be transferred over room-sized distances nearly omni-directionally and efficiently, irrespective of the geometry of the surrounding space, even when environmental objects completely obstruct the line-of-sight between the two coils. Fisher points out: "As long as the laptop is in a room equipped with a source of such wireless power, it would charge automatically, without having to be plugged in. In fact, it would not even need a battery to operate inside of such a room." In the long run, this could reduce our society's dependence on batteries, which are currently heavy and expensive.
At first glance, such a power transfer is reminiscent of relatively commonplace magnetic induction, such as is used in power transformers, which contain coils that transmit power to each other over very short distances. An electric current running in a sending coil induces another current in a receiving coil. The two coils are very close, but they do not touch. However, this behavior changes dramatically when the distance between the coils is increased. As Karalis, a graduate student in electrical engineering and computer science, points out, "Here is where the magic of the resonant coupling comes about. The usual non-resonant magnetic induction would be almost 1 million times less efficient in this particular system."
Old physics, new demand
WiTricity is rooted in such well-known laws of physics that it makes one wonder why no one thought of it before. "In the past, there was no great demand for such a system, so people did not have a strong motivation to look into it," points out Joannopoulos, adding, "Over the past several years, portable electronic devices, such as laptops, cell phones, iPods and even household robots have become widespread, all of which require batteries that need to be recharged often."
As for what the future holds, Soljacic adds, "Once, when my son was about three years old, we visited his grandparents' house. They had a 20-year-old phone and my son picked up the handset, asking, 'Dad, why is this phone attached with a cord to the wall?' That is the mindset of a child growing up in a wireless world. My best response was, 'It is strange and awkward, isn't it? Hopefully, we will be getting rid of some more wires, and also batteries, soon.'"
This work was funded by the Army Research Office (Institute for Soldier Nanotechnologies), National Science Foundation (Center for Materials Science and Engineering), and the Department of Energy.
This artical is taken from massachusetts institute of technology.
Direct link to the artical --> Click
Note from University of Malaya
This link is to download the note...
Introduction
Introduction
Number Systems
Number Systems
Architecture of MC6800
Architecture of MC6800
Introduction to MC6800 Instruction set
Download MC6800 manual (including instruction set)
Extra reading
Machine architecture
Programming languages
Number systems
For more information just visit http://biomed.um.edu.my/notes/mp/default.asp
Introduction
Introduction
Number Systems
Number Systems
Architecture of MC6800
Architecture of MC6800
Introduction to MC6800 Instruction set
Download MC6800 manual (including instruction set)
Extra reading
Machine architecture
Programming languages
Number systems
For more information just visit http://biomed.um.edu.my/notes/mp/default.asp
Welcome
This blog is create to share information about Electrical Engineering to all who interested in this field of study especially to my classmate in 3SEE - University Technology of Malaysia. I hope this blog can help all the visitor to gain more information regarding Electrical Engineering course.
Thank you.
Thank you.
Subscribe to:
Posts (Atom)
