This is an easy and straight forward mapping, but has its own problems such as when the screen is densly populated, the tone diversity is low. Due to the nature of game of life, we usually do not have many cells in a row, so the higher order tones will seldom be played.
To address this problem, we remapped the tones using the lower order bits. So if we have the same situation of the 15 cells a row and 4 tones, the mapping will look like the following:. This mapping ensures more evenly distributed mapping of the tones so all tones will be played with relatively equal chance.
This mode is same as Mode 1 in tone mapping but we added some randomness to tone playing i. The probability a tone is played is determined by the live cell count over total cell count. So this adds more randomness to the mapping. The mode sound most interesting when there are more live cells. In this mode, the scan bar is fixed at one position. The length of the tone and the speed of playing are still determined by the speed of the scan bar if it is moving.
The tone mapping is same as mode 1. Similar to mode 2, there is randomness in whether the note is going to be played using the same scheme. Mode 4 is same as Mode 3 but does not have the randomness, so a note will always be played. Interestingly, just fixing the bar and letting the evolving of Game of Life evolve to determine the tone sounds most interesting.
As mentioned earlier, initially we had intended to use the NIOS to control a separate user interface on the screen possibly run out of SRAM , however as our design progressed we decided that the UI wasn't necessary or particularly useful. That being the case, we decided to keep the NIOS but just to use it for processing keyboard input and sending appropriate control signals to other hardware modules.
Using the NIOS for this task gave us added flexibility in designing and testing, as we could quickly modify different timing parameters and key mappings without needing to re-compile the entire hardware design.
Once a new key press is read, the value is passed into a switch statement which decodes the event type and sets the corresponding signals. One of the main problems that we encountered during debugging was an intermitent jittering and tearing of the image.
The problem appeared to increase in severity i. The problem seemed to appear and re-appear even after changing lines of code that were unrelated to creating the image.
For this reason, we believed that the problem was rooted in the place and route performed by the compiler. More specifically, we thought that sometimes the VGA controller was placed and routed in such a way that it didn't meet its critical timing deadlines for VGA monitor.
About halfway through the project, we discovered that changing the clocking on the M4K memory which was read by the VGA controller from negative edge triggered to positive edge triggered seemed to resolve the problem. However, after another week or so of testing and development the problem seemed to re-appear. Again we tried switching the clocking back to the negative edge and the problem disappeared.
From ths point forward, we didn't see any evidence of the jitter problem even as we continually re-compiled our design. In the future, this problem could probably be permanently fixed by using the Chip-Planner tool built into Quartus to fix the VGA Controller in a position that will minimize propogation delays along routes.
Earlier in our testing, we found that sometimes after we re-compiled the entire design, the NIOS processor wouldn't respond to keyboard input and in fact would occasionally send what appeared to be random characters to the JTAG terminal. With Bruce and Darbin's help, we discovered that Quartus was missing the timing constraints file a critical warning which we had naively been ignoring. After we generated this file and re-compiled, the problem disappeared.
At points in our project, the Altera monitor would successfully download the design onto the FPGA, however when we tried to load code onto the processor, it would error saying that not processors were detected.
After this precise sequence the Altera Monitor would successfully find the processor and load our code. Another problem we noticed throughout the project was that different VGA monitors displayed our UI and Automonaton better than others.
More specifically, we noticed shifting of the image not to be confused with jitter or tearing on some monitors but not on others. Simply using the auto-set feature or repositioning the image manually sometimes resolved the problem, however often times it wouldn't. For example, on some monitors the vertical borders would be displayed so far apart that both could not simultaneously fit on the screen. This problem could be resolved by tweaking the addressing so as to tune the system for the monitor, however we never found a solution that worked equally well on all monitors.
Our final design successfully displayed Conway's Game of Life on a VGA screen, allowed the user to add, draw and remove objects on the paused screen, add up to 3 scan bars which produced musical tones as they hit each line of cells and choose among 5 tone mappings to produce differents types of music.
The automaton was displayed without glitching and the evolution rate could be increased passed what was perceptable to the eye. Other than the intermittent glitching problems, which were not present in the final version of our design, we didn't discover any accuracy problems.
To our knowledge, our project doesn't pose any safety concerns. Our simple keyboard interface made interacting with and controlling both the automaton and music generation very simple and intuitive.
Our design did not make use of any external transmitters or other devices that produced substantial radiation. We are not aware of any interface issues created by our design. Our design was capable of filling the screen with random cells when the user pressed the "r" key while paused :. Once populated with cells, up to 3 scan bars could be added to the screen, each producing independent notes:.
The user is able to add a variety of objects to the screen while paused. An example of 2 glider guns is shown below:. One particularly interesting pattern was formed by dropping in an "x" on the screen by hitting the "x" key. A few steps of it's evolution are shown below:. Our final design met most of our initial expectations for the project.
We implemented Conway's Game of Life and gave the user a few options for producing "music" from it. In addition, we had enough time to add features that make the Game of Life itself more fun and amusing to play with i. The design didn't have any major bugs that we were aware of and was generally easy to control and produced a wide range of "music" depending on the mapping and initial conditions.
Given more time, we likely would have investigated more mapping schemes and or tone generation methods. More specifically, we think it would have been very insteresting to produce.
Additionally, we made use of the Megawizard functionality built-in to Altera's Quartus software package for instantiated our main video memory and PLL's used for generating clock signals to the audio codec and VGA controller.
Finally we used the VGA controller and Keyboard controller modules developed by Skyler Schneider , a previous student. We'd like to thank Bruce for helping us to develop this idea and turn it into an interesting project, and both Bruce and Darbin for assisting us with debugging in particular with our video jitter problems. In addition, we'd like to thank Altera for providing the DE2 boards.
Pages People more options. Direct Digital Synthesis Block Diagram. The game is now ready to begin, and this involves advancing through time one step at a time. A cell's fate depends on the state of its 8 closest neighbours our grid utilises wrapping, meaning a cell on the far left is thought of as a neighbour of a cell on the far right, and the same principle applies at the top and bottom.
Those 4 seemingly simple rules can result in wildy differing sequences. Sometimes an initial state will create an unpredictable, chaotic sequence. Other times, it will create a repeating sequence such as the glider, pulsar, and spaceship from the preset dropdown. The Luhn algorithm was created by Hans Peter Luhn and is a way of creating a simple checksum for a number.
This algorithm, also known as the mod 10 algorithm, is used in a wide variety of applications but is commonly associated with credit card numbers.
If you look at the numbers on the front of your credit card the last digit on the right is the checksum. An algorithm is done on the other numbers and if the checksum is the same then the number is considered valid. Outside of credit card numbers, the Luhn algorithm can be used to create a checksum on any number that you want to store. It is especially handy when you want to give users a number that they will be hand typing into a computer.
The checksum helps spot any errors in typing in the number before that number is processed. The good thing about the Luhn algorithm is that it doesn't matter how long the number is so it will work with any kind of digit sequence. I had an issue I was trying to debug today and needed a way to swap between different versions of composer.
Composer is one of the few things that I install globally so it was locked at a particular version on the machine I was using. There has been some significant changes between version 1 and version 2 and it isn't quite safe to use a composer 2 package on a platform that has composer 1 installed.
As some projects I'm working on haven't been upgraded yet I needed a way to swap between versions whilst this work was being done. As another step up from the game of snake I created in my last post I decided to try my hand at creating a side scrolling shooter. A side scrolling shooter, if you didn't already know, moves a scene from right to left across the screen with enemies moving with the scene towards the player's ship, which is on the left hand side of the scene.
The player can fire bullets towards the enemies so remove them from the scene. Share this Tweet this Share this I was saddened to hear of the passing of the Mathematician John Horton Conway today so I decided to put together a post on his 'game of life' simulator.
The rules of the game taken from wikipedia are as follows. Any live cell with fewer than two live neighbours dies, as if by underpopulation. Any live cell with two or three live neighbours lives on to the next generation. But I recently saw a very clever one by Patrick Mineault. Instead of churning through the whole grid of cells in a big slow ActionScript loop, he hands off the problem of counting up neighbors to an image convolution filter.
That lets the Flash player - maybe even the graphics hardware - do the work, instead of ActionScript. That's so clever I just had to try it out for myself.
0コメント