145 Reply by friendofmegaman

(244 replies, posted in Nintendo Handhelds)

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à! big_smile

Does it solve the performance problem?

Go to forum: Nintendo Handhelds

146 Reply by friendofmegaman

(244 replies, posted in Nintendo Handhelds)

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?

Go to forum: Nintendo Handhelds

147 Reply by friendofmegaman

(244 replies, posted in Nintendo Handhelds)

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

Go to forum: Nintendo Handhelds

148 Reply by friendofmegaman

(244 replies, posted in Nintendo Handhelds)

Why you need a shift register?

Go to forum: Nintendo Handhelds

149 Reply by friendofmegaman

(244 replies, posted in Nintendo Handhelds)

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.

Go to forum: Nintendo Handhelds

150 Reply by friendofmegaman

(1,206 replies, posted in Nintendo Handhelds)

I call it Post Apocalypse Boy

Features:
- Post pot-6.5mm and 3.5mm line out
- Double inversion
- Variable oscillator based on LTC1799
- Green backlight (handheldlegend.com) with brightness control via trim pot.
- PS/2 from kitsch-bent.com
- 1 and 1/2 clock speed switch
- New capacitors for the power regulator and the headphone jack
- Removed headphone PCB to save space for other mods (caps are connected directly to the jack)
- DB25 female connector used as a breakout for buttons and LCD data so in the future I could get video output to the VGA display, TV or laptop and plug in NES controller (additional work is required of course).
- Translucent red buttons from asmretro.com

Worklog is here

Go to forum: Nintendo Handhelds

151 Reply by friendofmegaman

(8 replies, posted in Nintendo Handhelds)

atomsmasha wrote:

sounds like the screen is fucked smile))

It's quite an interesting observation. I haven't considered that...

Go to forum: Nintendo Handhelds

152 Reply by friendofmegaman

(8 replies, posted in Nintendo Handhelds)

Dadibom wrote:

Bad ribbon cable connections?

I don think it's a problem, cable looks fine, connection also looks all right... It worked fine until some moment, I can't recall that I have changed anything since then...

Go to forum: Nintendo Handhelds

153 Reply by friendofmegaman

(8 replies, posted in Nintendo Handhelds)

PianoGameboy wrote:

What mods have you done to it other than the backlight, what backlight did you use, and did you use a resistor?
The only things I can think of that cause that to happen is if you're using a variable clock and you've got it slowed down, or if you're not getting enough power (batteries can be ruled out since you said it works fine with a different screen, so it could possibly be related to the backlight).


Sorry I forgot to mention. When I desolder backlight wires fizzling is still there, it doesn't fix the problem.

Variable clock is off, however it is indeed resembles underclocked 'shaking', but sound is fine and another screen works flawlessly. This also rules out lack of power.

Also capacitors seem to be fine, nothing blown.

Go to forum: Nintendo Handhelds

154 Topic by friendofmegaman

(8 replies, posted in Nintendo Handhelds)

Hey chip tune people

I was modding a DMG and suddenly the image on the screen started fizzling (impossible to capture on camera). There are basically there are thin horizontal lines blinking very fast as in the old badly tuned TV set. So you basically see the picture but it's soft of shaking. When I try another screen there is no such problem.

The screen is backlit and it worked fine until recently. Of course there's always a chance I accidentally damaged something and didn't notice but if you know the exact reason please share smile

Thanks!

Go to forum: Nintendo Handhelds

155 Reply by friendofmegaman

(8 replies, posted in Nintendo Handhelds)

If you remove the screen you will have to glue it back with the glue. It won't stick back on its own. Alternatively you could buy a new screen cover that already have adhesive. It's a good option if your screen is scratched.

Go to forum: Nintendo Handhelds

156 Reply by friendofmegaman

(244 replies, posted in Nintendo Handhelds)

No, but let's find out: http://marc.rawer.de/Gameboy/Docs/GBCPUman.pdf

Go to forum: Nintendo Handhelds

157 Reply by friendofmegaman

(8 replies, posted in Nintendo Handhelds)

Nursey wrote:
Jazzmarazz wrote:

I can't even address the main question until you answer my own: why would you paint a red-boy white?!

c-cause I have a black one to compliment it...!

Can you buy a grey one and paint it? Colorful guys are so beautiful and it's a waste to paint them smile
Or buy a clear boy and paint it white from the inside in this case you'll have more durable color.

Go to forum: Nintendo Handhelds

158 Reply by friendofmegaman

(244 replies, posted in Nintendo Handhelds)

uXe wrote:

That definitely does sound interesting - but if you are going to go to that level of abstraction to record video from a GameBoy, why not just record the output of an emulator instead?

Well in the end of a day you can chiptune on the emulator (without crashes and with much better and cleaner sound or better yet use a MIDI keyboard or a proper synth) as well as play, change the speed, invert, bivert, trivert (and possibly quadvert) and so forth. The point is to spend your time on something pointless! That's what makes one a nerd...

Jokes aside though:
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.

And

the webcam approach can be done not as a separate device that you plug a DMG into as I suggested earlier , but rather as a snap-on thingy that you could use with DMG, pocket or color - this is a huge advantage of the approach IMO. And no modding required. I have enough ideas for chiptune related stuff and the space for LCD breakout socket can be used for something else. Like a breakout with link, power, clock in/out, pre-pot left/right channels to plug into a music station with MIDI, prosounds, pitch and stuff.

Or maybe I just have gone mental and this doesn't make any sense sad

Go to forum: Nintendo Handhelds

159 Reply by friendofmegaman

(13 replies, posted in Nintendo Handhelds)

This is awesome! Thanks for sharing!
I always wanted some graphical instrument to quickly test the color combination and you did it. Are you planning on adding more shells and screen frames? (as for buttons, backlights and power LEDs is think you covered pretty much all of them). On the other hand I presume you put only those colors available right now which makes perfect sense...

Go to forum: Nintendo Handhelds

160 Reply by friendofmegaman

(244 replies, posted in Nintendo Handhelds)

Jazzmarazz wrote:

I took a few minutes to find the cycles per instruction, but all I can find are the cycles per assembly op-code. Obviously the code is not in assembly. Is there a way to disassemble the *.cpp.hex file (found in the working directory after compiling)? If we could do that, then you could get the actual cycles per instruction and find out if the interrupts are taking too long.

Is that still a possible cause of the problem?


The problem is that both interrupts and polling based approaches failed. We could predict it before starting the experiments if we thought it through a little bit better. The major problem now is lack of cycles, that's it. I don't see conclusive proof that it can be done with the current setting.

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.

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. As crazy as it sounds it is a very interesting idea (a good example of out-of-the-box thinking). We need a cam, then front PCB (we can actually saw off the lower half to make it smaller, add some light (either backlight or simple LEDs). But that's theory, to be certain experiments are needed.... In the end it can be hacked into a very tiny device (as big as the GB LCD and as 'fat' as webcam allows, which on its turn too can be disassembled and 'flattened').

Go to forum: Nintendo Handhelds