This is mostly just to get some pictures up. I'm just getting this posted so I can try and refocus on thesis...I should be so easily sidetracked... Any future developments will be posted in the forum first...I'll post here as facts become more concrete.
The farthest I got with this setup was a man-in-the-middle setup (as shown below) where I could intercept the CPU's commands to the LCD passing them through the microcontroller and then to the LCD board. I had to move up to a ~11MHz crystal (not shown) on the microcontroller just to come close to allowing the signals to pass through unhindered. The best I managed was a slightly distorted picture...I'll need something faster to actually read the signals so I can reverse engineer them. I've also removed the GameBoy's oscillator so I could clock the GB at a slower speed. This did work but I haven't taken a ton of time to work on the coding side.
The goal when I can work on it again is simply to replace the CPU PBC outright. I will keep the LCD, Voltage Converter and Audio Jack PCBs interfacing them with a newer microcontroller. This would allow all manner of interesting hacks...I could use it as a wireless remote for things, a desktop clock w/ USB, get some emulated or custom games running...endless possibilities. For now I have to put it in a box and try to forget it.
The farthest I got with this setup was a man-in-the-middle setup (as shown below) where I could intercept the CPU's commands to the LCD passing them through the microcontroller and then to the LCD board. I had to move up to a ~11MHz crystal (not shown) on the microcontroller just to come close to allowing the signals to pass through unhindered. The best I managed was a slightly distorted picture...I'll need something faster to actually read the signals so I can reverse engineer them. I've also removed the GameBoy's oscillator so I could clock the GB at a slower speed. This did work but I haven't taken a ton of time to work on the coding side.
The goal when I can work on it again is simply to replace the CPU PBC outright. I will keep the LCD, Voltage Converter and Audio Jack PCBs interfacing them with a newer microcontroller. This would allow all manner of interesting hacks...I could use it as a wireless remote for things, a desktop clock w/ USB, get some emulated or custom games running...endless possibilities. For now I have to put it in a box and try to forget it.
 | |||||
| Test Setup | |||||
 |  | ||||
| LCD PCB Front | LCD PCB Back | ||||
 |  | ||||
| CPU PCB Front | CPU PCB Back | ||||
 | |||||
| Breadboard Setup | |||||
 |  |  |  | ||
