Replace GD-ROM with Flash Card?

That sounds like a good idea for a backup solution. I would still prefer the 2GB cards for the retro aspect of it. This GD emulator is supposed to have USB support?

 

no body has moved this past proof of concept. if someone decides to take the ball and run with it, any number of media could be supported. with the dreamcast stuff, i usually see this:
1. someone wants to take on the project.
2. the get it to boot.
3. they dream about the possibilities.
4. they move on.

 

Hi Guys & Gurls,

Sorry to say that I've lost motivation for this project. I could never get it to boot past the SEGA Logo. :banghead: OH:

So, I've attached a zip which includes the Altera Quartus project folder and a few notes. Hopefully, a more experience programmer might find it useful.

If you have the motivation (and more knowledge about the DC than me), you might have better luck. You'll need an FPGA board for this though, and some soldering skills to hook up to the DC GD-ROM port.

A recommended board for this is something like the Terasic DE0. It's pretty good for the price (no, I don't work for them!). Maybe Haunted360 would like to give this project a try? ;-) (hint hint).

If you're not used to Verilog, it's very similar to C. But, you also need some knowledge of data busses, registers, CF / IDE / DMA timing etc, and a LOT of patience (which I unfortunately ran out of). lol

Just to confirm - this code is NOT running ANY games or images at the moment! There WILL be many mistakes in the code and it's VERY incomplete, so it's purely for hardcore experimenters only. It might give some basic starting points or inspiration though.

Most of the Verilog was converted from the nullDC GD-ROM source, so credit goes to drkIIRaziel, and whoever else I've "borrowed" snippets from. That's not to say that my code is any good though!

The most important document is the GD-ROM Bible (Sega Packet Interface spec), which I think I uploaded in a previous post (I'll check this in a mo).

The test GDI image needs to be converted to 2048-byte sectors, then I've just hard coded a TOC to boot the image from LBA 45150 on the CF card. So, this is using the FAD addressing direct from the GD-ROM commands.

The image file needs to be written to the CF card in a continuous fashion (using WinHex or whatever). There should be NO filesystem on the CF card, so don't format it with FAT32 or anything - it will NOT show up as a normal icon on your PC!

I think the code is left in the state where I was trying to get it to transfer bigger chunks from the CF card at a time. So, the state machine for the CF is likely screwed up too (see "cf_state 11" in the code where I was trying to get it to transfer 248 sectors at once, and then the remainder).

EDIT: Oh, also, the main reason for trying to transfer bigger chunks is that I think the DC is trying to read the GD-ROM buffer memory too fast, so the poor CF card can't keep up (buffer underrun). This is likely the main reason for my board failing to boot past the SEGA logo!

Basically, you need some buffer memory to store the sectors from the CF card before the DC reads a whole chunk. This should give much better results in theory. Unfortunately I don't have any SRAM on my board and SDRAM was too much of a pain to try. If you buy an FPGA board - make sure it has a chunk of SRAM!!

The GD-ROM drive has a 128KByte buffer apparently (enough for storing 64 "DC Sectors" at once).

The DC TOC is hard coded for both the Single-Density and Double-Density, but when the "disk type" is set to GD-ROM, I think the DC pretty much ignores the Single-Density area at boot and just tries to read the GDI track from 45150.

The security reply and other basic replies are stored in a small "reply ROM" file. I still think there's a problem with the way the status is being set after the DC reads the security response. It at least reads the SEGA Logo, so I must have been doing something right?

Anyway, that's all for now.
I can give some help if anyone is brave enough to continue this project.

http://www.mediafire.com/?2gu398n20367nzq

Cheers,
OzOnE.

 

You did really good to tackle this problem and got as far as you did. Very impressive for someone who is mostly self-taught.

You recommend this board: Terasic DE0 Does it have sufficient SRAM for buffering purposes? If you had $300 or more to spend, what would be the ultimate board to get?

It seems that one needs to have some sort of logic analyzer where you hook it up to the Dreamcast to monitor the bus signals for a real GDROM drive and then hook it up to your dev board and do the same. By comparing the two, you would see where it differs.

I took a look at the sample code you uploaded awhile ago and although I'm a software engineer, it was greek to me since I don't know Verilog.

I haven't done any hardware stuff since my first job and grad school which is 20 years ago. I would love to do some hardware again and work with FPGA. I'm curious as to how did you teach yourself your FPGA knowledge? One way would be to read some books or google for tutorials on the internet.

I wonder if there's a way you could buy a some sort of interface board and hook it up to a PC. Rather than programming the FPGA, you write code to toggle the lines and put data on the bus, etc. I wonder if it would be easier to get it working? Once it's working, then you work to make a FPGA out of your logic?

The challenge I would have is the full-time job/family which leaves me with very little free time.

I was thinking of something like this:
http://interestingbytes.wordpress.com/hello/open-usb-io-interface-board/

 

> $300
> ultimate FPGA board
> LOOL

"Ultimate" FPGA chips alone cost thousands of bucks.. High end boards usually come up with powerfull DSPs, tons of memory, optical interfaces, etc etc...

It's sad the project stopped though..


n64coder: What you're thinking of doing PC-side is what the FPGA does locally and much faster. There's noway a PC controlling the signals over USB with a little microcontroller capable of handling an optical drive emulation at hardware level..

 

do not kick me out of this guys , i wanna say some words...

n64coder - if you are good at software, so if you want to see what comes from CPU side to gd-rom better try dissasemble bios syscalls. those response for SPI handling (sega special IF . maybe looks like ATA or ATAPI ) and work with the ATA-like registers. so maybe it doesn need any analizer...

and it takes much time if you want start to learn work with FPGA by yourself in home. better someone makes anything ( i can do it for example) and show how its work.

i got the same thing that i must care - family/home.... so i have no free time too...


but i deal with FPGA (ALTERA) on my main work, if in short i'm HW engineer. i work with FPGA for 5 year. and fix consoles (ps1/ps2/psp/sega dc) since they born. and still for today.

also i think - the main reason of peole begin to stop - that it's too hard make gd-rom emu all at once. i mean big task must be diveded on little steps.
in general i have ideas how make it. so its sad that some has stoped. but he was not alone who wanted make it real)))).

 

