I have been working on adding additional features, and am finally done with them.
* 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!)