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

also - you can find pinout of tc9450 from pdf on samsung pc cd-rom. like sc 140, sc 148, sc3232

 

I think a lot of my problems is because I hate waiting for the DC to boot from the GD drive, so I've got Dreamshell booting from SD card.
This is why I can't use serial debug, or could be causing problems with the checksum?

When SWAT said he "got lucky" with the checksum, does that mean his DS-with-BIOS passes the check OK? I'm guessing it must do?

With the 0x71 command, I was sending back the fixed data that nullDC uses. Without this exact data, the DC won't even boot to the License screen?
I've tried using the response data grabbed from real GD disks, but this won't work either, as it appears to have some sort of random seed?

I tried the fixed nullDC data with the PAL / NTSC / DEV BIOS too, but no change.

The DMA doesn't use both clocks (like UDMA), it's just simple MultiWord DMA Mode 2 (IIRC).
So 16.66MBytes/s peak, and transfers only on the rising edge of "gd_rd_n" (data prepared on the falling edge)...

http://www.assemblergames.com/forum...Facebook-group&p=596703&viewfull=1#post596703


The more I think about it, my real problem appears to be this...
http://www.assemblergames.com/forum...Facebook-group&p=597943&viewfull=1#post597943

My TOC looks OK (it matches a real TOC exactly), but maybe something is wrong with my session info?
As soon as "gdrip" tries to read the tracks, it shows these weird negative values, and also shows -659MB as if it's trying to read it as a CD-Rom??

Oh dear, I didn't think I'd be getting back into this again, but I won't ever completely stop until these things are solved.

@cybdyn - did you say you've used Altera FPGA's and Altera Quartus?
You can do some great things with it, like that SignalTap screenshot, but each capture is limited by the on-chip RAM (very small).

I have just "built" a 32-channel Logic Analyser though. It's just an FPGA board with SRAM on it.
I've sent it to a friend atm for testing something, but I will plug it into the IDE port on the DC soon to capture MUCH more data.

It's based on the SUMP code. Have a look at the "Altera DE2" example on this page...
http://www.sump.org/projects/analyzer/?addComment

 

Yes, I saw the good work on DC SWAT with finding the different pinouts etc.

I spent most of the past two days looking for more info on the GDD...

I have the SC-140 schematic PDF, but it's quite hard to read? I tried changing the font with all sorts if software, but the text is done using "glyphs" / graphics.

EDIT: Ooops, you're right again. I forgot about the SC-148 PDF. Much clearer, thanks! (page 6)
http://elektrotanya.com/samsung_sc-148b_cdrom.pdf/download.html

The SC-140 schematic is what I used for most of those TC9450 test pad pinouts.

I still couldn't find the exact TC9450 datasheet, but the TC94A14 and TC9462 has some basic info on the 4-bit bus protocol (page 9)...
http://www.datasheetcatalog.org/datasheet/toshiba/4219.pdf

If somebody can find the full protocol for this, a GD Emu could be made which just emulates the Servo / CD Controller chip instead?

It's a very common protocol for CD Servo's apparently, but I still couldn't find any real info on it?

