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

Maybe that's where I went wrong! *eyes dart side to side* Yeesssssssssssssss :friendly_wink:
Pretty sure I went the chisel route, not sure I had decent desolder braid at that point...
Well that and that I was possibly soldering a completely incompatible chip in... :biggrin-new:
If I were to have the need to try it again though, I'd definitely give it another go!

 

I find wick to be useful only when you want to fully remove solder from solder pads. I tried using the flooding technique but you have a big chance to end up with an unreachable solder bridge between 2 pins deep under the bridged pins. Then you start to try and bring it up front but you'll put alot of heat on those 2 pins and depending on the component you could damage it.

I've seen alot of people who brought boards with this and most of the time I ended up removing the chip, clean the solder pads then put it back on the "traditionnal" way.

And it's true that bigger soldering tips do the best job! Really pointy tips won't hold small solder drop onto the very end of the tip.

 

That's just practice, though - if you end up with any significant amount of solder on the part of the lead frame that's not lying on the board you're doing it wrong. I used to not like that technique too - until one of the technicians I was working with showed me how to do it right - basically, you have to be fast, and use the inside edge of the chisel bit to keep the solder away from the inside of the lead frame. This guy was soldering 0.5mm pitch 240 lead QFPs and taking about 2s to put the solder on each side. Then when you wick off the excess you put the edge of the wick up against the bend in the lead and apply the heat there.

I watched him build 20 protos like that (in addition to the big QFP, there were a couple of smaller ones and some TSOPs), and he didn't leave a single solder short on the board - I'm not pretending to be that good, though :friendly_wink:

 

A good really-fine tip that holds solder is *priceless* though! Maybe not to solder chips with lots of legs, but for R or C that are very small; or a wire to a small via.

 

A fine tip is also very useful for initially soldering parts down - These are the two I normally use, and between them can handle pretty much any job without having to change tips.

 

I must admit that the fact you point out is so true.

Maybe it's because I haven't invested in a really high quality tip that I found them to be more messy than anything else. I should hunt down one of these.

 

Yeah, I'm lucky enough to have free access to a badass soldering station (http://www.jbctools.com/nast-nano-rework-product-11-gama-11-category-11.html) and I can tell you it makes it easy to piggybank a dreamcast bios! It's overkill for hobbyist stuff though, I just use it because I can, would never buy.

Picture for reference:

 

Any particular reason you soldered the WE/ wire to the pin on the TSOP rather than the via? That just seems to be making life harder for yourself...

 

I had a hard time making the solder stick to the via (you can see I tried on the pic), and using the very-fine "hook-shaped" tip and a binocular I had no issue soldering on the chip, so it saved me hassle in the end.

 

Cool stuff. I must admit that it would make it really easier to solder really small pitched devices. For the rest, I still have good, young eyes!

 

OK, after seeing Cybdyn's great progress with this, I thought I might paste the Verilog source for my GD EMU attempt again...
http://www.multiupload.nl/SGFLL06D53

Hopefully this will help somebody out, as I don't really have time to continue with this project atm.
The code is still at the non-booting stage ofc, but it loads up the very first part of Crazy Taxi (the black screen with the white debug text) then gives the AICA_DRV error.

