Judging interest in project.

So I have been the last few weeks began work on Drawing up dev boards for me to test out an idea I have been tossing around for a few months and plan to go full steam on. What I want to create Is a GD-Rom replacement unit that will fin inside the unit comfortably. That one takes the GD-Rom IDE connector using Molex part number 0525840579 (I have Samples in my hand of these) Then from there use the IDE master and go to a SD card (Full/Micro) or CF card slot this will hold what was the CD data dump to the drive as a raw so 1 GB drive minimal then Take the slave channel of the IDE to M -SATA slot (via an IDE to SATA chip) So one can keep the M-SATA SSD in the Dreamcast for Game Storage.

I already have started on Eagle CAD PCB layouts to break out boards of connectors, once I finish drawing I will be sending the boards off to be made so hat I can put on components to then start proto boarding parts like the SD card parts, the MCU, and IDE to SATA (will attempt to replicate existing circuits used in current adapter boards used in PC's).

Now My question is this anything people here would be interested in?

I am well aware this is my first post here but I have been a long time Dreamcast fan as well a robotics designer so this is well inside the scope of my skills. Though when searching for info on things I kept running into this one or a few others looking for data so I figured I would make a post here.

Also does any one have Eagle CAD LBR's for the molex connector that they know is good? As I have made one but would prefer if someone has one that is "known good" I'd prefer to use that.

 

Hold for updates.

 

What's the difference, from the end user point of view, between what you're offering and gdemu/ USB gdrom?

 

I'm with FamilyGuy on this one. They already have SD card devices that plug into the "EXT" port on the console that you can play games off of it. However, it requires Dreamshell. If this doesn't, I'd be interested. If it does? Ehh, no.

 

I would hope to get it to not need dream shell.

I would also Make it an all in one device where if you wanted to add games you just need to plug in your USB cable that would be exposed under the drive door. Where everything needed is in the device the SD/CF would only be needed to update the software of the device and to emulate A game as a RAW copy for problematic games as if it was the GD disc itself. This would allow to hopefully boot from the root Dreamcast OS if this is your choice from the SD/CF raw or use a boot loader menu to get to the MSATA ssd. I would plan to make it use dream shell for those who chose to as well as make my own boot loader software that would be similar to the Wii Flow system.

I would also open source the design (upon completion of revisions) allowing anyone to make the device as wanted (and able to) or they could purchase it from me after I have batches run.

 

Pretty sure you aren't going to be able to just dump a gdr then write it raw to a cf card and have it boot.

 

That is a plan I am looking to tackle, but under theory it shouldn't look any different than a disc as it is coming from a device connected to IDE port , Thus is why i am adding an MCU/FPGA to help if it doesn't just work.

 

Hard drives and cd/dvd drives don't use same commands.

http://wiki.osdev.org/ATAPI

 

Well aware of ATAPI vs IDE but it is possible with some software trickery I can make a IDE device like a CF card look like an ATAPI device running it through a programmed FPGA or MCU to make it look like ATAPI device. I have done this with certain devices we use in my production environment we do this very thing we make a flash device look like ATAPI for backwards compatibility (retrofit). we do this via a one chip solution.

 

Yes, adding an mcu or fpga in between the data will obviously work (with the right coding). But that's certain not what was described originally (and by your own admission the plan).

I know it can be done, there is already a product out that does it. It's just not going to be as simple as you are making out.

 

I know on my first post and I have been simplifying as I am fielding the idea (thus large amounts of fine details are indeed left out)... I am well aware of the difficulty I have designed circuits and software for a while now, but I have come to the situation where I will have the next few years very open to me where in which I need a project to fill said time and this is something I am very serious about doing merely and I am asking about and for interest in this.

Though my first post does mention the use of a MCU I just didn't directly tie it to the data exchange area.

 

I do truly wish you luck. Don't take my skepticism as negative. But we have had people come in with grand plans and not much understanding of the task at hand.

If you get it working, I'll be the first to congratulate you.

Fielding responses is pointless though. If you can do it so it treats it as a gdrom and the DC knows no different, then people will use it. People are already paying quite a bit for the current ones, so there is no risk of it being ignored. Especially if opensourced

 

Is going to say that unless you can make it cheaper than gdemu it would not be a commercial success, but since you plan to open source it I can only support you. One day gdemu or USB gdrom won't be produced anymore and an open source version will clearly be a plus.

Also, the commercial ones that exist right now don't need dreamshell.

 

I am well aware and I do not take your skepticism as negativity Bad_Ad84. As I am new to this forum as I am fairly new to the Dreamcast scene
and most of my previous world has been CAD and Hardware/Software design forums. But I am well aware of the troubles I likely face ahead though seeing the age of the unit and the niece of this I also doubt I will see a C&D come from Sega especially considering I will be ending up doing some reverse engineering of the hardware protocol coming out of the DC's GD-Rom lol. But I do hope to accept your congratulation someday in the next year or two Bad_Ad84 That I expect this research & development to take.

I am merely establishing my Idea though the next few weeks will be down time as a await Breakout boards to make there way through production and shipping from china... I am big on open source hardware as I myself know I will not want to continue making them forever, Thus open sourcing designs once I hit design revision I see as stable will be a plus as someone else with a little technical knowledge needed will be able to pick up my files and make them if they choose.

Also I am sure I can get cost of production and thus sale of the unit cheaper than the likes of similar devices as this has also put me off using other products as the price seem extremely high for what they are. Due to the fact when I have looked at them and done cost analysis of the components on the boards what I can make out and over estimate cost and am still puzzled by the cost.

 

A nice idea is to make it like a drive bay and put a 2.5" Sata drive inside.

 

they make M-SATA to SATA cards and the board will have a standard Molex power on it so you could use that to get you a 2.5 drive in there I am just using Msata for its small foot print. So I could make a adapter set as an add-on kit.

 

I definitely would purchase multiples of this unit if it came into production.

 

This is the main thing that's put me off either solution - they're very expensive. Also, when one did make it to a re-seller it suddenly became almost twice the price (well, almost)

A cheaper open-source solution is exactly what a lot of people are still waiting for. At the moment they're more of a luxury item... admittedly, it's nobody's fault given the work that went into them - but the person who brings the price down could clean up imho.

 

I agree, if you could get something in the works that would be in the ballpark or $70-$100 it would make more people show interest in such a device. If you could make it come down even more than that, which would be doubtful, considering the work you have to put in then even better.

 

You have my interest.