Welcome to Robot Dialogs. This is a place where I will record my progress, mistakes, errors, failures, lessons learned and hopefully occasional success in my designs and implementations of robots and other technical endeavors. I will try to make it as educational, informative and entertaining as I can...
Showing posts with label gameboy. Show all posts
Showing posts with label gameboy. Show all posts

Saturday, May 28, 2011

GameBoy (Classic) Work In Progress Part 5

21.2 FPS! I'm borrowing a ChipKIT Max32 from a friend. Hooked it up to the long running GameBoy Classic LCD project I've been working on and after some optimized code I hit 21.2 FPS! Best result yet.
I'm used a simple java program to generate a version of my AVR C code in optimized Processing (Arduino-ese). I had to un-roll loops to the point of absurdity that's why I started using code generation...

Java code is here.

Up on my plate in the near future:
  • IOIO Tinkering - I need to come up with a project worthy of android powers.
  • 30 Days of Creativity - June 1-30 - I'll be doing this again for sure!
  • Maple Tinkering - I think this board might be the next step for the GameBoy Project. I have to return the ChipKIT Max32...the thing can only toggle an I/O pin at 719 kHz (I can get something better at the same price point).
  • And most importantly the KC Maker Faire: June 25-26:

Saturday, February 26, 2011

GameBoy (Classic) Work In Progress Part 4

I finally dug the GameBoy back out of the project box and started making some more progress on it. I'm still working with an ATMega32, but now I've cranked it up to the full 16Mhz it can handle...


I also took some new data from the GameBoy LCD control signals with the Logic Sniffer. This time I wasn't clocking the GameBoy with my micro-controller. Instead I used the GBs original crystal, so the data is from the actual signals with actual timing that the GameBoy uses.

I was able to break down the timings of the signals and essentially emulate them with the ATMega32. The logic I use to determine what pixel data to push out was simply if(x = y) then the pixel was turned on. I figure a diagonal line is a good test that doesn't look like the crazy vertical and horizontal screen artifacts you sometimes get with the GB.


This picture is very deceiving, the contrast is a lot better in the picture than on the actual screen. The ATMega32 can't quite output data as fast as the GBs CPU, and even though I can emulate the signals I still don't fully understand them. I feel it's going to take a lot more effort to actually understand the non-obvious signals.

When I finally understand them I hope to be able to slow the frame rate down, leaving an old image on the screen while I compute the next. Unfortunately my attempts to leave the image on screen while doing other stuff just lets the screen clear... I hope this is fixable, otherwise I'll have to either devise some sort of video ram setup that takes new data but always keeps the screen refreshing while leaving another chip to create the data and send it to the ram or I will have to upgrade to some much higher frequency micro-controller that can do both. From what I can tell the Z80 in the classic GB does both, but to pull it off it has dedicated hardware to pull data from shared memory and drive the LCD, while the main Z80 just handles the game logic and graphics computations and just stores into the shared memory...probably over simplified that explanation... you can go read the GB's patent if you want the real story/architecture.

Oh, my current source code is inexcusable. Give me some time to figure out the purpose of the LCD signals and then I'll put up some code. Also, you'll need the OpenBench_LogicSniffer_JAVA_CLIENT_2.1 to view that data.

Wednesday, August 4, 2010

GameBoy (Classic) Work In Progress Part 3

First: The Open Logic Sniffer is the best thing since sliced bread.

Second: I finally have reliable recorded data from the GB CPU to the GB LCD.


Okay so before making sense of the data here's what you need to know. I clocked the GameBoy CPU with my own micro-controller the resulting GameBoy CPU Frequency was 812 kHz. That's 24.63 times slower than normal (20 MHz), so all of the data collected needs to be time scaled appropriately.

