Replace GD-ROM with Flash Card?

I'll take a look tonight to see if I can make some sense of it.

 

this thread has been a very interesting read. Very impressed at how far you've come so quickly. Thank you very much for working on this and best of luck!

 

Sorry, I haven't looked at it until just now. Looks like I'll need to look at a Verilog syntax reference since some of it looks foreign to me.

 

good luck to all who help with this project!

 

I'm probably going to release the full source for this. There are many parts of code still missing, and it doesn't have any of the CD-Audio stuff yet.

If it benefits the community as a whole, I might as well just paste it online.

The source isn't very big tbh, the main bulk is the translation of the GD commands - the actual data is transferred from CF by the DC because it uses the same standard DMA mode.

I think the code needs to use a sector buffer for it to work reliably. This would also make it a bit easier for managing CDDA sectors in the future.

Should I just paste the code, 'cos I don't think I have the time to progress it much further?

@n64coder - yep, it can a bit alien compared to C at first. Many of the operators are the same, but there are differences like using <= instead of = for an assignment. You can also do = as well, but I think this forces it to evaluate the assignments in order (like in C).

With <= , it evaluates ALL assignments in the same time slot (clock cycle / state etc.). This might seem counter-intuitive at first, but there are good reasons for it apparently. The big problem is, you often need to wait until it changes to the next state before you do an "IF" check on a variable that has just been updated. This means a lot of extra states are added just for this purpose.

I must admit, it's a proper pain trying to convert something from C just because the evaluation of statements isn't linear when using <=. You have to think of most chunks of code as evaluating all at same time.

You also need to think about how the data outputs will be generated and how things are latched into registers. Also keep in mind how the hardware might evaluate things on the falling OR rising edges of a clock or signal...

For instance, when you write a command to the CF card, the data is latched in the CF on the RISING edge of the WRite signal. So, you need to do something like this on each state (WRite normally starts off as "1"...

0: begin
cf_data_write <= my_data;
cf_wr_n_reg <= 1'b0; // Assert CF WRite signal (active low).
cf_state <= 10'd1;
end

1: begin
cf_wr_n_reg <= 1'b1; // De-assert CF WRite (data will be latched on CF).
cf_state <= 10'd2;
end

2: begin // Do whatever else (WRITE is Done!).
end

This seems way over-complex - I'm not sure if there are cleaner ways of do it?

Also, you'll notice the way of defining a Radix is different. You don't necessarily need to say "10'd1", you could just say "1", but you'll end up with many warnings about truncation (ie. I think the compiler sees the "1" as a 32-bit integer, so it just truncates it during compilation to fit the 10-bit variable "cf_state").

You can refer to a variable in any Radix, but it's nice to keep it as decimal ('d) for state machines etc. The number before the ' always defines the number of bits you're assigning (I think)??

The size of the variables are usually defined at the top of the source as normal. I think you can define variables in other places, but it's best to keep everything as static as possible (the registers are pretty much fixed and non-dynamic in the FPGA once it's compiled, so there's no point allocating and de-allocating variables or static data).

You can actually use "tasks" and "functions" in Verilog - I think the main difference is a function can take parameters when it's called. A task just carries out something with no parameters (like a "void" procedure I guess?).

You still to worry about the timing though - if a task is called from a particular state, it's statements will be evaluated in the same time slot. So, you need to make sure that any variables or data that you do a conditional on ("IF" etc.) have already been updated in a previous time slot!

You can use SystemVerilog, which is apparently designed to be much closer to C. I don't know much about it though - I tried using it for defining and initializing arrays easier, but I got completely lost. lol

Please don't take the above as gospel btw - there are many things I'm still trying to work out myself.

Anyway, let me know if I should post the code. I can try to help with the Verilog, but as I say, I'm still learning. A good person to ask if we get stuck would be someone like Marshall. :nod:

OzOnE.

 

maybe you should talk with krizz and see if he can help the ever drive guy

 

I second that, give it to person/group who are committed to quality and want to see it through to product. Why chance some cheap Chinese crap beating it to market...

 

This!

But, who is to say XKDIY would go that far? I know they did with the SD adapters, but if this wasn't fully working, why would they go to that trouble?

Those boards can coast quite the pretty penny to begin with. I know some can be had for $50 but are they all up to the task of emulating the Gdr drive?

 

Who knows. Let's be honest, why chance removing one of the main motivators here -- money. Not necessarily for monies sake alone, but if there's a lot of time and effort involved something needs to offset that.

