ESP32 emulating to be a cartridge Using the Game Boy as a remote control is a childhood dream of mine. Having it connected to the web was later on on the top of the list of things I wanted to have for this sweet machine. So that's what I'am aiming at: control stuff over the web with a Game Boy.
Or may be war driving with a Game Boy, controlling MQTT stuff and browsing http://retro.hackaday.com/ - depending how far I get.
WIFI Game Boy Cartridge | Infomercial: someone succeeded in creating a WiFi cartridge
2021-12-16 15:27:22
I've been recently contacted by Sebastian, asking me things about this project because he made a WiFi cartridge. We talked a bit about the hurdles I faced and now there's a video of his project out and here's a link to his blog post as well.
WIFI Game Boy Cartridge | Infomercial: someone succeeded in creating a WiFi cartridge
2021-12-16 15:27:22
I've been recently contacted by Sebastian, asking me things about this project because he made a WiFi cartridge. We talked a bit about the hurdles I faced and now there's a video of his project out and here's a link to his blog post as well.
WIFI Game Boy Cartridge | Soldered a prototype, found a bug
2019-12-14 14:58:34
Finally decided on soldering a PCB and when I programmed it, it wouldn't start the program afterwards. So I was calling for help on twitter and got some well meant advices about pulling certain pins that no ESP32 dev board pulled up. It took me a while to notice that I was missing the capacitor in my reset circuit. I didn't check what C6 actually does while debugging, so I thought being so close to the ESP reset pin and resistor, that it was part of it. With a bodged on capacitor it now resets to run the program!
So far it's only a cartridge shaped ESP dev board that can talk to 5V devices, but it's good to know this is programmable!
WIFI Game Boy Cartridge | Soldered a prototype, found a bug
2019-12-14 14:58:34
Finally decided on soldering a PCB and when I programmed it, it wouldn't start the program afterwards. So I was calling for help on twitter and got some well meant advices about pulling certain pins that no ESP32 dev board pulled up. It took me a while to notice that I was missing the capacitor in my reset circuit. I didn't check what C6 actually does while debugging, so I thought being so close to the ESP reset pin and resistor, that it was part of it. With a bodged on capacitor it now resets to run the program!
So far it's only a cartridge shaped ESP dev board that can talk to 5V devices, but it's good to know this is programmable!
WIFI Game Boy Cartridge | Let's do some test boards
2019-02-08 10:12:03
I'm scared of that rats nest of wires on a breadboard that is hidden in a box. Thanks to some experience I gained with using IO0 and IO2 as a regular pin, I know that it's okay to use them as the missing two address line pins. I might steal one of them back to be able to reset the game boy, as I don't think using one of the serial pins is a good idea, especially if you want to have a serial debug terminal ;)
With less address pins the programs written / compiled for should adjust memory bank switching for smaller banks. I think that's doable.
Not sure if I said this here, but I was able to run the I2S parallel code on the ESP32 and that gave me hope. After a lot of unexpected twitter feedback about groundplanes and copper tunges, I made some changes and this is what I came up with. Cleanly routed, doesn't fit any reproduction cartridges, but form follows function, right? There's even a 1M ohm connecting the usb connector shield to Ground (not even sure if this is 100% necessary, but better safe then sorry, right?
Power consumption of the ESP vs. 4 AA batteries inside a DMG or even worse - 2 AAA batteries inside a GB Pocket is still an issue with this board. The plan is to have one AAA LiPo added to a later revision of the board. To get an idea how this could look like, check out the Pokemon Pinball cartridge, or any Game Boy rumble cartridge for that matter. This design is supposed to be powered over USB, since it's a dev / debug board.
WIFI Game Boy Cartridge | Let's do some test boards
2019-02-08 10:12:03
I'm scared of that rats nest of wires on a breadboard that is hidden in a box. Thanks to some experience I gained with using IO0 and IO2 as a regular pin, I know that it's okay to use them as the missing two address line pins. I might steal one of them back to be able to reset the game boy, as I don't think using one of the serial pins is a good idea, especially if you want to have a serial debug terminal ;)
With less address pins the programs written / compiled for should adjust memory bank switching for smaller banks. I think that's doable.
Not sure if I said this here, but I was able to run the I2S parallel code on the ESP32 and that gave me hope. After a lot of unexpected twitter feedback about groundplanes and copper tunges, I made some changes and this is what I came up with. Cleanly routed, doesn't fit any reproduction cartridges, but form follows function, right? There's even a 1M ohm connecting the usb connector shield to Ground (not even sure if this is 100% necessary, but better safe then sorry, right?
Power consumption of the ESP vs. 4 AA batteries inside a DMG or even worse - 2 AAA batteries inside a GB Pocket is still an issue with this board. The plan is to have one AAA LiPo added to a later revision of the board. To get an idea how this could look like, check out the Pokemon Pinball cartridge, or any Game Boy rumble cartridge for that matter. This design is supposed to be powered over USB, since it's a dev / debug board.
Me: I have this project idea: #WIFI Game Boy Cartridge - I was a bit naive when I started this, tried to toggle pin for pin but it was way too slow. Would/could this work with the I2S parallel interface? I wasn't able to find much on the I2S interface when I started this and what I found was above my skill set, but I still like the idea of having a cartridge that has wifi.
Sprite_tm says:4:31 PM Ah, I saw that. Did something like that on a Vectrex with a CortexM4.
Sprite_tm says:4:32 PM Wrt the WiFi GB cartridge: Long story short, I don't thing I2S is the right way to go there.
Me: okay, any right ways?
Sprite_tm says:4:33 PM The issue mostly is that you need to see that a CS line goes low, then immediately read the address lines, look up whatever you want to send back and send it.
Sprite_tm says:4:34 PM I think that I2S would be too slow for that; you'd have to set up a transaction and everything. I think you could get it to work if you wrote a high-prio interrupt for the CS pin, then in the interrupt handler, in assembly, read the address GPIOs as fast as you can, grab a response from internal memory (which luckily you have more than enough of) and send that to the data pins.
Sprite_tm says:4:35 PM If you need help with that, poke me; by now I have some experience with high-level interrupts and I'm actually curious if the ESP32 can do it, but don't really have any interesting consoles here.
Me: I thought "as fast as I can" would be I2S, since there's no way of getting pins parallel
Sprite_tm says:4:37 PM You might get it to work... but there's a fair amount of setup using the I2S peripheral. It may still be quicker than doing it manually, I agree.
Sprite_tm says:4:39 PM @davedarko Maybe a good idea to move on to other qs... if there is still time at the end, I'd love to come back to it. For now, feel free to poke me at [mail] for this.
Me: I have this project idea: #WIFI Game Boy Cartridge - I was a bit naive when I started this, tried to toggle pin for pin but it was way too slow. Would/could this work with the I2S parallel interface? I wasn't able to find much on the I2S interface when I started this and what I found was above my skill set, but I still like the idea of having a cartridge that has wifi.
Sprite_tm says:4:31 PM Ah, I saw that. Did something like that on a Vectrex with a CortexM4.
Sprite_tm says:4:32 PM Wrt the WiFi GB cartridge: Long story short, I don't thing I2S is the right way to go there.
Me: okay, any right ways?
Sprite_tm says:4:33 PM The issue mostly is that you need to see that a CS line goes low, then immediately read the address lines, look up whatever you want to send back and send it.
Sprite_tm says:4:34 PM I think that I2S would be too slow for that; you'd have to set up a transaction and everything. I think you could get it to work if you wrote a high-prio interrupt for the CS pin, then in the interrupt handler, in assembly, read the address GPIOs as fast as you can, grab a response from internal memory (which luckily you have more than enough of) and send that to the data pins.
Sprite_tm says:4:35 PM If you need help with that, poke me; by now I have some experience with high-level interrupts and I'm actually curious if the ESP32 can do it, but don't really have any interesting consoles here.
Me: I thought "as fast as I can" would be I2S, since there's no way of getting pins parallel
Sprite_tm says:4:37 PM You might get it to work... but there's a fair amount of setup using the I2S peripheral. It may still be quicker than doing it manually, I agree.
Sprite_tm says:4:39 PM @davedarko Maybe a good idea to move on to other qs... if there is still time at the end, I'd love to come back to it. For now, feel free to poke me at [mail] for this.
Finally found the time and inspiration to work on this project again. To get the I2S demo of CNLohr working, I also needed to be able to compile with the esp-idf.
WIFI Game Boy Cartridge | Starting with esp-idf-v2.0
Finally found the time and inspiration to work on this project again. To get the I2S demo of CNLohr working, I also needed to be able to compile with the esp-idf.
WIFI Game Boy Cartridge | celebrations are in order
WIFI Game Boy Cartridge | precognition in a game boy?
2017-05-13 14:24:35
So I thought to myself, if the ESP is too slow, but the query itself is taking microseconds instead of nanoseconds: why not trick the ESP and spit out the next in array? here's what I got, admittedly one of the better results, but you can finally read something! I can live with it, if I can get it to work reliably.
WIFI Game Boy Cartridge | precognition in a game boy?
2017-05-13 14:24:35
So I thought to myself, if the ESP is too slow, but the query itself is taking microseconds instead of nanoseconds: why not trick the ESP and spit out the next in array? here's what I got, admittedly one of the better results, but you can finally read something! I can live with it, if I can get it to work reliably.
Seems like I'm 3us late with reading and preparing my response. The posted scan looks like it takes 175us from address change to address change. Putting it in relation, an EEPROM takes 150ns to respond, that's 1/20 of the time I have now. With 240MHz the ESP32 should have a clock cycle time of 4.16ns. Whaaaat? My math is broken. Seems like the maximum speed for gpios on the ESP is "quite" limited, max toggle freq is around 4MHz. https://www.esp32.com/viewtopic.php?f=2&t=1595&p=7482&hilit=parallel#p7482
Seems like I'm 3us late with reading and preparing my response. The posted scan looks like it takes 175us from address change to address change. Putting it in relation, an EEPROM takes 150ns to respond, that's 1/20 of the time I have now. With 240MHz the ESP32 should have a clock cycle time of 4.16ns. Whaaaat? My math is broken. Seems like the maximum speed for gpios on the ESP is "quite" limited, max toggle freq is around 4MHz. https://www.esp32.com/viewtopic.php?f=2&t=1595&p=7482&hilit=parallel#p7482
So from far away it looks alright! I checked every byte and the data is correct. But...
Look a bit closer and you see this:
It might make sense to give the ESP the control over the OE of the data pins, since it's not fast enough to react to every change on the fly, it might needs better timing.
So from far away it looks alright! I checked every byte and the data is correct. But...
Look a bit closer and you see this:
It might make sense to give the ESP the control over the OE of the data pins, since it's not fast enough to react to every change on the fly, it might needs better timing.
https://cdn.hackaday.io/images//2991131494677823376.jpg
Look a bit closer and you see this: 