logo
navigationGo.pngQuick Navigation
allprojects32.pngAll projects
hardware32.pngHardware
links32.pngLinks

favoriteStar32.pngTop projects
Alan numitron clock
Clapclap 2313/1386
SNES Pi Webserver
USB Volume/USB toys
Smokey amp
Laser cutter
WordClock
ardReveil v3
SNES Arcade cabinet
Game boy projects
cameleon
Home Presence Detector

github32.pngGitHub
AlanFromJapan

navigationMail.pngContact me

alanfjmail.png
3flags.pngWho's Alan?


Akizukidenshi
Elec-lab
Rand Nerd Tut
EEVblog
SpritesMods
Switch-science
Sparkfun
Suzusho
Datasheet Lib
Reddit Elec
Ermicro
Carnet du maker (fr)
Marutsu
ATmel blog (defunct)

gameboy clock

kalshagar - Gameboy clock
nintendo-game-boy-icon.pngSee my other Gameboy related pages

Summary

gameboy_256.pngIdea is to use a gameboy to display time. If possible, even allow the gameboy to still play games (would be great). Why? Well... because it's nice, vintage, unique. And if you're fed up with my nth project with clock (I won't blame you) as long as we control the screen you can connect to internet and read the news, tweets, or show the weather info (though looking by the window works too). That's most likely how it would end up anyway. But you can't deny the definite geekiness and uniqueness (at last a good argument) of the result.

How to

Among the multiple options that exist I see two, and I will most likely try them in the following order:

(1) Hacking the screen signal

That might sound a bit convoluted but even without a cartridge the gameboy shows the black boc and the does the da-ling sound. Means cpu runs, does a bit of ROM magic and what we want: it displays stuff on the screen. Means it draws the screen at 60Hz! There are a few signals involved, but basically:
  • Data0 and Data1: because each pixel is a 4 color pixel
  • Clock: for the pace
  • Horizsyn: when you change line
  • Vertsyn: when you change page
Talking about the protocole there is one link that talks about it here. I will just hijack the data lines and inject my video signal.

(2) Making my own "game"

Hardware is doable, I saw some samples. You need a pcb with the correct padding (can be found on internet or made with eagle), put an eeprom on it (like 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.

[Option 1] Hacking the screen signal

Theory

Invaluable resource : https://flashingleds.wordpress.com/2010/10/26/intercepting-the-gameboy-lcd/
gameboyconnector_pinout.png
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):

Screen details

lines
160 px
pixels per line
144 px
freq
60 Hz
lines per sec
9,600 lines/sec
pixels per sec
1,382,400 px/sec
image size
23,040 px
one pixel info
2 bits
one image size in mem
5,760 bytes

Modus operandi

  1. Begining of screen: every 60, sacrifice one to do background job (get latest time info, prepare the display somewhere in memory). Other 59 times:
  2. Start of line : get ready to spit the line data: get the memory point at the right place, get the first byte
  3. For each pixel of the line: change the status of D0/D1 and fetch next byte of data when needed

Hardware

Gameboy side

(The connector for the screen ribbon is this one)
  • Cut carefully the data0 and data1 lines (add image here), and get 4 wires : 2 original ins from the CPU, 2 outs to the screen
  • Solder wires to get the clock, vsync an hsync signals (should be all for now)
  • Redirect all the signal outside the GB for the time being and avoid stress on the connectors. I will be easier to connect to the development display module.
gameboy_pins_timing1.PNG
Sample of Data1, Data0, Clock and hSync
gbscreen_vsync.PNG
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
gbscreen_scanoneline.PNG
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).

Display control module

Speed
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.
CPU
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/

Software

Let's work with interrupts: clock, hsync, vsync. What crystal speed required? We saw earlier it needs 1.5 Mhz min, so let's go with 16Mhz and we'll check how to optimize later. Main point here is to go with interrupts so that the program can do other stuffs while it still paints the screen in the background. We could wire the buttons, the sound and even make games (everybody catches the irony of such a convoluted solution just to avoid writing a Gameboy game?)... so we'll go with a simple "read the RTC" as a start. We'll need also to generate the image in memory and store it there.

[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

[Option 2] Making my own game

See dedicated project : Gameboy homebrew cartridge.

Links

Internal

External

Hackaday :
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 - 2017])