OK, get ready, here comes "Mr Mammoth-Post" again...

@Jorge - I think he meant the "ultimate" as far as this project needs, and at a decent price. ;-) You're correct though - you can't really beat an FPGA for interfacing to the DC.

The interface is very simple - No logic or circuitry is needed between the DC and FPGA at all. The G1 bus (GD-ROM connector) is basically just an IDE port (albeit with a few extra pins for the CD-Audio data + clock).

The difference to the "standard" IDE / ATA protocol is in the way Sega changed the command packet format.

The tricky part from the build point of view is soldering the wires to the DC mainboard. You could buy the same connector that the GD drive uses, but then you'd need a small custom PCB to solder it to.

What I did was to cut a short ribbon cable in half then strip / tin / solder each wire to the DC solder points. The pinout is included in the ZIP file from my last post.

I first used a multimeter to check the pinouts against the VA0 schematics and they matched fine. I checked the pinouts many times, so they should be 100%.

I then found that somebody had already drawn up a handy image of the solder points (bottom of the post) which also match...

http://benheck.com/forums/viewtopic.php?f=6&t=30585

@n64coder: You don't need a separate logic analyser. The FPGA does it all in one package. I've set up the code so you can just hook up the JTAG cable to the PC and modify a small part of the code to switch between "spy" and "emulation" mode.

Many dev boards like the DE0 have the JTAG interface built in, so you just plug into the USB port and away you go.

Of course, you should always disconnect the original GD drive when the FPGA is in "emulation" mode or it's possible that something could get damaged!

I haven't completely given up hope with this project and I'm thinking about getting a DE0 or something with some SRAM on it. It might have to wait a while until I have more funds though. :033:

You might only need the 128KBytes of SRAM to make further progress.

EDIT: I've just noticed that the DE0 doesn't appear to have any SRAM after all!...
Deunan also mentioned that he only had 8KB of internal memory on the FPGA to spare for the buffer. I might be able to squeeze some more out of my board if this is the case (it uses almost the same FPGA).

The problem is that the logic analyser (SignalTap) is uses all of the internal memory, so it will need to be reduced or disabled altogether. This means working almost "blind". I do have a whole 64MBytes of SDRAM on my board, but it can be troublesome trying to use it in an SRAM style due to the timing issues. I might give this a try also.

The fact that the DC is loading to the SEGA Logo is good news. It's definitely loading the first part of the bootloader / IP.BIN for this to happen. I can't be 100% sure if it's stopping due to the lack of a buffer, or due to a security / status issue?

I fairly certain that the lack of a buffer is the biggest problem. The DC will try to read up to 64 sectors (128KB) very fast, and in one chunk. It expects that the data has already been put into the buffer before the GD tells the DC that the data is ready (rather than streaming it directly from disk).

tbh, everything that can be done on a simpler interface board can probably be done on an FPGA (and more). If you're looking to find a more programmer (C++) friendly approach, we could actually do things in a different way...

You can add a NIOS CPU core to the FPGA. This function is built-in to the Altera Quartus software. What it means is that you can program directly in C to control the FPGA so you could port the GD-handling routines from something like the NullDC or Makaron source to the NIOS core. This is what Deunan did (second post)...

http://dknute.livejournal.com/

You'd need to add the interface stuff so the NIOS can talk to the GD bus though. I haven't tried this 'cos I've never used NIOS before. It always seemed a bit over-complex to me, but I can now see the benefits. I might give this a try at some point.

