"Let's make GD ROM emulation happen" Facebook group.

I was also thinking the exact same thing as you.People are upset because he isnt set on sharing and some dont seem understand that he might just be doing it out of enjoyment or learning.Some people seem to have trouble grasping that he may have initially not done it for money.

 

You wanna know why I'm getting upset over this? Someone who creates something that average Joe has no chance of doing showcases it with no way for us to get or even build ourselves. To me that's like saying "Look what I made. You can't have it. I'm better than you. HAHA!" I don't care for that. Anything I find I like to share with the community even if it is a loss of money for me. So even if there are no plans to go into production then at least offer a way to make it available. Sell a license for the schematics and code or something. Just do something to make it available for the rest of us. After all. the gaming community SHOULD be about sharing stuff even if you are out to make money from it. Hiding something because of personal reasons is something a bit dumb. If it was for legal reasons then I'd understand.

 

Man he shares so people get to know it exists. He has every right to keep it ot himself or not. Also, there could be legal issues with this, reverse engineering is not well seen in every country, fpga/apu having special licenses etc. Don't judge him too fast. Maybe he'll end up delivering once it's in a state he's satisfied with. Maybe he's not sure about commercializing it or not, in which case it's obvious why he isn't sharing all his infos with everybody. And last but not least. Maybe he's fed up with the flood of stupid questions in his blog's comments and can't stand the waves of stupid questions if he share more there without proper preparation.

Truth is, he has no requirement to share whatsoever. The fact he shared the research process and results is nice already. You got the right to not like him personally, but don't slander his name for an opinion disagreement.

 

In the end, we all know that the only thing that matters is the product that is delivered.

Proof of concept, big ideas, schematics, those are all fun and helpful for everyone, whatever the motivation.

But, the person or crew the community remembers is the one who makes it happen for everyone that wants it, and supports it until it's polished. History doesn't seem to remember many others. There was only one Henry Ford, despite all the others working on automobiles at the time . . .

It would be cool if 2014 was the year of the virtual GD-ROM, but I am speculating that it might actually be finally realized in 2015. It's okay, though, I'm patient. heck, I've been waiting for years for the next version of the ATARI flash cartridge that will support the 7800, not just the 2600 (the HARMONY series, if anyone follows it). Retro gaming seems to be a patient man's game

 

I had no idea who he was to be honest, which is why I was surprised at everyone being so convinced without any real proof (beyond a jpeg of a pcb)

Well, if he has done it purely to prove to himself that it can be done, great - although my question still remains: If he's smart enough to build it, why does he need a beta tester?

My best guess is that if it's real, then he'll release it - there's a lot of money involved here, and unless he's got a money tree in his garden, I doubt he'll pass up the opportunity. That's what I'm thinking right now.

Still, congrats on achieving what others have spent so long trying to achieve, great work.

 

I understand the criticism given you didn't know him. I guess the beta-tester is simply a friends of his or some contacts to whom he sells the other PCBs in the batch, as I doubt it's very economical to build stuff like this in batches of one.

While there's a good potential profit in commercializing those, it also takes a good initial funding, and that can be intimidating. Especially if the APU/FPGA has proprietary code/licenses.Also, it took him long to achieve what he's done. The blog is a good read actually.


Just my 2 cents.

 

@OzOnE - Well, that's understandable. I won't say I like it much, but I respect that.
Guess I'm starting "from scratch", then.

I'm not in it for money, I really wouldn't care if I didn't make a cent off it. I'm more interested in the challenge, but it is going to be quite difficult, of course.
Hopefully I can get some help after you guys finish yours. Even with all the documentation I have, there's lots of unanswered questions. For example, immediately after boot, the Dreamcast reads a lot of data from the drive and shows some odd waveforms on the control pins. Is this documented? Does it need to be emulated? I have no idea. I suppose I'll start finding out once I can get some boards made and get to programming.

I do hope we can work together eventually, though. It just pains me that other people have this stuff figured out already and I've gotta try to figure it all out again! I'm totally excited for DCIO, though, don't get me wrong! I'll definitely be buying one when they're available.

 

Just been reading some blog entries now... on your advice!

Damn, he's good! He had games running way back in 2011. I guess he really does know his stuff, I should've looked a bit deeper before making my original comment.

