Replace GD-ROM with Flash Card?

Discussion in 'Sega Dreamcast Development and Research' started by _SD_, Jun 8, 2010.

  1. Melchior

    Melchior Rapidly Rising Member

    Joined:
    Jun 12, 2011
    Messages:
    79
    Likes Received:
    3
    I just had this horrible vision of a Dreamcast with the optical drive ripped out - and replaced with a PCB that occupies the same space, with the G1 Bus cable attached to it...

    Still room to cram a ARM9 & CPLD & CF Card socket and then some.

    IIRC The Dreamcast bios is on the same G1 Bus, could it be used to override the bus (rom)

    For Custom firmware?
     
  2. -=FamilyGuy=-

    -=FamilyGuy=- Site Supporter 2049

    Joined:
    Mar 3, 2007
    Messages:
    3,097
    Likes Received:
    1,045
    No (read "not necessary"), if you convert the .bin files into .iso (2352 => 2048) it'll work. Just remember to change the .gdi accordingly.

    Good luck on your fantastic project! If you got any questions about "gd-rom/mil-cd" stuff feel free to ask me in this thread or in pm, I know this topic to some extent.

    FG
     
    Last edited: Nov 19, 2011
  3. Anthony817

    Anthony817 Familiar Face

    Joined:
    May 12, 2010
    Messages:
    1,123
    Likes Received:
    595
    I am so amazed by your progress! You are fucking awesome! Sorry about all the cursing but wow, this is more than Deunan has showed us! :clap:

    Please keep us updated! I would pay you to make me one! :nod:
     
    Last edited: Nov 21, 2011
  4. OzOnE

    OzOnE Site Supporter 2013

    Joined:
    Nov 10, 2011
    Messages:
    538
    Likes Received:
    173
    Thanks, Anthony,

    Believe me, I'm no expert on this. It's all self-taught, requires heavy Googling and a LOT of head-scratching tbh.

    Here's a (long) update...

    I think I've figured out the TOC stuff now and I've started to add (basic) CF card access to the code.

    Unfortunately I think I killed my 2GB CF card when I plugged it into the PC adapter on the wrong pins. :(

    My 4GB card doesn't want to work on the FPGA board for some reason, so I've ordered a new card which should be here in a day or two.

    I converted the gdi of Crazy Taxi to ISO format, so it should be a bit easier now to read the images from the CF card. The code currently has a hard-coded TOC which I'm hoping will be enough for the DC to access the rest of the game from the correct sectors etc.

    I still need to add the code for setting the output signals at the correct time, and add the DMA stuff.

    One confusing thing I found is that it only seems to read the GD high-density area TOC now? I was certain I saw it read the low-density part first before? I might have to emulate both types of TOC. The method could be called "cheating", but it might just work...

    http://pastebin.com/KLwqeRDF

    @-=FamilyGuy=- (or anyone) - Do you know if the DC always reads the single-density TOC first on GD disks? I can't seem to capture it now?

    Also, do you know if the first entry of the double-density TOC is often left blank (0xFFFF)?

    btw, I literally only have two old DreamOn demo GD-ROMs for testing - all my other disks are "silver coloured". ;-)

    I'll get on eB*y now and buy some more GD's. Preferably some which have identical dumps already available (so I can make direct comparisons with the emulation).

    My 64DD just arrived from Japan this morning too, so I'll have my work cut out. :033:

    Don't worry, I still intend to get the DC thing working. It's actually been quite interested figuring things out.

    I also forgot what a great console the DC is - very nice PowerVR high-res textures, especially via the VGA box. I remember when I bought this DC, I went to the Game shop one night in 1998 at midnight on it's release!

    Ok, enough of that.

    I'll keep you updated, but it will be a few days until I have more info.

    OzOnE.
     
  5. splith

    splith Resolute Member

    Joined:
    May 2, 2010
    Messages:
    997
    Likes Received:
    4
    Self taught you say? Pretty darn good!
    I personally got a Cyclone III dev board with quartus II and whatnot I was going to play around with but still haven't had the darn time!

    Something aside and just personal preference, which do you prefer and use, verilog or vhdl?
     
  6. -=FamilyGuy=-

    -=FamilyGuy=- Site Supporter 2049

    Joined:
    Mar 3, 2007
    Messages:
    3,097
    Likes Received:
    1,045
    I don't know if it read the 1st session TOC everytime, but it has no good reason to do so. Genuine games have no game data there, and if you wanna use the 1st session in a selfboot mil-cd you've got the link the two TOC to index the 1st session files in the 2de session TOC. So I guess it doesn't matter, but I can't say for sure.

    As for the 1st HD track to sometimes be blank, it's always data at physical sector 45150, so maybe it's not even read by the bios as it'd be redundant...

    FG

    [EDIT]

    The TOC you talk about, is it the iso9660's one, or the ip.bin one? (ip.bin one would be at pysical block 45150).

    In mil-cd, the ip.bin TOC isn't used at all, I don't know for gd-roms. Also, ip0000.bin, the ip.bin-like bootsector of LD session, doesn't contain this TOC. So i you're talkin about the ip.bin's TOC, then it's normal it isn't accessed on LD session.

    FG
     
    Last edited: Nov 21, 2011
  7. OzOnE

    OzOnE Site Supporter 2013

    Joined:
    Nov 10, 2011
    Messages:
    538
    Likes Received:
    173
    @splith - definitely Verilog from the start. I honestly can't understand the need for VHDL. Many people say that it forces you to code things more "specifically" to the task (which is good for some designs), but you can do exactly the same in Verilog, just a lot quicker and easier IMHO.

    Verilog is as close to C as you can get (SystemVerilog even closer - includes "structs" and "unions" etc.)

    Quite often, I've had to convert VHDL code to Verilog just to understand it. Here's a free converter (demo) which does a good job with most of the code...

    http://www.sugawara-systems.com/

    @-=FamilyGuy=- Thanks for the info. I can see now how libGDR (in nullDC) generates both type of TOC depending on the request.

    I think it ignores the SD TOC when it finds a GD. I could have sworn I saw it reading both TOC's though? Oh well, I can confirm this soon.

    The GD TOC is actually in "IP.BIN" in the first sector of the ISO file at offset 0x100. This seems to be exactly what is read for the GD TOC data, the only difference is that it is marked with "TOC1" in ASCII before the data.

    Yep, this is at the 45150 "physical" sector as you say, which is "FAD" type addressing. With LBA addressing, this is at sector 45000 - it looks like the DC uses FAD addresses quite a lot?

    btw, I said "ISO" file and not raw BIN file because the DC only ever sees the pre-processed 2048-byte sectors (also as you said). It's much easier working with ISO files because the IP.BIN part starts at offset 0x0000 like it should. ;-)

    The error correction is done internally by the drive, so I'm assuming the extra data is included in the BIN file for completeness?

    The extra data (2352-byte sectors) might be required in audio tracks though - the Q channel data is used to determine the playback offsets etc.

    Anywho, I think I might need to spoof both types of TOC just in case.

    As for the actual GD Emu progress, I finally got around to trying it for real, but it's not very happy. :rolleyes:

    (Please note: no actual images are being run yet!!)

    I can get it past a certain point, but I can't even get the DC to boot to the setup menu. There were many things to sort out in the code because I realized it was trying to access the status register all the time. My code wouldn't let it access the status reg because it was still in a different state.

    What it does now is allows access to any register at any point in time (like a real drive would do). This actually simplified other parts of the code and the output is much cleaner, but it looks like it will need a bit of a re-write...

    (it gets stuck after the REQ_MODE command, so maybe my spoof data is incorrect for my PAL BIOS?)...

    http://imageshack.us/f/535/gdemutesting241111ozone.jpg/

    I think the problems now are getting the correct timing for the handshaking signals (interrupts / status bits etc). Basically, I need to add state machines just like in the nullDC source so it outputs the correct signals at the correct times.

    It was surprising how many registers need to be emulated just to get to this point. In the end, it's like designing your own CD-ROM controller. :crying:

    Still no CF card access yet. My new CF card arrived, but it has the same problem as the 4GB card (always "BUSY"), so there's an inherent problem somewhere. Typical that the old 2GB card didn't have this problem, but I fried it. :evil:

    At least it's much easier to switch between Spy and Emu mode now - I can just plug the GD-Rom back in and change two lines in the code to start monitoring transfers again. I'll double-check the data that my PAL DC BIOS is expecting and see if that helps.

    OzOnE.
     
  8. LCardoso17

    LCardoso17 Newly Registered

    Joined:
    Oct 30, 2011
    Messages:
    4
    Likes Received:
    0
    I've been away for a while because I got myself into two video games projects (one to be finished in mid December (PC/web) and the other to be finished in June/July(PC/MAC and probably X360/Android/iOS) and University work.

    I gave a fast view at the last posts from Ozone and I see there where lots of progress... unfortunately now I can't give any time to the project.

    I decided to rip off a mini HDD from an old broken Ipod I bought last month and do the connections trough the EXP (like Net BSD did). After that I started to program a OS (Net BSD idea) but as an extension of the original Bios... Basically I grabbed some of the programming ideas of the Net BSD work, the original BIOS/Dreamshell ideas (running SD trough the DC S.P.) and make a working combination of both.

    I will grab the project again as soon as I can.
     
  9. -=FamilyGuy=-

    -=FamilyGuy=- Site Supporter 2049

    Joined:
    Mar 3, 2007
    Messages:
    3,097
    Likes Received:
    1,045
    All disc references are in Big Endian FAD as far as I know. You can even "Hide" the filesystem of a Dreamcast backup for Windows users by blanking the Little Endian TOC of the disc and only keeping the Big Endian one for the DC to read if I recall correctly.

    FG
     
  10. OzOnE

    OzOnE Site Supporter 2013

    Joined:
    Nov 10, 2011
    Messages:
    538
    Likes Received:
    173
    A quick update...

    After many more days of frustration, the code is now at the point where the Dreamcast is requesting the disk data from the proper address...

    I'm still working on getting the CF card to read though. It's not behaving itself at all atm. As soon as I can read some data off the damn thing, I can try to boot a gdi.

    Basically, I could have saved myself a ton of work over the past few days if it wasn't for a very silly bug. As an exercise for you guys (if anyone's interested), check page 50 of the GD-ROM bible...

    http://www.mediafire.com/?01x4dmma6waf3dm

    ...Please convert the DiscFormat bits to decimal, then guess the stupid mistake that I made. :redface: :rolleyes:

    Ok, so a few discoveries. It turns out that the DC does appear to only read the GD TOC when it detects a GD-Rom. So far, it looks like the SD TOC is ignored (on the DreamOn disk at least).

    This simplifies things for a lot of the "standard 3-track" GD images. It also seems that my fake TOC and session info is working - the DC reads it, then tries to boot directly from sector 45150 (LBA 45000)!

    So, as long as there aren't any annoying protections, this might actually work!

    I need to get the CF card working next, then the DMA stuff (almost all transfers for games are done via DMA).

    Fingers crossed!

    OzOnE.
    EDIT: Note - I found that the DC needs to have the ~33.8688MHz clock that the GD drive normally generates. This is the clock for transferring CDDA audio, but it appears the AICA needs this, or the DC won't even get to the first logo!
     
    Last edited: Nov 27, 2011
  11. runkthepunk

    runkthepunk <B>Site Supporter 2013</B><BR><B>Site Supporter 20

    Joined:
    Aug 13, 2010
    Messages:
    209
    Likes Received:
    0
    Hey OzOnE

    I have been following your progress with much interest. I have recently been home and can send you a couple of full dreamcast games to help you with your attempts at getting this up and working. I have a copy of Mortal Kombat Gold and Spirit of Speed. Neither are good games to sit and play on but both work properly and maybe they will be of some help?

    If you want them let me know and I can send the discs on to you.

    Thanks mate

    Rob
     
  12. OzOnE

    OzOnE Site Supporter 2013

    Joined:
    Nov 10, 2011
    Messages:
    538
    Likes Received:
    173
    Hi, Rob,

    Thanks for your kind offer. I will gladly take the disks off you if that's OK. :)

    I will PayPal you something for them. I need a couple of GD's for testing. (pm'd).

    As for the project - still no joy. I'm having nightmares with the CF card. Marshall warned me about needing "hold times" for Reads or Writes with CF cards and it's definitely proving to be a pain.

    The DC is trying to read data from the expected position and I can get it to read some data from the CF card up to the point where the CF card freezes (DC is requesting data too fast). I haven't even got it boot to the Sega logo yet.

    I really need to get DMA working on the CF card. I have a better understanding of it now, and the process is actually simpler than I thought. You just set up the transfer, set a pin high (DMARQ), the DC will bring (DMACK) low in response, then clock out all the data.

    I have a way of routing the DMA transfers directly between the CF card and DC, but I just can't get DMA mode working on the CF card. Does anyone have any experience with ATA commands on CF cards or HDD's??

    I've tried doing the Set Transfer Mode feature and sending the Read DMA command, but the CF card never raises the DMARQ pin?

    (I've messed around for three days with data buffers and other ideas - it could probably be made to work SLOWLY with PIO, but this is a bit pointless and is actually more complex to implement.)

    Does anyone know if it need to initialize the CF card by sending the "Init Drive Parameters" command first? Is this even needed with CF cards? Or, are there any other commands which I need to send to set up for DMA transfers?

    Thanks,
    OzOnE.
     
  13. TmEE

    TmEE Peppy Member

    Joined:
    Aug 13, 2008
    Messages:
    362
    Likes Received:
    1
    I'm quite sure you got to initialize the CF card just like a HDD. There's a whole lot of commands, and they get written to one/few of the 8 addresses of the HDD.
    I don't know all the details, not yet haha
     
  14. APE

    APE Site Supporter 2015

    Joined:
    Dec 5, 2005
    Messages:
    6,417
    Likes Received:
    141
    CF cards use the same ATA controller specs as IDE HDDs. They're pin for pin compatible, blah blah blah.

    You might want to look into getting a faster CF card. They easily hit 60mb/s but I can't speak for their random access times.
     
  15. OzOnE

    OzOnE Site Supporter 2013

    Joined:
    Nov 10, 2011
    Messages:
    538
    Likes Received:
    173
    OK, I think DMA on the CF card is "trying" to work now. The problem was that I was using "DMA READ w/o Retry" command (0xC9) instead of the standard "DMA READ" command (0xC8)!?

    Apparently, the "w/o retry" command has been obsolete for some time now.

    Still no joy with actually booting anything though - the DC appears to be trying to read TWICE as fast as the CF card can keep up with :-0 ...

    I bought a 133 MB/s CF card, so it should be easily fast enough and it looks like the issue now is a problem with the way I designed the PCB. Basically, I tied the /CS0 pin on the CF (IDE) port to ground because it wasn't intended to share with any other devices...

    This was done mainly to save one pin on the FPGA - you don't normally need to change the /CS pin states for accessing just one CF or HDD (or so I thought!)...

    It turns out that in DMA mode, both /CS pins are actually negated (brought HIGH) during the DMA transfer. duhhh :crying:

    Again for anyone interested, check page 48 under "True IDE mode addressing"...

    http://www.transcendusa.com/support...t Word - Datasheet CF100I_128MB_16GB_V1.1.pdf

    The /CS1 and /CS0 pins on my FPGA board are tried to 1 and 0 respectively. You can see in the pdf that apart from the "Alt Status" register, the "DMA RD / WR" state is the only damn thing which needs the /CS0 pin high!

    Alright, I supposed it's not too bad - I'll just have to modify the board (yet again) and connect the /CS0 pin to the FPGA.

    If this attempt doesn't work, the only way is to buffer the CF data into the FPGA first, then let the DC read it from the buffer as fast as it likes. It's not too complex, but I wanted to avoid it if possible and just read straight from the CF card.

    Only time will tell.

    OzOnE.
    P.S. I must get and look at the 64DD as well. I wanted one for ages, but now that it's sat here on the floor, the novelty has warn off very slightly. (always the way, isn't it?)
     
  16. mar.vetto

    mar.vetto Rising Member

    Joined:
    Oct 7, 2011
    Messages:
    53
    Likes Received:
    1
    I don't like cf solution.....nice but not for me....
     
  17. -=FamilyGuy=-

    -=FamilyGuy=- Site Supporter 2049

    Joined:
    Mar 3, 2007
    Messages:
    3,097
    Likes Received:
    1,045
    Then buy a sd/hdd to cf adapter. Or make your own drive emulator with support for whatever you want.

    FG
     
  18. OzOnE

    OzOnE Site Supporter 2013

    Joined:
    Nov 10, 2011
    Messages:
    538
    Likes Received:
    173
    @mar.vetto - Actually, this was just the easiest route to take at first to get this thing working. What did you have in mind?...

    The DC appears to use MultiWord DMA Mode 2 to do the actual data transfers from the GD drive. This is the same mode that virtually ALL modern CF cards and HDD's support. :nod:

    Once it is working, the idea was to actually use a laptop HDD, because 1GB DC images aren't exactly small. In theory, once the CF card is working, it should be a straight swap for a HDD. An SD card slot or anything else you can imagine can be bolted on after the basics are working. ;-)

    I think I'm getting closer to finally booting an image - the way it works now is to convert the Sega packet commands to a standard DMA request from the CF card. The Dreamcast itself drives the rest of the DMA transfer and the data simply passes straight through the FPGA unchanged (this is how I wanted it to work originally).

    The problem I have now is that it's not counting the data words reliably (not sure why), so the FPGA doesn't know the correct time to assert the interrupt at the end of the transfer. The DC just sits there waiting for an int which never arrives.

    I'm now just trying to figure out why the interrupt from the CF isn't being asserted? I think I need to clear the "nIEN" bit?

    Once the interrupt is working, you don't even really need to keep track of DMA transfers, you just kick it off and away it goes! All the FPGA is really doing then is...

    Parses the Sega packet commands.
    Generates a TOC for the chosen gdi image.
    Generates the GD drive's ID and security responses.
    Translates the CD_READ command to read from the CF card instead.
    (DMA transfers pass straight through automatically).

    I just need to get this last hurdle over with. I might have to get medieval on it! :evil:

    OzOnE.
     
    Last edited: Nov 30, 2011
  19. n64coder

    n64coder Robust Member

    Joined:
    Mar 25, 2009
    Messages:
    249
    Likes Received:
    2
    Cool stuff, ozone. What's your background again?
     
  20. TmEE

    TmEE Peppy Member

    Joined:
    Aug 13, 2008
    Messages:
    362
    Likes Received:
    1
    oh wow, this is awesome :)

    Interrupt is probably masked out somewhere, you should be getting interrupts with no problems from the drive, why else they got that line on them haha
     

Share This Page