Great! Thanks for sharing rvan. So it's time to move on to the next strategy. Which one is it going to be? I think we must try Nitro's idea. I think we shouldn't move from micro-controllers until we test every single way to do the job.
Offline
In the second of a series of long posts, I think I have caught up with current developments.
Jazzmarazz wrote:
I think I will try out my new Raspberry Pi since it has built in video outputs. No idea where start with programming taht thing though...
The two options with a Raspberry Pi are to write standalone ('bare metal') code, or use a hard RTOS. I don't think an OS like Linux is really suitable for this project, due to various timing issues.
For the former approach, see http://www.cl.cam.ac.uk/projects/raspbe … orials/os/, which is apparently much recommended. For RTOSs, I believe FreeRTOS may be a good option, although I haven't looked at it much myself. See http://www.freertos.org/ in general and http://www.raspberrypi.org/forums/viewt … mp;t=22423 for the Raspberry Pi.
Jazzmarazz wrote:
all I can find are the cycles per assembly op-code.
Is this a straightforward calculation on the ARM? Could you please post a link to the information you found?
friendofmegaman wrote:
However, Nitro's idea seems to be viable, but what I don't want to do is underclocking the boy to get video. I have a feeling that to implement it this way we gonna need to write some assembly code, because it must run the program normally and when signal arrives (and we can predict that) read the bits. So it should be fine grained to instruction-wise precision.
I think this is still the best approach short of using a faster board or FPGA. Nitro seemed to suggest that the limited clock cycles wouldn't be an issue with this approach, and that the bottleneck would in fact be the data bandwidth of the USB Serial. I do plan to benchmark this on the Teensy at some point (or see if someone else has done benchmarks), to see if we are actually close to Full Speed, in which case RLE would probably be viable, assuming that we have the clock cycles to do this too.
friendofmegaman wrote:
Aside from FPGA and SNES+SGB there's one more option that actually Craig from FlashingLEDs suggested - use a web cam, put it close to the screen and then on PC side extract the actual frame based on pixel colors.
I'm not in favor of this approach personally, although it does seem viable, so by all means try it if you're keen.
friendofmegaman wrote:
1. Having the recording device you can have nice big picture on PC. On emulator you'll need to upload your save file back and forth. It's a minor inconvenience, but I'd like to eliminate it
2. This also allows you to make *authentic* game reviews / let's plays
3. I find aesthetically more appealing to play on real hardware. Unfortunately GB LCD is shit and I wan't to fix that.
To be honest, it seems like a Super Game Boy would be a good solution here, although point two still stands, as a Super Game Boy is arguably less authentic due to the difference in clock speed.
Part of my motivation for being part of this project is to make a portable recording (not redisplay) solution which does not involve carrying around a SNES and a Super Game Boy. I am aware that a Game Boy Advance with a TV Adapter is a reasonable solution, but I am also interested in the authenticity aspect, and would like to avoid the de-digitization and re-digitization of the signal necessary with this approach, assuming a digital recording medium (although this could admittedly be remedied with an amount of post-processing).
Jazzmarazz wrote:
Does anyone know what sort of data is stored in VRAM? Is it simply active sprites, windows, etc? or might it be something useful to us?
This is an interesting idea. The question is can we read the VRAM fast enough?
friendofmegaman wrote:
Great! Thanks for sharing rvan. So it's time to move on to the next strategy. Which one is it going to be? I think we must try Nitro's idea. I think we shouldn't move from micro-controllers until we test every single way to do the job.
You're welcome. I agree that we should try Nitro's plan.
I have also been experimenting with a 74HC595 and have so far got the hardware side set up correctly (as far as I can tell). I'll aim to write code and test this over the weekend.
Offline
friendofmegaman wrote:
Why you need a shift register?
The serial side is connected to the DMG's D0 (pixel bit 0 output), the parallel side is connected to the Teensy. This should mean that the Teensy needs to read data 8 times less frequently, while all 8 bits can be read from a single register (GPIOx_PDIR) in one go. This will eventually require two shift registers, one for each pixel bit, but I am testing with a single one first.
Offline
CA
rvan wrote:
friendofmegaman wrote:Why you need a shift register?
The serial side is connected to the DMG's D0 (pixel bit 0 output), the parallel side is connected to the Teensy. This should mean that the Teensy needs to read data 8 times less frequently, while all 8 bits can be read from a single register (GPIOx_PDIR) in one go. This will eventually require two shift registers, one for each pixel bit, but I am testing with a single one first.
Oh, this is a nice idea, I'm not sure it will save us a lot of cycles but might be just enough to keep up with the video signal
Offline
CA
Ok, my naive understanding that clock signal is just a square wave fell apart. The 0-1-0-1-... signal produced with 4M frequency and connected to where I would connect an LTC doesn't do the job.
So does anybody know how do I get scaled clock output from Arduino / Teensy and feed it to GB?
Offline
Melbourne, Australia
rvan wrote:
Jazzmarazz wrote:Does anyone know what sort of data is stored in VRAM? Is it simply active sprites, windows, etc? or might it be something useful to us?
This is an interesting idea. The question is can we read the VRAM fast enough?
An Arduino Mega can directly address external SRAM as if it were internal:
http://andybrown.me.uk/wk/2011/08/28/51 … ga-design/
http://web.archive.org/web/201204190428 … garam.html
looks like some work has been done on Teensy support as well:
http://github.com/xxxajk/xmem2
the question would be if it could be timed not to conflict with the GameBoy's access to VRAM - or maybe a second SRAM chip could some how be piggy-backed to receive the same data from the GameBoy but allow reading by the Arduino without timing concerns...
Offline
friendofmegaman wrote:
Ok, my naive understanding that clock signal is just a square wave fell apart. The 0-1-0-1-... signal produced with 4M frequency and connected to where I would connect an LTC doesn't do the job.
I was quite certain a square wave would do fine (if not, I suspect Nitro knows what to do). Looking at the data sheet for the LTC6930 (the chip in Kitsch-Bent's easy_CLK) would suggest a square wave works. Perhaps your synthesis isn't working as expected at that speed? I assume you are using an Arduino or Teensy. If so, put up the code and I can test it with my DSO at some point. I can also try to look at the DMG's actual clock signal with the DSO if need be.
rvan wrote:
I have also been experimenting with a 74HC595 and have so far got the hardware side set up correctly (as far as I can tell). I'll aim to write code and test this over the weekend.
A brief update on this: I ended up having a hedge to cut this weekend so haven't had as much time as expected, but still plan to do this at some point.
Last edited by rvan (May 4, 2014 6:09 am)
Offline
Michigan
uXe wrote:
rvan wrote:This is an interesting idea. The question is can we read the VRAM fast enough?
An Arduino Mega can directly address external SRAM as if it were internal:
http://andybrown.me.uk/wk/2011/08/28/51 … ga-design/
http://web.archive.org/web/201204190428 … garam.html
looks like some work has been done on Teensy support as well:
http://github.com/xxxajk/xmem2
the question would be if it could be timed not to conflict with the GameBoy's access to VRAM - or maybe a second SRAM chip could some how be piggy-backed to receive the same data from the GameBoy but allow reading by the Arduino without timing concerns...
Or replacing the VRAM with the teensy and having the Teensy mimic it with interrupts linked to VRAM reads/writes from the CPU.
Offline
friendofmegaman wrote:
I can also try to look at the DMG's actual clock signal with the DSO if need be.
I realized I could just do this on the board I'm using for testing without having to remove the crystal. It's a sine wave.
DSO Trace of DMG CPU Clock. Probe at X10 setting.
I'm fairly certain other waveforms should work, too:
LTC6930 Typical Output Waveform. From the LTC6930 Datasheet.
Offline
uXe wrote:
An Arduino Mega can directly address external SRAM as if it were internal:
Good news. But can the Arduino (or Teensy) access the RAM at 4.19 MHz, and when it is not providing the clock signal itself? Clearly, we wouldn't have to read the RAM every single clock cycle, though. Let's look more into whether the data stored in VRAM is in fact useful to us.
Offline
Melbourne, Australia
rvan wrote:
uXe wrote:An Arduino Mega can directly address external SRAM as if it were internal
Good news. But can the Arduino (or Teensy) access the RAM at 4.19 MHz, and when it is not providing the clock signal itself? Clearly, we wouldn't have to read the RAM every single clock cycle, though. Let's look more into whether the data stored in VRAM is in fact useful to us.
...it's SRAM (static) so it doesn't need to be clocked / refreshed the way DRAM (dynamic) does, here's a memory map:
http://gameboy.mongenel.com/dmg/asmmemmap.html
like I said, the question would be if it can be timed not to conflict with the GameBoy's access to VRAM - or maybe a second SRAM chip could somehow be piggy-backed to receive the same data from the GameBoy but allow reading by the Arduino without timing concerns...
Offline
Melbourne, Australia
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!
Then just take the video generation routine of a GameBoy emulator and instead of having it generate video from a software emulation of the 'Boy, feed the real GameBoy's memory contents into and let it generate easily recordable video for you - voilà! 
Offline
CA
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!
Then just take the video generation routine of a GameBoy emulator and instead of having it generate video from a software emulation of the 'Boy, feed the real GameBoy's memory contents into and let it generate easily recordable video for you - voilà!
Does it solve the performance problem?
Offline
Michigan
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!
Then just take the video generation routine of a GameBoy emulator and instead of having it generate video from a software emulation of the 'Boy, feed the real GameBoy's memory contents into and let it generate easily recordable video for you - voilà!
Sounds legit, but also sounds like the most complex of ways to do this...hah...
Offline
Melbourne, Australia
Jazzmarazz wrote:
Sounds legit, but also sounds like the most complex of ways to do this...hah...
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!