The code is the one with SD card and SRAM (not SDRAM, 'cos it sucks to get working).
The SD card code is the one that came with the cheap FPGA board I was using, it's not the best and I had to modify it slightly so I can pause the transfer.

(To be honest, it's been many months since I last looked at this, and I can't remember exactly what state the code was at.)

A lot of stuff like the TOC is hard-coded, and there will be many issues and bugs to sort out.
It will also need the pin assignments changing for your specific board ofc.

Just to reiterate - this code is NOT booting game images yet!

If anyone wants to try diving in with the FPGA stuff, please don't hesitate to PM me or post on here and I'll try to answer any questions if I have time.

Good luck with the build Cybdyn! It's looking great so far. :wink-new:

What it really needs to test my code is a high-speed debug output via USB (which your board should be capable of?)
You could then compare between the exact data that's being transferred from the real drive / disk with the data from the Emu board.

I don't think the actual data is corrupting, so it's likely a problem with the drive status / control stuff.

Or, could just be the security data isn't correct (taken from the NullDC source).
Although, without that security data, it doesn't even attempt to boot to the license screen.

OzOnE.

 

Thanks - this is very interesting to look at - I have actually connected one of my DCs to an FPGA, but all I've done so far is a bit of data logging, and this should encourage me to have another look at it.

Yeah, I had a lot of fun with SDRAM and those Cyclone FPGAs - my eventual conclusion was that if you tried to connect the SDRAM clock line to the same source as the FPGA clock then it's simply impossible to meet the setup and hold time requirements. To get it working, I had to introduce about 80 degrees of negative timing skew on the SDCLK line using one of the PLLs.

 

i'm working on debugging of psio, so i dont know when i reach to dcio. maybe soon
i think using of ARM based controllers will help reduce time of developing and most of them have built-in hardware : SD card, sdram, usb host! controllers

 

Ah there's no rush, we've all waited this long. A little bit more will not hurt.
Plus the PSIO project is just as great a cause as DCIO! Your work is appreciated on everything! :encouragement:

 

I dont like the flood technique. Once you get the knack, drag soldering you learn how much is "enough" and hardly have any excess. What excess you do what, you can "swipe" away from the pins and job done.

 

Hi, all,

Firstly, just a quick request...
Does anyone in the UK have an OTI-9220 type GD-Rom board that I could buy from them?

I've sent a couple of the DC to IDE adapters to SWAT to see if he has time to add support to Dreamshell, so in the mean time I thought I'd have a go at "attacking" the GDD firmware itself.

The board looks like this ofc. Did they even use them in European DCs?...
http://chip.tut.su/=dc/dc_parts/GD-rom-plate=XU937-OAK-OTI.jpg


I also spent some time working out some of the test pads on the Yamaha (/Samsung??) board.
I know Cybdyn and others have done some work on figuring out the chipsets (on DC SWAT), but here's what I have so far if anyone's interested...

(I did more of this a while ago, but I can't find the damned text file atm)...


Yamaha GD board test pads...

TP101 - TC9450AF Pin 29 - VCREF?
TP102 - TC9450AF Pin 32 - SLCO

TP103 - TC9450AF Pin 45 -
TP104 - TC9450AF Pin 46 -
TP105 - TC9450AF Pin 47 -
TP106 - TC9450AF Pin 48 -
TP107 - TC9450AF Pin 49 -

TP108 - TC9450AF Pin 53 - FLAG A
TP109 - TC9450AF Pin 54 - FLAG B
TP110 - TC9450AF Pin 55 - FLAG C
TP111 - TC9450AF Pin 56 - FLAG D

TP112 - TEST?? (pin 68)


TP113 - TC9450AF Pin 77 - Left Audio Out
TP114 - TC9450AF Pin 80 - Right Audio Out

TP115 - TC9450AF Pin 27 -

TP212 - TC9450AF Pin 99 - EMPH Out
TP215 - TC9450AF Pin 3 - I2S SDATA Out
TP216 - TC9450AF Pin 4 - DOUT (SPDIF!)
TP217 - TC9450AF Pin 5 - XOUT (Clock?)

TP219 - TC9450AF Pin 13 - SBSY = Subcode Block SYnc.
TP220 - TC9450AF Pin 12 - SFSY = Playback Frame SYnc.
TP221 - TC9450AF Pin 7 - SBOK = Subcode Q data CRCC result.

TP222 - TC9450AF Pin 2 - BUCK = Micon Clock

TP223 - TC9450AF Pin 11 - DATA = Subcode P to W Data output
TP224 - TC9450AF Pin 8 - CLCK = Clock for reading Subcode P to W data


J5...
1. GND
2. TXD0 (from TMP95 Micon)
3. nc
4. nc
5. +5V
6. nc
7. nc
8. nc


J7...
1. nc
2. TC9450AF Pin 16 - COFS
3. TC9450AF Pin 14 - SPCK
4. TC9450AF Pin 15 - SFDA
5. GND
6. Micon pin 12 / TP14.
7. GND
8.


A while ago, I did hook up a TTL serial-to-USB adapter to that TXD0 pin on J5, and it outputs a lot of debug info. Not sure how useful it is though?

I mainly want to put to rest exactly what this "magical" register on the Holly chip does to lock / unlock the G1 bus.
I know you need to transfer the BIOS across the bus after setting the BIOS size in this register (0xa05f74e4), but I want to know if the "checksum" can be brute force attacked?

Also, I'd love to know what exactly the security command does on the GD drive. To my knowledge, this algorithm has never been fully understood?
The only way to completely understand this is to of course extract the firmware from the MPU on the GDD board.

We know the different GDD boards use either a Toshiba TMP, Hitachi H8, or OTI-9220 microcontroller, but the firmware will likely be protected in all of those chips.
The OTI-9220 board seems to have far more test points connected though, which may help with reversing some stuff?

I'm also gonna do more Logic Analyser stuff on the GDD board to see what the 4-bit bus commands are between the ATAPI, MPU and Servo chips.
It may prove more rewarding to use the original chipset, but just emulate the accesses to the Servo chip itself?

I'm even thinking of getting the MPU chips on some GDD boards decapped, so we can finally crack this nut.

Does anyone have ANY inside info on whether the GDD actually tries to read the "barcode" on the disk or not?
I may have to try covering parts of the disk with tape to see if it still boots?

Just wondering if this might get us somewhere, as this DC thing has been bugging the hell out of me for years now. lol


OzOnE.
EDIT: btw, it looks like most of the GDD boards have analog as well as digital audio outputs (S/PDIF).
Don't know how interesting that is though, it's just for the CDDA tracks.

 

Oh, and just for reference, this is basically what the DC BIOS does to "reactivate" access to the GD drive?...


/* initialize ROM checksum */
*HW32(0xa05f74e4) = 0x001fffff; // <- This is the size of the BIOS ROM, not sure if the exact size matters to the "checksum"?. OzOnE.


/* switch to double precision (for 64bit copying below) */
reg[FPSCR] = 0x00140001;


/* Copy various parts from ROM to RAM */
/* This is done for two reasons:
* First, code and data must be available to be executed from RAM
* secondly, the data read from ROM are passed through some type
* of "checksum". Unless a specific value is computed, a flag is
* set to disable the GDROM drive. Sega must have put this in there
* to "discourage" people from replacing the BootROM with their custom
* versions!
*/

Also has this part in the BIOS?...

/* could this disable gdrom? */
*_a05f74e4 = 0x000042fe;


I wondering exactly what "access" to the GD drive is being blocked without this code?
It's apparently a hardware register inside the HOLLY which does this, but maybe there's a brute-force way to find a valid checksum?

If a custom BIOS could be used which contains just enough code to cause a valid checksum, surely this would bypass the BIOS / HOLLY part of the protection?


OzOnE.

 

i think it unlock Holly - cause bios is copied in the first stages of boot strap before any access to gdrom. but you can notice bios starts coping not from 0 , but from 0x100 . before it placed init code for sdram and something else. this is the place where we can mode code a little))) and after copying bios we can execute moded code. and fill mem with new data...

 

Hi, cybdyn,

Do you think it might be possible to make the "checksum" pass without transferring the original BIOS?

If there is a way to check what the Holly chip is blocking, then maybe it would be as simple as checking to see if that gets unlocked while transferring some data from the BIOS?

Then, maybe the check code can be made much simpler by only transferring a very small amount? (just enough data to get it to pass)?

I still don't know what's stopping the "DMA done" flag from working, so maybe that is what the HOLLY disables?
This would make sense, as it would be simple enough for the HOLLY to disable the /DMA_ACK flag.

hmmm, some more thinking to do on this. I'm just looking through the DC BIOS again in IDA Pro for more info.
(the disassembly files at the bottom of this page are incomplete, and don't contain the Packet commands stuff)...
http://www.ludd.luth.se/~jlo/dc/


OzOnE.

 

we pass data from bios but then we execute our code... better i'll try show it when i get to my board)) i dont think it's easy understand algorithm of calculation chk summ, better leave it as is. cause every dc has bios))

maybe you missed something when perform comand "a0 : 71". and gd emu is not initializeproperly. or you select from gdrom to emu after all chks?
also i hear from somewhere gd-dma clocks data on every edge ? - as dma mode 2 or ?