I still wouldn't be surprised he does some sort of limited run though, as much as it's a challenge to do it in the first place, I don't think someone would go through all that effort without wanting to get something back.

Is there any reason why the DCIO team can't collaborate with him in some way? Surely he could give them a helping hand with some aspects? Regardless, an interesting read, and a very talented guy - kind of reminds of Bunny who cracked the original XBOX way back when.

 

As was mentioned, perhaps if someone can snag one from the limited run Ozone/cybdyn can reverse engineer it. Or maybe duenan will release the documents for it. I shouldn't have been so down on duenan in my previous post. It's just that I think we're all very excited for something like this and we would all hate to see it slip away.

 

10 heck even 5 years ago, someone putting a board like that on the web, would have been greeted with awe and wonder and acclaim. In 2014, it's really no big deal, and if you're not going to sell them to the community, serves very little real purpose. It's just what people have grown used to now.

 

when i only start work on DCIO, i asked him on his forum but i didnt get any reply or reaction from him. if he could even send/sell pcb - i could save time, but i had started make my own scematic and pcb board.

it could be useful/helpful if he shares common theory about how-gd-drive works, any secrets/hidden details. that's why i left "gd-drive" support on dcio.

 

This is the type of biohazard 1.5 type fan batshit douchebaggery that is going to push him to not release ANYTHING about it.

Nice going guy.


I also see that entitled prick werejag shitting up the comments on deunans lj post.

 

I was just throwing out ideas. No need to resort to name calling.

 

It's the Internet, it's inevitable - - 'tuffin up!

