DMG/Pocket video capture with Arduino or Teensy? (Page 9 of 16)

Seriously though. So with a third post: kudos to you for bringing that up.

I'll be damned! It's bloody brilliant.

So, uXe, you seem like an expert in these things - any chance you're willing to try this direction? If you don't want to bother yourself, could you at least provide clear instructions how to do it? Concretely:
1. Are these the same types of RAM? Do we need any adapters to plug it to GB?
2. In my understanding the dual-port RAM replaces RAM in GB and connects (not replaces) to Arduino since the latter can work with external RAM is it correct?
3. Let's assume we have steps 1 and 2 done, then to get the frame data we just need to read the corresponding region of RAM using Arduino's RAM API at the rate we want (may be 60Hz as screen, may slower if we are saving bandwidth) - did I get it right?
4. Why do we need a piece of emulator code? Is it to get background and tiles data and build a 160x144 screen (or as you suggested 256x256 which is even better)?

This in fact could be even used in GBC...

Last edited by friendofmegaman (May 5, 2014 11:25 pm)

Any ideas how do we map the pins?

Pins marked A0-A12 on gameboy SRAM are mapped to either A0r-A12r or A0l-A12l

It seems like D0-D7 are mapped to IO0-IO7 (either r or l)

NOT OE also presented in both chips

Last edited by friendofmegaman (May 6, 2014 2:55 am)

Good point, but in this document (http://gameboy.mongenel.com/dmg/lesson5.html) says that data in the video ram (which is a dedicated region of the 64Kb SRAM) suffices to build the frame. But then again it worth double-checking.

Last edited by friendofmegaman (May 6, 2014 2:56 am)

I'm not sure actually... this fragment (talking about GB RAM):

The lower 32K ($0000-$7FFF) is used for accessing cartridge rom. A gameboy cartridge is basically carved up into 16K pieces, called BANKS, with the first 16K bank of cartridge space being addressable at the first 16K of the address space ($0000-$3FFF). This first 16K bank is called the HOME BANK. This piece of the cartridge is ALWAYS accessed from this area. This is where most of your game's code will be placed, since it's always available. This first 16K also holds the HEADER of a GameBoy game, located at $0100. The header is basically an ID tag for a game. The rest of the cartridge banks can be "paged" into the address space from area $4000-$7FFF. This area is called paged because you can change. NOTE, only ONE bank of the cartridge is visible in the paged space at any given time. To change which bank is visible, you need to tell the hardware what bank to change it to. This is pretty easy and will be detailed later.

So the data from the cartridge ROM is *loaded* into GB RAM. So even if we need something from the ROM we can grab it from here. The only thing that bothers me is that we may run into timing issues again. Let's say I need a particular piece of data from the cartridge region, however by the time I'm accessing it it can be already gone (replaced by another bank). This holds of course only if we really need the data from there.

It's true that we're going to need some emulator code to build the frame again.

Let's think about it for a second. Because I see dramatic change in the direction. So instead of dealing with clocked frame data we are dealing with GB's internal structures. Let's weight pros and cons.

**** Frame data approach ****
Pros:
- Just 5 bits required
- It's easy to reconstruct the frame
- Easy soldering job

Cons:
- Clocking issues

**** RAM approach ****
Pros:
- Solves clocking issues (allegedly)
- Can display the whole 256x256 background (although I'm not sure that overlaying sprites window is also 256x256)
- We can also write memory
- We have control over building blocks of the frame and hence have more options to mess with them on the PC side (it's especially interesting from the coloring point of view). It would be interesting to reverse engineer pieces of Super Game Boy to add the colors and extra content.

Cons:
- Trickier to solder (actually de-soldering the existing RAM is the hardest part)
- More complex frame reconstruction algo
- We're moving away from the idea of video capture. E.g. we could just read a cartridge rom and feed to the emulator - pretty much the same effect but less work then.

Last edited by friendofmegaman (May 6, 2014 3:15 am)