Replace GD-ROM with Flash Card?

@n64coder - Hi, sorry if this is long-winded, but few people can pass an opportunity to talk about themselves. ...

I've been doing electronics as a hobby for many years (when I was about seven I was already taking car stereos apart). I also do TV / VCR / DVD / Amp repair and build audiophile amps etc. All self-taught really.

I then started programming PIC processors in assembly language around ten years ago and it was a fantastic learning resource. I now use AVR chips more often as they seem more powerful for the same cost and are actually a bit easier to program for.

I would HIGHLY recommend anyone to buy a simple kit like the Arduino, then program it in C using AVR Studio (I don't like the Arduino's own software tbh, you don't have to use it luckily).

A few years ago, I got on a mission to get a CF / HDD working on the Doc V64. It took literally months to figure out how the original code worked, then once I got it loading a ROM from the HDD, I had to write the code for parsing the FAT32 file system...

http://www.eurasia.nu/modules.php?name=News&file=article&sid=2124

I'd never programmed a 6502 before but it's quite similar to a PIC I suppose.

I'm a bit of an obsessive when it comes to game console hardware. Mainly with the N64, but it's been fun messing with the DC (when things work as expected). ;-)

Funny enough, I'm not much of a gamer as I get bored easily and I'd personally rather be building or creating something.

My interest in the N64 started mainly because of SGI - I loved seeing the awesome power of those machines when they started being used for CGI in movies like Terminator 2 and Jurassic Park, and for rendering DK Country on the SNES.

Of course, PC's already had 3Dfx Voodoo and PowerVR cards when the N64 came out, but it was still amazing to see Mario 64 for the first time.

Some of you in the UK might remember the superb series Bad Influence (I wish it was still on!) - I mean, just imagine seeing this back in November 1993 when PC's were still running crappy Windows 3.1 and I'd only just got my first CD-Rom drive!...

http://www.youtube.com/watch?v=Z45nbzMLk98&feature=related

The Dreamcast is also a great machine. I'm sorry to say that I left it in the loft (attic) for the past seven years though, so I'm starting a bit of a re-discovery.

OK, enough of that me thinks. I might have to split this into two posts - is that allowed?

OzOnE.

 

@TmEE - It's strange about the interrupt. You'd think it would be enabled by default, but it doesn't look that way? You need to write to the Device Control register to make sure it's enabled, but guess what - I'd need to modify the damn board yet again to control the CS1 pin!

(note to self - NEVER scrimp on IDE pins again!)

I found a way around that though - I finally got the data counter to work reliably.... The /RD and /WR pins from the DC have to be "sampled" to clean them up because they're asynchronous signals (like on the N64 cart slot). This slight sampling delay meant that the FPGA sometimes missed parts of the DMA signal and screwed up the counting.

So, the DC is now reading the first 8 sectors of the gdi from the CF card and I'm generating my own interrupt to the DC when it's finished. It won't boot any further though, and just goes back to the setup menu?

I think this is because I haven't added every single part of code yet. You see, the DC expects the "status" of the GD-Drive to change in an exact sequence of events and it's very fussy.

I was wondering if it was a security response problem due to me using a PAL DC, but this same 0x71 response is apparently used in NullDC for any DC region / BIOS?

@MrSporty - I know you've done a lot of research into this stuff - do you possibly have any copies of your logic analyser logs of the GD interface that you could send to me?

I can only capture a very small window of events via SignalTap, and my logic analyser is only a cheap 8-channel one.
It would be a great help just to see the exact boot sequence.

OzOnE.
P.S. Here's some docs which have been super helpful for this project (especially the CDIF and Gdfm files) :thumbsup:...
http://www.mediafire.com/?iwwiah1hqerii5s

 

Why? Because you want to reuse your old, slow SD cards? I can think of a few reasons why CF might be better than SD but your personal preference isn't really one of them.

But hey feel free to build your own using SD cards. I might even buy one.

 

