Offline
Michigan

Whoa, cool! The papilio looks like something I will pick up sometime soon. As for the other stuff, looks a bit gimmicky. I just want the VGA, np buttons, or controller inputs. However:

the Spartan-3/-3E I/O is not 5V-tolerant.

But:

Spartan-3/-3E I/O can be made 5V-tolerant by using an external series current-limiting resistor to limit the current into the upper clamp diode to 10 mA. This makes the input 5V-tolerant, but an I/O configured as an output still cannot drive 5 Volts and the resulting VOH does not meet the input specifications of the 5V device.

What that means is you can still read all of the LCD pins. The papilio is too expensive for everyone to mod their gameboys with, but it is made for devs to take inspiration from. We can design a standalone board with JUST the Spartan-3/-3E and VGA later on, depending on cost.

Cheers for finding that.

EDIT: here is the VGA "wing":
http://store.gadgetfactory.net/vga-wing/
12$ is more than I want to pay for that, but it looks easy to breadboard once you had a Papilio.

Last edited by Jazzmarazz (Jul 18, 2014 12:30 am)

Offline
CA

I don't understand this bit:

Jazzmarazz wrote:

using an external series current-limiting resistor to limit the current into the upper clamp diode to 10 mA

What's the upper clamp diode? I thought for each input pin we just need to throw a divider to get 3.3V or whatever voltage is required...

VGA wing is cool, but it's $12 while the whole arcade wing is $19... $7 difference...

Overall it looks pretty good, I think we need to read through the documentation and figure will this thing resolve our problems with uC or not.

For the video capture device it has USB UART. But it says:

"Channel B is connected to the Papilio One in an Asynchronous serial UART configuration that is capable of speeds up to 2MHz"

What's that suppose to mean? Will it provide 2Mbaud speed?

If so then I'm gonna need to build the frame in the Papilio and send it to PC to save on bandwidth (4MBaud required to send raw data). Furthermore the frame must be assembled by FPGA clocked by DMG's clock. Is there a way to check if FPGA has enough capacity to handle that? Because you said that your project was too big. What if this one is too big for Papilio as well?

These are my first thoughts, I guess I'll figure this things out once I familiarize myself more.

Last edited by friendofmegaman (Jul 18, 2014 1:03 am)

Offline
Michigan

Microcontrollers and FPGAs will have internal protection. the protection is weak, but useful. The clamp diodes are internal, see:

When you write your FPGA code, the environment will have an emulator option to compile and test theoretical ROM/RAM useage. If it fits or does not fit, it will say so.

Offline
CA
Jazzmarazz wrote:

Microcontrollers and FPGAs will have internal protection. the protection is weak, but useful. The clamp diodes are internal, see:

When you write your FPGA code, the environment will have an emulator option to compile and test theoretical ROM/RAM useage. If it fits or does not fit, it will say so.


Ah I see, thanks!

Offline
friendofmegaman wrote:
Timbob wrote:

If you want to play games on the DMG, but want a copy of the screen sent to the snes for say, a workshop, then no.

Yah, actually I was hoping to achieve exactly that. Not for a workshop of course, but for LSDJing on big screen without patching LSDJ to be in tune with other instruments (since SGB has slightly different frequency)... Why is it not possible?

Doesn't it work to use a DMG crystal on an SGB?  Or even a DMG CPU, if you want to be that authentic.

FPGA sounds like a good way to go for video capture/output, though.  I probably don't have to the time to invest in learning to code for FPGAs, but I'll definitely keep up with what you all are doing.  I'd be especially interested in composite output (rather than VGA) so that it can be recorded.

Offline
CA
rvan wrote:
friendofmegaman wrote:

Yah, actually I was hoping to achieve exactly that. Not for a workshop of course, but for LSDJing on big screen without patching LSDJ to be in tune with other instruments (since SGB has slightly different frequency)... Why is it not possible?

Doesn't it work to use a DMG crystal on an SGB?  Or even a DMG CPU, if you want to be that authentic.

FPGA sounds like a good way to go for video capture/output, though.  I probably don't have to the time to invest in learning to code for FPGAs, but I'll definitely keep up with what you all are doing.  I'd be especially interested in composite output (rather than VGA) so that it can be recorded.

My primary purpose is sending data to PC, so you'll be able to record indeed if this part succeeds smile

Offline
CA

So it appears that FPGA manufacturers tend to discriminate Mac users sad

Offline
CA

So I was wondering which language to use Verilog or VHDL. So for I found a bunch of reading on the former and not so many introductions / tutorials on the latter. Thus for now I'm gonna stick with Verilog...

Last edited by friendofmegaman (Jul 22, 2014 1:43 am)

Offline
Dallas, Texas
friendofmegaman wrote:

So it appears that FPGA manufacturers tend to discriminate Mac users sad

Everyone does really. Couldn't you run something like Parallels on your mac or are you rockin' a PowerPC?

Offline
CA
TylerBarnes wrote:
friendofmegaman wrote:

So it appears that FPGA manufacturers tend to discriminate Mac users sad

Everyone does really. Couldn't you run something like Parallels on your mac or are you rockin' a PowerPC?

I'm just saying. I'm gonna use bootcamp or find a PC. This definitely won't stop me from doing the project smile

Offline
Dallas, Texas

smile Thats good. Yeah, I happily use Bootcamp paired with Parallels for all my Windows Software/Hardware needs. I even got a 32 bit XP virtual machine for all my really old stuff that require 32 bit windows. Running those in Coherence mode I almost forget I'm even virtualizing cause the mac/win apps run side by side. wink

Offline

If you haven't seen it already, there is some new interesting discussion about NeX's video out mod here: How is the VHS capture card made?.

Offline
Michigan

Well, I gave it a go. A few weeks back I sat down and attempted to read the data bits into my serial monitor. I tried a hundred different sketches using different methods of reading ports, reading pins and using interrupts.

AF one point I was getting a bunch of 0's and 3's which is how a gameboy screen boots when there is no cart inserted (having internal pullup resistors in the data bus) meaning all 1's or 0's. Perfect. The only problem I had was that I was not properly utilizing v or hsync. So the monitor was simply reading anything and everything as quickly as possible.

When I tried interrupts on the clock trace, I couldn't get the to work AT ALL. Not once. I tried everything. I tried with an arduino nano, uno and mega but nothing worked with interrupts.

I think the problem may have been that I was using the port as a data port which also contained the interrupt pin.

In any case, I got data at one point, but nothing useable...yet.

Offline
Jazzmarazz wrote:

When I tried interrupts on the clock trace, I couldn't get the to work AT ALL. Not once. I tried everything. I tried with an arduino nano, uno and mega but nothing worked with interrupts.

Great to hear some progress has been made. I think the problem may be that interrupts on the Arduino (or even interrupts on microcontrollers of this speed in general) are just too slow. Have you tried capturing the clock as data on the same port as the actual data bits to verify that you're reading the data bits at least once per the Game Boy's clock cycle?

Offline
World

Last edited by luftek (Aug 8, 2017 8:12 pm)

Offline
Michigan

Yes, I would like to help test that Luftek.