"Let's make GD ROM emulation happen" Facebook group.

dont know how it looks in VHDL style, i use logic AND/NAND/... for generating strobe RD : (graph or ahdl)

i think i can help after i start debuggin my own board.

 

This is now officially complicated enought so that I don't understand well what's going on... I guess it means it's going in the right direction!

Just wanted to cheer you guys up! This thing would rock!

 

Way too much post to process here..

Some things I picked out:

-Yes the DC must latch on the rising edge of /RD (usually a little BEFORE the rising edge since the strobe is a combinatorial signal), it's always this way because /RD actually serves to enable an internal transparent latch (or master latch of a register) in whatever's reading.

-Yes you want to increment the address counter on the rising edge of the strobe, by the time the rising edge increments the counter the data is already latched/registered, kind of like a shift register.

-To keep things understandable it's probably best to keep only an always block for each clock domain and an asychronous one.

-You can't have multiple edges in your sensitivity list if you intend to synthesize it.


I wasn't really paying attention in the last post, so what I posted was from the DC's perspective... oops. This is the idea, neglecting the actual signals, decoding etc:

inout wire [15:0] data;

assign data = (rd_n) ? 16'hZZZZ : r_buffer[r_addr];

always @(posedge rd_n)
begin
r_addr <= r_addr + 1;
end

always @(posedge wr_n)
begin
w_buffer[w_addr] <= data;
w_addr <= w_addr + 1;
end

From here you need to cross clock domains to your fast system clock

 

Yep, it seems much better when incrementing on the rising edge, thanks for that.

I just spent another few hours going through the code and comparing it to the old CF code / nullDC Source / SPI Manual / ATA + ATAPI specs.
I also tried confirming that the data matches the original GDI and made "dc_bytecount" increment properly, so it now represents the true offset in the GDI.

