DVD Drive IO voltage

[pyroholic]

Hi,

I'm currently planning to start a project with my gamecube dvd drive. I have tried to find out what io standard is used for the drive bus and control signals but have not managed to find any info. I know the drive is powered by 5v, but what voltahe does the io use? I have tried googling an searching the forums without succes, so i hope somebody here knows the answer.

[novenary]

It should be 3.3V as the WKF runs on 3.3V. FYI the drive's controller runs on 3.3V as well and there's a stepdown regulator somewhere on the drive board to power it.

[pyroholic]

Thanks, that's what i was hoping for

[novenary]

No problem. May I ask what you want to do ?

[pyroholic]

Sure, I have started a bit already so I attached a couple of pictures that kind of gives you a hint on what I'm doing. Don't mind the messy desk

[DerGali]

Looks like an ultimative fpga for the gamecube melting two fpgas into one wasp+gcvideo sandwich

[emu_kidid]

Nice, if you end up making something mass produced (DVD emulator), please make it easy for Swiss to support it and for the love of all good things, don't make it stupid like the WODE where it simulates a eject/etc. Feel free to PM me when you're up to that stage if you'd like.

[pyroholic]

I actually got started with some coding today. I decided to start with the video interface since it is a lot simpler and it's fun to make some progress. It was pretty straight forward to read the data stream, extract sync flags and synchronize the Y Cb Y Cr stream. Shown on a vga monitor without conversion it looks like this:


And that's no fun so i hacked up color space converter to turn the video into RGB color space and ended up with this:

So far I have not done any compensation for the conversion delay, so that's why there is a strange 4-pixel wide border to the left.

I think have a strange issue though, it can be seen on the lower right part of Mario's pants, where there is a strange blue artifact near the outlining. I'm suspecting, well actually i'm pretty sure, that it is a timing issue since I have not gotten around to setting up timing constraints yet, but have not started to dig deeper into it yet.

Swiss support would be awesome, and I promise that no eject simulation will be present

[novenary]

Whoa nice. I hope you succeed with the DVD emulator. We really need one that's tailored for the GameCube and not the Wii, plus now that the WASP is out of production having a replacement would be awesome.

Also that's a lot of component cable clones we have now lol.

[tesla246]

Very nice work indeed pyroholic. Ah, the dream of a colour modded-gamecube, with HDMI audio/video, wireless gamecube controller with rumble(without the wabeird ''bulky'' form factor, And lastly, a fully gamecube compatible emulated drive replacement with genuine audio on all games and of course running swiss... WOW

[novenary]

You're describing the most perfect console the world would have seen.

[tueidj]

I wouldn't call the WiiU perfect.

[pyroholic]

Got some time over today so I fixed the sync issue, so now timing is correct and everything looks nice and clean. I noticed one "odd" thing though. I thought for certain that the resolution was 640 pixels/line, but it seems that the cube sends 660 pixels. From what i can tell all pixels are "real" pixels, and not any black border or similar. Haven't been able to find any info that says other than 640 pixels. Hopefully I'll get started on the drive part soon

[Unseen]

I thought for certain that the resolution was 640 pixels/line, but it seems that the cube sends 660 pixels.

The number of pixels depends on the software that is running - for example the Ocarina of Time N64 emulator uses 704 active pixels per line, Mario Kart (at least the PAL version) uses 666 pixels and Eternal Darkness (PAL) uses 640 pixels. I have no idea though if they are "real" pixels that are calculated internally or if the Cube just uses 640 pixels per line and scales them up slightly during output.

If you want to see a rather broken video mode, try the Kinderkram demo from Hitmen - they seem to have set up the blanking ranges incorrectly, so there are unblanked "half-lines" in the video signal.

[Extrems]

In most cases, it is scaled from 640 or less.
A few homebrew achieves real 720 pixels.

[pyroholic]

I see, that's kind of tricky if one would like to do image scaling. From what I have understood the framebuffer is fixed size 640x480 pixels, so for wider video modes i guess that vertical resolution is lowered to be able to fit in memory, or is the framebuffer actually larger? I guess that scaling would be done by hardware and most likely to comply with the 720x480 TV video standard, since that seems to be what the cube is using. It would be nice from an upscaling perspective to have the video unscaled to limit scaling artefacts, maybe it is possible to force to off somehow.

[novenary]

I wouldn't call the WiiU perfect.

Who said Wii U ?

[tueidj]

I wouldn't call the WiiU perfect.

Who said Wii U ?

It does all the things mentioned except for running swiss, which isn't needed anyway.

[Extrems]

The external framebuffer can be of any* size.
The embedded framebuffer's limitations can be worked around by:

• Rendering multiple times with shifting of the scissor box.
• Rendering in planar RGB using the Y-only format and converting in hardware or software.

[novenary]

It does all the things mentioned except for running swiss, which isn't needed anyway.

Oh well, I prefer to play GC games on a real GC, might as well use Dolphin otherwise.

By the way if you have extra pins you should consider adding IPL replacement functionality to your board and load Swiss that way.

[pyroholic]

I have to agree with you, playing on the original gc is the best.

There is a lot of unused pins on the dev board, and I have actually thought about IPL replacement as well usb-gecko etc. The FPGA is also kind of overkill for this project, so it should be possible to stuff whatever is desired into it. It also has an embedded ARM core that could handle communication with usb-drive, ethernet etc

[emu_kidid]

Use the ARM core to support USB Mass storage when you've set up the DVD side.

[pyroholic]

Yeah, I think using the ARM for USB mass storage support is the way to go. I'm considering a couple of different possibilities depending on what FPGA I want to base it on in the end. But using one with embedded CPU is the easiest for sure. There is also USB host controller connected on the ARM side so it should be fairly straight forward to run a small linux kernel with USB support for external hard drives. In my opinion it is also worth a little bit more money to be able to use a usb drive than SD cards. There is probably going to be a lot of logic left though, but that only leaves room for improvements and new functions

[novenary]

Emulate the BBA on it.

[pyroholic]

We'll see about the BBA, I think it will probably not be worth the time.
Anyway, I have not been able to spend much time on this the last week, but i have a least gotten most of the environment ready.
So far I have a small linux kernel running with some skeleton code. Currently I just generate some interrupts in the FPGA and handle them with a kernel module, the plan is basically to generate interrupts on drive commands received by the FPGA and then do most stuff in software.