A trusted member/team can always add to their ranks as they see fit.

 

Non-blocking assignment enforces that a register receives only one assignment per sensitivity block evaluation so you can make things like shift registers. Blocking assignment allows you to evaluate a lot of logic asynchronously (think priority encoder) such that only the final value is used. Basically registers with blocking assignment act as level-sensitive transparent latches which are enabled at their sensitivity and disabled (latched) out of their sensitivity. You can use non-blocking for asynchronous designs too, just put them in a level-sensitive block. I avoid blocking assignment entirely this way (apart from assign, definitions, initial etc of course).

That's the standard/straight-forward way to make a Moore machine. It might be easier to maintain by separating the state into it's state table, and then decode the states separately but you end up with the same thing.

Numbers like "1" are (sign) extended to match the width of whatever number or register you're operating upon. The actual integer type in Verilog is useless/isn't synthesizable, it's only there for the preprocessor to perform loops etc.

Decimal is implied when you don't specify a base so most people leave it off for clarity, unless they are mixing bases or partially-decoding cases.

Everything is fully set in stone when it's "compiled" (well there's partial reconfiguration...) so I'm not sure what you mean by allocating variables or static data. Immediate data that you apply to registers is static because it generally synthesizes to gates. When you add a variable/dynamic value to another register, the addend synthesizes to a register. As for allocation, all registers are both "global" and local to their preceding asynchronous logic that you (or the synthesizer) route to them. You can't deallocate variables (?) to free registers, but you can explicitly time multiplex them in the design to serve multiple purposes (like a union in software).

It really helps to have a background of digital design using gates and discrete chips before jumping into HDL, otherwise it might not be clear what translates (well) to hardware and what does not. It's important to remember that while the synthesizer can make sense of a bad design, it won't necessarily smooth out the timing issues so it's good to be aware of glitches/hazards and metastability.

 

Oh, I misunderstood. The FPGA he's using? Yeah, it can do it, but the final product would be a dedicated cable/PCB/SD interface. He's using it to prototype. Once the design is done you produce hardwired chips for faster performance.

 

Like the x360key right?



http://www.consoledemon.com/x360key-review-installation-guide-and-tutorials

What do you reckon that an ODE for the Dreamcast should cost with parts and labor? I know the ones for the 360 cost $120.

 

What ever the parts cost/labor+profit+people talking up a projected value.
You are at the mercy of whoever wants to design/build something, unless the project becomes open source. I can't get the concept of how you would build one(software/FPGA wise), otherwise I would have marketed this a long time ago. Lots of people have decoded the DC's drives communications protocol, but no body has marketed it, or shared complete knowledge. The Dreamcast has been my white horse for Optical drive emulation for a while(something that can read my vast library of DC games off a HDD) . My other white horse would be a GB/GBC flash cart with good compatibility and an actual game storage solution (ie;sd/CF). Cash is in hand here:033:

 

Just a little update, the Makaron Dreamcast emu coder creator said he will be making his avalible in the $30-$40 range.

Here is what I asked him.

And here is his reply.

Source

http://dknute.livejournal.com/39623.html

He is still not close to finishing these yet, so we will see if our friend here can get his out before dknute does. I wish them the best of luck to both of these guys with their projects.

 

I've been looking for something like this for over a year now. Turn my Dreamcast into a slot loader like a Genesis. Have the game ROMs loaded onto individual flash cards, one per card. Since most games are GD-ROM format, they are probably over 1GB and will require 2GB compact flash cards. Found them new for as low as $6 online. The nice thing about that is the game can then be run uncompressed since some of them are (I think they are, probably wrong). Since there would be no moving parts, chances for failure are lower, a big issue I have. Noisy GD-ROM, scared it will die soon. You can bet that I will be snatching a few up as soon as possible.

 

The line forms to the left... :lol:

 

and snakes along 6 blocks :nod:

 

Or HDD based, so you don't have to do all that switch'in.

 

Nah. I prefer each game to be on a separate card so that if it fails, I don't lose the whole collection, just the one game on the dead card. Besides, I rather it this way because of my Genesis. Like the slot loader concept. Would think of it as a Genesis on steroids.

 

1 tb hdds are stupid cheap, even after the whole hdd, thailand flood thing. buy usb 1 tb and have a backup. I have a file server at home so i always have a backup anyways.