Offline
Michigan
uXe wrote:
Jazzmarazz wrote:

Sounds legit, but also sounds like the most complex of ways to do this...hah...

smile seems really nice, and really straight-forward to me - the data is just 'there' in the shared RAM for you to read, being constantly updated by the GameBoy, without you having to make any effort at all! No crazy timing to try and match, no counting cycles, you would just read the data and assemble the frames...

For certain games you would even be able to mess around with constructing and viewing the entire 256x256 frame, instead of just a scrolling 160x144 window into it!

In fact, you could also experiment with writing into the shared RAM instead of just reading from it! smile

NICE IDEA on the 256 x 256 frame! That could possibly make a world of difference with custom software's!

Offline
Michigan

Like, freaking revolutionary to say the least. Haha

Offline
Michigan

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

Offline
Melbourne, Australia
uXe wrote:

Actually, scratch that - just use a dual-port SRAM like this:

http://www.idt.com/products/memory-logi … l-port-ram

and there won't be any conflicts for the GameBoy and the Arduino to share the same memory!

...and then Batsly announces this:

http://chipmusic.org/forums/topic/14236 … interface/

Ha! Beautiful! big_smile

Offline
CA
uXe wrote:
uXe wrote:

Actually, scratch that - just use a dual-port SRAM like this:

http://www.idt.com/products/memory-logi … l-port-ram

and there won't be any conflicts for the GameBoy and the Arduino to share the same memory!

...and then Batsly announces this:

http://chipmusic.org/forums/topic/14236 … interface/

Ha! Beautiful! big_smile

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)

Offline
Melbourne, Australia
friendofmegaman wrote:

1. Are these the same types of RAM? Do we need any adapters to plug it to GB?

The pinout isn't going to be the same, because it is dual-port so there are twice as many pins!

friendofmegaman wrote:

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?

Yes.

friendofmegaman wrote:

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?

Yes.

friendofmegaman wrote:

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)?

A good explanation from http://gameboy.mongenel.com/dmg/lesson5.html

"The address space from $8000-$9FFF is video ram (VRAM). This area of memory isn't a plain linear collection of bytes that represent pixels on the LCD, rather this memory area contains building blocks that the LCD controller builds each screen with. Each of these 8x8 pixel blocks is called a TILE. The VRAM contains two major sections, one section for tiles, and another section for a MAP. The map area is a 32x32 byte array (1024 bytes) that makes up the Background Map, or BGMAP for short. The way the LCD draws a screen is this: it takes the byte value in the map area, and gets the corressponding tile from the tile set, and draws the 8x8 tile where it got the map byte from."

The only spanner in the works might be that the Sprite Attribute Table (OAM) is stored outside of VRAM - maybe physically separately in the other SRAM chip? in which case you'd need a second dual-port chip to be able to keep track of that as well - I haven't dug deep enough to be sure about that, anybody?

Offline
CA
uXe wrote:

A good explanation from http://gameboy.mongenel.com/dmg/lesson5.html

It becomes more and more interesting... basically this way we could access all the data including variables used in the game... neat!

Offline
CA

I will try this direction then. It's an interesting approach allowing us (in the future) do something more than mere video capture or even extend this idea for GBC. But I'll be asking for some help here, hope uXe will help me out with theory smile

Anybody wants to try Nitro's idea to make uC the clock master?

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

Offline
CA

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)

Offline
Boston, MA

i could be wrong but...

having access to the GB's ram will only give you the tiledata, you will need access to the rom to assemble the tiledata into screens / images. This includes sprite data and locations, priorities etc. And you would need to know what code is executing in the rom to figure out what needs to be where on the screen. i dont think its as simple as using image generation code from an emulator.

edit: separated posts.

Last edited by ultramega (May 6, 2014 2:58 am)

Offline
CA
ultramega wrote:

i could be wrong but...

having access to the GB's ram will only give you the tiledata, you will need access to the rom to assemble the tiledata into screens / images. This includes sprite data and locations, priorities etc. And you would need to know what code is executing in the rom to figure out what needs to be where on the screen. i dont think its as simple as using image generation code from an emulator.

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)

Offline
Boston, MA

I was kind of wrong, but you gotta consider sprites, screen on/off, color palette... there are some things that affect the screen that are outside of vram, and if you want 1:1 video capture they need to be considered.

Offline
CA
ultramega wrote:

I was kind of wrong, but you gotta consider sprites, screen on/off, color palette... there are some things that affect the screen that are outside of vram, and if you want 1:1 video capture they need to be considered.

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.

Offline
Melbourne, Australia

Yeah, like I said above, you would probably want TWO dual-port chips to be able to access both the Video RAM and the Working RAM - you are going to need access to the Object Attribute Memory to be able to draw the sprites...

Offline
CA

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)

Offline
CA
uXe wrote:

Yeah, like I said above, you would probably want TWO dual-port chips to be able to access both the Video RAM and the Working RAM - you are going to need access to the Object Attribute Memory to be able to draw the sprites...

Now I'm a bit confused are there two RAMs?

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