(sorry if this next part isn't exactly DC related)...

I've started messing with the Doctor V64 again because somebody asked for a replacement EPROM chip. It's now loading from CF card 30% faster and displaying the ROM regions. There are a few interesting things which could still be done but programming in 65C02 assembler is frustrating - has anyone here programmed the 6502 in C before?

btw, I haven't even thought about the £300 64DD that's sitting here on my desk. :shrug: The only way the 64DD project will advance is if we could dump full RAW disk images (including the system areas). This is a bit beyond my programming experience unfortunately, but I do know roughly how the code would need to work.

OzOnE.

 

Ohhhhhh. It appears that Duenan actually used a DE1 after all !!!

It's definitely a DE1 and not a DE0. The DE1 has 512KB of SRAM on board and the DE0 has no SRAM (only SDRAM).

I therefore wouldn't necessarily recommend the DE0 unless you can program it to use the onboard SDRAM as a buffer, or could add an external SRAM. I wonder why Deunan didn't use the SRAM on the DE1?

So, my options are...

1. Connect an SRAM chip to my board (tricky, but not impossible).
2. Try to trim down SignalTap so I can fit the buffer in the internal memory.
3. Attempt to get the SDRAM working as a buffer (reliably).
4. Buy a relatively expensive new board with SRAM.
5. Buy a cheap new board with SRAM. Something like this...

http://www.ebay.co.uk/itm/EP2C8Q208...ment_Tools&hash=item3cbec7fa86#ht_5764wt_1396

Please note: Many of the cheaper Chinese boards will need a separate JTAG adapter like the Altera USB Blaster. The "original" can be expensive, but they sell cheap clones which work almost as fast for around $12 USD.

They also scrimp a bit on the FPGA at this price range (obviously), so you only have so many pins to play with (should be enough though).

It's a shame the FPGA isn't bigger - my GD-EMU code would currently already fill that 8K FPGA. I need at least at 12K or 15K chip ideally.

What you gain is that it's already set up to work with NIOS and you get many of the nice sockets and SD card slot. You can basically connect it directly to a keyboard / mouse / monitor and run a small version of Linux and C programs on it.

It looks like there is SRAM on the underside in the photos, but it's probably an extra $10 to have it fitted.

Hmmm, I'm mildly tempted.

OzOnE.

 

Wait what? You're reaching about 100% FPGA utilization? How is this possible? what exact partnumber do you have?

My upscaler uses a XC3S1000 and I have 1478 slices occupied out of 7680... (Inside there's a microblaze CPU and a tile-based VDP right now)

Why messing with SDRAM or SRAM even? FPGAs have BRAMs built-in

Ohh wait, you need 128kB.. hum yeah get an SRAM

 

Actually, no. I just realized that it was SignalTap which was taking up 90% of the logic! :redface:

(sorry, I just installed a new 1TB hard drive and I'm booting from a fresh install on a 60GB SSD. A lot of stuff in different places. Luckily, Quartus still runs from the backup without needing any registry crap).

My board has an EP3C16Q240C8, so 15,408 logic elements.

In reality, the core GD-Emu code only appears to need around 1500 logic elements.

I need to make a copy of the SignalTap file and strip it down to the bare minimum so I can at least have some debug info.

Yep, the internal BRAMs are a bit lacking on most FPGAs. Could they not fit an SRAM inside as a dual-die design?

If Deunan was running his design with only 8KB of buffer, then I might have a chance after all. (My chip has exactly 63KB of internal mem. Only 2KB (3%) of that is being used for the GD "reply" ROM).

btw, @Jorge, I'm very impressed by your blog and scaler design. This is another area of interest to me. I've said many times in the past that a massive hurdle for me is getting decent PCBs made - where did you get yours from?

I was also experimenting with adding HDMI to the N64 a couple of years ago. It wasn't very successful since I was trying to hook up to an HDMI transmitter IC from a cheap DVD player which doesn't have any datasheets!

I did send the HDMI code to Marshall, and that might be part of his inspiration for the N64 VGA board. He could have at least put an HDMI port on it too! lol

I did get some basic polygon drawing working though - I was trying to recreate the N64 RDP on my old FPGA board (slowed down many times of course)...

http://www.youtube.com/watch?v=9AQJN2eE_wY

I got stuck with THAT project because I couldn't get it to draw Mario's face without screwing up the polygons.

btw, the Mario "data" was taken from the real game. Unfortunately, I didn't make a video of that. It would have been quite amusing.

The board could be hooked pretty much directly to a monitor via some RC filters because it uses sigma-delta DACs in the FPGA itself (running at very high speed).

The board has 64KB of real (old) SRAM chips and some EPROMs. The obvious question would be: Why don't I use it for the DC? Well, it doesn't have quite enough spare pins, it doesn't have a proper JTAG connector, and it's a PITA to solder to!

That old FPGA board was actually part of another one of my abandoned projects for building an AGC (Apollo Guidance Computer) replica...

(bit of background info) - John Pultorak did an amazing job on the first AGC replica around 2004. He somehow managed to get hold of most of the original diagrams from NASA and other companies! (It probably helped that he's a chief engineer at Lockheed)...

http://www.ibiblio.org/apollo/Pultorak.html

What's more amazing is that he built a working replica from standard logic IC's and it was completely hand-wired!

I did get almost all of John's diagrams translated to Verilog, and that's when I learnt the bulk of my FPGA knowledge (over MANY months).

So basically, to learn Verilog, it was just sheer determination and a great interest in the project's subject matter. If you program in C / C++, it's quite similar but you need to start thinking more in terms of the actual hardware involved, and how registers become real logic.

The most difficult part for me was having to visualize exactly what is going to happen on each clock cycle (which is much closer to Assembly programming, like I'd done on PIC chips).

Also, there are many operations which can happen in parallel on an FPGA (unlike most standard C programs), and you have to decide what needs to work in parallel, and what needs work in a more linear fashion on each clock tick (like a state machine for example).

In the end, all you're really doing is manipulating registers like you do in C, then connecting certain registers or combinational logic to real IO pins to control the hardware. Many of the functions and operators you use in C are also available in Verilog (there are exceptions).

I can't recommend any good books on the subject tbh, 'cos I live my life in the land of Google. :dance:

Yes, sadly, I pretty much had to do some hardcore Googling to piece everything together. I'm still learning all the time. I probably should start reading more books.

Right, enough of that. (Sorry, I got lost in a typing trance. Again.)

@n64coder - My best source of info for the DC stuff was the NullDC GD-Rom C sources. I did look at Makaron too, but NullDC was a bit easier to read.

@Jorge - I can send you my N64 RDP project if you fancy trying it? It's not set up for SDRAM, but probably wouldn't matter too much for a framebuffer.

btw, how do you use SDRAM as a framebuffer and avoid the glitches during refresh? I never quite got the hang of that?

OzOnE.

 

Yeah, he uses a DE1. 512 KB SRAM, 8 MB SDRAM, 4 MB Flash ROM, RS232, VGA, Line in, Out and Mic, MAXII, 4 7-Segment Displays, 10 Switches, 4 micro-tac buttons, PS2 keyboard, SD card slot and two GPIO ports.

 

emulation of original GD-ROM is tough enough.

but let me talk about another way. Nowadays we got SD-mod that used trick with new bios (DraeamShell) and it basicaly works on new syscalls that were replased in original bios.

so if we can read/write on G1(G2) bus (maybe also use DMA) we needn't use native sega protcol (SPI) at all. we can make what we wish, make our own driver like in case with sd-mod.

so this is the work for programmer!, just learn how use KolistiOS and other stuff for makin executible file for DC. and from HW side we only need simple device for read/write operations and for more smarter with DMA.

but there is one problem - bios do chekin data by weird way.

 

That also means someone would need to replace the bios in their DC. The major benefit of emulating the original drive is - you could make it an easy drop in replacement.

Most people are not capable of soldering chips into their console, but can connect a cable.

Also, its a completely different project to what this thread is talking about really.

 

Ohh, so you're using an internal logic analyzer, yeah that explains it :nod:

In my case, I have an old memec design evaluation board with a small virtex2pro with a logic analyzer stored on the flash memory (I use that board just for the LA). Of course there's the hassle of having to bring out the internal nodes into accessible package pins but atleast I don't clutter my design with extra crap..

I got the LA design from here: http://www.sump.org/projects/analyzer/
In my case I took the S3E Experimental version and ported it to my own board (Piece of cake: just defining pins, and messing around with the BRAMs)

_______

I got the PCB made in www.pcbpool.com and I'm not using the SDRAM yet. It's reserved for the actual upscaling part. My idea is to clock it at the pixel clock (right now 148.5MHz, but it will depend on the output resolution), open the row which is a full line and do a burst access during the active line. On blanking I write the input buffer into it and do some refreshes.

 

Completely unrelated, I was trying to do some stuff with an ambit modem earlier, and I saw your name on some other forums for that kinda stuff bad_ad84 haha, very nice very nice.

 

So many time after

Hello all, I've been "missing" this thread for a while now. When I first came here I came with the objective of make the Dreamcast run games with an hard drive/Flash card trough the modem. I have to say that after some lttle work per day I did make the hardware based on the NetBSD project and now I've putted a friend who is better than me coding OS with the Dreamshell changing the SD coding entry from the Serial to the Modem, since the Dreamcast has that innate possibility and he said that it was possible ad not too hard to do.

PS: I'm on the run so I couldn't read what's happening in the thread, sorry

 

Just recently grabbed the TOSEC for the dreamcast, 498gb only.

Yeah, it would be nice a drive emulator for it.

 

Just thought I would bump this up a bit and ask if there has been any further progress at all? Seem to be a few knowledgable people in the thread so fingers crossed.

 

Didnt notice your post... but I (was) one of the admins from sbhacker. There was some recent drama and I am no longer a part of that "scene". I continued to work on new modems for sometime after I moved from a cable area (DSL only now!).

 

Well this mod we could use cf card like the Sega Naomi i think they used a new bios i think i am unsure but would be a cool mod.