I checked the data coming from the SD card again and it looks OK? (although, it's very laborious to check every single byte with Sigtap).
I don't know why I got those random data errors on SigTap before? As I say, I don't have a simple way of checking the data as yet.

The data from the SRAM appears to match the GDI too. And so it should! - it comes directly from the SD card!

The TOCs were double-checked (against the original Taxi disk) and the FAD / MSF addresses appear to match the Sega GD-ROM Format specs for a standard 3-track TOC.

Still no booting! :mad-new: And now the DC keeps going straight to the Menu screen? It shows the correct audio track (Track 02, 1min29secs) in the music player, but that's about it.

I even just changed the TOC so it will attempt to boot a CDI instead. But, I'm not quite sure what the TOC looks like for a MIL-CD? I'll have to do some captures from a real CD at some point.

@calpis - Is it OK to use two edges when doing a global async reset? It seems fairly standard?...

always @(posedge SYSCLK or negedge RST_n)
if (!RST_n) begin
state <= 10'd0;
end
else begin

case (state)
0: blah blah blah
encase
end

I see what you're doing with the always blocks, but it needs a way of resetting the addresses too.
Does the reset NEED to be done within the same always block as the address? (to prevent "multiple driver" errors)?

I don't think it needs to buffer the data as such. All it does to handle writes to internal regs is this (constantly clocked within the main always block)...

if ({gd_cs, gd_addr} == 5'b10001 && gd_wr_rising) begin // WRITE to "gd_features_reg".
gd_features_reg <= gd_data[7:0];
end

And when the DC wants to read a register, the FPGA just allows access to the regs using the assigns and "Output Enable" driver assign at the top of gd_emu.v
(the STATUS reg also has a separate read handler, which is just there to clear the interrupt flag like it's supposed to)

I was mainly trying to get it to increment the DMA address automatically / asynchronously, so that the data was prepared sooner and the DMA transfer took care of itself
(apart from monitoring the byte count to know when to finish / assert the int / send status back etc.).

tbh, the DMA / address incrementing seems to be working great atm (by clocking the async sigs through FF's, then checking for falling or rising).

With all that said, I've come to the conclusion that I should wait until I do the FLASH BIOS mod! lol
That way, I can hopefully compile some DS code or scripts so I can use the DC itself for debugging.
Even be able to display the contents of DC RAM on screen would be a Godsend.

btw, does anyone know if the REAL source to the gd-ripping code is available? (not just the LUA script).


Thanks, calpis and FG, :encouragement:
OzOnE.
P.S. I know it's mentioned before, but has anyone tried connecting a GD Drive directly to a PC? It will need a custom driver, but the cable would be simple enough.

 

i dont think anyones ever tried you would likely be the first to ever hook a GD drive to a PC
then maybe we could use Linux to dump the |GD firmware and examine it

i think we might have a much easier time if we could get a dump of the GD firmware

 

Yes, I've connected a GD-ROM drive from a NAOMI to a PC, it's just a SCSI interface, but there's no drivers for it as said so it can't be used.

 

Technically yes because the negedge reset it's not actually an edge in hardware like the posedge is. The language parses the HDL in the block and figures out by implication that it's async reset which are really level sensitive, not edge sensitive, and implements that instead of what is literally specified.

You can't for example:

always @(posedge clk or negedge clk) // requires a DDR FF which isn't built into the language

or

always @(posedge clk or posedge otherclock) // this doesn't quite make sense in a design, but you could manually implement it if you don't mind the bad timing and metastability

If you're implementing a FIFO as you should you can "reset" the address either by having it roll over or do a synchronous reset using the same clock signal (/RD and /WR strobes). So if your buffer is 512 words, it will automatically roll over with a 9 bit address. If you have a weird 600 word buffer then

always @(posedge rd_n)
begin
if (addr == 599) addr <= 0;
else addr <= addr + 1;
end

I'm not sure exactly what is meant but I think so.

always @(posedge clk) q <= d;

always @(negedge reset_n) q <= 0;

this would be illegal because async reset isn't implied. For all the language knows you really want to control the register synchronously from two drivers.

This is using the system clock to sample the bus right? It's only a matter of time before you get a glitch because the bus is sampled at the moment it's also updated. You can filter this glitch quite reliably by using the "synchronization flip flops" or more complex methods but now your bus is delayed and you might not meet critical timing. BTW, if that's what you're doing for gd_wr_rising, remember to also synchronize gd_cs and gd_addr too, they should have the same delay.

 

@angelwolf71885 - Yep, I don't think the driver would be too difficult, and might give a great insight into the security commands etc.
After the security response is taken care of, the interface is fairly similar to a "normal" CD drive apart from the SPI commands.

@splith - did you ever get the PC to recognize the NAOMI drive in any way? Was it definitely a SCSI card?
I only ask because I always assumed the NAOMI drive was actually still IDE like the DC GD, it's just that it uses a "SCSI" type D-Sub / Centronics plug?

Thanks, @calpis, that clears a few things up.

Yep, that's what I meant. I know you generally can't drive the same reg from more than one always block, I wondered if there were other ways of doing it?
I suppose you could use flags, but is there a neater way? I've seen that many people just use separate always blocks to set / clear regs based on which state the main FSM is in?

I find it strange that many things seemed to be compiled by "implication" with FPGAs? I'm guessing a lot of these coding rules comes from industry / chip planner standard practices?

AFAIK, it's not sampling the bus directly as such. It clocks each async signal through two FF's first, then checks for a rising or falling edge...

reg gd_wr_n_1, gd_wr_n_2; // Flip-flops for detecting async edges.
reg gd_rd_n_1, gd_rd_n_2;

wire gd_wr_rising = gd_wr_n_1 & ~gd_wr_n_2;
wire gd_rd_rising = gd_rd_n_1 & ~gd_rd_n_2;

wire gd_wr_falling = ~gd_wr_n_1 & gd_wr_n_2;
wire gd_rd_falling = ~gd_rd_n_1 & gd_rd_n_2;

always @(posedge mclock or negedge gd_rst_n)
if (!gd_rst_n) begin
gd_state <= 10'd0;
blah blah blah
else
begin
gd_wr_n_1 <= gd_wr_n; // Update edge regs on every clock.
gd_wr_n_2 <= gd_wr_n_1;


gd_rd_n_1 <= gd_rd_n;
gd_rd_n_2 <= gd_rd_n_1;

main code / state machines blah blah blah
end


This is the way I've seen it done on many web tutorials, and I don't know another way of doing it apart from clocking things directly using the async signals
(like in my previous post) http://www.assemblergames.com/forum...Facebook-group&p=596710&viewfull=1#post596710

(blimey, that's a long URL)

I suppose it's still "sampling" the async signals, but I read that passing through a couple of FF's basically registers and synchronizes the signal?
(This is also what Marshall suggested to me when I was helping him with some of the N64 cart emulation code).

Anywho, I was desperate enough yesterday to even try hooking up an IDE port to the new board again to retry the old CF code...
This is still a PITA without a custom board; I had to crimp wires into plugs in a certain order and snip bits of plugs off to fit two side-by-side etc.
Needless to say, it didn't work at all. :moody:

I'm not exactly surprised - it must be a wire in the wrong place or something.
I'll test it all with a meter once I find the motivation. lol

In the mean time, I'm waiting for my shiny new FLASH chips to arrive (Thanks to @splith and @Bad_Ad84!)
I can then have a play with KOS / DS and perhaps attempt to write my own sys calls or assembler routines for reading GD's / SD / FPGA.

(a LOT of learning to do first)

I still can't find any decent low-level source code for accessing a GD on the DC itself. If anyone has some code, please shoot it my way. :wink-new:
Preferably, this would be a stand-alone / homebrew app in C which doesn't require KOS or any pre-compiled libraries etc.


OzOnE
wow - I was intending to keep it a short post this time, oh well.
You might need to take the laptop in with you when you're taking a d*mp. lol

 

Why do you need to do that? It doesn't make sense to me.

Have you worked with discrete logic chips before? How would you tie a register's clock to multiple sources? I'm afraid you're looking at programmable logic in terms of procedural software where as long as multiple threads aren't in contention for a variable you're free to time-multiplex it. HDL won't build systems for you where stuff like that's possible, it's too complicated and wasteful and in many cases impossible unless your input signals are referenced to the FPGA's clock, but you're free to build it yourself if that's what you want.

This doesn't make sense to me either. If you have a FSM in one block, evaluate all of that FSM's input in that block. Otherwise you get broken Rube Goldberg logic.

It has nothing to do with FPGA, it's Verilog (which is still a lot closer to the hardware than VHDL), if you designed with schematic entry everything would be unambiguous.

In Verilog "regs" aren't necessarily regs depending on which type of always block they're in, and sensitivity lists define which edges if any the block is evaluated.

always @(posedge a or negedge b or c)

here the block gets evaluated by the rising edge of a, the falling edge of b or ANY change in level from c.
It's then up to the language to try to design the logic to fit those constraints, which may be impossible based upon the language's lack of knowledge about the signals in the sensitivity list, the block's other input signals, or the physical hardware implementation's abilities.

You're still sampling the bus as opposed to letting the bus drive the FPGA logic.

You don't have the sync FFs for the address or data bus to provide a uniform delay do you? This is a must.

 

I can't remember much about connecting up the GD-ROM to a PC, all I remember is it was on my GBA dev PC and I replaced the SCSI2 cable for the GBA kit with the GD-ROM and booted windows.

 

@splith - received the chip and piggy-backed it fine! It was a tad more difficult than I first thought (I must be out of touch).

I bridged a couple of pins at first, but sorted it quickly and had the mod done in around half an hour. I wanted it to look neat, so I put heatshrink on the resistors and bridged them across from pin 1.
Then I joined pin 1 to 3.3V at the closest end of R522. The Kynar wire I have was too big to fit through the /WE via, and it didn't want to solder directly, so I soldered it directly to pin 9 of Flash.

(I would have uploaded a photo of the mod, but my cheap £2 Bluetooth dongle refuses to work.)

Anyway, all went well and flashed it OK with the DS "Bootloader with BIOS".
I'm assuming the DS "Bootloader" option with the red swirly was the original BIOS for homebrew, but the text-only "Bootloader with BIOS" contains more of the original sys calls so that retail games will work?

EDIT: Just answered my own question - I checked the hex in the DS BIOS files, and the "DS Bootloader" only appears to have the basic KOS installed (only ~0.5MB filled).
The "DS Bootloader with Bios" has most of the original code.

Is this OT? Should I post programming questions in another thread?...

I also managed to install DC Dev R4. I got Cygwin compiling things fine (KOS examples), but Code::Blocks is still throwing errors about romdisk and wfont not linking?
I've Googled and seen threads about compiling with Cygwin first (which works), then copying and linking romdisk and wfont to Code::Blocks, but I'm not sure exactly how to do this?
Is this just a case of copying the object (.o) files into the Code::Blocks project Dir, then adding some linking options in the project?

OK, this might be a stupid question - if I take a simple KOS example (like the Adventure text game), can I add code to it which directly talks to the DC hardware?
I want to be able to write to the registers for controlling the GD Drive directly, then reading from RAM to display the sectors which were DMA'd.

Basically, I need to show a few pages of hex on-screen because I don't have a BBA and the serial port will obviously be in use for the SD card.
I will try ripping some sectors to SD first, this will give me a huge amount of debugging info. I'll then try displaying memory on-screen as it should make debugging quicker.

(In case anyone's wondering, I'm hoping to use DS or some custom code to debug this FPGA and finally get it working.
If I manage to learn enough about DC programming, I also hope to interface directly to a hard drive on the GD connector!)

I've yet to hook up the SD Card slot. It will be SO nice to get rid of the noisy GD Drive. I'll have to thank Mr SWAT personally.
("In Russia, Dreamcast also cook very good pies.")

btw, something only just occurred to me last night - has anyone flashed their BIOS with Dreamshell, then removed the GD Drive completely? (for portables etc.)
Is there a BIOS which will boot without the drive connected? If nobody has got their DC to boot without the drive, then there might be a very simple solution...

You just need to supply the AICA's master audio clock using a cheap off-the-shelf clock oscillator.
This should be 33.8688MHz (44100Hz x 768, so 33,868,800Hz). If it's faster or slower, I'd imagine all your audio will play faster or slower too!
The GD drive normally supplies this via pin B23 on the GD connector. This is pad P096 on the underside...

http://yam.20to4.net/dreamcast/va1.html

(second pin down on the far left, in the GD connector group, naturally. DON'T connect to the top pin - this is +12V!!).

This clock frequency is very common for CD players and AV / audiophile stuff. But, you could probably steal the oscillator from the GD drive itself?
It should be a proper clock oscillator module, which takes 3.3V power and outputs a square wave - I doubt a standard crystal would work.

I don't think the AICA needs the LRCK and BCK signals to allow boot-up. I will test this later (my FPGA board supplies all of these signals, so I can unplug the GDD).

OzOnE.

 

good stuff Ozone!

few month ago i had same idea about direct connecting HHD to gd connerctor, and using flash-bios and sd mod. DS has option to write module (soft driver) and storing them in SD. it can give access to hw registers. but i didnt test it in practice. just told with Mr SWAT.

 

Hi, all,

OK, I don't know if everyone enjoys reading these long posts.
Please let me know if I should try to cut them down a bit / get to the point (honestly, I really don't mind) :cool-new:...


I had HUGE problems with SD cards for many hours yesterday, and I think I might have damaged one or two cards due to a silly mistakes.
It looks like probably damaged my SD readers too, so I just bought a new internal reader, I hope it works better than the last two.

I thought I'd try and save myself a bit of time by using an SD slot from an old DVD player. NOT a good idea!
I'd used the exact same type of slot fine in another project, so I thought it would be OK.
Basically, I'd forgotten that it has resistors on the SD board so it can work with 5V signals, not 3.3V that the DC serial port uses!!

In the end, I just had to pray that my three or four micro-SD cards would work and I just soldered the wires directly to my remaining micro-to-SD adapter. :encouragement:
In the mean time, I "borrowed" my Dad's SD reader and got DS and everything booting OK.

I also had to get PIO transfers working on the FPGA so that I could try the standard "gdrip" app on Dreamshell to help debug the FPGA.
The only reason I needed to add PIO support was because the standard cdrom functions in KOS (which "gdrip" uses) only support PIO.

(Every real GD disk I've seen uses DMA for all sector transfers, not PIO).

So, it I can't yet directly test the normal DMA loading, but I need to see what the hell the DC is actually reading from the FPGA.

OK, next problem. The "gdrip" included with DS does now appear to be reading the sectors via the FPGA (I can even watch the data fly across on the PC and it looks OK), but it just says this...

"Please wait, checking to disc..."
"Reading IP.BIN ..."
"You inserted not a GD-ROM disc!"

At least it shows that the data I'm sending is NOT correct for some reason?
But I now need a way of displaying that data on-screen, so I tried compiling my own command for DS...

I've installed DC DEV R4 and all it's own examples compile fine (under Cygwin).
I gave up on trying to get things to compile under Code::Blocks. It still complains about linker stuff missing?

So, I nicked some code from the dreamrip201 source and I'm trying to get it to compile as a DS command...

http://pastebin.com/uA3rWb1v

All I'm really interested in is getting it to print the hex as ASCII on-screen....

for (i=0; i<32; i++) {
ds_printf(" %01X", secbuf+i);
}

The problem is, I don't think you can compile raw code (with standard "printf" etc.) and run it under DS...
You need the handle the DS command structure and add the DS includes etc.
I got the basic KOS example to compile, but it won't work under DS for the above reasons (just hangs the DC).

Right, NEXT problem - The Dreamshell SDK examples don't seem to compile under the toolchain included with DC DEV R4?
There are tons of files missing, like these...

../../../include/ds.h:61:23: kos/rwsem.h: No such file or directory
../../../include/ds.h:62:32: kos/recursive_lock.h: No such file or directory
../../../include/ds.h:63:22: kos/once.h: No such file or directory
../../../include/ds.h:64:21: kos/tls.h: No such file or directory

So I'm stumped once again!
Does anyone know if the DS RC1 SDK files can compile with DC DEV R4?
Is it necessary to wipe out my nice working Cygwin, then install gcc again from the DC SWAT download page?

I've just registered at DC SWAT. I'll paste some of the this post there later on.

Cheers,
OzOnE.
btw, I learnt some more about the DC syscalls yesterday. What's good is that the dreamrip source appears to talk directly to the GD_ROM syscall!...

\\ 0x8c0000bc is the original BIOS GD_ROM syscall location!...
#define MAKE_SYSCALL(rs, p1, p2, idx) \
uint32 *syscall_bc = (uint32*)0x8c0000bc; \
int (*syscall)() = (int (*)())(*syscall_bc); \
rs syscall((p1), (p2), 0, (idx));

 

Ozone, i tryed ask to Swat about soure code he used for chaning original syscalls. but he afrid give any info, he said he can help write any kind of driver or additional code for DS support. its sad - he know info about sysalls - so he know what they acts and what for. i see myself - it has simple mechanism of storing and using, but to dicover how it exactly work i thuink i use disassembling.... only if you can discover them early - it would be very good.

so, i see you not want to use any help in AHDL or Graph?

also - it's very useful have connect with pc, you can see what in you buffer after DMA, i think serial can be used for this task. but i plan make usb support even on gd-rom board. its too hard working in blind.

 

I don't think people here will be able to help much with the DS problem. Only at DC SWAT you'll get some help.
But I enjoy reading about development, it's a good way to keep learning about the structure on the dreamcast.

 

@cybdyn - I think the syscalls would be interesting, but I think I need to confirm that I'm transferring the data OK first.
Hopefully then, SWAT might be able to add support for the FPGA in DS.

I can understand him not wanting to show the syscall info. Then again, there is a fair bit of info out there.
Marcus' page explains the basic syscalls....

http://mc.pp.se/dc/syscalls.html

It took me a while to understand how the syscalls are called, but it's quite simple really.
It's just an address pointer that gets written to ram. You just read the specific address then jump to the address it points to.
The arguments for the syscall should already be in the CPU regs before it gets called.

In theory, I guess you can just write some different pointers to ram that call your own routines instead.
It looks like it would be very hard to program and debug though?

btw, I just pasted some disassem that I did in a couple of hours. I'm not a s/w programming expert, but I can read most of the assembly OK.
I had to step through the code using the MESS debugger to work out a lot of the values.
I don't think I'm allowed to post it here since it's a BIOS R/E??

Yep, it's very difficult not knowing exactly what's being transferred to DC memory.
I can watch the data from the PC side (via JTAG / SigTap), but it's very limited in the amount I can capture at any time.

Could you possibly show a very small section of your AHDL code? I've never used AHDL before and I think it would take me a long time to learn.
Can you understand the Verilog that I posted quite easily, or would it be good if it could be translated to AHDL in some way?

Also, what is Graph? Is it just a graphical way of making logic, or is it a specific software program?

@veggav - Yep, I'll definitely post on the SWAT forum when I've got energy. :tranquillity: lol
He'll probably have many answers for me.

I spent another whole day today messing with compilers and trying to get some code working on DS.
I managed to compile parts of Dreamrip, but it's not much use 'cos it's not DS compatible and just gives a blank screen then resets back to DS.

Oh well. I'm now trying to think of any other way of viewing the GD sectors on screen.
I can't really boot the DC from a disk because I can't have the GD drive plugged in at the same time.
That means that I have to use the serial port for the SD Card and DS, so no serial uploading.

(and I don't have a BBA, only a crappy modem. I could technically use the modem, or maybe hack a serial port into it??).

Just out of interest - Does anyone know of any homebrew disassemblers or memory viewers which run on the DC itself?
Maybe I could get the file to run from DS as an ISO or direct BIN / ELF?

(I'm going to test if Gameshark or Action Reply are any help.)

I think I'm SO close to getting this thing working. There's just some evil bug somewhere.

Thanks,
OzOnE.

 

my thought about connecting the FPGA and the GD drive at the same time would be to get another donor dreamcast and take out the |GD connector from the motherboard and the |GD drive and create a FPGA GD sandwich

 

I've been wondering about the best way of making an adapter for that.
It might even be possible to switch between the GD drive and FPGA easily by just holding the /RST pin low on the GD side.
The FPGA could then talk to the GD drive as well - this could allow direct ripping via USB.

IMHO, the best adapter would have a standard 40-pin IDE (or 44-pin laptop) socket on it (since the G1 port is basically IDE anyway).
The extra signals for CDDA audio would be on a separate connector as well as power.
That would allow a hard drive to be plugged directly into the DC at a later date (if we get that far with the programming?)

One problem with a direct connection is the DC still needs the clock to the AICA before it will boot. This can be done with a cheap oscillator on the adapter board.
Obviously, CDDA audio will NOT work with a direct HDD / CF connection unless someone figures out a way of streaming via software too?

Anyway, a bit of good news for a change! I'm starting to get somewhere with this board! :biggrin-new:
Don't build your hopes up just yet, it's not quite booting...

I had a good night's sleep and woke up around 6:30 this morning...
After tea and toast, I somehow managed to get the GD debug code to compile under Cygwin...

It's very basic (all I needed atm) - All it does is print the first couple of lines of IP.BIN to screen.

I just "stole" the main bits of code from Dreamrip by BERO (so thanks to him / her?!).
I then made sure I could compile the simple "keyboard" example from KOS / Libdream and added the Dreamrip code to it so I could print to screen.

The damned thing actually worked when run from DS! Please excuse my lazy "coding" style on the bits I added or changed (x, y, "bfont_draw" etc). ...

http://www.filedropper.com/gddebug01ozone21-7-12

Straight away it showed the main problem - I told you guys it would be a STUPID mistake on my side. :redface-new:
Something I've been suspicious about for a while now...

THE SECTOR DATA WAS BYTESWAPPED!!!! wft!!??

I don't remember at any point needing to byteswap the data before? Maybe that's why I had better luck with the CF card?
At least it seems to confirm that the data is OK; I still need to keep an eye on it though.

So now, it actually loads the first 7 sectors of IP.BIN (at FAD 45150) and I was greeted by the wonderful "Bwrrrriiing!" sound on the DC menu.

Unfortunately, it doesn't boot to the Logo yet because when it tries to read the bootstraps (from FAD 45157), the crappy SD Card driver ignores the sector address
and keeps sending out the first sector instead (start of IP.BIN, again!).

OK, so I'll have to implement the SD Driver from Opencores or something, or figure out why this one isn't working right.

More news when I have it.

EDIT: All they had to do was add a few lines to the SD Driver. It can now read the other files in the GDI.
Wasn't too much to ask was it? lol...

Multiple_Block_Read:
case(MBR_state)
MBR_Send_CMD18:
Command_Arg <= Host_Command_Arg; // This now sends the sector offset to the SD Card.
endcase


No booting of the game yet, but WE HAVE SEGA LOGO!

So we're now back where we were 7 months ago.
It boots to the license screen, and is trying to read 1ST_READ.BIN, but is getting stuck after a SET_MODE command (yet again).
After the logo it just goes back to the DC Menu and says "Please wait while disc is being checked. blah blah".


OzOnE.

 

we could probably have the connector part for the dreamcast mass produced that way it would be a plug and play solushion

 

No need. :wink-new:

http://uk.mouser.com/ProductDetail/Molex/52584-0579/?qs=nDwhpid8gJawAJ3E%252bLks9O/PjG3S5Rk4
http://uk.mouser.com/Search/ProductDetail.aspx?qs=Y/rI5Y8Al88XZnlCvKRZSg==

Ok, so the GD one is out of stock atm, but it looks like they are still produced and Molex themselves show them...
http://www.molex.com/molex/products/datasheet.jsp?part=active/0525840579_PCB_RECEPTACLES.xml

(I know the image of the GD connector looks longer, but the part number should relate to the 50-pin version).

They can also be bought from China in minimum quantities of 10 for a pricey $0.1 - $1 each! (ouch, expensive).

btw, still no boot. And "gdrip" on DS shows this?...

DS_PROCESS: Please wait, checking to disc...
DS_PROCESS: Reading IP.BIN ...
GD-ROM:

No Type Start Size MB
Session 1
1 DATA 0 600 1M
2 AUDIO 600 5950 13M
Session 2
3 DATA 45000 504150 1032M

DS_PROCESS: Writing to /sd/Track03.iso ...

DS_PROCESS: 0 from -659 Mb ripped, 0 Percent completed
DS: No more DATA on this track.
DS_PROCESS: 0 from -659 Mb ripped, 0 Percent completed
D$:


OzOnE.