Loved Bad Influence Violet Berlin and Andy Crane good stuff! Think I still have an episode taped off TV somewhere.

I defo have the last episode of Gamesmaster on VHS sweet!:thumbsup:

 

That's very impressive. I wish I had the time/motivation to do stuff like this.

 

You meant "time/motivation/skills to do stuff like this" I guess?

Seriously, what you're doing is an achievement in itself, but given your background it's even more impressive. Being "self-though" in "dreamcast stuff"/programming/electronic myself (although I'm not excellent in either one of them), I can understand how much effort you've put into this!

Cheers!

FG

 

I concur very excited about this work and that its being conducted by a friendly, affable kind of person willing to share advancements/knowledge is very refreshing :thumbsup:

 

quite unusual these days:-0

 

Very true. I do software for a living and I admit my EE skills are rusty but time is the biggest challenge for me. In the limited spare time I have, I tend to prefer low-tech stuff such as home improvement & carpentry.

Still, very impressive what Ozone has done especially since he's self taught.

:clap: :clap:

 

Thanks for the kind words, guys. Much appreciated. :love2:

I know what you mean about lack of time. It's only because I left my job last month that I have any time to work on this stuff. I didn't get any projects finished while I was working (ironically in an electronics factory).

Erm, I've hit a bit of a wall.

I still can't get the damn thing to boot. It does appear to load the first 7 sectors from the CF card, then goes back to the setup menu. Often, it will flash the "Please wait while the disk is being checked" message just before the menu fades in?

Like @runkthepunk said, it could be a problem with the gdi I'm using or the way I'm reading it. I was hoping that the gdi I "found" on the Interweb is an exact copy of this Crazy Taxi (PAL) disk I'm using as a reference.

The main issue is that the FPGA has limited on-chip memory, so I can only capture a small sample of data at a time via JTAG. I really need a log of all the DC -> GD accesses on boot up. (This is same problem with the 64DD emulation).

Does anyone know if Makaron or nullDC or MAME can output more verbose debug info for the GD accesses?

Ideally, I need to get nullDC to output more GD info - I tried downloading the nullDC source last night, but I can't seem to get SVN to download the entire source tree??

I've tried a few different SVN clients, but they all said "connection timed out"?...

http://code.google.com/p/nulldc/source/checkout

Otherwise, I'll have to download each file manually, and that's gonna suck! :nod:

The other thing could be that I'm reading "cooked" 2048-byte sectors from the CF card. The BIN files were converted to ISO's as FamilyGuy said...

I can't see how it needs the extra ECC / Subcode data, because the real Crazy Taxi GD doesn't even read that stuff - as soon as it finds a GD TOC, it ignores the ISO9660 data and audio tracks, then just reads the first 7 sectors from 45150.

The small amount of data I've captured suggests that the same data (7 sectors) is being loaded from the CF card as with the original GD?

So, the problem must be to do with the security check, or with the state not being correct at the right times?

I won't let it win! lol

OzOnE.

 

http://www.crazynation.org/SEGA/Saturn/cd_tech.htm

This might be of use, it's a description of the saturn security check, pretty much the same thing as the DC I guess as it's obth based on 0xa8 & 0x59 MSF patterns to draw the nice ring under gd-roms/saturnCd.

Maybe you're missing the "modchip" part of the code? To pass this security check?

Good luck,

FG

 

Honestly I don't think that's a problem for him, because the security code is something required by the original GD drive itself, not by the Dreamcast or the Dreamcast BIOS.

I believe that at most he would need to simulate an eventual security handshake or init required by the CD Drive ... :thumbsup: (And he was already posting some information regarding that here)

 

Thanks for giving us updates at least every 2 days. Godspeed to you man! :thumbsup:

 

:thumbsup:

 

Hi, all,

I've done about as much as I can with this now and I'm completely stumped. Needless to say it's still not booting, but I thought I'd dump a LOT of info here if anyone can make sense of it!

Sorry for the mammoth post!...

I couldn't figure out for ages why I didn't have the Storage Qualifier feature on Quartus - as it happens, I was using version 8.0 and SQ was only added in version 8.1 (typical, isn't it!).

So I'm now running version 8.1 and can filter out a LOT of redundancy when I'm capturing logs of the real GD -> DC transfers, or debugging the FPGA.

Using SQ means it writes to the capture buffer ONLY when specific logic conditions are met (like all Reads / all Writes / one register only / one command only etc.). I can store a hell of a lot more in the logs now!

I've attached the logs from the real Crazy Taxi (PAL) GD which is from power-up till the first CD_READ commands. I've deleted the CF card registers (30 to 43) from the log files for clarity and I've added a few comments here and there.

Unfortunately, there is still a bit too much data to capture the Reads AND Writes in one buffer / log file. Also, it made Quartus crash! I'll try it again at some point.

Please keep in mind that the attached logs are from the REAL GD disk and generally, when I'm talking about emulation mode is when the GD drive is unplugged and the FPGA is doing all the work. (I haven't attached logs of the FPGA transfers yet)...

(btw, I'm working on the assumption that the 0x70 command probably reads the barcode, and the response to the 0x71 command is the data returned from the security check)...

You can see the security response data from C-Taxi is 814 bytes. AFAIK, this differs each time the barcode is requested? I haven't confirmed this though.

What nullDC does (and what I'm doing) is sending the exact same 1012 bytes back to the DC for the 0x71 security command. This happens regardless of how many bytes the DC requests in the first place.

(You can force it to send fewer bytes back because the DC reads the "BYTCLHI" / "BYTCLLO" registers to get the byte count before it reads the actual data.)

This is apparently supposed to bypass the basic protection - nullDC appears to use this same security response for all DC regions too? It seems to be working to an extent because in emulation mode, the FPGA at least gets the DC to read the first 7 sectors from FAD 45150 into memory...

The first 7 sectors look like they're being transferred from CF to DC perfectly fine (it uses the exact same DMA mode as the GD drive does), but then it tries to do the security check again, stops reading any more data, then just thinks it's an audio disk (goes back to the setup menu and shows the couple of minutes of audio track in the music player)?

OK, sorry if this gets harder to follow - I also found that the DC does indeed read both the Single-Density AND Double-Density TOCs from the GD one-after-the other!!

The reason I missed this before is because when I'm spying on a real GD, the counters in the FPGA are running in parallel to the original GD drive. There are some differences though...

I always send back the fixed 1012 bytes of security data, but with CT (and most GD's I'm guessing?), the number of security bytes requested is variable and often shorter...

If you look in the "all reads after reset" log file around line 548, you can see where the DC has finished reading the 834 security bytes (ignore the 836 count), but my code is still stuck in the security state because it's expecting the DC to read 1012 bytes.

So, it gets half-way through the Single-Density TOC before my counter in the FPGA finally reaches 1012 and then waits for the next command (which happens to be the command for reading the Double-Density TOC!).

So, all this time I've been missing the Single-Density TOC because my trigger point was set to look for the "GET_TOC" command. It of course only saw the second (Doub-density) one! :redface:

Anyway, I've now added both types of TOC in the FPGA. These are an exact duplicate of the TOC data read from the real GD.

There's another difference now though - before, I was just sending back the DD TOC for both the SD and DD requests and the music player showed "122:04" minutes, which is the full length of the GD track...

Now I'm sending the SD and DD TOCs, the music player ONLY shows the couple of minutes of the audio track??

With the real CT disk, if you go back to the music player (press all buttons + start), it shows both the SD audio track 02 (couple of minutes) AND the GD track 03 ("122:04" minutes).

In conclusion, it looks like I'm still not passing the security check properly. I don't know how the mechanism works for unlocking the GD drive or exactly what the DC expects when booting a GD. :crying:

In emulation mode, it's like it reads the first 7 sectors OK (IP.BIN etc.), the boot code then isn't getting the correct response / status back from the FPGA and it fails to unlock the GD area?

Admittedly, I'm not doing the REQ_ERROR part at power-up like the real DC / GD does, but nullDC doesn't do this anyway? Is it possible that nullDC is working with a different revision of BIOS to my PAL DC? My DC is one of the very first versions, 'cos I bought it at midnight!

Does this problem sound like what you would get from a bad CD-R burn or anything anyone is familiar with? Any questions about this stuff is helpful at this point. It's been many years since I burnt a DC game, but I do remember some bad ones which kept going back to the setup menu like this does.

Is there a way to use a custom IP.BIN or first 7 sectors to show any info on the screen and at least prove that it's loading correctly?

Or, does anyone know of ANY way to get some debug info from the DC while it's booting. Maybe via the serial port or something? I could solder on a flash chip if necessary?

I will need to try some different images, and see if I can get a .cdi selfboot image to work. The only info I really need to try booting an image is the TOC info (that I'm currently manually spoofing), and exactly where it expects to see each track image (FAD or LBA).

If that doesn't work, I'll have to plug the FPGA back into the 64DD and start messing with that while I think about the DC.

EDIT (again): Also, on every attempt with emu mode, the disk logo never appears in the music player - only a blank disk! Where is this logo stored?

OzOnE.

http://www.mediafire.com/?d8i6erqo0xylh2d

 

My mind hurts reading that!

I hope someone a lot smarter than me can help you out with some good tech knowledge, I am still excited about the possibilities of this.

(OzOnE I posted those game discs on saturday just so you know)

 

Hi, Mr Punk,

The disks arrived today. Perfect condition, so thanks again. :thumbsup:

It only just occurred to me to try sending the security data specific to each game (gdi). I'll try that now with CT and see what happens, then I'll try a selfboot cdi.

OzOnE.

 

OK, I think we're starting to get somewhere!...

@runkthepunk - I should have listened more closely when you mentioned about the image file I was using. To tell the truth, I'm a lazy programmer and because I was fairly certain the data was written correctly to the CF card in the first place that it would stay that way...

Well, with all the code glitches and stuff, it appears the CF card got corrupted!

I'd originally copied the USA version to the card, but it didn't get over-written correctly with the European version due to my broken copy of WinHex.

So, rather embarrassingly, it still had the USA header / IP.BIN in there, and the rest of it was corrupted! :redface:

I was checking a capture of the first few bytes and saw this...

"SEGA SEGAKATANA SEGA ENTERPRISESAD31 GD-ROM1/1 U"

Ohhh, sh*t! lol

OK, so I got a decent version of WinHex, copied the PAL version to the card, unplugged the USB -> IDE adapter, plugged back in, then verified that it was written correctly with Hex Workshop...

We now have a SEGA LOGO !! :033:

It won't boot further yet because I haven't implemented the SET_MODE command. It shouldn't take too long, all it does it write some parameters back to the drive such as "CD-ROM Speed" and "Read Retry Times" etc.

It currently freezes 'cos it then does a REQ_MODE command and of course expects those parameters to have been updated.

btw, the security response from nullDC seems to be working fine up to this point. The one from the C-Taxi GD didn't work at all.

Wish me luck!

OzOnE.

 

Cool! glad the discs got there.

I am glad to help in anyway I can :thumbsup:

I thought that might be worth a shout like I said I have so much trouble just making bootable games on CDR that I thought it may be something simple that was in your way.

Long way to go I guess but fingers crossed!

 

Wow, you're progressing really fast! Can't wait to see this finished!
It seems like your problem was a corrupted ip.bin in the end

As for DC randomly booting some cd-r games,I beleive it to be a media quality problem. I made some test and for cheap almost transparent cd, it could take a lot of reboots until it boots, while using quality cdr with a white top it booted each time. Same burner, same settings.

Cheers,

FG