btw, I also noticed that the Yamaha / Samsung GDD board uses the Hitachi HD6433396 (it's actually the H8/3397 Series, 80-pins, so pinout is on page 41)...
http://documentation.renesas.com/doc/products/mpumcu/e602078_h83397.pdf

It's a shame we can't easily read the code out of these. I'm fairly certain they would have enabled the code protection bits.

 

I have a spare board - if you can't find one locally, I would be happy to donate it, although it might take a while to arrive from HK.

 

DC must have overly complicated control and/or hardware parameters to be having this much hell with it...

 

Thanks, TriMesh!

I'd be happy to buy that one from you. Please PM me your PayPal address, and let me know how much you want for it.

@sonicdude - it's not so much that it's overly complicated, just that my programming skills are nothing compared to somebody who knows C / C++ inside and out.
Also, there aren't that many people working on this, and quite frankly, a lot of people aren't too bothered about GD emulation on an old system tbh.

The other problem is the lack of debug info. When the SD card / Dreamshell ties up the serial port, this is a big problem for me.
I was still playing with the DC yesterday, and did some captures of the 4-bit bus between the MPU and Servo on the GDD board.

But, I will have to try booting DS from a CD-R at some point (so I can use the serial port for debug info).

The 4-bit bus stuff isn't going to be very useful tbh.
I can't find the protocol spec anywhere on the web (believe me, I looked through about 400 pages yesterday, and about 80 datasheets).

Unless anyone can figure out the commands in this crap? lol....


I had to solder some Kynar wires directly to the Servo chip pins to grab that capture.
(The actual capture can be many seconds long, the above is only about 240 microseconds worth.)

The /XRD and /XWR pulses are only relevant to the Servo chip (TC9540) when /XCE goes low.

I'm pretty sure the actual CD / GD data goes directly to the ATAPI interface chip.
The 4-bit bus is a low-speed (~1MHz) interface between the MPU and Servo / DSP which commands things like sled movement, and reads the disk presence / focus status etc.

I'm assuming the 4-bit bus protocol is probably a Philips design, but I've never seen the spec for it.
It might be confined to CD-ROM drives as opposed to CD players though, as the latter often used a serial bus for the Servo chip / CD DSP.

It will still be very useful to know what the MPU is doing with the Servo for the different types of packet command though.
This will help us to know how the security commands work.

I saw this spec, but I don't think any of the commands match? (it doesn't have the same signals either)...
http://www.daisy-laser.com/products/cd/modules/cdpro2/p10501_dsa.pdf

I've even started disassembling the firmware of the Samsung SC-148 to try to figure out the protocol (this is a VERY similar chipset to the GDD, but uses a different MPU).

If anyone has any info on the CD DSP or 4-bit bus protocol, PLEASE let me know.


OzOnE.
P.S. I will have fun playing with this stuff for a while, but I don't want to get too hung up on it if Dreamshell can be made to work well with CF / HDD.
Just planning my next attack though.

 

i remember i read long ago a good book about basic knowledge how cd stuff works on the first generation chipset from sony/philips, and the author wrote many interesting things. i dont know if there is such book in English. but i remember he notice about toshiba's servo chip of first generation (1x..2x speed drives) but i think most thing leaves same in modern ones. so maybe search old pdf fo first-generation cd-dsp and servo from Toshiba.
but, this idea as interesting as looks like you go deeeep to dark wood of cd drive electronics))).

http://www.radiofiles.ru/news/cd_proigryvateli_skhemotekhnika/2010-06-28-523

he wrote about TA8191F (servo ic) and TC9284AF (dsp)

but also good information how dsp/servo works you can get from pdf of Sony's chip.

 

