Download 3.0 Constraint Analysis and Component Selection

ECE 477 Final Report
Fall 2004
Team Code Name: ____________The Nostalgic Four_______________ Team ID: ___5___
Team Members (#1 is Team Leader):
#1: ____Peter Salama_____________
Signature: ____________________ Date: _________
#2: ____John Mastarone__________
Signature: ____________________ Date: _________
#3: ____Jorge Marcet____________
Signature: ____________________ Date: _________
#4: ____Zhang Zhixiang__________
Signature: ____________________ Date: _________
ECE 477 Final Report
Fall 2004
-ii-
ECE 477 Final Report
Fall 2004
REPORT EVALUATION
Component/Criterion
Score
Multiplier
Abstract
0 1 2 3 4 5 6 7 8 9 10
X1
Project Overview and Block Diagram
0 1 2 3 4 5 6 7 8 9 10
X2
Team Success Criteria/Fulfillment
0 1 2 3 4 5 6 7 8 9 10
X2
Constraint Analysis/Component Selection
0 1 2 3 4 5 6 7 8 9 10
X2
Patent Liability Analysis
0 1 2 3 4 5 6 7 8 9 10
X2
Reliability and Safety Analysis
0 1 2 3 4 5 6 7 8 9 10
X2
Ethical/Environmental Impact Analysis
0 1 2 3 4 5 6 7 8 9 10
X2
Packaging Design Considerations
0 1 2 3 4 5 6 7 8 9 10
X2
Schematic Design Considerations
0 1 2 3 4 5 6 7 8 9 10
X2
PCB Layout Design Considerations
0 1 2 3 4 5 6 7 8 9 10
X2
Software Design Considerations
0 1 2 3 4 5 6 7 8 9 10
X2
Version 2 Changes
0 1 2 3 4 5 6 7 8 9 10
X1
Summary and Conclusions
0 1 2 3 4 5 6 7 8 9 10
X1
References
0 1 2 3 4 5 6 7 8 9 10
X2
Appendix A: Individual Contributions
0 1 2 3 4 5 6 7 8 9 10
X4
Appendix B: Packaging
0 1 2 3 4 5 6 7 8 9 10
X2
Appendix C: Schematic
0 1 2 3 4 5 6 7 8 9 10
X2
Appendix D: Top & Bottom Copper
0 1 2 3 4 5 6 7 8 9 10
X2
Appendix E: Parts List Spreadsheet
0 1 2 3 4 5 6 7 8 9 10
X2
Appendix F: Software Listing
0 1 2 3 4 5 6 7 8 9 10
X2
Appendix G: User Manual
0 1 2 3 4 5 6 7 8 9 10
X2
Appendix H: FMECA Worksheet
0 1 2 3 4 5 6 7 8 9 10
X2
Technical Writing Style
0 1 2 3 4 5 6 7 8 9 10
X5
CD-R of Website Image
0 1 2 3 4 5 6 7 8 9 10
X2
TOTAL
Comments:
-iii-
Points
ECE 477 Final Report
Fall 2004
TABLE OF CONTENTS
Abstract
1.0 Project Overview and Block Diagram
2.0 Team Success Criteria and Fulfillment
3.0 Constraint Analysis and Component Selection
4.0 Patent Liability Analysis
5.0 Reliability and Safety Analysis
6.0 Ethical and Environmental Impact Analysis
7.0 Packaging Design Considerations
8.0 Schematic Design Considerations
9.0 PCB Layout Design Considerations
10.0 Software Design Considerations
11.0 Version 2 Changes
12.0 Summary and Conclusions
13.0 References
Appendix A: Individual Contributions
Appendix B: Packaging
Appendix C: Schematic
Appendix D: PCB Layout Top and Bottom Copper
Appendix E: Parts List Spreadsheet
Appendix F: Software Listing
Appendix G: User Manual
Appendix H: FMECA Worksheet
Appendix I: MTTF Calculations
-iv-
1
1
2
3
6
9
13
16
18
23
25
31
32
32
A
B
C
D
E
F
G
H
I
ECE 477 Final Report
Fall 2004
-v-
ECE 477 Final Report
Fall 2004
Abstract
The Nostalgic 4 (N4) is a game console that interfaces to two Nintendo-style game
controllers for single or two-player game play, and displays the pre-loaded game on a regular TV
set in NTSC format. N4 will also have the option to load game data from a USB memory stick
via the USB interface. Following the theme “Nostalgia”, N4 will run the classic “Pong” game
for two players. Further game development may extend to other classic games like “Cannon
Fodder”.
1.0 Project Overview and Block Diagram
BDM &
RS232
5/3.3 V
Power
Supply
Microprocessor
NTSC
Video
Output
Audio
Output
USB
Interface
User
Interface
(Nintendo)
Figure 1.1 Block Diagram of the N4 Video Game Console
-1-
ECE 477 Final Report
Fall 2004
The N4 project is the implementation of a simple video game system. The system will
utilize an MC9S12 MCU and 128KB of SRAM to control and provide data to a 16-color video
display circuit, which in turn will output images with a resolution of 320 x 240 in NTSC video
format. The system will retrieve games from a type-A USB memory device through a USBinterface circuit, will use two pre-existing Nintendo Entertainment System controllers, and will
also utilize a simple monotone sound circuit to produce sound while a game is being played.
Finally, the circuit will use a 12 volt DC power supply combined with one 3.3 volt and one 5 volt
step-down regulator to power different portions of the system. A block diagram of this system is
shown in Figure 1.1. A picture of the actual N4 video game console is shown in Figure 1.2.
Figure 1.2 N4 Video Game Console
2.0 Team Success Criteria and Fulfillment
The project specific criteria are as follows:
-2-
ECE 477 Final Report
Fall 2004
1. Ability to generate NTSC video output signal
2. Ability to create and run games
3. Ability to control game functions via two controllers
4. Ability to load game code from a USB Memory Stick
5. Ability to generate sounds synchronized with game functions
Criteria 1, 2, 3 and 5 were successfully demonstrated. Although the code for the USB
driver had been written, there was not enough time for sufficient testing and debugging. Hence,
the 4th criterion was not sufficiently demonstrated.
3.0 Constraint Analysis and Component Selection
Attached in Figure E is the parts list for N4’s design. The following is the constraint
analysis and component selection.
Analysis of “real world” design constraints
Computation Requirements
According to the video circuit reference website [1], the minimum time required to
perform a write operation to the video circuit is 70 ns; this is approximately 14 MHz. In order to
optimize our project’s performance, a processor with a greater frequency than 14 MHz is desired,
so that no delay is perceived during gameplay. In general, a faster processor is required so that
transfers from the USB, computation of game logic, updates of the game image are not so long
as to reduce the quality of gameplay.
Interface Requirements
The main interface requirement is that the processor has a large number of I/O pins to
accommodate our peripherals. The product will need I/O pins for two Nintendo controllers, USB
address/data and control lines, 16-bit address and data pins to interface to external RAM and the
video circuit, video control lines, and audio control lines. The microcontroller will interface to
Nintendo controllers, an audio circuit, a USB host circuit, and a video circuit.
-3-
ECE 477 Final Report
Fall 2004
Power Requirements
A wall-wart will supply 12 V DC to the board. The on-chip power supply then steps
down the 12 V to 3.3 V and 5 V respectively for the different circuits. The USB interface runs on
3.3 V while the rest of the board runs on 5V. In addition, current considerations were taken into
account. Table 3.1 shows a tabulation of the current requirements of each chip on the board.
Since both step-down regulators will output 1 A current each, it is safe to say that there will be
enough current for all the components.
Part
Qty
Max Required Current per
Max Required
Chip (mA)
Current (mA)
MC9S12A256
1
65
65
XC95108
1
200
200
AD724
1
42
42
SL811HS
1
25
25
CY7C109
3
90
270
74VHC573
2
75
150
Total:
752
Table 3.1 Current Requirements
Packaging Requirements
Issues such as the general shape, size, weight, and color scheme should be considered in
order to capture consumer attention. The console breaks away from the angular norm. The main
body of the unit will be cylindrical in shape, displaying 2 simple Nintendo-style controller ports,
a USB port, and a speaker vent for audio output. In addition, there are vents on the back of the
main unit for ventilation. Light and compact, ideal for placement in a home entertainment
system, the console’s target weight should be no more than 1.5 kg.
Cost Requirements
Development kits for our processor and USB host controller are expensive and will thus
not be used in our product; no other development kits are available for the major blocks in our
-4-
ECE 477 Final Report
Fall 2004
product. None of the individual components required for our product are expensive, but due to
the large number of parts required, the project could have a large cost if multiple copies of
certain parts need to be ordered (due to part failure, destruction, etc). The total cost of our
project, assuming no part is ordered more than once, is approximately 100.00 dollars, and our
team as a whole is not constrained by this cost estimate.
Rationale for Component Selection
Clock speed, number of pins, memory size, and port speed were deciding factors in the
choice of processors. Due to the nature of the project it was found that a large number of pins
would be required to accommodate all the peripherals interfaced, fast I/O would be important in
minimizing delays, and the overhead of clock cycles would have to be kept to a minimum to
maintain game and display synchronization without signal corruption. With those three
important elements in mind it was found that all the Atmel microcontrollers [2] would be out of
the question as they don’t have enough pins. On the other hand the Rabbit microcontrollers [3]
provided too much overhead for the purposes of receiving requests from the user and outputting
video successfully. Thus the Motorola family [4] was the only option. Two chips were found
MC9S12DG256 and MC9S12A256. Both have 12k RAM, 256K Flash, and 25 MHz, however
the former has one more MUX unit. Due to the unavailability of the MC9S12DG256 the
MC9S12A256PV chip will be implemented in the project.
Table 3.2 provides a clear concise comparison of the Atmel, Rabbit, and Motorola
microcontroller families respectively. Notice that the MC9S12A256 has the most pins along
with a fast processor and enough memory, making it ideal for the intended design. Finally for
interfacing to the TV and video production, it was found that a successful design included a
CPLD, NTSC driver, and a SRAM chip. The CPLD generates all the NTSC sync signals, while
the SRAM acts as a frame buffer, sending the RGB signal to the NTSC encoder chip and then
converting it to NTSC composite signal.
Product
Memory
Operating
Packaging
Frequency
ATmega64
64K Flash
8/16 MHz
2K bytes EEPROM
-5-
64-pin
ECE 477 Final Report
Fall 2004
4K bytes SRAM
RCM3000
512K Flash
28.4 MHz
52-pin
25 MHz
112-pin
512K bytes
EEPROM
MC9S12A256
256K Flash
4K bytes EEPROM
12K bytes SRAM
Table 3.2 Microcontroller Comparisons
4.0 Patent Liability Analysis
An introductory analysis of possible patent violations can be done by examining hardware
and software components of our system separately. For the software, patent analysis can be
performed on the video games that this team plans to implement and the source programs that
will be written for the MCU. For the hardware, patent analysis can be broken up into
examination of the video display circuit, the USB control circuit, and the power supply.
Results of Patent Search
Software—Games
N4 currently plan to implement simple versions of two games. The first is popularly
known as “Pong”, and the other is known as “Cannons” to our team—it is also called “Cannon”
or “Cannon Fodder” [1]. Atari Interactive Inc [2], the mostly like owner of a patent for Pong
source code, does not have such a patent. Searches for a combination of “pong” and “game” as
patents yield no results referring to a video or computer game that matches the intended game. It
is also unlikely that a patent exists that is still in effect since there are currently many free
versions of the game available in a variety of programming languages; the game seems to have
entered the “public domain”. Similar circumstances apply to “Cannons”.
Software—Others
-6-
ECE 477 Final Report
Fall 2004
There are three major portions of the software we will use to control hardware: USBinterfacing code, low-level microprocessor code to load and execute a game, and software to
control the video circuit. The USB-interfacing code will be lifted from a document [3]
copyrighted by Cypress. Since the document is copyrighted, it is unlikely that the code is also
patented—searches for such patents yield no relevant results. Some of the software written by
the developers of Sparky is used as a reference. Patent searches for patents held by the members
of this team yield no results. Finally, the software used to control the video circuit is freeware;
patent searches for the author of this software as the assignee yield no results.
Hardware
The first major hardware block of our game console that may have patent violations is
our power supply circuit. The power supply utilizes a 12 volt DC adapter made by RadioShack
and two step-down regulators made by Maxim. The step-down voltage circuit our team uses is
from the datasheet of the MAX831 [4]. Although Maxim does have several patents involving
step-down regulation, such as #5677619, none appear to deal with a circuit as simple as the one
our team is using. The MAX831 datasheet also makes no claim of a patent on this circuit. Other
searches imply that it is unlikely for a patent to exist pertaining to a circuit containing only an
off-the-shelf step-down regulator and three common discrete components.
The next major part that may have patent violations is our USB controller circuit. The
source of our circuit is a Cypress application note [5]; unlike the previous Cypress document,
this one is not copyrighted. One result of patent searches for “USB” with Cypress as the assignee
is #6,541,879; this discusses the fact that USB devices can be protected with voltage regulators
and some type of controller; however, the patent is for a self-powered USB hub, not a USB
controller. Patent #6,754,725 seems to pertain to our USB host controller, and may contain the
circuit used in our design, but the “images” section of the patent office website’s page for this
patent does not load correctly. Other results from the search for the USB circuit do not seem
relevant.
The final hardware block is the video display circuit. The source of our video circuit is
the team that produced Sparky, and none of its members hold any patents. That team’s source is
a website[6] providing a semi-detailed description of a video display circuit along with a
schematic and source code (as previously mentioned) for a controlling CPLD. The author of the
-7-
ECE 477 Final Report
Fall 2004
website makes no patent claims, and patent searches for the author’s name yield no results.
Searches for a similar circuit or memory mapping scheme yield results that are very difficult to
narrow. Further attempts to determine if our video circuit is similar to any patents will have to be
delegated to dedicated legal team.
N4 as a whole is also a legitimate target for patent analysis. Patent searches for a USB
game console yield no relevant results. Aside from the USB circuit, our methods and technology
are simple and outdated. Further searches should be restricted to “older” game consoles. Patent
#4,112,422 is for Atari Interactive Inc.’s game console, and patent #4,053,740 is for even older,
unnamed game console. The details of device operation in these two patents do not seem similar
to those of our device. Regardless, the patents have expired. The patent for the original Nintendo,
#4,824,106, is similar in that the details of device operation largely differ from those of our
device. Patent searches for other early game systems are likely to also have expired.
Analysis of Patent Liability
None of the software under development appears to violate a pre-existing patent. The
software for the planned games is not currently patented or already expired. The software for the
video display circuit and some of the software for the microprocessor is pre-existing; while a
version of the planned USB software written in C appears to be copyrighted, none of its software
appears to be patented.
Patent searches for the power supply circuit indicate that our circuit does not infringe
upon another patent. It is also that unlikely that such a patent would exist, due to the simplicity of
our circuit. Patent searches for the USB circuit in its entirety are inconclusive due to one patent
whose images would not load on the patent office’s website [7]. However, no patent
infringements for the circuit have been found. The video display circuit is also not responsible
for any patent infringements; the video circuit is “open-source” and appears to have been
independently developed—not taken from a patent. However, since narrowing patent search
results for video circuits is very difficult, not all patents of interest were examined; it is
recommend that our legal team examine these patents as time permits.
N4 as a whole does not infringe upon any “live” patents; its operation and circuitry is too
simple for today’s video game consoles. Any possible infringement would probably be expired;
N4 is not liable for patent infringements.
-8-
ECE 477 Final Report
Fall 2004
In summary, N4 does not appear to have any patent infringements.
Actions Recommended to Avoid Infringement
Since N4 does not appear to have any patent infringements, it is not necessary to do
anything. However, it cannot be guaranteed that the game console is free of patent violation
without the assistance of patent attorneys that can devote hours to researching on video display
circuit patents. It is also highly recommended that our team evaluates our video game console
patent-worthy features. Since we are using several “freeware” programs/circuits, it is possible
that in the future another entity/group could patent these items; therefore, if our team was to
patent these items first, it could help prevent future legal liability.
5.0 Reliability and Safety Analysis
As this video game console is intended to target a market for mainly young programmers
and gamers, safety and reliability considerations must be an integral part of the console
development. The first step taken in order to keep the risk of the user at a minimum is that the
whole console circuitry is enclosed in a plastic housing which acts as a shield for the player(s) in
the case an unforeseen failure occurs. As an overview, potential safety issues can involve fire
hazards, electric shock, EMI, unintended flying components, audible effects and television
damage. From the reliability aspect, each block of the project will be thoroughly evaluated in the
following sections.
Reliability Analysis
The five blocks that are the most potential to be sources of failure within the system are
the following:
1. The Voltage Regulator block
- MAX831/SO
- MAX832/SO
- MBR350
2. The RGB to NTSC conversion block
- AD724
-9-
ECE 477 Final Report
Fall 2004
3. The Microprocessor block
- MC9S124256
4. The Xilinx CPLD block
- XC95108-PC84
5. The USB controller block
- SL811HS
In order to determine mean time to failure (MTTF) for each of the chosen components,
the equation for integrated circuits (ICs) provided in the “Designing for Reliability,
Maintainability, and Safety” article [01] must be used shown below:
 p  (C1 x T xC2 x E ) x Q x L
The definitions of each of these variables are:
C1 = Die Complexity
 T = Temperature Coefficient
C2 = Learning Factor
 E = Environmental Constant
 Q = Pin Constant
 L = Quality Factor
Calculated MTTF values are attached as Figure H-1.
Summarized Reliability Analysis conclusions
By inspecting the attached mean time to failure (MTTF) spreadsheet (Figure I) it can be
seen that the worst case component of the 5 devices chosen is the USB controller device with
just ~31 years of life (lambda = 3.74). In order to give a broader range of failure rate, the
calculations were also performed using a quality factor of “2”, “5” and “10”. Overall worst case
MTTF calculation was (10^6)/ (overall lambda). With a quality factor of “2” the total MTTF is
~80 years. With the absolute worst quality factor rating of “10”, the MTTF is ~16 years. Taking
into account that video game consoles are devices that become obsolete within about 3 to 5
years, this MTTF calculation proves sufficient. The deterioration of the physical circuit should
-10-
ECE 477 Final Report
Fall 2004
not be a disadvantage to the users, however if designed for durability, quality factor is the best
option to improve this.
Apart from the improvement of the quality factor, these are other possibilities for
potential improvements in the durability of the console:
Voltage Regulator: Smaller chipsets with fewer pins for the DC-DC step down regulators can be
used in order to increase the MTTF. Also suitable heat sinks should be used in order to decrease
the operating temperature and therefore increase the durability and quality factor of the
regulators.
Microprocessor: A microcontroller with a smaller package can de used. The video game console
design does not use the A/D block, so a smaller microprocessor that does not have this feature
can be used and therefore decrease the number of pins in the device and increase the MTTF. A
suitable heat sink should be used in order to decrease the operating temperature.
Xilinx CPLD: The MTTF for this part cannot be increased that much as 3 pins are left unused in
the design and therefore there is no room for pin omission. One potential way to actually
increase the MTTF would be to add a heat sink to the CPLD.
Video conversion: The MTTF for this device is among the lowest in the design (522.30 yrs. in
best case and 104.46 yrs. in worst case scenario). A potential way to increase this MTTF would
be to utilize heat dissipaters as well as a suitable heat sink. Another option would be to move
from digital to analog components which would increase the complexity and manufacturability
of the design as well as troubleshooting and root causing problems that can present themselves in
the future.
USB controller: This is the device with the worst MTTF of all the components chosen to be
analyzed. It has best case scenario longevity of ~152 years and a worst case scenario of ~30.5.
The factor that most reduces the longevity is the Temperature Coefficient. A potential way to
significantly improve MTTF would be to decrease maximum junction temperature and also use a
heat sink. A heat dissipater would be strongly recommended.
-11-
ECE 477 Final Report
Fall 2004
Overall Reliability: All reliability figures are calculated in the scenario where the component
being analyzed is working 24 hours a day 7 days a week. This is not the case for the video game
console. Estimating a usage rate of 5 hours per day, the MTTF calculated for each component
should increase considerably.
FMECA Worksheet
The MTTF selected for this criticality levels is shown in Figure 5.1. The complete
FMECA worksheet is attached as Figure H.
Extremely High
Lambda
0.0000000001
MTTF (hrs.)
10,000,000,000
MTTF (yrs.)
11,114,155
Odds
1:10000 millon
Very High
0.000000001
1,000,000,000
1,114,155
1:1000 millon
High
Medium
Low
Very Low
0.00000001
0.0000001
0.000001
0.00001
100,000,000
10,000,000
1,000,000
100,000
11,416
1,142
114
11
1:100 millon
1:10 millon
1:1 millon
1:100000
Figure 5.1 Criticality Levels Against MTTF
Miscellaneous
Different effects that can happen in case of a failure have been omitted. For example, if
the video system fails, and causes the television screen to alternate between black and white
causing a console failure, this failure can not be root caused to a specific component and shall
not be assumed to cause user injury. The explosion of electrolytic capacitors is assumed to fry
only the capacitor and not to fly in the air as a projectile. All these failures are taken into
consideration when designing the packaging for the system. The packaging plays a huge role
when failure like the ones mentioned above happen because it works as a shield between the
console and the end user.
EMI that interferes with hospital equipment is assumed to be a user risk. Any failure that
may increase electromagnetic interference is assumed to be not-critical. Most of the components
within the console are assumed to be flame-proof and will not be a fire hazard. It is also assumed
that the user cannot hurt itself with the controller and in the case of an injury due to controller
-12-
ECE 477 Final Report
Fall 2004
interaction; the patent holder for the controller will be held liable for the injury. Finally, software
failure has a really low MTTF and since firmware is upgradeable.
6.0 Ethical and Environmental Impact Analysis
Existing game consoles make use of many components in its design, manufacturing and
packaging that may be harmful to the environment. It is an ethical responsibility to ensure that
the design comply with the safety standards set by professional societies like IEEE [1] and
Association of Computing Machinery (ACM) [2]. Following the article by Frank G Splitt [18],
these concerns to either minimize or eliminate them. Specifically, the processes of design,
production and disposal are scrutinized.
Ethical Impact Analysis
“Ethics” is the set of professional guidelines that govern the safe practice of engineering
and also to ensure product quality. IEEE and ACM have individual ethical guidelines published
on their website [3]. The presiding ethical concern is the safety to the consumer. In N4’s design,
the areas for ethical consideration are design, production, testing and documentation:
Design
The design component may be split into three sub-components for discussion:
Hardware Component
Durable hardware should be chosen because products should be safe for consumption for
their intended life. N4 has included a main fuse and appropriate decoupling capacitors to ensure
that the overall design will not function at dangerously high currents. Headers have also been
placed for monitoring and testing purposes. The availability of documentation from Fairfield
Semiconductors [5], Analog Devices [6] and Motorola [7] facilitated appropriate selection of
parts. Other possible modifications include the addition of light-sourced warning signals to
shows indicate erratic operational behavior.
Software Component
-13-
ECE 477 Final Report
Fall 2004
The Xilinx CPLD programming was accomplished with reference to a successful design
by Elm-Chan [8]. The microprocessor should necessarily make provision for detection of
hardware failures. In the event that any hardware part fails, a warning register may be set to
indicate the malfunctioning part.
Packaging
N4’s exterior packaging is mainly plastic and, although not cylindrical as intended, is
non-angular, reducing the number of sharp edges. Vents in the casing allow for escape of heat.
The controllers are large enough to be a safe around children.
The USB interface and the power adapter are potential hazards. The USB jack must be
securely fastened to the casing to prevent injury due to slipping. A warning label should be
placed on the adapter to ensure that consumers handle it under appropriate conditions.
Production
Installation of the hardware components to the PCB must be closely monitored for
hazards. Semi-exposed traces and wires must be shielded to prevent undesired shorting. Soldered
surfaces must also be tested for connectivity. Markings on the silkscreen layer of the PCB to
indicate possible warning signs in the event of exposure from the casing. Additional warning
labels should be placed on the casing to deter consumers from performing untrained
modification. Tests for quality assurance should also be conducted during production.
Testing
Sufficient testing must be conducted to ascertain that the product is safe for consumer
use. The operating limits of the N4 should also be determined. Factors like optimum operating
temperature, ideal operating time period, and durability of hardware components should be tested
and documented. Claims of the hardware should also be tested. Care must be taken to ensure test
results not be misreported.
Documentation
The most important part of documentation is in the form of the user’s manual. This
manual should clearly detail all relevant information for the safe operation of N4.
-14-
ECE 477 Final Report
Fall 2004
Other important documentation lies with the production crew. Design procedures,
manufacturing procedures and testing results should be documented for future reference.
Documentation should comply with an internationally recognized standard, for example
International Standards Organization (ISO) [9].
Environmental Impact Analysis
N4 is essentially a PCB in a plastic casing. As there is little or no pollution during
operation of N4, we turn to these two main components in our environmental analysis.
PCB
The mass production of the PCB creates a significant amount of waste. As outlined in an
article by International Network for Environmental Compliance and Enforcement (INECE) [10],
the anti-pollution act Pollution Prevention (P2) by the California government [11] and the United
States Environmental Protection Agency (US EPA) [12] suggest the following to minimize
wastage and pollution during manufacturing:
1. Substitute aqueous processable resists for solvent processable resists where feasible
2. Replace chemical board production with computer-driven mechanical etching processes
for low-volume board production, such as for prototypes
3. Replace chromic-sulfuric acid etchants with ferric chloride, or ammonium persulfate
where possible
4. Use thinner copper foil to clad laminated boards, where feasible
5. Reuse/recycle spent etchants by means of electrolytic recovery
The disposal of the PCB is another source of pollution. The lead and the other electrical
components cannot be easily reused. However, some companies, like ElectroniCycle [13] and
BFI Industrial Waste Services [14], provide recycling services. These names should be included
in the user’s manual.
Plastic Casing
There are three distinct approaches to the recycling of plastic [15]:
1. Reuse
-15-
ECE 477 Final Report
Fall 2004
2. Physical reprocessing and reformation
3. Chemical treatment to isolate each component for reprocessing to be used in other
manufacture
Companies like Connecticut Metal Industries [16] and United Plastic Recycling [17]
offer recycling services. Again these names should be included in the user manual.
7.0 Packaging Design Considerations
With increased competition in the consumer electronics industry, it is important that the
product not only exceeds consumer technological demands but also capture the consumer’s
attention. Hence, issues such as the general shape, size, weight, and color scheme should be
considered.
Analysis of Similar Products
Among the gaming giants, three main consoles have successfully emerged. They are
Sony’s PlayStation 2 (PS2), Nintendo’s Game Cube (GC), and Microsoft’s XBOX, and they will
form the basis of our analysis.
Sony’s PlayStation 2 (PS2)
PS2’s packaging information is shown in Table 7.1.
Power Requirements
120V AC, 60 Hz
Power Consumption
79W
Dimensions (approx)
301 x 78 x 182 mm (w/h/d)
Mass (approx)
2.2 kg
Table 7.1 Sony PlayStation 2 Packaging Specifications [1]
The PS2 is a very powerful gaming console. However, for classic gaming purposes, the
DVD-ROM storage, the 128-bit CPU at 300 MHz, and the internet-gaming capability are beyond
the scope of N4’s design.
-16-
ECE 477 Final Report
Fall 2004
The PS2 packaging is simple and sleek. However, because of all the additional electronic
components required—especially the heavy heat-sink and fan for cooling purposes—the PS2 is
relatively heavy. Weight aside, the compact design of the PS2 is desirable for N4.
Microsoft’s XBOX
XBOX’s packaging specifications are shown in Table 7.2.
Power Requirements
120V AC, 60 Hz
Power Consumption
100W
Dimensions (approx)
300 x 180 x 80 mm (w/h/d)
Mass (approx)
4 kg
Table 7.2 Microsoft’s XBOX Packaging Specifications [2]
The game controllers are too large to be held comfortably in both hands. Also, the XBOX
itself is very heavy—even more so than the PS2. Although the XBOX LAN capability is
interesting, it is not what N4’s target consumer would need. With the excessive processing power
and unwieldy design, the XBOX represents the antithesis of N4.
Nintendo’s GameCube
The GameCube’s packaging specifications are shown in Table 7.3.
Power Requirements
120V AC DC12V, 60 Hz
Power Consumption
100W
Dimensions (approx)
148 x 108 x 158 mm (w/h/d)
Mass (approx)
2 Kg
Table 7.3 Nintendo’s GameCube Packaging Specifications [3]
On analysis, the game controller is sizeable, but light in weight. The light-weight
controller is something N4 should emulate.
N4
N4 stands out because of its simple, classic approach in design (refer to Appendix B for
design). The console breaks away from the angular norm. The main body of the unit will be
-17-
ECE 477 Final Report
Fall 2004
cylindrical in shape, displaying 2 simple Nintendo-style controller ports, a USB port (for loading
of games), and a speaker vent for audio output. In addition, there are vents on the back of the
main unit for ventilation. Light and compact, ideal for placement in a home entertainment
system, is what the N4 intends to accomplish.
Materials for packaging
Materials required are the following: DC power connector, Controller connectors, USB
Port, RCA jack, and Plastic enclosure.
Tooling Requirements
The tools required for project assembly are knife, industrial glue, drill, screw driver, and
soldering iron. Note that the drill, knife, and glue will be mainly used for constructing the clear
plastic casing. The knife will be used to cut slits into the back to allow for ventilation of the PCB
board.
Weight and Cost
Today old fashioned game consoles are very cheap, implying that the N4 should be
offered at a very reasonable price. The console designers however would like to recover the
incurred costs of approximately $55.00. Thus, a marketing price could be set at $65.99. A higher
price is very possible. The weight of the console for the intended purposes is projected to be no
more than 1.5 kg, making it ideal for home entertainment systems and mobility.
8.0 Schematic Design Considerations
The Nostalgic 4 (N4) features three main interfaces to the microprocessor:
1. Handheld Nintendo Controller(s)
2. Universal Serial Bus (USB) Memory-stick Reader
3. RGB-to-NTSC Video Encoder
The main components of the console are as follows:
1. MC9S12A256 Motorola Microprocessor
-18-
ECE 477 Final Report
Fall 2004
2. XC95108 Xilinx CPLD
3. AD724 RGB to NTSC Analog Devices Encoder/Decoder
4. CY7C109 Cypress RAM
5. USB Memory-Stick
6. SL811HS Cypress USB Host/Slave Controller
7. 74VHC573 Fairfield High-Speed Latches
8. MAX831 and MAX832 Maxim DC-DC Step-Down Converters and Regulators
Theory of Operation
When the power switch is turned on, the user will be able to interact with the console
through the Nintendo controllers. The controllers are directly connected to the Motorola
microprocessor through PULSE, LATCH and DATA lines. On booting up, the microprocessor
will start executing the game that is already stored in memory or by extracting the information
from the USB memory through the USB interface. If reading from the USB memory stick, the
microprocessor will move the game data into the Cypress RAM for storage prior to execution.
On execution, the game transfers the video display to the Xilinx CPLD. This frees up the
microprocessor from handling the NTSC video output. The microprocessor will then continually
update the changes in video data directly to the CPLD
MC9S12A256 Motorola Microprocessor
The MC9S12DP256 MCU unit (MCU) (Fig. 1) is a 16-bit device composed of standard
on-chip peripherals. From the schematic in Figure C-1, all the different components that will be
interfaced to the MCU can be seen.
To support the fast gaming interface, the MCU will be run at 16 MHz to allow for fast
graphics update, leaving sufficient processing power for game processing. In the event that 16
MHz is insufficient speed for efficient game management, the microprocessor will be run at 25
MHz. The MCU requires a voltage of +5VDC to function—supplied by the on-chip power
supply. However, the MCU has an internal step-down voltage of +3.3VDC [02].
The MCU has several decoupling capacitors in accordance with the data sheet. In
addition, the microprocessor will be interfaced with the 128 KB RAM (2 Cypress 64 KB RAM
Chips) module were the game will be stored. Also, the microprocessor will be interfaced with a
-19-
ECE 477 Final Report
Fall 2004
USB Host Controller for the ability to read external game data for execution. Graphic data will
be sent to a Xilinx CPLD for handling prior to actual video display. For programming purposes,
the microprocessor will be directly attached to an RS232 driver—MAX233A—which will
function as the channel between programming software and MCU. The MAX233A was chosen
over the MAX232 because it features charge pump capacitors which are already integrated in the
package that would help save Printed Circuit Board (PCB) space [03].
From Figure1, it can also be seen that 8 I/O port pins (PM0..PM7) are devoted to the
transfer of data from the USB Host controller to the MCU. Then, 16 I/O port pins are designated
to interface the MCU with the 2 main system RAMs (PB0..PB7 and PA0..PA7). The PULSE,
LATCH and DATA lines from both controllers are also interfaced with 3 I/O port pins each (For
controller one PT0 for data, PP1 for latch and PP2 for pulse, for controller two PS2 for data, PH5
latch and PH6 pulse). PP1 and PP2 are Pulse Width Modulation (PWM) ports that will be turned
into I/O port pins when programming the microprocessor. VSSPL (VDDPL pin), VDDPLL
(VDDPLL pin) and XFC (XFC pin) are used to drive a Phase Lock Loop Filter [01] (page 60)
that is required due to microprocessors data sheet. PT6 and PT7 are devoted to drive the power
safety device for the USB controller which will be explained later in this document. PK4 and
PK5 are the “Output Enable” pins for each system main RAM chip. The Transistor-ToTransistor Logic portion (both Receive - RX and Transmit - TX) of the RS232 chip [03] is
interfaced to pins PS0 and PS1.The last main chip interfaced to the microprocessor is the Xilinx
CPLD. DISP, XWRD, XWR and XWAIT which are the main signal in the chip are interfaced to
PH0..PH3. All capacitors values and external circuitry are taken from the data sheet. Finally,
headers have been added to the main ports of the microprocessor in order to facilitate debugging.
XC95108 Xilinx CPLD
The XC95108 [04] is a high-performance CPLD providing advanced in-system
programming and test capabilities for general purpose logic integration. It is comprised of eight
36V18 Function Blocks, providing 2,400 usable gates with propagation delays of 7.5 ns. This
CPLD is the graphics updating arm of the N4 console.
Each video pixel will be kept in a fast SRAM (Cypress 64 KB RAM) for access by the
CPLD. The CPLD will be clocked at 4 times the NTSC rate (3.579 MHz), i.e. 14.31818 MHz
[04]. This speed will allow for color bursting, which indicates the color associated with each
-20-
ECE 477 Final Report
Fall 2004
pixel. The voltage required by the CPLD to operate is +5VDC at a typical supply current of
100mA. The original video system design was obtained from elm-chan.org [05]. The TDI, TMS,
TCK and TDO pins are also connected to a JTAG which will be used for debugging the CPLD
software in case problems are encountered once the chip is already soldered to the PCB. Please
refer to Figure C-2 for the schematic of the Xilinx.
AD724 RGB-To-NTSC Encoder/Decoder
The AD724 [06] is a low cost RGB to NTSC/PAL Encoder that converts red, green and
blue color component signals into their corresponding luminance (base-band amplitude) and
chrominance (sub-carrier amplitude and phase) signals in accordance with either NTSC or PAL
standards. These two outputs are also combined to provide composite video output. This chip
will be used to convert the Red-Green-Blue (RGB) output from the CPLD to NTSC format for
TV output. Although the AD724 has the ability to output in S-Video, this feature will not be
utilized. The operating voltage required by the chip in order to operate is +5VDC ad a supply
current of 42mA. The FSC frequency is 3.579545 MHz for NTSC, this frequency will be
generated by pin 47 (SCCLK) of the Xilinx CPLD. All resistor and capacitor values for the
external circuitry of the chip are taken from the data sheet [06]. Please refer to Figure C-2 for the
schematic of the AD724.
CY7C109 Cypress RAM
The 64 KB RAM Chips [07] are used mainly for game storage. Initially, two of these
RAM chips would allow for 128 KB of RAM game storage prior to execution. However, due to
layout constraints, only one chip will be used. The CY7C109 is a high-performance CMOS static
RAM. The voltage required by each RAM chip to operate is –0.5V to +7.0V due to spec at a
typical supply current of 90mA. A +5VDC voltage will be provided by the power supply. Please
refer to Figure C-3.
SL811HS Cypress USB Host/Slave Controller
The SL811HS Cypress USB Host/Slave Controller [08] would be responsible for reading
the external game data stored on the USB memory-stick. The USB Controller will be used in
Host mode. This ensures that a DMA controller is not needed. This mode is attained by setting
-21-
ECE 477 Final Report
Fall 2004
the M/S pin HIGH. The chip has 7 main parts: an active LOW chip select pin (!CS), an active
LOW read (!RD), an active LOW write (!WR), and active HIGH interrupt signal, an address bus
pin (A0) and an 8-bit data bus (D0..D7). The chip select pin enables the USB controller to READ
or WRITE and it has to be asserted by the MCU at least 65ns for any transaction to be valid.
The interrupt (INTRQ) and data bus (D0..D7) pins are self explanatory. From Figure C-4
it can be seen that the USB controller also has a power protection and that the chip is clocked at
48 MHz. The external circuitry for the clock and for the chip itself was taken from the data sheet
[08]. The chip also has a built in 256 byte RAM buffer in order to facilitate data transmission.
The USB memory-stick will be the commonly used Type A. The USB Host will ensure that the
memory stick be read fast enough for minimization of loading times. The voltage required by
USB controller to operate is +3.0VDC at a typical supply current of 25mA. A +3.3VDC voltage
will be provided by the power supply.
74VHC373 High-Speed Latches
This 8-bit D-type latch [09] is controlled by an active LOW latch enable input (LE) and
an active LOW Output Enable input (OE). When the OE input is HIGH, the eight outputs are in a
high impedance state.
The multiplexed address from the CPLD is not stable for long. The specifications on the
data sheet of the CPLD state that the minimum time between ECLK to the end of address is tMAH
= 2 ns. This can be increased to approximately 5 ns by using ECS instead of ECLK. To
accomplish this, a high-speed transparent latch is required. For this reason the 74VHC373 was
chosen, because it has a typical speed of tPD = 5 ns [09]. The voltage required by each latch to
operate is –0.5V to +7.0V due to spec at a typical supply current of 40µA. A +5VDC voltage
will be provided by the power supply. Please refer to Figure C-3.
Power Supply Design (MAX831, MAX832 DC-DC Step-Down Converters and Regulators)
The majority of the components that comprise the video game console are powered at
+5VDC. The only component that is powered at +3.3VDC is the USB Host Controller. The
power supply will be constructed with a +12VDC at 1500mA AC to DC power adapter that will
be the responsible to convert the AC voltage from the power outlet to DC. Then this +12VDC
input will be fed into two different step down DC-DC regulator chips. The MAX831 chip [10]
-22-
ECE 477 Final Report
Fall 2004
converts a DC input from 8-40VDC to a steady +5VDC output, the MAX832 [10] performs the
same task but gives an output of +3.3VDC.
The typical operating circuits for these chips were available in the MAXIM data sheet
[10]. From specs it was also noted that clip-style heat-sinks and wide copper traces to connect
the leads to reduce thermal resistance and dissipate heat have to be used. The chips have a
maximum thermal temperature of +125ºC so it was a perfect fit for our design as our input DC
voltage of ~+15VDC at continuous load current produces a temperature of 50-70ºC from spec.
Please refer to Figure C-5.
Miscellaneous
The connections of the Nintendo controllers to the microprocessor were in accordance to
the amateur data found on the internet [11]. Please refer to Figure C-6. In order to add a safety
feature in case of Electrostatic Discharge from the controller into the MCU, optical isolators
were added to each line (PULSE, LATCH and DATA). The basic optical isolator circuitry was
taken from the EE362 Notes [12]. However, since the optical isolators blew and were hard to
replace, the isolators were replaced with current limiting resistors instead. The resistor values
were taken from typical values used in industry.
9.0 PCB Layout Design Considerations
The Printed Circuit Board (PCB) layout was separated into 6 main parts as follows:
1. Power supply for 5 V and 3.3 V
2. Microprocessor (Motorola)
3. Video Display Circuit (Xilinx)
4. USB Interface (SL811HS)
5. External RAM
6. Controllers
Only the SL811HS operates at 3.3 V. The rest of the circuit is powered by the 5 V source.
Special Layout Considerations
-23-
ECE 477 Final Report
Fall 2004
In order to successfully complete this task, precautions must be made to minimize
Electromagnetic Interference (EMI). This is largely accomplished by the routing of the main
power (PWR) and ground (GND) routes first, ensuring that both of them run approximately the
same course in a single-point, star-style manner [1]. The PWR is largely placed on the top layer
(TOP) while the GND is routed on the bottom layer (BOT). Decoupling capacitors have also
been specially positioned to be as close to the chip in question, usually in concordance to the
datasheet constraints [2].
To ease layout constraints, the board was divided in accordance to the 6 segments
mentioned in the introduction section. The general layout idea of the 6 areas, along with the
miscellaneous areas like the RS-232 programming interface of the Motorola (MAX 233) and the
latches (Fairfield), used in compensating for the clocking constraints of the circuit, is shown in
Figure 9.1. As opposed to having the Motorola in the center of the board, because the signals
from the Motorola need to be latched prior to use by the Xilinx, the latches instead take center
stage to spatially. This is for laying out the 16-bit address bus.
Power Supply
External RAM
Video Circuit: Xilinx
Microprocessor:
Motorola
Latches
USB
RS-232
Controllers (with Optical Isolators)
Figure 9.1 PCB General Layout Map
To further minimize EMI, the smallest clock frequency for the Motorola was used (16
MHz). This would suppress some of the noise generated [1]. In the event that this frequency is
not high enough for successful running of the hardware, we would step the clock frequency up to
-24-
ECE 477 Final Report
Fall 2004
25 MHz. Extra decoupling capacitors will then be interfaced to better suppress the clock
harmonic noise. These capacitors would probably be fly-wired.
Wide traces of 50 mils were used for PWR and GND traces where possible [3]. Other
traces were kept at 12 mils where possible, and where layout constraints make 12 mils
impossible, the minimal trace width was lowered to 8 mils [4]. This is to facilitate more compact
and efficient routing of several components, in particular the Cypress.
Please refer to Figures D-1 and D-2 for the image of the top and bottom copper layers.
10.0 Software Design Considerations
The video game system will require several different software modules. The start-up
module initializes the system and retrieves game code from the USB host controller and stores it
onto system memory. The microprocessor code will then execute the game code from memory.
The video game will be Pong, and if further development time is available, a “cannon fodder”
game will also be developed. Each game will have three major sections: a “polling” section
where the game controllers are polled to determine which buttons are pressed; a logical section
where the inputs from the controller are used to determine how objects in the game will move on
the screen; and a video-mapping section, where an new image is created, based on the output of
the game logic, and written to the video circuit in its proper format. Finally, the video circuit
requires will require software to convert an image into “RGB” and intensity values at the proper
frequency that can be used by an RGB-to-NTSC converter.
Software Design Consideration
Memory Model
The video game system will utilize the MC9S12’s RAM and 256KB flash EEPROM, and
may also use 128KB of external RAM. The MCU’s RAM will contain the stack and variables,
and the flash EEPROM will contain the start-up code. A high-speed USB memory stick will
initially store a game or games (and nothing else). If only one game is produced, it will likely be
stored in the EEPROM after being retrieved from the USB; if additional games are produced,
they may be stored in the external 128KB memory.
-25-
ECE 477 Final Report
Fall 2004
Memory Map
With one game, a memory map of the USB stick would simply show all necessary
executable game located in one block in a random section of USB memory. It is not clear at this
time what a memory map of multiple games on a USB stick would look like; it may depend on
particularities of the USB standard [1]. The memory map of the flash EEPROM will likely show
the start-up code at its beginning, followed by as many games as will fit in the remaining
memory. The code for retrieving a game from the USB stick has not yet been developed, but a
driver [2] provided by the manufacturer of our USB host controller for the Linux operating
system is 61KB. At the present time, a Pong game has been developed for a GameBoy Advance
emulator [3]; the size of the code is 252 KB, but 237KB of this is image data for a memory map
six times as large as the one for our video circuit. Therefore the predicted size of our Pong game
is around 55KB, excluding code to retrieve data from the video controllers and code to produce a
sound; the previous semester’s video game team [4], who produced Sparky, developed code for
these functions totaling 2KB. As a result, 57KB plus 61KB plus a generous estimate of 5KB for
the rest of the start-up code still leaves almost half of the flash EEPROM free.
Start-up Code
The start-up code will consist of two main parts: a port-mapping section, and a USB
driver section. The port-mapping section will execute first. Its purpose is to set data-direction
registers to their necessary values, and to assign mnemonics (port names) to their respective
ports. The USB driver will then retrieve whatever games are stored on the USB memory stick
and place them onto flash EEPROM / external RAM as necessary.
Organization of Embedded Application Code
The organization of embedded application code can only be discussed at this time with
reference to Pong, as it is the only game that has been developed. At the present time, the game
is fully developed for the GameBoy Advance Emulator, but memory mapping and controller
data-acquisition for the MC9S12 is incomplete. The first part of the game has inclusion of
headers, function prototypes, and initialization of global variables. Next, coordinates for the pong
ball are determined. The pong code is primarily written in C; after the code is assembled, a
-26-
ECE 477 Final Report
Fall 2004
section of code developed in assembly language will be inserted to obtain data from the NES
controllers. Using this information, the coordinates for the pong paddles are determined. The
game is poll-driven; the NES controllers will only be polled when necessary to determine new
positions for the pong paddles. Finally, the video image will be written to the video circuit.
The major software design consideration for the game, at first glance, is to be certain that
images are written to the video display circuit faster than the circuit produces them on the
television (at approximately 60Hz). According to the source for our video circuit, a write
operation can take as long as 415 ns; as long as the MCU can perform a write to an external
CPLD in 10.375 clock cycles (at 25MHz) this time period will be the worst-case time for writing
one data byte. The video memory map is 38.4KB; if an entire image is rewritten every 1/60
seconds, this still leaves 0.73 milliseconds remaining in that time period. Subtracting the time to
read all data from two controllers, approximately 0.192 microseconds, still leaves 0.54
milliseconds, or 13.5K clock cycles, to execute the remainder of the code.
The software for the video circuit will not be discussed in detail, as it was provided in a
reference design [5]. The software accepts an image in the format shown in Figure 10.1, stores it
in the video RAM, and uses it to produce RGB and intensity values in a format understood by
the RGB-to-NTSC converter.
-27-
ECE 477 Final Report
Fall 2004
Figure 10.1 Video Memory Map
Software Design Narrative
The final version of the project has two major software modules: the Pong game, which
includes start-up code, interrupt vectors, and game content developed in a combination of C and
Motorola assembly code, and the video circuit CPLD code, used as freeware from the video
circuit reference website [5]. Our start-up code was slightly modified from the start-up code
included with the embedded GNU compiler to set some of the register positions and disable
interrupts. A file containing the interrupt vectors, also included in our GNU compiler, was
modified to set our reset address to that of the beginning of our Pong game. The Pong game
itself first initializes data direction registers and ports as necessary. Ports A and B are used for
multiplexed addressing and data, video control lines are on port H, the Nintendo controller I/O is
on ports T, P, S, and H, and the audio output on is on port S. Next, after initializing game
variables such as initial paddle and ball positions and their respective maximum and minimum
positions, the Pong game draws its first (and only) copy of the background to the screen by use
of inline assembly code. The game then enters an infinite loop of continuous ball and paddle
movement. In the loop, the pong ball’s new position is computed based its previous direction
and whether it has made contact with a wall or paddle. Next, data from the Nintendo controllers
is gathered with inline assembly code that sends a strobe to each controller followed by a 12microsecond pulse that instructs the controller to send a bit reflecting the state of each of its
buttons. Once this data is recorded, the pong paddle positions are modified if necessary. Next,
ball and paddle images from the prior game loop are erased from their old positions. This creates
some flickering in their images, but this can be corrected in future editions of the game. Finally,
the new ball and paddle images are redrawn with their new coordinates. Each of the three
redraw functions has a “delay” section so that the ball and paddles do not move too fast. Finally,
the game begins another iteration of the infinite loop.
The video circuit software is freeware and will not be discussed in detail; its I/O
functionality is to receive addresses and data from the MCU, and generate red, green, blue, and
intensity bit values in NTSC format that go through a resistor matrix and are interpreted by an
RGB-to-NTSC converter.
Software Documentation
-28-
ECE 477 Final Report
Fall 2004
A general flowchart for the start-up code and Pong game is shown in Figures 10.2 and
10.3. Details for the operation of the USB driver are not known, so the nature of its functionality
can only be approximated. Flowchart details for the video display circuit are also left out; the
focus is on the software that our team will develop or adapt from Sparky. From any state in the
chart, a reset will force the state back to the beginning of the start-up software.
The only major algorithm currently developed is the logic used to determine how the
Pong ball moves in the game. The algorithm was provided by the Pong reference site[3] and will
be unchanged for the two-player adaptation of game; the size of the algorithm prevents it from
being listed in full. Below is its beginning fragment:
void MoveBall(void) {
if (ballDirection == 0 && ((xball >= xMax || yball >= yMax) || (xball >= xAI - 6 && yball >= yAI - 4 && yball <=
yAI + 32))) {
if (xball >= xMax) {
ballDirection = 5;
} else if (yball >= yMax) {
ballDirection = 1;
} else if (xball >= xAI - 6 && xball < xAI) {
ballDirection = 3;
}
}
if (ballDirection == 0 && xball < xMax && yball < yMax) {
xball++;xball++;xball++;xball++;
yball++;yball++;
}
The algorithm keeps the ball moving at an angle in one of four directions, and changes direction
upon encountering a wall or an object. Special cases occur when a ball hits a back wall. The full
code listing and a description of this algorithm is located at the aforementioned reference.
Software Listing
The port-mapping code, not yet developed, will be done similarly to Sparky’s method of
implementation [7]. The USB driver, also not developed, will likely be adapted from several
sources [2],[8]. The Pong source code in C was adapted from a website [3] which developed the
game for a GameBoy Advance emulator. Assembly code for interfacing to the NES controllers
and audio circuit [9] will likely be adapted from Spring 2004 Team 5, who developed Sparky.
Video circuit software was provided on the video circuit reference site [5] used by both our team
and the team that produced Sparky[4]. Attached in Figure F is the complete software listing for
N4.
-29-
ECE 477 Final Report
Fall 2004
Power on
Port
mapping
and
initializatio
n
USB
Memory
Stick?
Prompt user
to insert USB
Memory
Stick
Load game
from USB
into micro
memory
Execute
Game
Figure 10.2 Flowchart: Loading the Game
-30-
ECE 477 Final Report
Fall 2004
Game Executed
Initialize
headers,
function
prototypes and
global variables
Game
stopped?
Move paddles
as directed by
player
Player hit
Start?
Ball remains at
wall
Compute new
ball coordinates
Ball will
resume motion
next time
through loop
Ball hit
top/btm wall?
Bounce it in
new direction
Ball hit
paddle?
Stop game,
beep
Write new
image to
memory
Ball hit back
wall?
Read data from
controllers
Advance ball
Figure 10.3 Flowchart: Pong
11.0 Version 2 Changes
If we were to have a second go at it, these are the following changes that we would make:
1. Test and make functional the USB component of the console
2. Integrate external memory into the circuit for larger game storage
3. Make controllers detachable
4. Implement more sophisticated audio circuit, possibly with its own audio driver
5. Make body cylindrical
6. Optimize game to include more levels
7. Program a development kit for game development
-31-
ECE 477 Final Report
Fall 2004
8. Create more games
12.0 Summary and Conclusions
The design and construction of the N4 video game console has led to a greater
understanding of the engineering processes involved in the development of general entertainment
systems, as well as a huge appreciation for the production teams of other existing game consoles.
Specifically, we now know more about schematic and layout constraints of printed circuit
boards, how to handle boards with components driven at different frequencies, and also the value
of perseverance during the debugging process—both for hardware and software. In addition, we
have been given a greater insight into the selection and procurement of components for any
particular design. Although there were other equally significant lessons learnt, e.g. double-check
if the PWR is shorted to GND before ever powering the board, they can be easily summarized
that being meticulous from the onset pays off in the long run.
Having experienced the thrills and spills of the design experience, we believe that we are
better equipped to deal with actual design matters. It is our hope that the N4 video game console
will benefit others as much as we have benefited from its design.
13.0 References
3.0 Constraints Analysis and Component Selection
[1]
Video display circuit/code: http://elm-chan.org/works/crtc/report.html
[2]
Atmel: http://www.atmel.com
[3]
Rabbitt Semiconductors: http://www.rabbitsemiconductors.com
[4]
Freescale Semiconductors: http://www.freescale.com
4.0 Patent Analysis
[1]
Screenshot of Cannon Fodder:
http://mac.the-underdogs.org/index.php?show=game&id=667
[2]
Atari: http://corporate.infogrames.com/
[3]
Potential source of USB interfacing code:
-32-
ECE 477 Final Report
Fall 2004
http://www.cypress.com/cfuploads/support/developer_kits/sl811hs_appnote.pdf
[4]
Power supply circuit reference:
http://shay.ecn.purdue.edu/~477grp5/Documents/MAX830-MAX833.pdf
[5]
Source of USB host-controller configuration:
http://www.cypress.com/cfuploads/support/app_notes/Iface_Ext_to_SL811HS.pdf
[6]
Video display circuit/code: http://elm-chan.org/works/crtc/report.html
[7]
U.S. Patent Office: http://www.uspto.gov
5.0 Reliability and Safety Analysis
[01]
“Designing for Reliability, Maintainability, and Safety”, by George Novacek
http://shay.ecn.purdue.edu/~dsml/ece477/Notes/PDF/4-Mod9_ref.pdf
[02]
“MC9S12A256 User Guide”, Freescale Semiconductors
http://shay.ecn.purdue.edu/~477grp5/Documents/9S12DP256BDGV2.pdf
[03]
“MIL-HDBK-217F, Military Handbook – Reliability Prediction of Electronic
Equipment”
http://shay.ecn.purdue.edu/~dsml/ece477/Homework/Fall2004/Mil-Hdbk-217F.pdf
[04]
“MAX830-833 Data Sheet”, MAXIM Integrated Circuits
http://shay.ecn.purdue.edu/~477grp5/Documents/MAX830-MAX833.pdf
[05]
“Xilinx XC95108 CPLD Data Sheet”, Xilinx Corporation
http://shay.ecn.purdue.edu/~477grp5/Documents/ds066.pdf
[06]
“ECE477 Class Lecture Notes – Module 9 – Designing for Reliability, Maintainability,
and Safety”, Dr. David G. Meyer
http://shay.ecn.purdue.edu/~dsml/ece477/Notes/PDF/4-Mod9.pdf
[07]
“Cypress USB Host Controller Data Sheet”, Cypress Semiconductor
http://shay.ecn.purdue.edu/~477grp5/Documents/SL811HS.pdf
6.0 Ethical and Environmental Impact Analysis
[1]
IEEE, www.ieee.org
[2]
Association of Computing Machinery (ACM), www.acm.org
[3]
“Software Engineering Code of Ethics and Professional Practice”,
www.computer.org/tab/seprof/code.htm?SMSESSION=NO
-33-
ECE 477 Final Report
Fall 2004
[4]
Onlineethics, http://onlineethics.org/eng/index.html
[5]
Fairfield Semiconductors, www.farifield.com
[6]
Analog Devices, www.analog.com
[7]
Freescale Semiconductor, www.freescale.com
[8]
ELM—General Purpose Display Controller, http://elm-chan.org/works/crtc/report.html
[9]
International Standards Organization, http://www.iso.org/iso/en/ISOOnline.openerpage
[10]
International Network for Environmental Concerns Enforcement,
http://www.inece.org/mmcourse/chapt7.pdf
[11]
Pollution Prevention (P2), http://www.calgold.ca.gov/P2/3672.htm
[12]
United States Environmental Protection Agency,
http://www.epa.gov/seahome/inject/src/printedcir.htm
[13]
ElectroniCycle, http://www.electronicycle.com
[14]
Printed Circuit Board Recycling,
http://p2library.nfesc.navy.mil/P2_Opportunity_Handbook/2_II_8.html
[15]
“Plastic Recycling Processes”, http://greennature.com/article2157.html
[16]
Connecticut Metal Industries, http://www.ctmetal.com/plastic.htm
[17]
United Plastics Recycling, http://www.unitedplasticrecycling.com/
[18]
“Engineering Education Reform”,
http://shay.ecn.purdue.edu/~dsml/ece477/Homework/Fall2004/enviro_refs.pdf
7.0 Packaging Design Considerations
[1]
Sony, www.us.playstation.com/consoles.aspx?id=2/info/415007657.html
[2]
Dabs.com, www.dabs.com/uk/productView.html?quicklinx=10XF&familyid=0
[3]
Nintendo, www.nintendo.com
8.0 Schematic Design Considerations
[01]
Reference Design, Sparky, S04-Grp08
[02]
MC9S12A256B, Motorola, 9S12DP256BDGV2.pdf
[03]
MAX233A, Maxim, MAX220 thru_MAX249.pdf
[04]
XC96108, Xilinx, pdfds066.pdf
[05]
Elm-Chan, elm-chan.org/works/crtc/report.html
-34-
ECE 477 Final Report
Fall 2004
[06]
AD724, Analog Devices, 40671345AD724_b.pdf
[07]
CY7C109B, Cypress, CY7C109B.pdf
[08]
SL811HS, Cypress SL811HS.pdf
[09]
74VHC573, Fairchild, 74VHC573.pdf
[10]
MAX831 and MAX832, Maxim, MAX830-MAX833.pdf
[11]
NES/SNES Controller Information, www.gamesx.com/controldata/nessnes.htm
[12]
EE362 Notes, http://shay.ecn.purdue.edu/~dsml/ece362/Notes/PDF/3-Mod4.pdf
9.0 PCB Layout Design Considerations
[1]
Motorola Semiconductor Application Notes, Motorola AN1259
[2]
Lecture Notes Module 2, PCB Layout Basics
[3]
TA Brian, “Power and ground traces should be as big as possible.”, Tuesday Lecture, 19th
October 2004
[4]
Dr. Meyer, “8 mils. (In answer to a question on the minimum trace width.)”, Tuesday
Lecture, 19th October 2004
10.0 Software Design Considerations
[1]
USB Information: http://www.usb.org/home
[2]
A Linux USB Driver:
http://www.cypress.com/support/software_download.cfm?objectID=FAED7893-9595483E-8D8CDF1FE28D0C5D&tid=0AC3D3A6-D363-4D3B-98ACB18079FBE66B
[3]
Developing Pong for a GBA emulator: http://www.webbesen.dk/gba/default.asp
[4]
Sparky: http://shay.ecn.purdue.edu/~dsml/ece477/Webs/S04-Grp08/
[5]
Video Display Circuit: http://elm-chan.org/works/crtc/report.html
[6]
Atari Interactive, Inc.: http://corporate.infogrames.com/
[7]
Sparky’s register and port mapping:
http://shay.ecn.purdue.edu/~dsml/ece477/Webs/S04-Grp08/ASM/lib/port_lib.asm
[8]
Cypress generic USB driver code:
http://www.cypress.com/cfuploads/support/developer_kits/EZ811.zip
[9]
One version of Sparky’s controller / sound code:
-35-
ECE 477 Final Report
Fall 2004
http://shay.ecn.purdue.edu/~dsml/ece477/Webs/S04Grp08/ASM/THINGS%20THAT%20WORK/
-36-
ECE 477 Final Report
Fall 2004
Appendix A: Individual Contributions
Contributions of Peter Salama:
Originally I presented the idea of a remote weather sensing system that would be
controlled wirelessly, the idea failed to appeal. So after conducting further research on ideas for a
senior design project I stumbled across the idea of a video game console. This appealed to me
since it combined learning and entertainment components to a project that comes from a popular
hi-tech background. The classical video game console, as I had envisioned it, was presented to
the other three members and they agreed to present it to the project advisors. I was made team
leader even though I advised against it since I was talking 16 credit hours of classes as well as
working a part time job. However, I was determined to go ahead and be involved as much as
possible in the design process and utilize my software background where needed.
I wrote the preliminary proposal with Jorge and laid out the initial block diagram on the
second week of the semester. The following week Jorge and I worked on the second homework,
where we created the schematic. In the fourth week I began looking at some controller types and
started pushing the group to consider the design steps. I started creating a parts list of the
components we would require and thought about a project website. I then began designing the
website by choosing the colors and layout as soon as the team completed the parts list.
Next I conducted an extensive research for the best microcontroller to utilize in the
design. I placed an order for the MC9S12A256. In the meantime Jorge and I worked on
completing the final project proposal. At this point I began devoting myself to the Constraints
Analysis and Component Selection Rationale and Packaging Design documentation, which were
completed successfully.
Following fulfillment of my documentation component I aided Zhang, to the best of
ability, in the layout generation process. In addition I aided Jorge in prototyping the video circuit.
Next I began researching extensively ways to implement USB in our Project. I had taken a great
interest in USB, as it was the challenging component that would set our game console apart from
any of the other senior design game consoles. I began designing and developing the USB
interfaces, where I initially researched USB interface theories and protocols. I decided to go
with a “Ping-Pong” interface protocol and began writing an interface between USB controller,
external memory stick, and the microcontroller. I completed the USB header file and source
A-1
ECE 477 Final Report
Fall 2004
code while aiding in debugging of the hardware as well as software for the game and NES
controllers.
Finally, after the project demonstrated all the outcomes, except the one I had worked
diligently on, I aided Jorge in finishing the package for the product. We glued the buzzer to the
inside of the packaging shell and drilled holes to place reset and power buttons. We documented
the outcomes and presented the project.
I hope to receive an A in the course. I was involved in most of the design steps of the
project, utilizing my software expertise where needed. I devoted a lot of time in developing the
most original and challenging part of the project. Although it did not demonstrate its
functionality a lot of effort was devoted to complete the USB within the time constraints. In the
long hours I committed to the project I learnt many lessons and gained many skills.
Contributions of John Mastarone:
My chief contribution to the project was to create and test the Pong game. The following
is a chronological account of my efforts including other things that I did.
At the beginning of the semester, I first suggested several viable ideas: a GPS-based cell
phone tracker, a breathalyzer, and a simple sensor mote. Once a video game console was
chosen, I helped write the initial and final design proposals and project success criteria. Mr.
Zhang and I corrected Jorge and Peter’s schematic portion of HW3 and did the layout portion of
the homework. I selected and ordered parts for the video circuit CPLD, RAM, the USB circuit,
and several other miscellaneous items. Determining how to integrate USB into our project took
time; at first we thought we needed a DMA controller; then I hoped that a USB-to-RS232 cable
would work, and finally I was pointed to a USB host controller that had an example circuit of
how to integrate it to a microcontroller. The circuit’s power protection chip was outdated;
finding what I thought was a suitable replacement also took time.
I assisted Jorge with our schematic; I found and showed him the source for the USB
circuit and how it should be integrated into our overall design, and filled in some of the blanks
on how everything would work. I assisted Mr. Zhang with portions of the midterm presentation
and presented our block diagram and the video circuit portion of the schematic. I also assisted
Mr. Zhang with the layout by setting footprints for many of the small components. I located and
ordered prototyping sockets for our CPLD and RAM, verified that the ported CPLD code
A-2
ECE 477 Final Report
Fall 2004
compiled and downloaded successfully, wrote the patent analysis and software analysis, and
assisted Jorge in wiring our video prototype. Once our board was fully populated, and noise
problems and problems caused by shorting power to ground were fixed, I assisted in debugging
problems between the MCU and video output. I discovered that ground on the video output was
1.5V instead of 0 volts, that our system RAM was fighting with our latches, and that we had a
wrong input to the RGB-to-NTSC converter. I got Team Sparky’s game and controller code to
work on our board, allowing us to pass 3 outcomes. As the only comp. engr., I was entirely
responsible for writing, debugging, and optimizing our Pong game, which I did successfully;
most of this was done after our video circuit worked 9 days before our presentation. I had to find
a reference pong website to help write the initial code, integrate Team Sparky’s controller code,
which didn’t work at first, and learn how to use the embedded GNU C compiler and the
Motorola software tools. I added sound to our game with a simple buzzer, and 4 outcomes were
completed. Over the course of the semester, I worked roughly the same amount of time on the
project as the other members of the group, and while Zhang and Jorge worked excessively on the
layout and schematic, respectively, I worked a lot on the Pong game. Since our team got 4 of 5
outcomes to work, and since we didn’t get the last outcome to work only because we ran out of
time—I finished the Pong game the night before the final presentation—I think I should get an
A.
Contributions of Jorge Marcet:
Hardware:
-
Soldering of components to the PCB
-
Troubleshooting of circuit
o Re-wiring mistakes in the PCB layout
o Removing not used components
o Root causing and troubleshooting of 200 ohm short from VCC to GND
-
Finding root cause and troubleshooting noise in GND plane
o Re-wiring GND plane pattern
o Placement of bypass capacitors in strategic places in order to filter HF noise
-
Packaging design and construction
o Package design in AutoCAD
A-3
ECE 477 Final Report
Fall 2004
o Construction of actual package
o Wiring of circuit inside package
-
Debugging of signals using the oscilloscope and multi-meter
o Signals from the microcontroller to the latches
o Signals from the microcontroller to the CPLD
o Data multiplexing by latches
-
Schematic design
o Design of schematic in Capture CIS
-
Reliability, Maintainability and Safety Analysis
o Used MTTF analysis for Reliability
o Used FMECA analysis for Safety
-
Prototyping
o Construction of prototyping boards for CPLD
o Construction of prototyping sockets for chipsets
o Prototyping of the Video Circuit
o Prototyping of the Power Supply
Software:
-
Initialization of Microprocessor in Assembly
o Adjustment of internal bus clock speed
o Initialization of PLL for clock speed
o Initialization of PWM signal for audio circuit
-
Creation of website
-
Creation of poster
-
Circuit Pictures
-
Project Video
Grade: A
Contributions of Zhixiang Zhang:
Although I was actively involved in the hardware design and troubleshooting efforts of
the project, I served most in the area of documentation—midterm review presentation, final
A-4
ECE 477 Final Report
Fall 2004
presentation, final report preparation. Following is a chronological account of my contributions
to the team effort.
From the onset, I was responsible for researching on projects involving RFID. After
settling on designing a video game console however, I was then put in charge of the selection
and procurement of some of the parts.
Towards the start of the midterm review, I was responsible for coming up with the
backbone of the presentation slides. With input from the other three members and also revising
quite a bit of the Design Constraints homework, I presented our design findings in what I hope
was a succinct account of our design considerations.
Since I took charge of the layout homework, I experienced determining the footprints of
the hardware components selected, and laying them out nicely on our circuit board. I was
assisted by John who also helped to select many of the parts and the footprints accordingly.
Because of the many components we were using, laying out the board took longer than I
expected. After discussing with the team, we decided to remove one of the SRAM chips used in
the circuit to free up some layout space. I turned in the final layout report a week after it was
originally due. It was later found that the latches I procured were a variant of the schematic used.
If the correct pin-out for the parts I chose were used instead, there would have been fewer
problems with the laying out of the board.
Prior to the arrival of our board, I assisted Jorge in the prototyping of our power supply
and video circuit. Although we managed to get the power supply to output the desired voltages,
we were baffled by the video circuit.
When the board arrived however, Jorge and I abandoned the prototyping, and instead
worked on populating the board. I was not proficient with handling the more intricate surface
mounts. Hence, I was only responsible for populating the through mounts on the board.
On first powering of the barely populated board, Jorge and I noticed that our power
supply was not working. Initially, we did not know why. From here began a long tedious
debugging session, where I assisted Jorge in the identification and cutting of traces to isolate
certain areas of the board. It was only later that Jorge noticed he had soldered the PWR and GND
lines together on the adapter connecter, as well as blew the optical isolators in our first powering
of the board. On top of this, I also helped debug the video circuit as well as some of John’s
software initialization code.
A-5
ECE 477 Final Report
Fall 2004
When we finally got the video circuit and programming underway, it was realized that
the audio circuit was yet to be tested. I wrote test codes for the sound, and realized that the audio
circuit was not receiving the PWM signal correctly even though the micro was outputting the
desired signal. Because of the lack of time, I suggested that we switched from a speaker to a
buzzer to better focus our efforts in getting other outcomes demonstrated.
I assisted Jorge with the packaging, especially when we needed to drill holes in the
plastic casing for port components. It was during this time that I also worked with Jorge and John
to produce our User Manual. I was also responsible for its final revision, with pictures provided
by Jorge.
Finally, I was responsible for condensing all the homework information onto final
presentation slides. I assisted in the filming of our success criteria demonstrations, and was
responsible for documenting most of the information. Following the presentation, I also was
responsible for coordinating and putting together the final report, having summarized and edited
the majority of the homework material.
I am expecting an A in the course. Although we did not manage all the success criteria, I
do not believe that we placed any less time than other groups in the design and eventual
production of N4. Also, I believe the fundamental purpose of the course is to encourage learning.
I have learnt a lot more from ECE477 than any other course I have taken at Purdue.
A-6
ECE 477 Final Report
Fall 2004
Appendix B: Packaging
Figure B Initial Packaging Design
B-1
ECE 477 Final Report
Fall 2004
Appendix C: Schematic
Figure C-1 MC9S12A256 Freescale Microprocessor
C-1
ECE 477 Final Report
Fall 2004
Figure C-2 Video Circuit (Xilinx and AD724)
C-2
ECE 477 Final Report
Fall 2004
Figure C-3 Latches and RAM
C-3
ECE 477 Final Report
Fall 2004
Figure C-6 Audio Circuit, Controllers, RS-232 Interface
C-4
ECE 477 Final Report
Fall 2004
Figure C-4 USB Interface
Figure C-5 Power Supply with Step-down Regulators
C-5
ECE 477 Final Report
Fall 2004
Appendix D: PCB Layout Top and Bottom Copper
Figure D-1 Top Copper Layer
D-1
ECE 477 Final Report
Fall 2004
Figure D-2 Bottom Copper Layer
D-2
ECE 477 Final Report
Appendix E: Parts List Spreadsheet
Part
Manufacturer
Function
MC9S12A256 Motorola
Microprocessor
XC95108
Xilinx
Video Display
AD724
Analog Devices
SL811HS
Cypress
RGB to NTSC
Converter
USB Host Controller
CY7C109
Cypress
SRAM/Video RAM
74VHC573
Fairfield
High-Speed Latches
E-1
ECE 477 Final Report
Appendix F: Software Listing
Pong game code (pong_newgraphics.c):
void
void
void
void
void
void
void
void
void
void
void
void
void
MoveBall(void);
MoveBar(void);
GetData(void);
CopyBackground(void);
CopyBall(void);
CopyBar1(void);
CopyBar2(void);
CopyScore1(void);
CopyScore2(void);
CopyBall_clear(void);
CopyBar1_clear(void);
CopyBar2_clear(void);
Wait6u(void);
typedef unsigned char u8;
typedef unsigned short u16;
u8 * base_back;
unsigned int temp;
u8 KEY_UP1 = 0;
u8 KEY_UP2 = 0;
u8 KEY_DOWN1 = 0;
u8 KEY_DOWN2 = 0;
u8 KEY_LEFT1 = 0;
u8 KEY_LEFT2 = 0;
u8 KEY_RIGHT1 = 0;
u8 KEY_RIGHT2 = 0;
u8 KEY_A1 = 0;
u8 KEY_A2 = 0;
u8 KEY_B1 = 0;
u8 KEY_B2 = 0;
u8 KEY_SELECT1 = 0;
u8 KEY_SELECT2 = 0;
u8 KEY_START1 =0;
u8 KEY_START2 = 0;
u8 keys;
u16
u16
u16
u16
u16
u16
u16
u16
u16
u16
u16
u16
xball;
yball;
xbar; /*ball 8x8, bar 8x32*/
ybar;
xAI;
yAI;
xballold;
yballold;
xbarold; /*ball 8x8, bar 8x32*/
ybarold;
xAIold;
yAIold;
u16 ballDirection;
u16 userScore;
u16 AIScore;
u16 xMax; /*320 - 8 - 8*/
u16 yMax;/*200 - 8 - 8*/
u16 xMin;
u16 yMin;
u8 counter;
u8 counter2;
u8 counter3;
int main() {
counter = 0;
counter2 = 0;
counter3 = 0;
F-1
ECE 477 Final Report
base_back = (u8 *) 0x8000;
temp = 0;
xball = 38;
yball = 22;
xbar = 12; /*ball 8x8, bar 8x32*/
ybar = 16;
xAI = 148;
yAI = 16;
xballold = 38;
yballold = 22;
xbarold = 12; /*ball 8x8, bar 8x32*/
ybarold = 16;
xAIold = 148;
yAIold = 16;
KEY_UP1 = 1;
KEY_UP2 = 1;
KEY_DOWN1 = 1;
KEY_DOWN2 = 1;
KEY_LEFT1 = 1;
KEY_LEFT2 = 1;
KEY_RIGHT1 = 1;
KEY_RIGHT2 = 1;
KEY_A1 = 1;
KEY_A2 = 1;
KEY_B1 = 1;
KEY_B2 = 1;
KEY_SELECT1 = 1;
KEY_SELECT2 = 1;
KEY_START1 = 1;
KEY_START2 = 1;
ballDirection = 0;
userScore = 0;
AIScore = 0;
keys = 0;
xMax = 152; /*320 - 8 - 8*/
yMax = 190;/*200 - 8 - 4*/
xMin = 8;
yMin = 10;
asm("movb
#0xFF, 0x0002");
asm("movb
#0xFF, 0x0003");
asm("movb #0xFF, 594");
asm("movb #0x00, 592");
asm ("movb #0x76, 0x0262");
asm ("movb #0xFE, 0x0242");
asm ("movb #0x07, 0x025A");
asm ("movb #0x10, 0x024A");
asm ("movb #0xBF, 0x0033");
asm ("movb #0x20, 0x0032");
asm ("movb #0x06, 0x0260");
/* port init done*/
/* asm ("movb #0x02, 0x0034");
asm ("movb #0x00, 0x0035");*/
asm ("movb #0x4A, 0x0100");
asm ("movb #0x4A, 0x0110");
asm ("lds #0x3fff");
asm ("movb #0xFE, 576");
CopyBackground();
while(1)
{
MoveBall();
GetData();
MoveBar();
if ((xball != xballold) && (yball != yballold))
{
CopyBall_clear();
}
CopyBall();
if (ybar != ybarold)
{
F-2
ECE 477 Final Report
CopyBar1_clear();
}
CopyBar1();
if (yAI != yAIold)
{
CopyBar2_clear();
}
CopyBar2();
}
return 0;
}
void Wait6u(void)
{
int x = 0;
asm("psha");
asm("ldaa #2");
asm("sec");
asm("ldaa #4");
asm("ldaa #1");
asm("ldaa #3");
asm("ldaa #2");
asm("ldaa #3");
asm("ldaa #2");
asm("ldaa #3");
asm("ldaa #2");
asm("ldaa #3");
asm("ldaa #2");
asm("ldaa #3");
asm("ldaa #5");
asm("ldaa #7");
asm("ldaa #6");
asm("ldaa #9");
asm("clc");
asm("pula");
return;
}
void GetData(void)
{
int i;
asm("movb #0x02,0x0258");
asm("ldab
#0x00");
asm("stab 0x1014");
Wait6u();
Wait6u();
for(i = 0; i < 8; i++)
{
asm("ldab 0x1014");
asm("pshb");
asm("ldab 576");
asm("rorb");
asm("pulb");
asm("rolb");
asm("stab 0x1014");
Wait6u();
asm("movb
#0x04,0x0258");
Wait6u();
asm("movb
#0x00,0x0258");
}
if ((keys & 0x01) == 1)
{
KEY_RIGHT1 = 0;
}
else
{
KEY_RIGHT1 = 1;
}
if ((keys & 0x02) == 0x02)
F-3
ECE 477 Final Report
{
KEY_LEFT1 = 0;
}
else
{
KEY_LEFT1 = 1;
}
if ((keys & 0x04) == 0x04)
{
KEY_DOWN1 = 0;
}
else
{
KEY_DOWN1 = 1;
}
if ((keys & 0x08) == 0x08)
{
KEY_UP1 = 0;
}
else
{
KEY_UP1 = 1;
}
if ((keys & 0x10) == 0x10)
{
KEY_START1 = 0;
}
else
{
KEY_START1 = 1;
}
if ((keys & 0x20) == 0x20)
{
KEY_SELECT1 = 0;
}
else
{
KEY_SELECT1 = 1;
}
if ((keys & 0x40) == 0x40)
{
KEY_B1 = 0;
}
else
{
KEY_B1 = 1;
}
if ((keys & 0x80) == 0x80)
{
KEY_A1 = 0;
}
else
{
KEY_A1 = 1;
}
asm("movb #0x26,0x0260");
asm("ldab
#0x00");
asm("stab 0x1014");
Wait6u();
Wait6u();
for(i = 0; i < 9; i++)
{
asm("ldab 0x1014");
asm("pshb");
asm("ldab 0x0248");
asm("rorb");
asm("rorb");
asm("rorb");
asm("pulb");
asm("rolb");
asm("stab 0x1014");
F-4
ECE 477 Final Report
Wait6u();
asm("movb
#0x46,0x0260");
Wait6u();
asm("movb
#0x06,0x0260");
}
if ((keys & 0x01) == 1)
{
KEY_RIGHT2 = 0;
}
else
{
KEY_RIGHT2 = 1;
}
if ((keys & 0x02) == 0x02)
{
KEY_LEFT2 = 0;
}
else
{
KEY_LEFT2 = 1;
}
if ((keys & 0x04) == 0x04)
{
KEY_DOWN2 = 0;
}
else
{
KEY_DOWN2 = 1;
}
if ((keys & 0x08) == 0x08)
{
KEY_UP2 = 0;
}
else
{
KEY_UP2 = 1;
}
if ((keys & 0x10) == 0x10)
{
KEY_START2 = 0;
}
else
{
KEY_START2 = 1;
}
if ((keys & 0x20) == 0x20)
{
KEY_SELECT2 = 0;
}
else
{
KEY_SELECT2 = 1;
}
if ((keys & 0x40) == 0x40)
{
KEY_B2 = 0;
}
else
{
KEY_B2 = 1;
}
if ((keys & 0x80) == 0x80)
{
KEY_A2 = 0;
}
else
{
KEY_A2 = 1;
}
return;
}
F-5
ECE 477 Final Report
void MoveBall(void) {
if (ballDirection == 0 && (((xball >= xMax) || (yball >= yMax)) || ((xball >= (xAI - 4))
&& (yball >= (yAI - 0)) && (yball <= (yAI + 24))))) {
if (xball >= xMax) {
ballDirection = 5;
} else if (yball >= yMax) {
ballDirection = 1;
} else if ((xball >= xAI - 4) && (xball < xAI)) {
ballDirection = 3;
}
}
if ((ballDirection == 0) && (xball < xMax) && (yball < yMax)) {
counter++;
if (counter == 6)
{xball++;xball++;
yball++;
xballold = xball - 2;
yballold = yball - 1;
counter = 0;
}
Wait6u();
Wait6u();Wait6u();Wait6u(); Wait6u();
Wait6u();Wait6u();Wait6u(); Wait6u();/*Wait6u();Wait6u(); */
}
if ((ballDirection == 1) && (((xball >= xMax) || (yball <= yMin)) || ((xball >= (xAI 4)) && (yball >= (yAI - 0)) && (yball <= (yAI + 24))))) {
if (xball >= xMax ) {
ballDirection = 5;
} else if (yball <= yMin) {
ballDirection = 0;
} else if ((xball >= xAI - 4) && (xball < xAI)) {
ballDirection = 2;
}
}
if ((ballDirection == 1) && (xball < xMax) && (yball > yMin)) {
counter++;
if (counter == 6)
{xball++;xball++;
yball--;
xballold = xball - 2;
yballold = yball + 1;counter = 0;}
Wait6u();
Wait6u();Wait6u();Wait6u();Wait6u();
Wait6u();Wait6u();/*Wait6u();Wait6u();*/
}
if ((ballDirection == 2) && (((xball <= xMin) || (yball <= yMin)) || ((xball == (xbar +
4)) && (yball >= ybar) && (yball <= (ybar + 24))))) {
if (xball == (xbar + 4)) {
ballDirection = 1;
} else if (xball <= xMin) {
ballDirection = 4;
} else if (yball <= yMin) {
ballDirection = 3;
}
}
if ((ballDirection == 2) && (xball > xMin) && (yball > yMin)) {
counter++;
if (counter == 6)
{xball--;xball--;
yball--;
xballold = xball + 2;
yballold = yball + 1;counter = 0;
}
Wait6u();
Wait6u();Wait6u();Wait6u(); Wait6u();
Wait6u();Wait6u();/*Wait6u();Wait6u(); */
}
if ((ballDirection == 3) && (((xball <= xMin) || (yball >= yMax)) || ((xball == (xbar +
4)) && (yball >= ybar) && (yball <= (ybar + 24))))) {
F-6
ECE 477 Final Report
if (xball == xbar + 4) {
ballDirection = 0;
} else if (xball <= xMin) {
ballDirection = 4;
} else if (yball >= yMax) {
ballDirection = 2;
}
}
if (ballDirection == 3 && xball > xMin && yball < yMax) {
counter++;
if (counter == 6)
{
xball--;xball--;
yball++;
xballold = xball + 2;
yballold = yball - 1;counter = 0;}
Wait6u();
Wait6u();Wait6u();Wait6u(); Wait6u();
Wait6u();Wait6u();/*Wait6u();Wait6u(); */
}
if (ballDirection == 4) {
AIScore++;
if (AIScore == 10) {
AIScore = 0;
}
asm("movb #0xFF, 592");
ballDirection = 6;
}
if (ballDirection == 5) {
userScore++;
asm("movb #0xFF, 592");
ballDirection = 7;
}
}
void MoveBar(void)
{
if((KEY_DOWN1 == 1) && (ybar <= yMax - 24))
{
counter2++;
if(counter2 == 2)
{
ybar++; ybarold = ybar - 1;
counter2 = 0;
}
Wait6u();
Wait6u();Wait6u();Wait6u();Wait6u();
Wait6u();Wait6u();Wait6u();Wait6u();Wait6u();Wait6u();
Wait6u();Wait6u();Wait6u();Wait6u();
}
if((KEY_UP1 == 1) && (ybar >= yMin))
{
counter2++;
if (counter2 == 2){
ybar--; ybarold = ybar + 1;counter2 = 0;} Wait6u();
Wait6u();Wait6u();Wait6u();Wait6u();
Wait6u();Wait6u();Wait6u();Wait6u();
Wait6u();Wait6u();Wait6u();Wait6u(); Wait6u();Wait6u();
}
if((KEY_DOWN2 == 1) && (yAI <= yMax - 24))
F-7
ECE 477 Final Report
{
counter3++;
if(counter3 == 2)
{
yAI++; yAIold = yAI - 1;counter3 = 0;} Wait6u();
Wait6u();Wait6u();Wait6u();Wait6u();
Wait6u(); Wait6u();Wait6u();Wait6u();
Wait6u();Wait6u();Wait6u();Wait6u();
Wait6u();Wait6u(); Wait6u();Wait6u();Wait6u();Wait6u();
}
if((KEY_UP2 == 1) && (yAI >= yMin))
{
counter3++;
if(counter3 == 2) {
yAI--; yAIold = yAI + 1;counter3 = 0;
}
Wait6u();
Wait6u();Wait6u();Wait6u();Wait6u();
Wait6u();Wait6u();Wait6u();Wait6u();
Wait6u();Wait6u();Wait6u();Wait6u();
Wait6u();Wait6u();
Wait6u();Wait6u();Wait6u();Wait6u();
}
if((KEY_START1 == 1) && (ballDirection == 6))
{
asm("movb #0x00, 592");
ballDirection = 0;
}
if((KEY_START2 == 1) && (ballDirection == 7))
{
asm("movb #0x00, 592");
ballDirection = 3;
}
return;
}
void CopyBall_clear(void)
{
int y_offset, i,j;
y_offset = yballold * 160;
temp = y_offset + xballold;
/* 8x8black*/
asm("psha");
asm("pshx");
for (i = 0; i<4; i++)
{
for (j = 0; j<4; j++)
{
asm("pshd");
asm ("pshx");
asm ("ldx 0x1012");
asm ("stx 0000");
asm ("movb #0xA0, 0x0032");
asm ("movb #0x20, 0x0032");
asm ("ldaa #0x00");
asm ("staa 0000");
asm ("movb #04, 0x0260");
asm ("movb #06, 0x0260");
asm ("ldx 0x1012");
asm ("inx");
asm ("stx 0x1012");
asm("pulx");
asm ("puld");
asm ("subd #0x01");
}
asm("pshd");
asm("ldd 0x1012");
F-8
ECE 477 Final Report
asm("addd #0x9E");
asm("std 0x1012");
asm("puld");
}
asm("pulx");
asm("pula");
return;
}
void CopyBall(void)
{
int y_offset, i,j;
y_offset = yball * 160;
temp = y_offset + xball;
/* 8x8black*/
asm("psha");
asm("pshx");
for (i = 0; i<4; i++)
{
for (j = 0; j<4; j++)
{
asm("pshd");
asm ("pshx");
asm ("ldx 0x1012");
asm ("stx 0000");
asm ("movb #0xA0, 0x0032");
asm ("movb #0x20, 0x0032");
asm ("ldaa #0xFF");
asm ("staa 0000");
asm ("movb #04, 0x0260");
asm ("movb #06, 0x0260");
asm ("ldx 0x1012");
asm ("inx");
asm ("stx 0x1012");
asm("pulx");
asm ("puld");
asm ("subd #0x01");
}
asm("pshd");
asm("ldd 0x1012");
asm("addd #0x9E");
asm("std 0x1012");
asm("puld");
}
asm("pulx");
asm("pula");
return;
/*
int y_offset,i,j;
y_offset = yball * 320;
temp = y_offset + xball;
/*row 1
asm("psha");
asm("pshx");
for (i = 0; i < 1; i++ )
{
asm ("ldx 0x1012");
asm ("stx 0000");
asm ("movb #0xA0, 0x0032");
asm ("movb #0x20, 0x0032");
asm ("pshd");
asm ("ldaa #0x00");
asm ("staa 0000");
asm ("movb #04, 0x0260");
asm
asm
asm
asm
("movb #06, 0x0260");
("ldx 0x1012");
("inx");
("stx 0x1012");
F-9
ECE 477 Final Report
asm ("puld");
/* *temp = 0x00;
temp++;
}
for (i = 0; i < 2; i++)
{
asm ("ldx 0x1012");
asm ("stx 0000");
asm ("movb #0xA0, 0x0032");
asm ("movb #0x20, 0x0032");
asm ("pshd");
asm ("ldaa #0xFF");
asm ("staa 0000");
asm ("movb #04, 0x0260");
asm
asm
asm
asm
asm
asm
("movb #06, 0x0260");
("ldx 0x1012");
("inx");
("stx 0x1012");
("puld");
("subd #0x01");
/**temp = 0xFF;
temp++;
}
for (i = 0; i < 1; i++)
{
asm ("ldx 0x1012");
asm ("stx 0000");
asm ("movb #0xA0, 0x0032");
asm ("movb #0x20, 0x0032");
asm ("pshd");
asm ("ldaa #0x00");
asm ("staa 0000");
asm ("movb #04, 0x0260");
asm
asm
asm
asm
asm
("movb #06, 0x0260");
("ldx 0x1012");
("inx");
("stx 0x1012");
("puld");
/**temp = 0x00;
temp++;
}
asm("pshd");
asm("ldd 0x1012");
asm("addd #0x9C");
asm("std 0x1012");
asm("puld"); /*go to next row - 4*/
/*row 2*/
/* asm ("ldx 0x1012");
asm ("stx 0000");
asm ("movb #0xA0, 0x0032");
asm ("movb #0x20, 0x0032");
asm ("ldaa #0x00");
asm ("staa 0000");
asm ("movb #04, 0x0260");
asm ("movb #06, 0x0260");
asm ("ldx 0x1012");
asm ("inx");
asm ("stx 0x1012");
/* *temp = 0x0F;
temp++;
for (i = 0; i < 4; i++)
{
asm ("ldx 0x1012");
F-10
ECE 477 Final Report
asm
asm
asm
asm
asm
asm
asm
asm
asm
asm
asm
asm
asm
("stx 0000");
("movb #0xA0, 0x0032");
("movb #0x20, 0x0032");
("pshd");
("ldaa #0xFF");
("staa 0000");
("movb #04, 0x0260");
("movb #06, 0x0260");
("ldx 0x1012");
("inx");
("stx 0x1012");
("puld");
("subd #0x01");
}
/**temp = 0xFF;
temp++;*/
/*asm ("ldx 0x1012");
asm ("stx 0000");
asm ("movb #0xA0, 0x0032");
asm ("movb #0x20, 0x0032");
asm ("ldaa #0x00");
asm ("staa 0000");
asm ("movb #04, 0x0260");
asm ("movb #06, 0x0260");
asm ("ldx 0x1012");
asm ("inx");
asm ("stx 0x1012");
asm("pshd");
asm("ldd 0x1012");
asm("addd #0x9C");
asm("std 0x1012");
asm("puld");
/*row 3 - 6
for (j = 0; j < 2; j++)
{
for (i = 0; i < 2; i++)
{
asm ("ldx 0x1012");
asm ("stx 0000");
asm ("movb #0xA0, 0x32");
asm ("movb #0x20, 0x32");
asm ("pshd");
asm ("ldaa #0xFF");
asm ("staa 0000");
asm ("movb #04, 0x0260");
asm
asm
asm
asm
asm
asm
("movb #06, 0x0260");
("ldx 0x1012");
("inx");
("stx 0x1012");
("puld");
("subd #0x01");
/**temp = 0xFF;
temp++;
}
asm("pshd");
asm("ldd 0x1012");
asm("addd #0x9C");
asm("std 0x1012");
asm("puld");
}
/*row 7*/
/*
asm ("ldx 0x1012");
F-11
ECE 477 Final Report
asm
asm
asm
asm
asm
asm
asm
asm
asm
asm
("stx 0000");
("movb #0xA0, 0x0032");
("movb #0x20, 0x0032");
("ldaa #0x00");
("staa 0000");
("movb #04, 0x0260");
("movb #06, 0x0260");
("ldx 0x1012");
("inx");
("stx 0x1012");
/* *temp = 0x0F;
temp++;
for (i = 0; i < 6; i++)
{
asm ("ldx 0x1012");
asm ("stx 0000");
asm ("movb #0xA0, 0x0032");
asm ("movb #0x20, 0x0032");
asm ("pshd");
asm ("ldaa #0xFF");
asm ("staa 0000");
asm ("movb #04, 0x0260");
asm ("movb #06, 0x0260");
asm ("ldx 0x1012");
asm ("inx");
asm ("stx 0x1012");
asm ("puld");
asm ("subd #0x01");
}
/**temp = 0xFF;
temp++;
asm ("ldx 0x1012");
asm ("stx 0000");
asm ("movb #0xA0, 0x0032");
asm ("movb #0x20, 0x0032");
asm ("ldaa #0x00");
asm ("staa 0000");
asm ("movb #04, 0x0260");
asm ("movb #06, 0x0260");
asm ("ldx 0x1012");
asm ("inx");
asm ("stx 0x1012");
asm("pshd");
asm("ldd 0x1012");
asm("addd #0x9C");
asm("std 0x1012");
asm("puld");
/*row 8
for (i = 0; i < 1; i++ )
{
asm ("ldx 0x1012");
asm ("stx 0000");
asm ("movb #0xA0, 0x0032");
asm ("movb #0x20, 0x0032");
asm ("pshd");
asm ("ldaa #0x00");
asm ("staa 0000");
asm ("movb #04, 0x0260");
asm
asm
asm
asm
("movb #06, 0x0260");
("ldx 0x1012");
("inx");
("stx 0x1012");
F-12
ECE 477 Final Report
asm ("puld");
asm ("subd #0x01");
/* *temp = 0x00;
temp++;
}
for (i = 0; i < 2; i++)
{
asm ("ldx 0x1012");
asm ("stx 0000");
asm ("movb #0xA0, 0x0032");
asm ("movb #0x20, 0x0032");
asm ("pshd");
asm ("ldaa #0xFF");
asm ("staa 0000");
asm ("movb #04, 0x0260");
asm
asm
asm
asm
asm
asm
("movb #06, 0x0260");
("ldx 0x1012");
("inx");
("stx 0x1012");
("puld");
("subd #0x01");
/**temp = 0xFF;
temp++;
}
for (i = 0; i < 1; i++)
{
asm ("ldx 0x1012");
asm ("stx 0000");
asm ("movb #0xA0, 0x0032");
asm ("movb #0x20, 0x0032");
asm ("pshd");
asm ("ldaa #0x00");
asm ("staa 0000");
asm ("movb #04, 0x0260");
asm ("movb #06, 0x0260");
asm ("ldx 0x1012");
asm ("inx");
asm ("stx 0x1012");
asm ("puld");
asm ("subd #0x01");
/**temp = 0x00;
temp++;
}
/* *temp = 0x00;
temp++;
asm("pulx");
asm("pula");
*/
}
void CopyBar1_clear()
{
int y_offset, i,j;
y_offset = ybarold * 160;
temp = y_offset + xbarold;
/* 8x8black*/
asm("psha");
asm("pshx");
for (i = 0; i<24; i++)
{
for (j = 0; j<4; j++)
{
asm("pshd");
asm ("pshx");
asm ("ldx 0x1012");
asm ("stx 0000");
asm ("movb #0xA0, 0x0032");
F-13
ECE 477 Final Report
asm ("movb #0x20, 0x0032");
asm ("ldaa #0x00");
asm ("staa 0000");
asm ("movb #04, 0x0260");
asm ("movb #06, 0x0260");
asm ("ldx 0x1012");
asm ("inx");
asm ("stx 0x1012");
asm("pulx");
asm ("puld");
asm ("subd #0x01");
}
asm("pshd");
asm("ldd 0x1012");
asm("addd #0x9E");
asm("std 0x1012");
asm("puld");
}
asm("pulx");
asm("pula");
return;
}
void CopyBar1(void)
{
int y_offset, i,j;
y_offset = ybar * 160;
temp = y_offset + xbar;
/* 8x8black*/
asm("psha");
asm("pshx");
for (i = 0; i<24; i++)
{
for (j = 0; j<4; j++)
{
asm("pshd");
asm ("pshx");
asm ("ldx 0x1012");
asm ("stx 0000");
asm ("movb #0xA0, 0x0032");
asm ("movb #0x20, 0x0032");
asm ("ldaa #0xAA");
asm ("staa 0000");
asm ("movb #04, 0x0260");
asm ("movb #06, 0x0260");
asm ("ldx 0x1012");
asm ("inx");
asm ("stx 0x1012");
asm("pulx");
asm ("puld");
asm ("subd #0x01");
}
asm("pshd");
asm("ldd 0x1012");
asm("addd #0x9E");
asm("std 0x1012");
asm("puld");
}
asm("pulx");
asm("pula");
/* int y_offset,i,j;
u8 * temp = base_back;
y_offset = ybar * 160;
temp = (u8*) (y_offset + xbar);
/*row 1
for (i = 0; i < 4; i++)
{
*temp = 0x22;
temp++;
}
temp+=156;
F-14
ECE 477 Final Report
/*row2
for (i = 0; i < 4; i++)
{
*temp = 0x22;
temp++;
}
temp+=156;
/*row 3 - 30
for(i = 0; i < 28; i++)
{
*temp = 0x22;
temp++;
*temp = 0xFF;
temp++;
*temp = 0xFF;
temp++;
*temp = 0x22;
temp+=156;
}
/*row 31
for (i = 0; i < 4; i++)
{
*temp = 0x22;
temp++;
}
temp+=156;
/*row32
for (i = 0; i < 4; i++)
{
*temp = 0x22;
temp++;
}
temp+=156; */
return;
}
void CopyBar2_clear()
{
int y_offset, i,j;
y_offset = yAIold * 160;
temp = y_offset + xAIold;
/* 8x8black*/
asm("psha");
asm("pshx");
for (i = 0; i<24; i++)
{
for (j = 0; j<4; j++)
{
asm("pshd");
asm ("pshx");
asm ("ldx 0x1012");
asm ("stx 0000");
asm ("movb #0xA0, 0x0032");
asm ("movb #0x20, 0x0032");
asm ("ldaa #0x00");
asm ("staa 0000");
asm ("movb #04, 0x0260");
asm ("movb #06, 0x0260");
asm ("ldx 0x1012");
asm ("inx");
asm ("stx 0x1012");
asm("pulx");
asm ("puld");
asm ("subd #0x01");
}
asm("pshd");
asm("ldd 0x1012");
asm("addd #0x9E");
asm("std 0x1012");
asm("puld");
}
asm("pulx");
F-15
ECE 477 Final Report
asm("pula");
return;
}
void CopyBar2(void)
{
int y_offset, i,j;
y_offset = yAI * 160;
temp = y_offset + xAI;
/* 8x8black*/
asm("psha");
asm("pshx");
for (i = 0; i<24; i++)
{
for (j = 0; j<4; j++)
{
asm("pshd");
asm ("pshx");
asm ("ldx 0x1012");
asm ("stx 0000");
asm ("movb #0xA0, 0x0032");
asm ("movb #0x20, 0x0032");
asm ("ldaa #0x99");
asm ("staa 0000");
asm ("movb #04, 0x0260");
asm ("movb #06, 0x0260");
asm ("ldx 0x1012");
asm ("inx");
asm ("stx 0x1012");
asm("pulx");
asm ("puld");
asm ("subd #0x01");
}
asm("pshd");
asm("ldd 0x1012");
asm("addd #0x9E");
asm("std 0x1012");
asm("puld");
}
asm("pulx");
asm("pula");
/*
int y_offset,i,j;
u8 * temp = base_back;
y_offset = yAI * 160;
temp = (u8 *) (y_offset + xAI);
/*row 1
for (i = 0; i < 4; i++)
{
*temp = 0x22;
temp++;
}
temp+=156;
/*row2
for (i = 0; i < 4; i++)
{
*temp = 0x22;
temp++;
}
temp+=156;
/*row 3 - 30
for(i = 0; i < 28; i++)
{
*temp = 0x22;
temp++;
*temp = 0xFF;
temp++;
*temp = 0xFF;
temp++;
F-16
ECE 477 Final Report
*temp = 0x22;
temp+=156;
}
/*row 31
for (i = 0; i < 4; i++)
{
*temp = 0x22;
temp++;
}
temp+=156;
/*row32
for (i = 0; i < 4; i++)
{
*temp = 0x22;
temp++;
}
temp+=156;
*/
return;
}
void CopyScore1(void)
{
/* unsigned int * temp = base_back;
int i,j;
temp+=50;
if (userScore == 0)
{
for (i = 0; i < 4; i++)
{
*temp = 0x00;
temp++;
}
temp+=156;
for (i = 0; i < 4; i++)
{
*temp = 0x00;
temp++;
}
temp+=156;
for (i = 0; i < 6; i++)
{
*temp = 0x00;
temp++;
*temp = 0xFF;
temp++;
*temp = 0xFF;
temp++;
*temp = 0x00;
temp++;
temp+=156;
}
for (i = 0; i < 4; i++)
{
*temp = 0x00;
temp++;
}
temp+=156;
for (i = 0; i < 4; i++)
{
*temp = 0x00;
temp++;
}
temp+=156;
}
else if (userScore == 1)
{
*temp = 0xFF;
temp++;
*temp = 0xF0;
temp++;
*temp = 0x00;
F-17
ECE 477 Final Report
temp++;
*temp = 0xFF;
temp+=156;
for (i = 0; i < 1; i++)
{
*temp = 0xFF;
temp++;
}
for (i = 0; i < 2; i++)
{
*temp = 0x00;
temp++;
}
for (i = 0; i < 1; i++)
{
*temp = 0xFF;
temp++;
}
temp+=156;
for (i = 0; i < 6; i++)
{
for (j = 0; j < 2; j++)
{
*temp = 0xFF;
temp++;
}
*temp = 0x00;
temp++;
*temp = 0xFF;
temp++;
temp+=156;
}
for (i = 0; i < 2; i++)
{
*temp = 0xFF;
temp++;
*temp = 0x00;
temp++;
*temp = 0x00;
temp++;
*temp = 0x00;
temp++;
temp+=156;
}
}
*/
return;
}
void CopyScore2(void)
{
return;
}
void CopyBackground(void)
{
int i,j,k;
asm("psha");
asm("pshx");
for (i = 0; i < 2560; i++)
{
asm
asm
asm
asm
("ldx 0x1012");
("stx 0000");
("movb #0xA0, 0x0032");
("movb #0x20, 0x0032");
F-18
ECE 477 Final Report
asm
asm
asm
asm
("pshd");
("ldaa #0xEE");
("staa 0000");
("movb #04, 0x0260");
asm
asm
asm
asm
asm
asm
("movb #06, 0x0260");
("ldx 0x1012");
("inx");
("stx 0x1012");
("puld");
("subd #0x01");
/* *temp = 0xFF;
temp++;*/
}
for (i = 0; i < 188; i++)
{
for (j = 0; j < 8; j++)
{
asm ("ldx 0x1012");
asm ("stx 0000");
asm ("movb #0xA0, 0x32");
asm ("movb #0x20, 0x32");
asm ("pshd");
asm ("ldaa #0xDD");
asm ("staa 0000");
asm ("movb #04, 0x0260");
asm
asm
asm
asm
asm
asm
("movb #06, 0x0260");
("ldx 0x1012");
("inx");
("stx 0x1012");
("puld");
("subd #0x01");
/* *temp = 0xFF;
temp++; */
}
for (k = 0; k < 304; k++)
{
asm ("ldx 0x1012");
asm ("stx 0000");
asm ("movb #0xA0, 0x32");
asm ("movb #0x20, 0x32");
asm ("pshd");
asm ("ldaa #0x00");
asm ("staa 0000");
asm ("movb #04, 0x0260");
asm
asm
asm
asm
asm
asm
("movb #06, 0x0260");
("ldx 0x1012");
("inx");
("stx 0x1012");
("puld");
("subd #0x01");
/* *temp = 0x00;
temp++; */
}
for (j = 0; j < 8; j++)
{
asm ("ldx 0x1012");
asm ("stx 0000");
asm ("movb #0xA0, 0x32");
asm ("movb #0x20, 0x32");
asm ("pshd");
asm ("ldaa #0xCC");
asm ("staa 0000");
asm ("movb #04, 0x0260");
asm ("movb #06, 0x0260");
asm ("ldx 0x1012");
asm ("inx");
F-19
ECE 477 Final Report
asm ("stx 0x1012");
asm ("puld");
asm ("subd #0x01");
/* *temp = 0xFF;
temp++; */
}
}
for (i = 0; i < 1280; i++)
{
asm ("ldx 0x1012");
asm ("stx 0000");
asm ("movb #0xA0, 0x32");
asm ("movb #0x20, 0x32");
asm ("pshd");
asm ("ldaa #0xBB");
asm ("staa 0000");
asm ("movb #04, 0x0260");
asm
asm
asm
asm
asm
asm
("movb #06, 0x0260");
("ldx 0x1012");
("inx");
("stx 0x1012");
("puld");
("subd #0x01");
/* *temp = 0xFF;
temp++; */
}
asm("pulx");
asm("pula");
return;
}
void WriteToVid(void)
{
/*int j;
u16 * temp;
u16 * i;
asm ("psha");
i = (u16 *) 0x7F00;
temp = (u16 *) 0x7F08;
*temp = 0x8000;
*i = 0x0000;
j = 10;
for (j = 0; j < 30000; j++)
{
asm ("ldaa 0x9F00");
asm ("staa 0000");
asm ("movb #0xA0, 0x32");
asm ("movb #0x80, 0x32");
asm ("ldaa 0x9F08");
asm ("staa 0000");
asm ("movb #04, 0x260");
(*i)++;
(*temp)++;
}
for (j = 0; j < 2000; j++)
{
asm ("ldaa 0x9F00");
asm ("staa 0000");
asm ("movb #0xA0, 0x32");
asm ("movb #0x20, 0x32");
asm ("ldaa 0x9F08");
asm ("staa 0000");
asm ("movb #04, 0x260");
(*i)++;
(*temp)++;
}
asm ("pula");*/
return;
F-20
ECE 477 Final Report
}
Start-up code (9s12c32-crt0.s):
;----------------------------------------; startup code
;----------------------------------------.file
"crt0.s"
.mode mshort
;;
;;
;; The linker concatenates the .install* sections in the following order:
;;
;; .install0
Setup the stack pointer
;; .install1
Place holder for applications
;; .install2
Optional installation of data section in memory
;; .install3
Place holder for applications
;; .install4
Invokes the main
;;
;--------------------------------------------------------------------------.sect
.install0,"ax",@progbits
.globl _start
_start:
;;
;; At this step, the stack is not initialized and interrupts are masked.
;; Applications only have 64 cycles to initialize some registers.
;;
;; To have a generic/configurable startup, initialize the stack to
;; the end of some memory region. The _stack symbol is defined by
;; the linker.
;;
;
.equ
.equ
.equ
.equ
.equ
.equ
.equ
.equ
.equ
Custom startup code for the 9s12c32:
REGBASE, 0x0
RAMBASE, 0x3800
INITRM, 0x0010
; RAM Position
INITRG, 0x0011
; Register position
SYNR,
0x34
REFDV,
0x35
CRGFLG, 0x37
CLKSEL, 0x39
PLLCTL, 0x3A
sei
movb
movb
lds
;;
;;
;;
;;
;;
;;
;;
;;
;;
;;
;;
;;
;;
;;
;;
;;
;;
#0,
INITRG
#0x39, INITRM
#_stack
;
;
;
;
Disable interrupts
set INITRG to 0x0 (Registers at 0x0000)
set INITRM to 0x39 (RAM 0x3800 - 0x3fff)
stack is normally 0x3fce (specified in memory.x file)
The internal PLL clock lets us set the speed of the processor.
If you do not set the speed of the PLL as we are doing here, the
default bus speed speed will be 4 Mhz (half the OscFreq).
The math used to set the PLL frequency:
OscFreq = 8Mhz
initSYNR = 2
PLL multiplier
initREFDV = 0
PLL divider - 1
PLLCLK = 2 * OscFreq * (initSYNR+1) / (initREFDV+1)
Usually the OscFreq is 8Mhz, so we have PLLCLK = 2*8*3/1 = 48Mhz
The bus clock runs at half of the PLL speed:
Bus Clock = PLLCLK / 2 = 24 Mhz (for an OscFreq of 8 Mhz)
The effective cycle clock you should use for timing instructions is the
bus clock of 24 Mhz. This is currently the fastest speed this device
can safely use. Overclocking is not recommended.
F-21
ECE 477 Final Report
;;
;;
;;
;;
;;
;;
;;
;;
;;
;;
;;
;;
;;
;;
If you set a slower speed, it will reduce power consumption. If low
power consumption is important (like for battery-powered circuits), you
should also put the processor to sleep as often as possible.
Set the PLL speed:
bclr
bset
movb
movb
nop
nop
CLKSEL, #0x80
PLLCTL, #0x40
#0x2, SYNR
#0x0, REFDV
;
;
;
;
disengage PLL to system
turn on PLL
set PLL multiplier
set PLL divider
; wait for the PLLCLK to stabalize
brclr CRGFLG, #0x08, *+0 ; while (!(crg.crgflg.bit.lock==1))
bset CLKSEL, #0x80
; engage PLL to system
cli
; enable interrupts
;--------------------------------------------------------------------------.sect
.install2,"ax",@progbits
;;
;; Call a specific initialization operation. The default is empty.
;; It can be overriden by applications. It is intended to initialize
;; the 68hc11 registers. Function prototype is:
;;
;;
int __premain(void);
;;
jsr
__premain
;;
;;
;;
;--------------------------------------------------------------------------.sect
.install4,"ax",@progbits
jsr
main
fatal:
jsr
exit
bra fatal
;----------------------------------------; end startup code
;----------------------------------------;; Force loading of data section mapping and bss clear
.2byte __map_data_section
.2byte __init_bss_section
Vector code (vectors.s):
.sect .text
.globl _start
;; Default interrupt handler.
.sect .text
def:
rti
;;
;; Interrupt vectors are in a specific section that is
;; mapped at 0xff8a. For the example program, the reset handler
;; points to the generic crt0 entry point.
;;
.sect .vectors
.globl vectors
vectors:
.word def
; ff8a
.word def
; ff8c
.word def
; ff8e
.word def
; ff90
.word def
; ff92
.word def
; ff94
.word def
; ff96
.word def
; ff98
F-22
*/
ECE 477 Final Report
.word
.word
.word
.word
.word
.word
.word
.word
.word
.word
.word
.word
.word
.word
.word
.word
.word
.word
.word
.word
.word
.word
.word
.word
.word
.word
.word
.word
.word
.word
def
def
def
def
def
def
def
def
def
def
def
def
def
def
def
def
def
def
def
def
def
def
def
def
def
def
def
def
def
def
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
ff9a
ff9c
ff9e
ffa0
ffa2
ffa4
ffa6
ffa8
ffaa
ffac
ff9e
ffb0
ffb2
ffb4
ffb6
ffb8
ffba
ffbc
ffbe
ffc0
ffc2
ffc4
ffc6
ffc8
ffca
ffcc
ffce
ffd0
ffd2
ffd4
;; SCI
.word def
; ffd6
;; SPI
.word def
.word def
.word def
.word def
;
;
;
;
ffd8
ffda (PAII)
ffdc (PAOVI)
ffde (TOI)
;; Timer Output Compare
.word def
.word def
.word def
.word def
.word def
;
;
;
;
;
ffe0
ffe2
ffe4
ffe6
ffe8
;; Timer Input compare
.word def
.word def
.word def
; ffea
; ffec
; ffee
;; Misc
.word def
.word def
.word def
.word def
.word def
.word def
.word def
.word 0x4000
;
;
;
;
;
;
;
;
fff0
fff2
fff4
fff6
fff8
fffa
fffc
fffe
(RTII)
(IRQ)
(XIRQ)
(SWI)
(ILL)
(COP Failure)
(COP Clock monitor)
(reset)
Video generation code (crtif2a.abl):
MODULE crtif2a
TITLE 'CRT controller'
" General purpose display controller logic description. This is a freeware.
" (Type-A: for NTSC, Single clock source)
"
F-23
ECE 477 Final Report
"
"
"
"
"
Pin assignment in this file is for XC95108-PC84. Any changes are required
when fit to any other device.
E-mail: [email protected]
Homepage: http://elm-chan.org/
" Inputs
CLK
!XCS, !XRD, !XWR
XA0..XA15
!AOFS
!VOEN
!V200
pin
pin
pin
pin
pin
pin
9;
37,36,35;
33..31,26..23,21..17,15..12;
41;
40;
43;
"
"
"
"
"
"
Master clock (14.31818MHz)
Command inputs
External address input
Display area start address select
Enable video out
200/240 line select
" 3 state latched I/O
VD0..VD7
pin 62,58,57,54,55,56,61,63 istype 'reg_l'; " Video memory data bus
XD0..XD7
pin 11,10,7..2
istype 'reg_l'; " External data bus
" Outputs
VA0..VA15
address
!VOE,!VWE
!VCE
!XWAIT
pin 65,67,69,71, 72,74,75,76, 82,81,68,80, 77,83,79,1 istype 'com'; " Video memory
pin 70,84 istype 'reg';
pin 66
istype 'com';
pin 34
VOR,VOG,VOB,VOI
!SYNC
SCCLK,DCLK
DISPV
" Video memory control
"
istype 'com';
pin
pin
pin
pin
53..50
48
47,46
39
istype
istype
istype
istype
" Wait F/F (half of one)
'reg_g';
'reg';
'reg';
'com';
"
"
"
"
RGBI video output (half of one)
SYNC output
3.58MHz for NTSC encoder, Dot clock
Vertical blanking indicator
" Nodes
Xwait2
node istype 'com';
" Wait F/F (half of one)
VP0..VP3
XAEN
ACLK
Ready
HSD
node
node
node
node
node
"
"
"
"
"
LA0..LA15
node istype 'reg_l'; " External address latch
istype
istype
istype
istype
istype
DA0..DA15
HC0..HC7
VC0..VC8
VSI
DispH, Disp
EndOfHt, EndOfFrm
node
node
node
node
node
node
'reg_g';
'reg';
'reg';
'reg';
'reg';
istype
istype
istype
istype
istype
istype
Video output register (half of one)
Address select (Host/Display)
CRTC master clock
Wait release flag
Line end detector for half clock delay of ACLK
'reg'; " Display address counter
'reg'; " Horizontal counter
'reg'; " Vertical counter
'reg'; " V-sync indicator
'com,keep'; " Display active indicator
'com,keep'; " End of horizontal, End of frame indicator
" Constants and Symbols
" For video memory access controller
mstat = [ACLK, DCLK]; " State counter
S0 = (mstat==0); S1 = (mstat==1); S2 = (mstat==2); S3 = (mstat==3);
xread = XCS & XRD & !XWR;
xwrite = XCS & !XRD & XWR;
xcmd
= xread # xwrite;
XADDR
LADDR
VADDR
XDATA
VDATA
=
=
=
=
=
[XA15..XA0];
[LA15..LA0];
[VA15..VA0];
[XD7..XD0];
[VD7..VD0];
"
"
"
"
"
External address input
External address latch
Video memory address
External data
Video memory data
VOREG = [VOI,VOG,VOR,VOB,VP3,VP2,VP1,VP0];
VOREGH = [VOI,VOG,VOR,VOB];
VOREGL =
[VP3,VP2,VP1,VP0];
F-24
ECE 477 Final Report
" For
DADDR
HC
VC
SADDR
display timing generator (CRTC)
= [DA15..DA0]; " Display address counter
= [HC7..HC0]; " Horizontal address counter
= [VC8..VC0]; " Vertical line counter
= [0,AOFS,0,0,0,0,0,0,0,0,0,0,0,0,0,0]; " Display area start address
nHt
nHd
nHsp
nHsw
nVt
nVd240
nVd200
nVsp240
nVsp200
nVsw
=
=
=
=
=
=
=
=
=
=
227;
160;
181;
17;
263;
240;
200;
244;
224;
3;
"
"
"
"
"
"
"
"
"
"
Number
Number
H-sync
H-sync
Number
Number
Number
V-sync
V-sync
V-sync
of horizontal total (aclks) (0.5 clock is added)
of horizontal diaplay (aclks)
position (aclks)
width (aclks)
of vertical total (lines)
of vertical display in 240 line mode (line)
of vertical display in 200 line mode (line)
position in 240 line mode (line)
position in 200 line mode (line)
width (lines)
EQUATIONS
" Video memory controller
[DCLK, ACLK, SCCLK, HSD].clk = CLK;
[XAEN, VOE, VWE, Ready, VOREG].clk = CLK;
" Wait F/F
XWAIT = !Ready & !Xwait2 & xcmd;
Xwait2 = Ready
# Xwait2 & xcmd;
" Memory control state counter [ACLK,DCLK]
when
EndOfHt & S0 & !HSD then { mstat := 1; HSD := 1; }
else when EndOfHt & S0 & HSD then { mstat := mstat - 1; HSD := 0; }
else
{ mstat := mstat - 1; HSD := HSD; }
" 3.58MHz color sub-carrier output
when DCLK then SCCLK := !SCCLK
else
SCCLK := SCCLK;
" External access indicator (XAEN)
when
S0 & XWAIT
& !XAEN
# S2 & XWAIT & !Disp & !XAEN then XAEN := 1;
else when S1 # S3
then XAEN := XAEN;
else
XAEN := 0;
" Video memory control
VCE = XAEN
# (S1 # S0) & Disp;
VOE := S1 & Disp
# (S1 # S3) & XAEN & xread;
VWE := (S1 # S3) & XAEN & xwrite;
" Release wait request (Ready)
Ready := (S1 # S3) & XAEN & xwrite
# (S0 # S2) & XAEN & !Ready;
" Video output register
VOREGH.oe = VOEN;
VOREG.ce = S2 # S0;
when S0 & Disp then VOREG := VDATA.pin
else
VOREG := [VOREGL, 0,0,0,0];
" R/W data gate/latch
VDATA.oe = VWE.fb;
F-25
ECE 477 Final Report
VDATA.le
VDATA.d
XDATA.oe
XDATA.lh
XDATA.d
=
=
=
=
=
VWE.fb;
XDATA.pin;
xread;
VOE.fb & XAEN;
VDATA.pin;
" VRAM address multiplexer and external address latch
LADDR.le = XAEN;
LADDR.d = XADDR;
when XAEN then VADDR = LADDR;
else
VADDR = DADDR;
" Display timing generator (CRTC) driven by ACLK(3.58MHz)
[DADDR,HC,VC, SYNC,VSI].clk = ACLK;
" Horizontal counter (HC)
EndOfHt = (HC == nHt-1);
when EndOfHt then HC := 0
else
HC := HC + 1;
" End of horizontal line
" Vertical line counter (VC)
EndOfFrm = ((HC == nHt-1) & (VC == nVt-1)); " End of frame
when
EndOfFrm then VC := 0
else when EndOfHt then VC := VC + 1
else
VC := VC;
" Display active time indicator (DispH, DISPV, Disp)
DispH = (HC < nHd);
DISPV = (VC < nVd240) & !V200
#(VC < nVd200) & V200;
Disp = DISPV.com & DispH;
" Horizontal sync (SYNC)
when
(HC == nHsp-1)
then SYNC := 1
else when (HC == nHsp-1+nHsw) & !VSI
#(HC == nHsp-1-nHsw)
then SYNC := 0
else
SYNC := SYNC;
" Vertical
when
#
else when
#
else
sync (VSI)
EndOfHt & (VC
EndOfHt & (VC
EndOfHt & (VC
EndOfHt & (VC
==
==
==
==
nVsp240-1)
nVsp200-1)
nVsp240-1+nVsw)
nVsp200-1+nVsw)
& !V200
& V200 then VSI := 1
& !V200
& V200 then VSI := 0
VSI := VSI;
" Display address counter (DADDR)
when
EndOfFrm then DADDR := SADDR
else when Disp
then DADDR := DADDR + 1
else
DADDR := DADDR;
END
F-26
ECE 477 Final Report
Appendix G: User Manual
THE
NOSTALGIC 4
USER MANUAL
G-1
ECE 477 Final Report
Contents
Item
Page
Product Description
3
Product Illustration
4
Setup Instruction
5
Product Use Instruction
6
Troubleshooting
7
G-2
ECE 477 Final Report
Product Description
Is the hustle and bustle of everyday life threatening to wear you down? Are the highpowered, graphic intensive games no longer helping to relieve the stress at the end of the day?
Do you long for games that do not tax your mind as much as a full-time job?
Welcome to the world of The Nostalgic 4 (N4)—the family entertainment unit that will
bring hours of delight to both young and old. N4 will take you down the memory lane of video
game history by helping you relive the golden age of classic games like “Pong”. Designed with
up-to-date technology, you can be assured of the seamless running of these games.
The N4 is eclectically designed to differentiate itself from other video game consoles.
The body is cylindrical in shape, as opposed to the angular norm, yet compactly designed to fit
comfortably on any flat surface. It is easy to set up—with only two main cables to connect—and
will output video images to any NTSC television.
The N4 features two attached Nintendo style controllers for single or two-player game
play. These Nintendo style controllers are easy to use and will fit comfortably in hands of
children and adults.
Also, N4 has an incorporated USB interface that allows the user to run other classic
games. A USB Memory Stick can be used to download N4-compatible game data from any USB
enabled source. The USB Memory Stick with the game data can than be inserted to the USB
Memory Port on N4 prior to starting up to load the game for playing.
The N4 aims to excite the weary with simplistic yet well-received classical games that are
becoming extinct with the advent of high-powered gaming consoles. Through N4, we hope to
satiate the nostalgic needs of all gaming individuals, and hopefully educate the young in video
gaming history.
We hope you enjoy N4 as much as we have enjoyed putting it together. Have fun!
G-3
ECE 477 Final Report
Product Illustration
SPEAKER
Figure 1 N4 Illustration
Figure 2 N4 Package
G-4
ECE 477 Final Report
Setup Instructions
The following lists the components that should come with the product:
1. DC 12 V Adapter
2. The Nostalgic 4 Main Body
3. RCA Cable
4. 2 Nintendo-style Controllers (Connected to Main Body)
5. USB Memory Stick
In the event that any of the components are missing in the packaging, please contact the
customer care representative at [email protected] to obtain the requisite parts, or
return the product to the retailer for a full refund.
The Nostalgic 4 (N4) Main Body is compactly designed to be set up with ease. Please
follow this procedure to ensure safe and complete setup of the product:
1. Place the product on a stable flat surface away from water and flammable materials
2. Connect one end of the RCA Cable to the RCA Jack, and the other
end to the video input of an NTSC television
3. Connect the DC 12 V Adapter to the Power Jack, and the other end
to a 120 V AC power outlet
4. Insert the USB Memory Stick containing the game data into the USB
Memory Port
Note: Ensure USB Memory Stick is securely inserted to the USB Memory Port before continuing with Product Use.
If you have any problems with setting up the product, please consult the Troubleshooting
section of the user manual.
G-5
ECE 477 Final Report
Product Use Instructions
Please verify that the Setup Instructions have been carried out properly before continuing
with product use.
The operation of this product will involve the product case, the handheld controllers, the
power/reset switch, the USB memory device, and an NTSC television. If you have any trouble
using these devices while following the instructions, please consult the Setup and
Troubleshooting sections of this manual. Follow these instructions in order to begin playing the
game:
1. Turn on the television.
2. Turn on the power switch; or if already on, flip the switch twice to
reset the product.
3. If you have purchased the special edition memory device with multiple games, a screen
will appear in which you may select a game to play. If you have the standard edition
memory device, the game “Pong” will begin playing immediately
4. The game loaded onto the product will play continuously until the user resets or turns off
the device
To play the game “Pong”, follow these hints:
1. The object of the game is to hit the ball with the paddle every time it approaches your
side of the screen. To move the paddle, press the up or down buttons
2. If a player fails to hit the ball with their respective paddle, the ball will stop at the wall;
hit the start button to reset motion of the ball
3. If proper use of a controller does not produce appropriate motion of the paddle, ensure
that you are using the correct paddle
4. If a player continually scores a point or fails to see motion from the opposing paddle,
ensure that another player is in fact both present and using the opposite controller
Specifications for operation of future games to be included on the special edition USB
memory device are in development and will be included in future editions of the user manual.
G-6
ECE 477 Final Report
Troubleshooting Instructions
The following is a list of common problems customers encounter with the product.
Please consult the list first when troubleshooting. If you are unable to solve the problem with the
list, please contact our customer care representatives at: [email protected].
“Why does the product seem to be without power?” First, make sure the product is plugged
in. Next, ensure that the power switch is on. Finally, make sure that the power outlet being used
has power—did you pay your electric bill within the last few months, or is there a switch in the
room that needs to be on too?
“My television display is off/blank.” First, make sure the television is plugged in, turned on,
and connected to the product with a composite video cable in the composite video jack. Make
sure that the television is in the appropriate “video” mode. Verify that the USB memory device is
inserted into the product so that the “loading” screen is produced (this is a blank white screen).
Finally, try resetting the product.
“My game isn’t displayed.” Make sure that the USB device is fully inserted into the product,
and that the LED on the stick becomes active. Verify with a personal computer that the game is
on the USB device.
“My game is displayed, but the controllers don’t work.” Make sure that the controllers are
attached to the product. If the Pong ball is on the left or right wall, it will respond only to the
start button. Also, try resetting the product.
“The sound is absent/unpleasant.” Sound only occurs when the ball hits an object—has this
happened yet? Also make sure that the Speaker Port of the product is not blocked by an external
device. If the sound is unpleasant, this is not a technical problem with the product; it is an
indication of product functionality.
Finally, if the product fails, allow it to cool (without power) for at least 10 minutes,
before attempting to use it again.
G-7
ECE 477 Final Report
Fall 2004
Appendix H: FMECA Worksheet
Device: Video Game Controller
Circuit Block: Xilinx CPLD and external circuitry
Failure
No.
A-1
Failure Mode
Bypass capacitor
failure
Possible Causes
- Over-voltage
- Longevity
Capacitors: C7, C8, C9
Failure Effects
Method of Detection
Criticality
- Smoke
- Fried chip
- Loss of video
- Distorted video
- Unknown effects
- Video Failure
- Visual smoke
- Sporadic video
(Inspection)
Low
Remarks
The only failure
related to this is a
distorted video, no
injury to the user is
involved due to
protection from
plastic packaging
The video would be
completely lost and
therefore the console
is unusable
A-2
Xilinx
failure/malfunction
XC95108
Total video failure
- Video failure /nothing
output to the screen
(Inspection)
Medium
A-3
Oscillator (CLK)
failure
Capacitors: C13, C12
Oscillator: Q10
- Clock failure
- Xilinx failure
- Video failure
- Video failure
(Inspection)
- RAM is inaccessible
(Software)
Medium
The video would be
completely lost and
therefore the console
is unusable
A-4
Human Error
Jumper: JP1
Resistors: R19, R20
- Distortion in output
video
- Visual distortion in
video
(Inspection)
Very Low
This failure is very
low because the
jumpers aren’t
external to the
console.
I-1
ECE 477 Final Report
Fall 2004
Device: Video Game Controller
Circuit Block: Power supply
Failure
No.
Failure Mode
Possible Causes
Failure Effects
Method of
Detection
Criticality
B-1
Bad fuse
F1
- Black/Fried board
- Smoke
- Heat
- Flames
- Visible damage
(Inspection)
Very High
B-2
Overload output
VCC_5
VCC_3.3
- Fried components
- Total console failure
- Smoke
- Bad odor
(Inspection)
Very High
B-3
Wall-wart failure
VCC
- Fried components
- Total console failure
- Smoke
- Bad odor
- Heat
- Flames
(Inspection)
Very High
B-4
Regulator failure
U104, U105
- Fried components
- Total console failure
Extremely
High
B-5
Bypass capacitor
failure
C49, C50, C51, C52
- Over-voltage input to
DC-DC regulators
- Smoke
- Bad odor
- Heat
- Flames
(Inspection)
- DC-DC regulator
failure
- Smoke
- Bad odor
(Inspection)
B-6
Regulator external
circuitry failure
D1, D2, L1, L2, C53, C54
- Increased ripple of
regulator output, which
reduces efficiency of
regulator block
Unknown
Low
I-2
High
Remarks
Unlikely but possible. Bad
fuse that doesn’t trip can
lead to game console total
and permanent failure.
Current limitations from
wall-wart may save the
console.
Unlikely but possible.
Can protect system by
putting larger caps to GND.
Unlikely but possible.
If wall-wart fails, the input
to the DC-DC regulators
goes up to 40VDC, if
leakage voltage is greater
than this the power regulator
block will burn.
Unlikely but possible.
If DC-DC regulators fail,
everything fails.
If the bypass input
capacitors fail, there is a
chance of failure in the
regulators as well due to the
input of a greater voltage
than the maximum handled
by them.
Due to the fact that they are
discrete devices the failure
rate is low, but unknown
effects can appear.
ECE 477 Final Report
Fall 2004
Device: Video Game Controller
Circuit Block: RS-232 and PWM Audio
Failure
No.
Failure Mode
Possible Causes
Failure Effects
Method of
Detection
- Smoke in serial
connector
- Bad odor
(Inspection)
- Debugging not
available
(Software)
- RS232
debugging is not
available
(Software)
- No sound from
the game console
(Inspection)
- Loud volume
- Sound distortion
- Smoke
- Heat
(Inspection)
Very Low
Will only affect the
debugging unless reverse
short surge or EFT destroys
the microprocessor.
Very Low
Will only affect the
debugging and audio unless
the capacitors leakage
overloads the power supply.
Medium
(Excessive
current draw)
Annoying loud distorted
sound. No threat to user as
speaker is too small to cause
acoustical injury.
- Loud volume
- Sound distortion
- Smoke
- Heat
(Inspection)
Low
Annoying loud distorted
sound. No threat to user as
speaker is too small to cause
acoustical injury.
C-1
RS232 Failure
MAX233A
- Short could cause
damage in host
computer
- Reverse short can fry
microprocessor pins
C-2
Bypass capacitor
failure
C30, C40, C41
- RS232 brownout
- Distorted or no audio
C-3
Op-Amp failure
LM386/SO
- Sound distortion
- Overheated Op-Amp
- Loud sound
C-4
Op-Amp filter failure
R42, C40
- Sound distortion
- Overheated Op-Amp
- Loud sound
I-3
Criticality
Remarks
ECE 477 Final Report
Fall 2004
Device: Video Game Controller
Circuit Block: USB controller/Handheld controllers/RAM/Latches
Failure
No.
Failure Mode
Possible Causes
Failure Effects
Method of
Detection
Criticality
Remarks
D-1
Bus failure
U3 (system RAM)
- Failure to access
data and addresses
- Games may load
partially
- Unknown
(Software/Inspection)
Medium
Game will stop running, or
run slowly and sporadically.
D-2
Bus failure
U97, U98 (high speed
latches)
- Failure to write
extended data to
RAM
- Games may load
partially
- Unknown
(Software/Inspection)
Medium
Game will stop running, or
run slowly and sporadically.
D-3
Mal-functioning/Notfunctioning controller
R56, R57, R58, R59,
R60, R61, R64, R65,
R66, R67, R62, R63,
ISO1, ISO2, ISO3, ISO4,
ISO5, ISO6
- Cannot control
game
- Nothing happens
- Nothing happens on
the screen
- Console appears to
be not functional
(Inspection)
Medium
This will disable the end
user from playing any
games. This error is critical
as without the controllers
the console is useless.
D-4
USB failure
SL811HS
- Failure to download
game to the console
- Games won’t load
(Inspection)
Medium
This will disable the end
user from loading any
games. This error is critical
as without the loaded game
the console is useless.
D-5
USB power safety
device failure
MIC2075-2BM
- Fried USB
controller
- Total USB failure
- Smoke
- Bad odor
- Game won’t load
(Inspection)
Medium
This will disable the end
user from loading any
games. This error is critical
as without the loaded game
the console is useless.
I-4
ECE 477 Final Report
Fall 2004
Device: Video Game Controller
Circuit Block: Microprocessor/Video conversion
Failure
No.
Failure Mode
Possible Causes
Failure Effects
Method of
Detection
Criticality
Remarks
E-1
Bypass capacitor
failure
C14, C18, C19, C20, C15
- Microprocessor
brown-out
- The
microcontroller
will RESET on its
own
Medium
These are discrete
components so the failure is
low. The console is still able
to operate with difficulties.
E-2
Processor slow-down
C16, C17
- PLL circuit can be
damaged
- Game works
sporadically and slow
- Core frequency is
halved reducing
processing power
Low
Still operates but the high
end games are useless,
because of lack of
microprocessor speed.
E-3
Processor core
voltage failure
(VREGEN)
R23
- The core voltage
decreases
considerably due to
current leakage
- Console will not
operate
Medium
The microprocessor is unpowered so it becomes
useless until powered.
E-4
Processor failure
MC9S12A256
- Total collapse of
console
- Console will not
operate
High
This kind of failure can
generate all kind of random
signals and voltages within
the system. Console will
crash. The effects are
unknown.
E-5
Oscillator failure
Q1
-Microprocessor
slows down
-Failure between
cycles
-Micro looses
communication with
other components.
- Glitches occurs
and system fails
Medium
Games will appear not to
work and random effect
would be seen. Other effect
may be unknown.
I-5
ECE 477 Final Report
Fall 2004
Appendix I: MTTF Calculations
λb =
Voltage
Regulator
block
MAX831/SO
LM2676-5
0.00330
1.00000
8.00000
0.02640
37,878,787.88
MAX832/SO
LM2676-3.3
0.00330
1.00000
8.00000
0.02640
37,878,787.88
4,324.06
Maximum
junction
temperature is
of 125ºC and
minimum
junction
temperature is
of -40ºC. P.
11-1 of the
MIL-HDBK217F [3].
From this
document it
can be seen
that λp is
calculated by
using the
following
formula
λb*πQ*πE
0.00680
From the
chart in
P.
11-2 of the
MIL-HDBK217F [3] we
can determine
this value as
the regulators
are operating
on fixed
ground
(G_sub_F).
From the
chart in P. 112 of the MILHDBK-217F
[3] we can
also
determine the
quality level
as the
regulators fall
in the group of
power
transformer
and filters.
From the
lecture notes
[6], we use 1 /
λp to calculate
the men time
to failure.
MTTF(yrs.) =
(1 / λp)/
(8760 hrs in a
year)
5.60000
0.06000
2.00000
2.00000
0.25790
0.08154
12,264,270.90
1,400.03
0.00680
5.60000
0.06000
2.00000
5.00000
0.25790
0.20384
4,905,708.36
560.01
0.00680
5.60000
0.06000
2.00000
10.00000
0.25790
0.40769
2,452,854.18
280.01
From spec. [5]
the maximum
junction
temperature is
150ºC. This
chip is in the
category of
digital MOS
so from P. 513 of the MILHDBK-217F
[3] we can
find the
constant.
As this chip is
a 108 pin nonhermetic IC
from P. 5-14
of the MILHDBK-217F
[3] we can get
the package
failure rate.
From the
chart in
P.
15-5 of the
MIL-HDBK217F [3] we
can determine
this value as
the chip is
operating on
fixed ground
(G_sub_F).
The quality
level for this
chip is not
available in
the MILHDBK-217F
[3] as this is
not a military
specificated
part. So the
average value
for a CPLD is
taken.
The chip is of
a third
revision it has
been in
production
since 1998.
From the
equation on
P. 5-15 we
can calculate
the learning
factor
constant for
this part.
From the
lecture notes
[6], we use 1 /
λp to calculate
the men time
to failure.
MTTF(yrs.) =
(1 / λp)/
(8760 hrs in a
year)
The data
sheet for the
MAX831 and
MAX832 [4]
don't state the
junction
temperature
range for the
chips so
related DCDC step down
converters
from National
Semiconducto
rs were
chosen to
model the
MTTF for
these chips.
Xilinx CPLD
block
XC95108
Quality
Rating of "2"
Quality
Rating of "5"
Quality
Rating of
"10"
This chip has
2400 gates ~
4 transistors /
gate ~ 9600
transistors
therefore falls
into the
category of
5,001 to
20,000 gates.
This value is
found in P. 53 of the MILHDBK-217F
I-1
This are the
failures per
10^6 hours of
operation.
This are the
failures per
10^6 hours of
operation.
4,324.06
ECE 477 Final Report
Fall 2004
[3].
RGB to NTSC
conversion
block
AD724
USB
controller
block
SL811HS
Quality
Rating of "2"
0.29000
0.98000
0.00720
2.00000
2.00000
0.36598
0.21856
4,575,334.47
522.30
Quality
Rating of "5"
Quality
Rating of
"10"
0.29000
0.98000
0.00720
2.00000
5.00000
0.36598
0.54641
1,830,133.79
208.92
0.29000
0.98000
0.00720
2.00000
10.00000
0.36598
1.09282
915,066.89
104.46
An
assumption
was made in
this field. It
was assumed
that the
number of
transistors
was between
30,001 and
60,000 due to
the internal
amplifiers.
From page
P.5-3 of the
MIL-HDBK217F [3] the
die complexity
constant for a
MOS device
can found.
0.08000
The junction
temperature is
not specified
in the chip's
data sheet [6]
so it was
assumed to
be the
average =
85ºC. From
P.5-13 of the
MIL-HDBK217F [3].
As this chip is
a 16 pin nonhermetic IC
from P. 5-14
of the MILHDBK-217F
[3] we can get
the package
failure rate.
From the
chart in
P.
15-5 of the
MIL-HDBK217F [3] we
can determine
this value as
the chip is
operating on
fixed ground
(G_sub_F).
The quality
level for this
chip is not
available in
the MILHDBK-217F
[3] as this is
not a military
specificated
part. So the
average value
for the video
converter is
taken.
From the
lecture notes
[6], we use 1 /
λp to calculate
the men time
to failure.
MTTF(yrs.) =
(1 / λp)/
(8760 hrs in a
year)
3.10000
0.13000
2.00000
2.00000
0.73699
0.74878
1,335,502.47
152.45
0.08000
3.10000
0.13000
2.00000
5.00000
0.73699
1.87195
534,200.99
60.98
0.08000
3.10000
0.13000
2.00000
10.00000
0.73699
3.74391
267,100.49
30.49
Quality
Rating of "2"
Quality
Rating of "5"
Quality
Rating of
"10"
I-2
The chip has
been in
production
since 1999.
From the
equation on
P. 5-15 we
can calculate
the learning
factor
constant for
this part.
This are the
failures per
10^6 hours of
operation.
ECE 477 Final Report
Fall 2004
Maximum
junction
temperature is
of 125ºC and
minimum
junction
temperature is
of -40ºC. By
looking at P.
5-3 of the
MIL-HDBK217F [3] we
can model
this chip as a
MOS device
with 3,00110,000
transistors.
From spec. [7]
the maximum
junction
temperature is
125ºC. This
chip is in the
category of
digital MOS
so from P. 513 of the MILHDBK-217F
[3] we can
find the
constant.
As this chip is
a 28 pin nonhermetic IC
from P. 5-14
of the MILHDBK-217F
[3] we can get
the package
failure rate.
From the
chart in
P.
15-5 of the
MIL-HDBK217F [3] we
can determine
this value as
the chip is
operating on
fixed ground
(G_sub_F).
The quality
level for this
chip is not
available in
the MILHDBK-217F
[3] as this is
not a military
specificated
part. So the
average value
for the video
converter is
taken.
The chip has
been in
production
since 2001.
From the
equation on
P. 5-15 we
can calculate
the learning
factor
constant for
this part.
Best Case
Scenario
Worst Case
Scenario
I-3
This are the
failures per
10^6 hours of
operation.
1.42
6.99
From the
lecture notes
[6], we use 1 /
λp to calculate
the men time
to failure.
MTTF(yrs.) =
(1 / λp)/
(8760 hrs in a
year)
704184.3111
80.38633688
142963.0621
16.31998426