Heck, since it is the Internet, if the thread keeps going long enough, someone or the situation will eventually get compared to the Nazis and Hitler (link to Godwin's Law)

See there, I just did it - - self-fulfilling prophecy...

 

These forums are a preciously preserved area on the internet where Goldwin's law doesn't really apply.

Please keep it like this!

 

Agreed!

:thumbsup:

 

Right, because reverse engineering never led to anything great in the gaming scene. Idiot. Besides, Ozone/cybdyn are working on their own project that WILL get released to the public so who cares if he releases it or not.

 

By the way, Stone Age Gamer said that he offered dknute basically the same setup as ikari_01 has with krikzz. Someone else would produce the product, he'd get a license fee, and just help on support a little. Wasn't interested.

 

@Mario - sorry, but you can understand my position atm.
We're just on the verge of starting testing on the new boards, so just give us a few more weeks and I'll see what we come up with.

As I say, I know cybdyn is doing this for the community, as am I (or I wouldn't have released my previous code), but we'd need to sell at least a few of the boards to pay for more components / PCBs etc.

The latest "working" code is cybdyn's anyway, but you could ask him if he wants to release any of it at this stage.

There is quite a lot of info on this thread about the SPI protocol on the Dreamcast though.
It's essentially just an ATAPI / IDE interface, but with some customized packet commands that Sega added.

The SPI manual is on this forum somewhere, or just Google for "CDIF131E.pdf" / "DCDBSysArc990907E.pdf" / "Gdfm_k214e.pdf" / "Gdfm_s132e.pdf" / "E_DC_HW_outline.pdf"

The CDIF131E PDF is basically your "Bible" for the SPI commands. The exact format of the security stuff isn't mentioned though of course, but there are ways around that.
It's also good to cross-reference with the ATAPI spec manuals. You need to have a good understanding of the standard ATAPI packet commands.

One of the first things the DC does when it boots is to read the TOC of the disk, then do the security handshake.
This is believed to be a kind of checksum algorithm based on the barcode part on GD disks (there are a few patents on it).

But, emulators like nullDC and others just used a fixed response back to the DC.

Even though the DC usually requests a random packet length, most emulators simply send back a fixed length packet of data (1012 Byte IIRC).
This apparently makes it pass the security / barcode handshake?

The DC then just reads IP.BIN from the start of the last data track on the disk (usually the High-Density GD session on Track 03, unless the disk more than the "This is a Dreamcast disk..." audio track).
The IP.BIN bootstrap is then run, which usually triggers another security / barcode handshake, then reads the TOC / PVD of the disk to find the 1ST_READ.BIN file which it loads into RAM just after IP.BIN, then executes it.

Most of the games will be using the GD Syscalls in the BIOS as well, but you don't really need to understand that if emulating the SPI commands themselves.
To understand the Syscalls isn't too bad, but needs some knowledge of SH4 assembly and C function calls (which isn't my best area of knowledge tbh).

There's a ton of info on the boot process, including the BIOS Syscalls on Marcus' site...

http://mc.pp.se/dc/sw.html

I don't think this is anything that hasn't been mentioned before tbh.

It probably won't be an easy road, but as cybdyn said to me many months ago - it should be a lot easier if you use an MCU programmed in C so your debugging will be faster.
That will allow you to code things faster, and allow you to send a lot of debugging captures back to the PC for analysis.

Of course, you'll need to extract / generate all the TOC stuff as well, then send back the fixed security response (in the nullDC sources), and process the requested sectors into a buffer.
Then you have to handle all the DMA stuff, which isn't too dissimilar from PIO transfers, but the DC expects to read the data from the buffer at full speed (~16.6MBytes/sec).

You can apparently pause the DMA transfer if your buffer is too small or if it can't keep up (in the ATAPI docs).

I was loading all the requested sectors into SRAM on my original project.
That lets the DC read the whole chunk of sectors in one go (the maximum amount in one command / "chunk" being the size of the buffer on the original GD drive, which was 128KBytes apparently).

Anywho, after MANY months of work, I never got my FPGA-only project to boot past the Sega License screen, so that sucks. lol


btw, I wouldn't want to reverse-engineer somebody else's project (unless it's a old arcade board or whatever, which is an exercise in preservation).
Also, the ARM chip code can be very well protected anyway, so it would be a waste of time for all but the most determined people.

(this doesn't stop the Chinese or someone from reversing the DCIO either of course, it's just a sad fact of modern times.)

Of course, a lot of this very site is about preservation of older games and systems too, which is part of what the DCIO itself is about.

OzOnE.
P.S. No more arguing please, guys. Let's just look forward to the cool gadgets we'll have soon.

 

Thanks for all the info, I do love your gigantic posts! I have read through both threads (this one and the "Replace GD with flash card" one) twice each now, and I'm happy to say I think I've wrapped my head around pretty much everything. That's a really good summary of both the threads, too.
I do have to say, your previous posts have been a lot of help, too. I'm glad you documented everything, even if your files aren't up any more.

I do have all those Sega docs and have been going through them a lot, especially now I've done a few logic analyzer dumps, it's much easier to see what the (sometimes poorly-translated) specification meant.
I suppose we'll see how I do when I get some boards made - in an ideal world I won't need help, but we'll see how that goes.

Only two things I'm wondering about at the moment, would be wonderful if you had an answer.
One is how the drive is selected, as opposed to the other devices on the G1 bus. On my analyzer I can see accesses to the flash, but I don't see any change in the control lines (like CS0/1, DA0/1/2, Reset, etc). When the DC is reading from the flash or from the GDD, all the control lines seem to be in the same state. Is the only difference that the drive won't respond simply because it hasn't been given a command, or is there some other control line I'm not looking at? Seems like strobing the read line might just confuse it, otherwise.
(By the way, the strange stuff I was seeing on boot was indeed the other devices on the line - I completely forgot it was a bus with more than one thing on it.)

EDIT: Well, I answered my own question on this one after starting on the ATA spec. Guess I should probably finish reading that, too, before I ask any more questions.
"When CS0- and CS1- are both asserted or both negated and a DMA transfer is not in progress, the device shall hold DD (15:0) in the released state and ignore transitions on DIOR- and DIOW-."

The other thing is that the GDD read bursts while loading games often exceed 128kB, according to my logic dumps (and I'm pretty sure I'm counting right). So I guess it is more like a streaming buffer? I'll need to also be reading data from the SD while sending it to the Dreamcast, it seems.
Thankfully, there are ~1.5ms pauses between reading every sector of 2048 bytes (at least on my ReVolt mil-CD), so that's tons of time to start another SD -> RAM DMA operation.

By the way, I'm definitely more than happy to send a donation if you guys need prototype boards and components. I'm just as excited for this as anybody!