ESP8266 for Uzebox(Open Source Game Console)
Posted: Wed Dec 31, 2014 1:41 pmHello everyone,
This is my first post, and I would like to say thanks for the wealth of information this site provides; this is clearly the only good source for anything and everything ESP8266!
I'll give a quick overview of history/research to put my questions into perspective. Uzebox is an open source game console that has been around since 2008 with something around 100 games/demos made for it so far. It is based on an ATmega644 8bit microcontroller overclocked to 28.636mhz(8 times NTSC frequency) with 64k flash and 4k ram. It interfaces with NTSC televisions with minimal additional circuitry, and so the MCU must bit-bang out all pixels for every NTSC field at ~60hz. You can probably see the challenges with meeting a 60hz interrupt that generates scanlines for a display, and in fact the MCU spends the vast majority of it's time pushing out pixel values and only has a fraction of cycles available to do anything else(mix sound, render sprites, run game logic, etc.). The idea to have internet multiplayer games(in a manner similar to how kaillera/mame/emulators do it perhaps) has been kicked around for at least 5 years, but no one really found the right chip to start working with. Obviously people here know the reasons why the ESP8266 is more promising than other chips on the market or they wouldn't be here. There has been quite a bit of excitement since initial experiments using it, and most everyone is convinced that this chip is the answer. We are designing solutions that implement it and it's likely it could be part of the multiple official kit versions(US and European television variants) at some point.
So forgive me, I am just going to rattle off a bunch of question and statements and I would really appreciate all ideas and comments on the matter. Right now this is one of the versions being considered because it has a lot of GPIO that might be useful in the future and it will solder very low profile onto another board. If we don't end up needing all those pins in the future it would of course be preferable to use a cheaper version. There is an expansion port on the console that has multiple unused pins for the MCU available and the prevailing idea is to use a daughterboard connected to these pins and have an ESP8266 soldered onto that. The expansion port only has 5v VCC and all i/o pins are also 5v level, so we pretty much need a board no matter what for level conversion and a regulator to give a good source of 3.3v to the chip. Here is the thread on that if anyone is interested. I haven't found any version that accepts both 5v VCC AND 5v i/o, but experimentation shows that using 5v i/o hasn't killed my version 2 yet.. Any suggestions that might be helpful here, seeing as we are looking for the cheapest solution requiring the least amount of components?
The other major hurdle we have been worried about is the UART interface. Since internet data can come at any time and be directly put out to the serial lines it can't work directly hooked up to the console. The console gets interrupted at 60hz and must finish drawing the frame so any data coming out serial would get lost very frequently. There is also very little free cycles to sit around and poll for new serial data. When we first started thinking about this it didn't appear there was any working solution to use this device as an SPI slave which would be the most ideal solution. So we investigated using a separate MCU on the daughterboard that would have time to listen for serial data but also could be interrupted(quickly between bytes) and send received data to the console in the very small time window that is available. The estimated amount of data is currently sending 2 bytes every 1/60 second or ~17ms, and also receiving 2 bytes in that same time period. These 2 bytes are simply a 16bit value that represents the state of the local gamepad and the remote gamepad(simple lock-step networking is all we have the resources for). Only fairly recently I have seen anyone say they have a working solution for SPI slave but I haven't got that to work yet. So that paragraph is either a statement or a question, I am not even sure
I see that many people are managing to make their own custom firmware for the chip and that the onboard MCU seems quite powerful. I have not yet managed to build a custom firmware yet, but it would be very ideal to not require an extra MCU to buffer data for us and it appears it would be no problem for the 40mhz MCU onboard if properly programmed. So far I am using some official firmware to successfully communicate over the internet with the custom socket based master server(which keeps a list of all running game servers) but have to turn off frame rendering to do so. I want to pick everyone's brain here who is knowledgeable, because there really is a LOT of information available and it can be a bit overwhelming. Thanks for reading this rather long post!
This is my first post, and I would like to say thanks for the wealth of information this site provides; this is clearly the only good source for anything and everything ESP8266!
I'll give a quick overview of history/research to put my questions into perspective. Uzebox is an open source game console that has been around since 2008 with something around 100 games/demos made for it so far. It is based on an ATmega644 8bit microcontroller overclocked to 28.636mhz(8 times NTSC frequency) with 64k flash and 4k ram. It interfaces with NTSC televisions with minimal additional circuitry, and so the MCU must bit-bang out all pixels for every NTSC field at ~60hz. You can probably see the challenges with meeting a 60hz interrupt that generates scanlines for a display, and in fact the MCU spends the vast majority of it's time pushing out pixel values and only has a fraction of cycles available to do anything else(mix sound, render sprites, run game logic, etc.). The idea to have internet multiplayer games(in a manner similar to how kaillera/mame/emulators do it perhaps) has been kicked around for at least 5 years, but no one really found the right chip to start working with. Obviously people here know the reasons why the ESP8266 is more promising than other chips on the market or they wouldn't be here. There has been quite a bit of excitement since initial experiments using it, and most everyone is convinced that this chip is the answer. We are designing solutions that implement it and it's likely it could be part of the multiple official kit versions(US and European television variants) at some point.
So forgive me, I am just going to rattle off a bunch of question and statements and I would really appreciate all ideas and comments on the matter. Right now this is one of the versions being considered because it has a lot of GPIO that might be useful in the future and it will solder very low profile onto another board. If we don't end up needing all those pins in the future it would of course be preferable to use a cheaper version. There is an expansion port on the console that has multiple unused pins for the MCU available and the prevailing idea is to use a daughterboard connected to these pins and have an ESP8266 soldered onto that. The expansion port only has 5v VCC and all i/o pins are also 5v level, so we pretty much need a board no matter what for level conversion and a regulator to give a good source of 3.3v to the chip. Here is the thread on that if anyone is interested. I haven't found any version that accepts both 5v VCC AND 5v i/o, but experimentation shows that using 5v i/o hasn't killed my version 2 yet.. Any suggestions that might be helpful here, seeing as we are looking for the cheapest solution requiring the least amount of components?
The other major hurdle we have been worried about is the UART interface. Since internet data can come at any time and be directly put out to the serial lines it can't work directly hooked up to the console. The console gets interrupted at 60hz and must finish drawing the frame so any data coming out serial would get lost very frequently. There is also very little free cycles to sit around and poll for new serial data. When we first started thinking about this it didn't appear there was any working solution to use this device as an SPI slave which would be the most ideal solution. So we investigated using a separate MCU on the daughterboard that would have time to listen for serial data but also could be interrupted(quickly between bytes) and send received data to the console in the very small time window that is available. The estimated amount of data is currently sending 2 bytes every 1/60 second or ~17ms, and also receiving 2 bytes in that same time period. These 2 bytes are simply a 16bit value that represents the state of the local gamepad and the remote gamepad(simple lock-step networking is all we have the resources for). Only fairly recently I have seen anyone say they have a working solution for SPI slave but I haven't got that to work yet. So that paragraph is either a statement or a question, I am not even sure
I see that many people are managing to make their own custom firmware for the chip and that the onboard MCU seems quite powerful. I have not yet managed to build a custom firmware yet, but it would be very ideal to not require an extra MCU to buffer data for us and it appears it would be no problem for the 40mhz MCU onboard if properly programmed. So far I am using some official firmware to successfully communicate over the internet with the custom socket based master server(which keeps a list of all running game servers) but have to turn off frame rendering to do so. I want to pick everyone's brain here who is knowledgeable, because there really is a LOT of information available and it can be a bit overwhelming. Thanks for reading this rather long post!