| Audio Jack Front | Audio Jack Back | Voltage Converter Front | Voltage Converter Back | ||
Stumbled upon your blog while I was searching for info about the gameboy LCD. I'm attempting to do pretty much the same thing as you (ie. control the gameboy LCD with my own microcontroller). There's not much info out there and I think you've done really well to get as far as you have. Hope you haven't given up yet.
ReplyDeleteBTW, how did you connect the LCD ribbon cable to the breadboard wires? They look too small/delicate to solder and I can't tell from your photo how you attached them.
ReplyDeleteAlso are those some stuck pixels near the bottom left corner of your LCD? Were those the result of your experimentation? I'd like to avoid damaging my LCD if I can.
Nope I haven't given up, in fact I'll be attacking it again in a week or two. I just ordered a new logic analyzer to capture the signals the gameboy outputs after i get that data I'll be posting again. my first goal is to just figure out what the hell all the control lines do...
ReplyDeletei soldered the wire wrap wire directly to the ribbon cable. it is pretty delicate (and I really don't want to do it again...) but i left enough sticking out so that i can still plug the cable into the gb cpu board's socket (just melt a bit of the ribbon cable insulation and you can do the same). I also hot glued and taped them to the ribbon cable to secure them.
The other ribbon cable was soldered to the socket's connections (also a pain).
Hi Marc, I took some measurements with the back half of the gameboy while it was running a tetris cartridge.
ReplyDeleteI was able to confirm some of the pins on the ribbon cable.
Basically, I measured the oscillating frequency of some of the pins as well as the duty cycle. Here are some of the results:
Pin 12 is VERTSYN. This pin oscillates at 59.7Hz as expected (this is the refresh rate of the display).
Pin 14 is CLK. It oscillates at 1.38Mhz which is one third the CPU clock(?) Duty cycle was 17.5%
Pins 15 & 16 are DATAOUT1 and DATAOUT0. Their oscillating frequencies varied between 75kHz-110kHz. This is reasonable if these two bits are what makes up the 4 shade grayscale.
Pin 17 is HORSYNC. It oscillates at 8.6kHz which is exactly as expected if the display refreshes at ~60Hz and there are 144 scanlines (60*144).
I believe Pin 13 is ALTSIGL and Pin18 is DATALCH. This is based on what you've posted and cross referenced with Jeff Frohwein's schematic. Not sure if it is significant that Pin 18's frequency is around double Pin 13's. Also Pin 13's duty cycle is exactly 50% so it's a regular pulse at ~4.6kHz.
This leaves Pin 19, which by elimination must be CONTROL(?)
If you like I can email you the full set of results.
BTW your LCDHxx numbering makes sense to me and seems to fit. But your LCDVxx numbering doesn't seem to fit with Frohwein's schematic at all?
I think you're pretty close on those pins. The LCDVXX refers to the vertical axis ribbon cable (you have to pry the screen up to see it) it is very similar to the horizontal one that's visible. It has a chip-in-cable controller as well.
ReplyDeleteI have a hard time trusting Frohwein's schematic of the LCD board because it is obviously lacking certain parts and doesn't fully detail the circuit. So I tried to come up with explicit labels for everything that connects to the LCD. When I get a chance I might draw up a more detailed diagram of just the LCD board.
Oh, you can drop an email if you like (marc@robotdialgos.com), I'll toss it up when I start posting on this again. Or just post it to the forum I'm trying to dump the info into: http://gbdev.gg8.se/forums/viewtopic.php?pid=331#p331
ReplyDeleteI also happen to be working on this. I'm lucky to have found this blog post. Because I don't have a spare Gameboy at the moment (I ordered one), I'm currently taking another approach.
ReplyDeleteIf you look at the schematics for the Super Gameboy (http://www.devrs.com/gb/files/sgb.gif), you can clearly see that the elemental signals (data lines and sync lines) as wel as the latch and clock signals are connected to a special IC.
This IC, ICD2-R apparently receives the LCD data from the CPU and puts it in a format which can be passed on to the SNES.
Now what I'm gonna do is desolder this IC from the cartridge and put it on a seperate board with some jumpers and a microcontroller. Then I'll connect the board to the original pins, thus creating some form of in-circuit debugger.
I'll keep checking your blog as well to see if your approach yields any results.
c_rpg, sounds like a valid approach. Hope you get the info you (we) need. Please don't forget to post your findings even if they don't seem useful to you. It might help someone else move an extra step forward ;)
ReplyDeleteJust thought of something. According to the SGB schematic, the CONTROL and ALTSIGL pins aren't connected - probably not needed by the SNES. I think the signals on these two pins are important for the GB LCD.
I haven't desoldered the IC yet, but I've done some measurements on the signals as well. I've registered at the gbdev forums and have made a post over there.
ReplyDeletec_rpg/badut,
ReplyDeletegood to have some new voices on the issue. I'm still awaiting the logic analyzer, but I have dug out my GB and got my test rig up and running again. the only new thing i can add at this point is that pin 13 on the ribbon cable (altsig or datalch) doesn't effect the display (at least during boot up). It can be unplugged completely and not effect the screen. pretty much what i'd expect from a 4.6kHz clock (as far as we know)
Marc,
ReplyDeleteJust thought of something re your test setup. The problem you mentioned was that the "man in the middle" method wasn't working because your microcontroller wasn't fast enough. What if you connected the LCD directly to the gameboy CPU and used your uC to snoop on the bus line instead? Then your uC is free to sample as frequently as it is capable without affecting the GB CPU driving the LCD.
No substitute for a good logic analyser, but it could still give useful data.
"pretty much what i'd expect from a 4.6kHz clock"
ReplyDeleteThat's an interesting idea Marc. Here are my thoughts on the clock.
The LCD is 160x144 @ 60Hz. This means that every second, 160*144*60=1382400 pixels need to be refreshed.
This is what makes me think the LCD clock is in the order of Mhz frequency (ie. one clock per pixel).
If the clock is 4.6kHz, then the LCD needs to be capable of refreshing ~300 pixels each clock. This is possible but would probably require it to store ~300 pixels worth of data?
Still I wont rule anything out at the moment. The only signals I'm 99% sure about are the DATAOUT pins and VERTSYN. The rest are still open for discussion I reckon.
Oh, I wasn't claiming the 4.6kHz was the main lcd "clk" just that at 50% duty cycle it seems likely it is some kind of clk... I had another thought after that comment that the 4.6kHz signal might be used for some kind of (optional) interlacing which might explain why it has no effect when unplugged....
ReplyDeleteas far as the man in the middle stuff I did try exactly what you said, but my uC is a max 20MHz clk which is the same as the GB so it wouldn't be able to keep up with it at all if i let the GB go full speed. so at the moment I'm clocking the GB with my uC to slow things down. I just haven't been able to write robust data sampling code yet.
I will be working on this tonight i think so expect another post on this...
Thanks Marc,
ReplyDeleteGlad I found like minded people working towards the same goal.
Well I managed to get some data, but I don't trust it. I'm going to have to setup a simple protocol on top of my uC's serial protocol to insure data accuracy...it'll have to wait a few days though...i'll toss up the data anyways
ReplyDeleteThe data is in a csv, I would toggle clock (gb cpu clk) high , take eight readings, toggle low take eight readings, and on and on for a full frame and a half. It's a TON of data. I don't have a way to put it in a waveform (too big for excel)...any ideas?
https://docs.google.com/leaf?id=0B1wxSbWwqpqyNjA5NmYzNTMtNTA0ZC00ZTIyLTg3NzUtMDE5NmE4NTBjMWYz&hl=en&authkey=CIrOvm0
Google docs appears to be having technical problems at the moment. But I'm keen to check out your data. I'll try again later.
ReplyDeleteMarc, a csv file should compress quite well. Would you mind zipping it up and sharing the file somewhere? That might be faster than waiting for google docs to sort itself out.
ReplyDeletehttp://rapidshare.com/files/409492442/uart_out6.zip
ReplyDeleteMD5: 7D16E1693C6913B272DD323EEF48C72E
lol...98% compressed...should have done that first time around.
Thanks for the data. I'm sure it will be useful once I've had time to digest it.
ReplyDeleteInitial thoughts: is it possible your pin numbers are reversed?
The rightmost column looks more like VERTSYN (pin12) than the leftmost column?
You're right they're are reversed...I wondered why the clock wasn't working...
ReplyDeleteWhat software are you guys using to view the csv files as waveforms?
ReplyDeletec_rpg,
ReplyDeleteI'm viewing small portions of the file in excel. I don't have a good one to see the whole thing...too much data...(going to try Octave tonight)
please note that the files .zip and .csv have a mistake...reversed headings (pin numbers)
Guys, I'm able to view the data in its entirety using MS Excel 2007.
ReplyDeleteI read an article about LCD screens last night and learned about front and back porches. Dunno if you guys knew about these already but it is relevant to what we are doing. It might help explain some of the data we are seeing.
http://en.wikipedia.org/wiki/Front_porch
http://en.wikipedia.org/wiki/Back_porch
Got a new blog post with corrected data and the best waveform I can get with Excel 2003...
ReplyDeleteI haven't really analyzed it much, but I think it might be good enough to try writing some code to emulate...
I'm using Excel as well but it's a pain to view portions of the data (can't zoom or scale). I'll try Matlab later.
ReplyDeleteBadut, I knew about front and back porches in standard tv signals, but I don't know if they are used in digital signals as well.
Using these signals to emulate the result on the LCD screen might be a good idea. Do existing emulators actually emulate the LCD drivers? They might just take the data straight out of the LCD controller or the RAM I'm not really familiar with that.
Btw I've looked at some datasheets of other Column and Row drivers made by Sharp. They are: LH5003, LH1511, LH5021 and LH5006A.
The LH1511 datasheet actually mentions the drivers used in the gameboy at the very end. Apparently they are part of the same series.
Some of the signals used in the Gameboy are also described. An example is FR which apparently is: AC-converting signal input for LCD waveform.
I'm still analysing these datasheet for information.
c_rpg, could you please post a link to where you found your LH1511 datasheet. I found a scanned datasheet for LH1511 but couldn't find mention of the gameboy on there. The scan could be missing pages.
ReplyDeleteWell it doesn't specifically mention the word 'Gameboy'. There's just a table at the end which shows the lineup of drivers. This table also includes the two drivers used in the Gameboy: LH5028 and the LH5077 (the datasheet mentions LH5027A but I think these will be pretty similar).
ReplyDeleteMy point is that since these drivers are mentioned they are clearly part of a series of drivers which will most likely be pretty similar. Reading these datasheets might help in understanding how they work.
Some of the other datasheets also show waveforms. I'm checking these out to see if any of the patterns match the data mARC has captured.
I found the datasheets at:
http://www.datasheetarchive.com
The LH1511 datasheet can be found here:
http://www.datasheetarchive.com/pdf-datasheets/Datasheets-8/DSA-152295.html
During the weekend I'll finally have some time to work on this.
Hey guys, haven't had a chance to check those data sheets; however, I got my logic analyzer!
ReplyDeleteIt was super easy to use and I've made a new post with good (believable) data. I think it'll demystify a lot of the stuff we've been discussing. Enjoy.
http://www.robotdialogs.com/2010/08/gameboy-classic-work-in-progress-part-3.html
Hey, guys. Most of the links are out of date or dead :(
ReplyDeletec_rpg says he found LH50x7 datasheets but they don't appear now.
Anyone still have these?
I'm trying to fit later LCD displays to GB2, (others later), so need data on the LH5077.
Help me out if you can (praying smiley)
Uh, Oh! Forgot to tick the notify me box :(
ReplyDeleteI don't have local copies of any of those data sheets, sorry. I doubt anyone else is watching this post besides be at this point. If you look for similarly named posts on here (parts 3,4,5) you'll see I eventually go it kind of working but it was brute force emulation of the signals I recorded...there were still mystery signals I couldn't figure out.
ReplyDeleteIf any of the links I posted for my data are dead let me know and I'll try to fix them.
I managed to get the zip files from Part 3 but the gadget factory seems to have gone tits up.
ReplyDeleteLink times out constantly :(
Part 4 signals, same format as part 3?
Also I cannot find the LCD schematic gameboy2.gif on devrs.com. More :(
3 &4 are both from the logic sniffer if I recall correctly.
ReplyDeleteNot sure what's up with the gadgetfactory. Try this link, I haven't tried the latest version they have here, you might need to dig around for an older (2.1?) version to read my data.
http://www.gadgetfactory.net/logicsniffer/index.php?n=LogicSniffer.Download
I had the .gifs. Here's links
https://drive.google.com/file/d/0B1wxSbWwqpqyYlVLaXVweFNxcjQ/view?usp=sharing
https://drive.google.com/file/d/0B1wxSbWwqpqyTXZqNzdhNml0R3c/view?usp=sharing
https://drive.google.com/file/d/0B1wxSbWwqpqyUkJkempzRHNyeGM/view?usp=sharing
Thanks, mARC. Nice addition to my library.
ReplyDeleteI can download the latest LogicSniffer program but it seems to be buggy and won't open you files.
Trying to download 2.12 ends up the same as before and times out. :(
Try this version... Had to dig around my server for it...may or may not work, hooray for being a digital pack-rat...
ReplyDeletehttps://drive.google.com/file/d/0B1wxSbWwqpqyZXBQbHhlenZ3WVk/view?usp=sharing
OK, got it. Now to see if it will work on Windoze 7.
ReplyDeleteI know about the pack-rat syndrome. I'm rapidly filling a 1GB hard drive. Takes three hours to clone :(
If I get anywhere I'll come back with the info.
Hey! Started here with your awesome research and managed to end up controlling the LCD!
ReplyDeleteCheck it out:
http://community.arduboy.com/t/arduboy-classic/293
Hm, one of the hardest tutorials that I have ever seen in my life, but I definitely will try to do everything like you wrote, hope I can make something interesting! Thanks. By the way I wanna suggest u to try this cool gameboy emulator https://romsmania.com/emulators/gameboy that my son always uses when he wants to play in some great old games.
ReplyDeleteYeah, I wouldn't really call it a tutorial. This is just documenting the reverse engineering process. You'll need some engineering and software skills to take this to something more functional. I boxed the project up and haven't touched it in several years. Maybe someday I'll get back to it and clean up this.
ReplyDelete