try find scm for AIWA NSX-V50 (http://www.devicemanuals.com/productsupport/AIWA_NSX-V50_manual.html)

 

Thanks, cybdyn.

How the hell do you find this stuff?
(helps if you speak Russian I guess? lol)

That book looks very helpful, I can read most of the diagrams etc. (had to install WinDjView, but I converted it to a PDF )...
http://www.multiupload.nl/QSVPW49TB3

I've got the NSX-V50 service manual, but it doesn't show much about the CD chipset?...
http://elektrotanya.com/aiwa_nsx-v50,v52,v54_v51g.pdf/download.html

I think what I'll try next is to use the logic analyser on the data between the ATAPI chip and the MPU?
That would tell us exactly what data is being read, and which commands are being sent from the DC.

We still don't know the internal register map of the TC9474, but the data might give us some clues?


OzOnE.

 

Do these 4-bit commands look like they might relate in any way?

 

where from this information about defenitions?

 

From here: http://nemesis.hacking-cult.org/MegaDrive/CTrac/segaemulation.tar
This is an archive from a former employee of ICOM Simulations, the ones who developed the C-Trac CD emulator board used on the Cross Products MegaCD devkit used by Sega, and in fact, used in a standalone fashion before that unit existed. I acquired this information as part of my ongoing effort to reconstruct the software for this card, which has been completely lost to time, and which nobody I know of who has this hardware posesses.

The C-Trac card effectively replaces the CD drive in the MegaCD unit, directly plugging into the drive ribbon cable. It emulates the drive by responding to the same commands and requests as the real hardware, but loads sector data from a host computer, buffered in some SRAM chips on the board. ICOM Simulations were contracted to build this hardware, so they had access to all the necessary internal documentation.

This archive contains design schematics, and the sourcecode for the emulation program that's loaded on the onboard 6303 processor to drive the emulation. Unfortunately the corresponding PC-side software has been lost, and the schematics and CAD Diagrams are in very old formats that I've been unable to open as of yet (ClarisCAD for Mac and Design Works by Capilano for Mac, pre 3.1 version). The 6303 source however is very interesting. By examining the source, you can understand all the logic of how the SegaCD/MegaCD and the CD drive unit communicate. The Dreamcast may have come along around 10 years later, but I wouldn't be surprised if there were more than a few things in common. And of course, that source should contain everything you'd need to know in order to build a drive replacement for the MegaCD too.

 

did you try some of the open source ones or even googleing the extensions on the files?

 

Ozone, I might have said this before but I'll say it again. Ever try flashing DS to a modded BIOS chip? I don't know if you have other code in there that runs from the SD card but putting DS on the BIOS chip and ditching the SD reader should open the serial port up for better data logging and leave the GD drive free for whatever else.

EDIT: I just realized that might not work either since you need to be able to read the data from DS. I don't know if you can read the data from the BIOS as it comes through. If you can then it might work.

 

Cheers, Nemesis!

Anything like that could prove very helpful. :victorious:

The only other place I've found stuff like that (so far) is in the YDC103 datasheet (page 9). This is a similar chip to what I've seen on the dev kit drives...
http://pdf.datasheetcatalog.com/datasheets/2300/502414_DS.pdf

I've been doing a fair bit of research on the dev kit drives, and have been snooping around the firmware for the GD-X / GD-M / GD-R.
They're very complex though. It would take me far too long to figure out.

I've also asked a company in China if they can "do something" with the firmware on the GD drive.

I never gave thought to the Mega CD, but looks like it could give good clues too.
(SEGA does seem to be one of those companies who likes to stick to proven methods, then updating them).

I'll have a look at that source / schematic, I love stuff like this.
I can even understand the code for once, as it's very similar to the 6502 / 6803.

That data capture from the GD drive was at the Servo chip level, but it looks like the Mega CD source might contain info on that too.

@sonicdude - I've had the Dreamshell + BIOS flashed for a while now, but I wouldn't know how to flash the actual Dreamshell app directly into Flash?
(DS + BIOS is just a small bootloader, so it still required the SD card.)

I'd love to be able to make a stand-alone CF / HDD app without using KOS, but this is also a bit beyond me atm.
I'm sure that I'm missing some mutex stuff on KOS that's screwing things up. DMA from CF still isn't working without manual delays.

EDIT: When you say "read the data from DS", that's the thing, I actually only use DS for running the small app code.
The app then accesses the CF card directly by sending the commands to it via the G1 port (as a "slave" device with the GDD as "master").

If I could find a method for uploading a new app to the DC quickly, it would help a lot. The problem is, I'm assuming that most GDI's require the stock BIOS routines to be intact.
This is what I understand from SWAT as well. He managed to inject his DS bootloader into the stock BIOS, thus leaving the stock GD routines intact.

Although I am trying to bypass the GD syscalls, there are apparently a lot of other check routines in the BIOS too (like the mysterious "magic" GD unlock register).
We know the DC has to transfer the whole BIOS via the G1 bus to RAM before the Holly will "unlock" the GD drive, but nobody seems to know exactly which part of the GD transfers it unlocks?

I think at one point I even tried switching back to the stock BIOS (Eur / PAL), then running my test app from CD-R. Still no joy.
I also flashed to @link83's "dev kit" BIOS, but still no booting.

I've tried a few different GDI's, and even a few CDI's IIRC.
(I compared the Crazy Taxi (PAL) GDI image to the rip of my own disk, and it matches 100%).

Another thing I noticed the other day was that I was doing a "flush" of the cache at the area where IP.BIN / 1ST_READ.BIN is loaded...

I'm pretty sure I'm supposed to be doing an "invalidate" of the cache after doing the DMA from CF to RAM?
I tried this the other day, but no boot. It just shows the license screen then AICADRV ERR -1 again.

tbh, I'm holding out until SWAT can hopefully make some progress with the code. He should receive the adapters any day now.
There are a few other people who may be working on this as well soon, and they are likely MUCH better than me at coding (not a stretch tbh. lol).

What would be more ideal is to have debug output from the DC via the Maple bus or something?
Having to keep writing test apps to CD-R / CD-RW and booting from disk each time would be extremely time consuming, so Dreamshell + SD is the best I can do atm.

A BBA seems out of the question tbh. They're so damned expensive / rare.
Even if I did have a BBA, I'd likely still be stuck at the same point.

Thanks though, guys.
It's more of a personal mission at this point. I really want to crack this nut some day.


OzOnE.

EDIT2: I think it's important to add that the FPGA version gave the same error screen with Crazy Taxi?
The FPGA was using the stock BIOS and Flash though. This was before I even did the flash chip mod.

One difference is that the FPGA has to send the fixed "security" response back to the DC (taken from the nullDC source).
Without that exact data, it wouldn't even boot to the license screen.

With the software / CF adapter method, I'm bypassing the GD syscalls completely, so this is a layer above the security stuff (AFAIK).
What's strange is that both methods give the same / similar results? It could be that I've missed some of the syscalls, or I'm not doing the TOC / session stuff properly?

 

How did I not think of that? Of course it would only be the bootloader. Same as using a burned bootloader CD when DS is on the SD card. So using the full speed of serial port without SD reader is out then. It might be worth looking into the BBA despite the steep cost. It might be fast enough for the real time debugging and RAM access you need. Shouldn't be too hard to make work since it runs off the G2 bus. I know they cost a shitload of $$$ but it might be worth it. If it doesn't work out you can always turn around and sell it for same price as purchase.

 

Oh, @Nemesis - are you looking to emulate just the Mega CD drive, or was part of the aim to find the original software too?

If you want to make a Mega CD drive replacement, I'm tempted to buy one to have a play with.
That file you posted likely contains more than enough to emulate the drive using modern hardware (or even a 6303 core running on the FPGA).

Can't promise anything, since I'm bogged down with other projects atm, but will be fun to mess with.

OzOnE.

 

@sonicdude - I tried getting the serial port debug to work under KOS once the GD proggy is loaded, but even that didn't work?
I'm not sure how SWAT implemented the serial port / SD code, so it might be blocking access in some way?

KOS has quite a few debug console / printf options available, but I'm not clever enough to get them working with Dreamshell. lol

The BBA would probably be fast enough to grab a decent amount of data in real time (is the BBA 100mbit, or only 10mbit?).
I'm just not sure it would be worth the investment atm. Mainly because we still don't know exactly how these security checks work.

I've trawled through the BIOS disassembly and all sorts, but it's kind of a pain to get my head around.

I'm pinning my hopes on SWAT and others. I reckon he should be able to get Dreamshell to boot from CF / HDD at least.
That would allow SD-ISOs to run, and probably a hell of a lot faster too. He is very busy though, so I don't want to bug him too much.

 

what about building yourself SWAT serial to LAN adapter?

http://www.dc-swat.ru/blog/hardware/15.html

 

I think it would work, but would mean booting Dreamshell from CD-R since it ties up the serial port again?

tbh, I haven't asked SWAT exactly what the LAN adapter can do. If it can stream SD-ISO's then it could be interesting.
I'll have to ask him about that. Even just a serial output would be very helpful, but I hit a brick wall each time I thought about it.

I can't recall quite what I've tried now. The GD test app should run direct from CD-R, but I'd need a way to update the file much quicker.

EDIT: btw, @Nemesis - the MAME source is a great place to find out about the Sega CD / CDX inner workings as well.
In the latest MAME source (now merged with MESS), the "/src/mame/machine/megacd.c" file contains tons of info.

MAME has the megacd marked as "not working", but I just tried it with the following BIOS zip and it boots to the BIOS animation fine?...
http://www.multiupload.nl/25ZWKE9DD1