Alan numitron clock
SNES Pi Webserver
USB Volume/USB toys
SNES Arcade cabinet
Game boy projects
Home Presence Detector
Rand Nerd Tut
Carnet du maker (fr)
ATmel blog (defunct)
See my other Gameboy related pages
here), setup a tool chain and uploader and write a small program. That looks doable, but requires much more preparation than the bitbanging approach of injecting signal.
Another one http://www.bradsprojects.com/gameboy-to-vga-converter-in-progress/
And special thanks to this gentleman who inversed his gameboy display and kindly shared his technique http://blog.gg8.se/wordpress/category/mods/
Some other guys who did again (so much for my hoped originality):
Sample of Data1, Data0, Clock and hSync
Sample of one VSync: vsync is up for a looooong time (the whole first line) and you can detect as when the Clock ↓ AND HSync up AND VSync up
Top-bottom: hsync, data0, data1, clock. That's one line of the black box displayed when Gameboy is on with no cartridge. Look at data lines: a little white, all black, and 2 black pixels (part of the ® symbol).
We need a bare minimum of give or take1.5 Mhz (60 Hz x 160 lines x 144 px/lines = 1,382,400 instructions). But each instructions will require preparation, just to get the pixel color out of memory if we put a static image, some control logic and yes, read the time from the RTC. Let's say that we sacrifice the last image per second to read the RTC and do some magic preparation, it gives us 16 ms of time to do background tasks. At 4Mhz that's more than 66k%20 instructions, that's more than enough. So we can start with an internal oscillators RC of 8MHz.
Hum, you guessed it, it will be an ATmel because (1) that's the one I feel more comfortable with, plus I have lots of them (2) I just need 3 interrupts input and 2 pins output, that sounds like a mission for attiny2313. Since I won't be able to reuse the VRAM of the gameboy, I will wether generate the image on the fly or use a bit of RAM on the side : generate and store during the 60th frame and just fetch and draw the rest of the time.
One image in 4 levels of gray is 5,760 bytes.
Maybe this RAM chip: 300 JPY for 5 of them holding 256kb http://akizukidenshi.com/catalog/g/gI-01461/
[After theory now experimentation]
... and that's where things go south. You saw it coming? Not me, though I should have had since I had the same problem with my SNES cabinet when I emulated the controllers: I don't have enough cycles!
We need to spit pixels at 1.5 MHz, let's say 2 for the calculation. CPU runs at 16 MHz so means I have a luxurious 8 cycle per pixel... FYI just going IN and OUT of an interrupt if 4 cycles, leaving 4 cycles per pixel... that's very short. I tried a hybrid version that is an interrupt for the line start and after is just timed as fast as possible, I get an image but "stretched" horizontally. Of course, I can't keep up so the screen reads many time the same data on the D0/D1 lines.
Not 100% dead end, but a big bump though.
TODO code on google code
Gameboy homebrew cartridge.
All content on this site is shared under the MIT licence (do what u want, don't sue me, hat tip appreciated)
electrogeek.cc ~ Formerly known as Kalshagar.wikispaces.com (AlanFromJapan [2009 - 2019])