GameOfLife_ht1632c_display_AVR

I made a virtualization/simulation of this hardware device, which runs in a browser using Processing.js or in Java via the Processing IDE.

Link to the online web page simulation:

http://emdarcher.github.io/processing_GameOfLife_simulation/

Link to the github repo with the simulation code:

https://github.com/emdarcher/processing_GameOfLife_simulation/

here is the video:

link:

http://youtu.be/nCIYj61XwAQ

According to the link for this project. I must be project number 2048 on Hackaday Projects! If you look at the number in the link.

This is pretty crazy to figure out, after just recently finding out that my program compiles to exactly 2048 bytes, for a AVR ATtiny26 which has exactly 2048 bytes of flash program memory. I am also having a strange incling to play the 2048 game now as well...

Is 42 really the answer to life the universe and everything? Or is it 2048 now.

What has just happened?

I have decided that this project is mostly done electronics-wise (and probably code-wise since flash is full). So in this decision, I concluded that I sould solder up the circuit I have been prototyping into a more permanent form on a scrap of protoboard, so I did so ( but a made a non-fatal mistake soldering the button, easily fixable though ). The picture (very blurry due to horrible old camera and macro setting) has been added to the set up pictures in the project. Also updated the cover photo to show the display and protoboard circuit in action, uncovered, with no case. Next addition is to make a really awesome enclosure later when I have time, possibly made out of wood, plastic (lego maybe?), or just some cardboard ( most likely ).

I have been working on adding additional features, and am finally done with them. 

ADDITIONAL FEATURES:
---------------------

* There is a button connected to PB6 of the ATtiny26, which triggers external interrupt INT0 which can reset the display if the spectator desires to do so. Using this button with INT0 is optional, and can be disabled by clearing `DO_YOU_WANT_BUTTON_INT0` to `0` in `main.c` before compiling.

* There is the option to have a potentiometer or other analog sensor (photoresistor/LDR perhaps?) connected to PA7 (ADC6) to control the PWM brightness setting of the ht1632c-based display! This is also optional, and can be disabled by clearing `DO_YOU_WANT_ADC6_INPUT_TO_HT1632C_PWM` to `0` in `main.c` before compiling.

* At startup, when PB6 doesn't have INT0 or it's internal pullup enabled yet, the `init_srand(void)` function takes the lower byte of the floating ADC value on ADC9 (on PB6), which should have a bit of interference. It then feeds this byte into C's `srand()` function to seed the Pseudo Random Number Generator `rand()`, which is used later to put a "random" pattern onto the display when the Game of Life resets in the `reset_grid(void)`. This is to make it have a hopefully different set of random patterns every time you reboot/reset the MCU.

* If using INT0 for the button on PB6, and the ADC6 input on PA7, the code compiles to **exactly 2048 bytes!**. This isn't exactly a feature but is pretty interesting (the ATtiny26 only has 2048 bytes of flash! So be careful with changes to the code, or it may compile to be too big to fit in the ATtiny26! If unsure, type `make size` using the included Makefile to find out flash and ram usage). This may change later if I put some constants into EEPROM instead of PROGMEM (flash), but reads from EEPROM are slower than flash, so I probably won't change that unless I have to. The code can surely be better optimized ( I did as much as I could ), so feel free to do so. (compiler flags were a miracle as well, the `--combine -fwhole-program` gcc flags helped shave off many bytes!)

Prototype runs fine on the STK500 and when built on a breadboard. Code is now running and not crashing for many hours.