The data was collected on Pins 12-19 of the ribbon cable between the CPU board and the LCD board (See previous post for pin numbering and pin names, some of which are guessed). These pins correspond to inputs 0-7 on the logic analyzer respectively (see labels on image above if you're confused).

Two of the data sets were sampled at 10MHz and one at 1MHz. The 1MHz set was only taken for timing of the Vblank (it isn't a high enough sample rate to be considered accurate for data analysis).

I won't be drawing conclusions about the data just yet, for now I just want to make it available.

To get the data go here: GB Data 2.zip I'd be happy to collect more, just leave a comment.

To view the data go to The Gadget Factory and get the JAVA Client. It's Free. Run the executable (it doesn't install, it just runs a JAVA program) and then open one of the ".sla" files.

It's too late to code it up tonight, and I'm building a new PC tomorrow so hopefully this weekend I can get it working.

As a side note, I am really pleased with the Logic Sniffer. I had it out of the box, firmware updated, and got this data collected in less than an hour. I highly recommend that you consider getting one.

Wednesday, July 28, 2010

MakeKC: Mini Maker Faire

So I'll be participating in my first (Mini) Maker Faire next month. I'll have most of the projects from previous posts there with me on display. I don't know exactly where I'll be, probably get that email in the next few weeks. Should be some good projects out there.

In the time between now and the fair I'll be working feverishly to finish my GameBoy project. The idea has picked up some new traffic in the previous post's comments and on the forums so I've got some new data and help in that respect. New data is below and I've ordered a logic analyzer so I can get even better info.
1 Frame of GB LCD Data

More Data

Thursday, March 25, 2010

GameBoy (Classic) Work In Progress Part 2

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.

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

Monday, March 8, 2010

GameBoy (Classic) Work In Progress

This is a dump from the forum...it's notes on an in progress GameBoy hack. I will refine it later.

Forum thread is here.

I'm trying to identify and spec out the LCD signals in the GB (classic). I'm looking to do away w/ the GBs original controller board while keeping the LCD board.

Basically I want to plug the ribbon cable into my on PCB and output the necessary signals to drive the video myself.

I'm just wandering if anyone has more info on LCD signals output by the z80 so I can emulate them to display stuff.

So far I've mapped all the buttons, speaker, power LED, LCD negative power to the appropriate pins on the ribbon cable.

What I have so far:
Note: Pin 01 is the pin on the ribbon cable closest to the power switch (at the cables connector).
Note: Pin LCDV1 is the pin closest to power switch on the LCDs vertical axis connector (beneath LCD).
Note: Pin LCDH1 is the pin closest to power switch on the LCDs horizontal axis connector.

Pin 01 GND
Pin 02 Power LED - (Unregulated Batteries Voltage)
Pin 03 LCD Drive voltage (-19 V) This voltage comes from the voltage converter attached to the CPU section.
Pin 04 Left & B buttons
Pin 05 Button Diodes 1 & 2
Pin 06 Down & Start buttons
Pin 07 Up & Select buttons
Pin 08 Right & A Buttons
Pin 09 Button Diodes 3 & 4
Pin 10 GND
Pin 11 Vcc - Regulated 5V (different from Pin 02).
Pin 12 VERTSYN (I think) Goes to LCDV8.
Pin 13 ? - Connects to LCDV6 and LCDH7 (Either DATALCH or ALTSIGL)
Pin 14 CLK ? - According to nitro2k01's inverted display mod. Connects to LCDH8. (Data suggests Pin 18 as CLK though.)
Pin 15 DATAOUT1 ? - According to nitro2k01's inverted display mod. Connects to LCDH9.
Pin 16 DATAOUT0 ? - According to nitro2k01's inverted display mod. Connects to LCDH10.
Pin 17 ? - Connects to LCDH11 (Either CONTROL or HORSYNC)
Pin 18 ? - Connects to LCDV10 and LCDH12 (Either DATALCH or ALTSIGL) (Data suggests Pin 18 as CLK but this conflicts with LCD schematic...)
Pin 19 ? - Connects to LCDH13.
Pin 20 Speaker
Pin 21 GND

So I need help assigning Pins 12-19. I also need to know exactly what they do, and whether the controller or the LCD driver chip(s) are the ones switching them.

Basically...the sequence in which to flip bits...

I do have the LCD section schematic from devrs.com (gameboy2.gif) but it doesn't have the ribbon pinout or explain what the non-obvious signals do.

Here's a bit of captured data from all those pins...my current setup doesn't really do time stamping, so it's virtually useless...unless you want to know that 3 frames fits in 7000 bytes: