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

Because reverse engineering ancient software/hardware that in some cases documents cant be released for is absolutely the same as reverse engineering an active project that if you weren't entitled by recognition might actually be released without you having to go through the process off pissing off somebody AND having to do a bunch of work are one and the same right?

PPS: You might learn a lot by looking at the FOSS movement and seeing how projects can benefit hugely from merging/using source code etcetera from other projects.

insane resi 1.5 fanboys gonna insane tho

 

It doesn't matter anyway - it's nearly impossible to extract firmware off a microcontroller in any useful fashion. And sniffing the data lines is useless as well if it does properly emulate a GD drive; there will be no difference between the two.

 

You may want to research how to prevent writing run-on sentences.

 

A run-on sentence is one that contains two independent clauses without the proper punctuation.
A run-on sentence is not a sentence that is too complex or long for its audience to read.

Cyantist's post only contained one of the two options above; I'll let you figure out which one it is.

 

LOL. Good one.

 

"He's got me there! I know, I'll point out a slight error with his grammar, not knowing if English is not his first language or if he struggles with it"

You got me there bro

 

Keep calm and be constructive.

Any news Ozone and cybdyn?

 

i have got all parts,
i found few bugs, it took 1..2 days to found each.
now i'm working on fpga code, and code for ARM.
maybe soon i'll attach dcio to DC, and make vid. maybe ask OzONe.

 

CD Audio support?

 

in future

 

Just take my money, already!

 

PM me.

i mean, in future, because we run a games first, then run them from usb-hdd, then reach to cdda support. step-by-step

 

It seems that great progress has come about for DCIO.
All the efforts that the community programmers are putting into DCIO.

When boards are ready for the DC community, give the green flag so we can buy!

Thanks,
-Steve.

 

Preliminary schematic:
http://i.imgur.com/VlhZgX2.png
I just realized I forgot to label the SD breakout header, but that's all right. It'll all get cleaned up a bit later.

Right now I'm working on the PCB layout, then I'll double-check everything, then get boards made and I'll solder together a few prototypes.

Then comes the long and grueling process of programming it all! Hoh boy.

 

Do you mind if we add your progress to the DCIO Facebook group? They are getting antsy for news of SOMETHING. Be good to get your version out and known too if serious about getting it to work.

 

Sure! But please say that mine almost certainly won't be done before OzOnE and cyndyn's. It's more of a personal project. It may not even work at all; a microcontroller could be too slow.

However, I do plan on eventually selling them at low-to-no profit, and will be open-sourcing everything once it's all done.

 

you can chk http://www.dc-swat.ru/forum/thread-1888-page-17.html , there is gd_board.pdf - scheme of another gd-emu on STM and XILINX.

actually, group from the FaceBook is about gd-emu, not only dcio. so everyone can show what he does to make it happens.

i'm interesting did you think how your device will handle asynchronous signals /WR, /RD, CS[1..0] ?
I didnt test such way, maybe you plan use interrupt for such event. another question about DMA it's quite fast. - but you have a chance.

i wish good luck. track for updates

 

don't forget freq 33.8688 on MCK line.

 

Thanks, cybdyn. I don't think I've seen that particular project yet.

It looks like they're using the slightly higher-spec version of the chip I'm using. Actually, that's the most advanced chip STM even offers. That's just for the prototype though, right? I really doubt they'd need a microcontroller that fast if they have an FPGA handling the low-end signaling.

For capturing the CS, DA, and WR/RD signals, the current plan is to have the microcontroller just run in a constant loop while waiting for a falling edge on WR or RD (I think interrupts will be too slow). CS0/1 and DA2/1/0 are the control lines, set up to be read as an address straight from the GPIO port. So, if the Dreamcast requests the status, it would set the CS and DA lines, then RD would fall. The MCU would read the control line port, use that as an address offset, and copy the value from that spot in RAM to the data lines which the Dreamcast would then read.
Sorry if that's a bit more confusing; it makes sense in my head. The difficult part is definitely making sure I'm fast enough - it looks like the /RD strobe only lasts ~90-100ns, so about 15 instructions. Hopefully I succeed.

As for the 33.8688MHz signal: The plan is to eventually support CCDA, so I chose a chip with built-in serial audio capability. The 33.8688MHz signal needs to be synchronized with the audio, so I selected a 16.9344MHz (1/2 of MCK) crystal for the MCU and will be outputting the MCK signal on the serial audio MCK pin. This way, the MCU provides the master clock and is synchronized with the serial data as well. Plus, I don't need an extra external oscillator for the signal.

 

i understand what you mean.

data from PIO side updates w/ delay, so maybe couple clocks will be lost on synchronization.
also you need capture data from ADR[2..0] and CS[1..0]. it's possible get all this info as PIO port can be 32 bit wide. so better define data , addr, cs line on same port.