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

Definitely going to join the virtual queue for one here. This is a great project and I'm pleased it's coming along so well!

 

virtual queue sounds good, but it brings only virtual help.

 

All those developments are very amazing.

 

If data access with Cybydyn's board could be faster than the GDrom - would there be a possibility that large AES games on the neogeo emulator AES4ALL would run noticeably more smoothly? I believe AES4ALL swaps files into ram as needed in order to get around the DC's ram limitations with these very large filesize games - and the gdrom seeking and reading is a main speed bottleneck in this process.

 

Oh wow really glad to see some of the developments in this field. Last I heard someone had a working prototype but refused to share the details on it

 

Here's a very thorough httrack mirror of the site I made just recently:
https://mega.co.nz/#!kANRwZRR!ezDE8RuWat-8TpylYKDrAT3biFUVlSrhjzWMzAN7hv4

Bitter experience has taught me: archive everything. I've got hundreds of gigabyes of emulation-related website archives, and lots more still on the to-do list. I'd archive assemblergames if I could, but the mirror process would never end with a forum this size. I've considered making a special-purpose httrack mod for vbulletin boards which can scrape every topic in the forum without going into useless areas and page duplicates. If I ever get around to doing it, I'll probably archive the assembergames forums too.

 

x

 

Good to see this Project Alive and Well!

The 'mini' board has support for OTG ?

* Host (for reading USB flash drives - So you'd need a partial USB (Mass-Storage) stack AND 3/4 Filesystems ? ; Ambitious!)
* Client (For pushing data at the ARM/FPGA to reprogram / stream data to the DC G1 Bus ? Would be mighty handy for debugging and DEV work - could this be used to monitor the DC's memory indirectly?)

* USB Mass-Storage passthru for using a directly attached SATA(IDE) drive without disconnecting it from the DCIO/Dreamcast ?

 

What I believe from all my readings/tests, is that, for the dreamcast at least, the magic lies in the transition from data to ring, a reflective part that has its signature detected by the gd-rom controller via firmware. This could be what you call a wobble.

 

I am am insanely excited about this project...I'll be thrilled to solder one of these puppies into one of my (many) Dreamcasts if this keeps going well! It really could be the magic bullet for the Dreamcast's big weakness, the optical drive...! THANKS for working so hard on this!

 

It seems to be solderless, no?

 

Even better . . .

 

ARM w/ usb OTG = which means it can be Host and Device. Host for usb mass-storage devices like usb flash and usb-2-sata/ide to access to HDD of course... Device for conecting w/ pc. all of this USB 2.0 speed. i hope)))

also GD connector for gdemu, and GD stack connector to attach original GD-drive for spying (as we not sure in all things how gd works) and copying GD discs (board can work apart from DC if we need just copy disc).

as usuall - SD card support for games or someting else saves.

status : pcb on the way. OzOnE one of them.

 

@cybdyn - I just sent you an e-mail, but I clicked reply twice, so sent you a copy of your previous e-mail too. lol

Yep, solderless. It's not a mod chip, it's a replacement for the GD drive so has the proper Molex connectors on it.

I had a bit of a play with my ARM F4 Discovery the other day, and it's not too bad getting the code examples running.
There are quite a few examples for data transfer via OTG port, SD card access, and filesystems etc.

I'm awaiting the boards from cybdyn (hasn't been long since he sent them).
This will be my first try with an FPGA + ARM combination board, so I hope I can still be of help. lol

@dark - cybdyn's board will definitely transfer faster than the original drive.
The peak transfer rate is limited by the IDE mode on the DC itself (MultiWord DMA Mode 2), which is a tiny bit less than 16.6MBytes/s.

It has been determined that the average transfer rate for the original GDD is around 8-10MB/s.
The GD emu will also have massively improved random-access times too.

The only limitation then is the speed of the SD card, but even the cheaper ones are pretty fast with a 4-bit data interface.
It may even be possible to increase the transfer rate on the DC side by doing a BIOS patch (or patching within the game).

@Nemesis - I know you mean. It's a bit worrying when a site goes down after so many years, but it happened with geocities and hundreds of other sites before.

Luckily, I still had most of the files from the crazynation site for the Gamecube DVD drive emu etc.
Your archive is even better though - thanks a lot for saving that, downloading now.

I'll order the parts for cybdyn's new boards soon, then I can get stuck into the code when I get chance over Christmas.
I'm very grateful to cybdyn for carrying on with this project, as I'm not sure I would ever have got my old version working (still couldn't recently).

I know you guys are eager for info on this project, so I'll try to post updates more often once the PCB's arrive.

OzOnE.

 

yes yes !!!

 

Glad its still happening, will keep checking back for updates ;-)

 

Just received cybdyn's new DCIO PCBs.








cybdyn wanted to see them as well. He is surprised how fast they got here to the UK from HK.


OzOnE.

 

aaa both sides now can work and share the development!

 

Soldering all those little components will be fun. lol

I'm used to soldering 0805 passives, but these are 0603 I think, so I'll need to break out the tweezers.
Not too bad though, a good soldering iron helps a ton (I use a Metcal MX-500 with a 2mm chisel tip.

Just working out my finances atm before buying the parts.
It's not exactly expensive, but I've spent far too much on eBay recently.

I just bought my first Rasp Pi as well, to use with this project (not mine. Very clever coding)...
http://amigadrive.blogspot.co.uk/

OzOnE.

 

I am so friggin excited for this.