Our project design is a laser alarm clock that projects the time onto any suitable screen, such as a wall or a projector screen. It uses fixed lasers that are pointed to a rotating mirror to reflect the laser beam onto a screen (similar to how a laser jet printer works).
The user can set a time for when they would like an alarm to go off by using a Nintendo 64 Controller At that set time, a sound will ring notifying the user that it's the specified time. To turn off the alarm, the user must enter in a random "Easter Egg" combination specified by laser display. The combination has three difficulty levels that the user can set (also using the Nintendo 64 Controller). Once the correct combination has been inputted, the alarm will be turned off.
Member Task Distribution
Ray Ray
- Constructing alarm setup
- Talking and reading from the N64 controller
- Generating an annoying alarm ring
- Synchronizing mirror rotation and bus clock
- Mapping laser characters
- Implementing hardware to put it all together
- Designing alarm functionality
- Using the rtc and interrupts to update the time
- Creating menu system for user settings
- Generating random easter eggs based on difficulty level
- Implementing software to tie it all together
Hardware Design
Our project implemented ASCII character conversion in hardware and laser calibration and timing in hardware. We did this using memory-mapped IO to store each character in the string. From there, we hardcoded the timings for each laser and for each character. Each laser had it's own timing offset for each character, and also an offset for general calibration. Timing was based on a signal received from a phototransistor fixed to the rotating mirror assembly. Our original idea was to use the phototransistor signal to create a fine-tuned rotation speed using pulse-width modulation, but it turns out that a strong enough signal could be used as the base of the laser timings and work well without needing to use PWM.
We also implemented N64 communication in hardware. N64 communication is Manchester encoded, so we divided each bit sent or received into 4 time segments and based the middle two on the bit being sent or received. We used a shift register to basically shift data out and another one to store what was being received.
We also implemented the alarm sound in hardware. Our first idea was to use the DAC to drive a speaker, but upon seeing the simplicity of an alarm sound, we just used a hardware counter to drive a signal high or low, creating a square wave at 1 kHz that turns on and off with a period of 1 second when the alarm is activated. We then sent this signal to an op-amp to amplify the signal to be high enough to drive a speaker.
Software Design
The main part of the software was creating this clock that would update every time a minute has passed. The time was displayed as “12:35 A” through hardware character mapping on the any screen. To create this clock, we used the real time clock off of the power pc that triggered an interrupt every second. When a full 60 seconds had passed, the display would get updated with the new time. As with any alarm clock, you can set the current time and alarm time. In addition, the user can also set the difficulty level for the easter egg key.
The main flow of the software was if a full minute had passed, then the time would be updated. Or if the time matches the set alarm time, then the alarm sound would ring and the display would relay instructions to the user as to how to turn off the alarm in terms of an easter egg combination. To generate this random easter egg, the user has to press start before seeing the easter key so that we could get a seed time for randomizing values.
We originally had all of functions that wrote to memory mapped io’s for hardware and all other functions implemented in assembly. After coming a across a lot of abi compliancy issues, we eventually switched all of functions to c which resolved our problem. Still, we had a lot of N64 timing issues when trying to detect the easter egg combination input because the loop would detect many button presses and also detect non-button presses as part of the input string. For the most part, we were able to fix this problem by putting in loops that wait until after a button lift to grab the data and then wait until another button was pressed before continuing. However, this greatly complicated the easter egg checking so eventually switched this to hardware.
