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

No but someone saying "DUDE this totally needs a sequel" is ignored while "DUDE I totally have a sequel written out right here complete with story boards and a handful of pre-signed producers" might actually get some attention.

 

OZONE - "I've found that my data is still corrupted. I'm gonna throw the SDRAM idea out of the window and buy an SRAM board"
but original gd-rom and all drive use sdram! in you case dont forget DMA process can be puased/resume by manipulating bus contorol signals BREQ/DACK.

 

Hi,

This was mainly a reply to a PM from cybdyn. I thought the info might be useful to everyone...

Here is a collection of the VA0 schematics and all of the Dreamcast Dev docs I could find (101MB file!)...

http://www.multiupload.co.uk/YWPXS0TFY0

The most important document is CDIF131E.pdf (which I converted from CDIF131E.doc).
This manual describes the SPI (Sega Packet Interface) commands. NOT to be confused with SPI (Serial Peripheral Interface)!!

It took me a long time to get hold of that manual. It had fallen down a crack in the Interwebz. :wink-new:

The other important doc is Gdfm_k214e.pdf, which I used to figure out the GD TOC and many other things.

Basically, the original GD-Rom drive uses the ATAPI type protocol, but with modified packet commands.
And yes, in case anyone asks again, the GD-Rom interface IS standard IDE / ATA, except for the modified commands and a few extra pins for the CD-Audio data.

For all the standard Reads / Writes to normal registers, it of course uses PIO, but for all "CD_READ" commands, it uses Multiword DMA Mode 2.
(I've never seen the DC try to do a CD_READ command via PIO yet, but it does have a flag to choose between the PIO and DMA).

One of the first commands sent to the drive is "Set Features" which selects the PIO mode, and selects Multiword DMA Mode 2.
This means a transfer rate of around 16.66MBytes/sec during "CD_READ" commands.

I don't know how to modify the DC at SW level. I tried messing with IDA Pro and debuggers on emulators, but they weren't very useful.
This is a bit beyond my knowledge tbh. If I had a decent debugger for the DC which can set breakpoints properly, I might have better luck.

@cybdyn: I'm guessing you might be thinking of bypassing the need for SDRAM and SRAM by allowing the CF Card itself to drive the DMA transfer?

Well, this is what I was hoping for with my first attempt. :tongue:
I simply translated the SPI commands into the number of sectors on the CF Card, then let the CF Card drive the actual DMA process directly.

Basically, I just multiplied the "gd_sector_count" by 4 because the DC is expecting each sector to be 2048-bytes (CD standard), but a CF Card of course has 512-byte sectors (in IDE mode).

This worked fine for up to 256 CF Card sectors (the maximum for one "block"). This is only 64 "GD sectors" though!

This is why the Sega Logo worked OK from CF Card, but after IP.BIN etc., the DC requests the "1ST_READ.BIN" file in a continuous block of 210 sectors (840 CF Card sectors!!).

Quick side note: I converted my GDI RAW image to an ISO before copying it to the CF Card (SD Card on the new board).
This removes the extra sub-code Q info and error correction (2352-Byte sectors).
The DC doesn't appear to read this info when reading games. It only requests 2048-Byte "data" part of the sectors.

So, the problem was that the CF card was too slow to respond to the extra READ_DMA commands that you need to send every 256 "CF Card sectors".

The DMA transfer is fairly simple. I was a bit scared of it at first, but it's OK. It actually simplifies things in some ways (even though it's causing the problem) :rolleyes-new:

You can see the two DMA handshake signals at the top of this capture...

http://tinypic.com/view.php?pic=mt2iq&s=6

I've called them "gd_dma_req" and "gd_dma_ack_n". The DC schematics call these "DRQ" and "DACKN".
The IDE/ATA standard would probably call them "DMARQ" and "/DMACK".

"gd_dma_req" is an output FROM the FPGA (GD Drive) TO the DC.
"gd_dma_ack_n" is an input FROM the DC to the FPGA (GD Drive). Remember, this is active-low, so is normally HIGH!

After you have prepared your sectors and you're ready for the DMA transfer, you assert "gd_dma_req" HIGH...

The DC responds by setting the data bus as an input (and sets the "DMA channel" address), then it asserts the "gd_dma_ack_n" signal (LOW).

NOTE: You should only drive your data onto the bus when "gd_dma_ack_n" is Low AND when the address is in the "DMA channel"!

The "gd_rd_n" signal is then used to read each WORD from your sector buffer.
On the falling edge of "gd_rd_n", I increment my buffer address to read the next WORD onto the bus. On the rising edge of "gd_rd_n", the DC latches the data.

That's it really. There is a whole lot of other stuff to do before and after each transfer though. You need to set the status / intreason registers correctly, and handle the Interrupt Request signal etc.

I got most of the commands and info from the nullDC "gdrom.c" source. It was a bit easier to read the code instead of the SPI manual. :tears_of_joy:

You can see the DC reads in small blocks of 16 Words (32 Bytes) and it will often de-assert the "gd_dma_ack_n".

Remember, the "gd_rd_n" signal is toggling at around 8.333MHz !
So, even when "gd_dma_ack_n" goes high, it's not enough time for most CF Cards to respond to a new "READ DMA" command every 256 sectors.

There doesn't seem to be a way of pausing the DMA transfer, the DC just tries to read in one big block?

I tried de-asserting "gd_dma_req" after 256 CF sectors - I think the DC responds after a while, but I can't remember exactly what happens?
Actually, this might still work. I'll have to test it again.

It might be possible with a faster CF Card, or if you use a CF Card in "memory mode". I haven't tried this yet, I think this is what Marshall is using on the 64Drive?

This is why I need someone who is also working with real hardware so we can test these things. Especially if you have more Verilog / FPGA experience.
I've read through many ATA specs and source code - there's just a ton of stuff to figure out and I'm still learning as I go along.

What I do know is that I definitely managed to boot to the Sega Logo using the old board and CF Card. So, the core logic is working OK.
I just need reliable storage for the sector buffer. The on-chip (FPGA) memory is way too small to hold 420KBytes of 1ST_READ.BIN!

I confirmed yesterday that my data is being corrupted when read from SDRAM. The SD Card driver seems to be working fine though.

If anyone can help with the code, or supply an easy-to-use SDRAM driver, we could be loading games soon.


Regards,
OzOnE.

P.S. I noticed the GD-Rom port is on the same G1 bus as the BIOS ROM and FLASH. It would probably on need ten extra signals to be soldered and you could easily do the multi-bios thing.

 

ozone, if you put up a paypal link, I'll be glad to throw a few bucks your way to help you with R&D supplies.

 

Same goes for me.

 

Me too, let's make it happen! \,,/

 

Thanks, guys! :wink-new:

I genuinely do appreciated the offer, but I've always tried to do stuff off my own back if possible.
I have a small amount of cash coming in, so it just takes a while to work out what I have spare, and then carefully choosing the parts I need.

Don't worry, my DC is now a more of a permanent install on it's own bench, so I won't be tempted to de-solder it any more.
In the next few days I'll be buying the other FPGA board (with SRAM!) which will be bolted inside the DC.

I'm determined to get this booting, I almost had it working with the CF Card last year (or was it the year before)? lol

I spent most of today revisiting the DMA pause stuff (thanks for the reminder cybdyn!)
It's still not working, and I'm not sure that the DC conforms to the IDE/ATA spec 100%.

It does seem to pause the DMA transfers when you want, but my data is still screwed up somewhere?
Again, it could actually be made to work, but I think it will take ME too long to debug.

The good news is, IF somebody can get this working, it will work without any external SDRAM / SRAM and read directly from SD Card via a FIFO buffer.

I will upload the latest projects at some point if anyone's interested?

btw, there are huge amounts of info in the DCDBSysArc990907E.pdf manual I uploaded earlier (in the huge .zip file)...

The manual confirms the DC does DMA transfers in 32-Byte (16-Word) bursts (on page 217).
So, if you do try pausing the DMA, it needs to be done after every 16-Words (I tried waiting until "gd_dma_ack" / DMACK goes HIGH).

Most importantly - pages 303-313 describe the GD DMA registers, and pages 354-360 describe the standard GD ATA (PIO) registers.
It may be well worth printing these pages out if you're working on the code!

Also, I realized that I had a decent DC debugger installed all along - my old friend, the MESS emulator!

Here's something anyone can try...

If you start DC emulation under MESS with the debugger enabled, then enter "wpset 5f7000,4ff,wr" and keep hitting F5 you can actually watch the GD-ROM register accesses!
There might be some security stuff bypassed under MESS though, so don't take the results as gospel (they might not match a real DC).

If you're wondering what the log results mean, I can probably decode most of it be eye.
Seriously, my brain is full of this crap - you know, like in Flight Of The Navigator! (except it's "GD Packet commands" instead of "Star Charts".) :topsy_turvy:



Thanks again guys,
OzOnE.

 

good information and good luck in completion.
i see you use FPGA for handling packets, i think is rather hard to debug in the beggining.
i use mcu, its easer make pogram in C. and fpga is only for registers/FIFOs and creating special signal sequences (DMA, SPI, IDE,...)
i plan make program and send by USB, for debugging DMA and all other thing.

also if the "HW based DC-emu" tough to complete, there is way make it happen by SW - like SD-mod does it. i mean replacing syscall by our code and now we can dont support original interface at all.

so now what is need it's a PCB board. and i'm under way.

PS: it's unnecessary but any support will be good. maybe after i show my prototype?

 

doing it via SW is totally pointless due to the slow ass serial interface
it dont help with compatibility at all
the lazy way is NEVER the best way also emulating the lazier if HW emulations fails
would be far simpler due to the always on nature of optical media drives works on basically Morse code
we would just need hardware to read the game image and translate it into an on and off signal

 

"doing it via SW is totally pointless due to the slow ass serial interface"

you dont know what i'm talking about. i plan change syscalls on SW level for workin with my fast speed HW board.
under original interface i ment "SPI" packets and DMA data transfering. so in my case its not need do according for them, and i can make more comfortable and easy protocol, even same ATA/ATAPI.

 

translating image data to signals - it is possible, but very hard to complete

1- 8->14 bit coding
2- data is not sequenced -> data mixed from many parts of stream
3- using DAC to generating analog signals - so you need emulating A, B, C, D, E, F ~ 6 x DAC as minimum

4 - most complex you need also ADC for detecting stepping signal and spindel ~ 2 x adc

and all this set of "ADC & DAC" must work with good syncronisation , so i dont know - you mabe need good DSP!!

dsp + 6 x dac + 2 x adc + fpga/mcu -> can you say how much it can be cost))))??? and how much time it takes for debugging.?



so, it seems the easiest way is HW/SW emulaton.(IMHO)

 

umm dreamshell only interfaces with the dreamcast serial port right now it says it has support for HDD but yet no such device exists
the only other interface we have is the G2/modem bus still nothing concrete exists for that interface eather there was one project to convert the G2 bus into PCI and use a PCI network card but very little is known

also even a drop in solution for the G1/GD drive bus will be using SW emulation if we had the GD drive firmware and lazier specs we wouldn't need a project like this we could just have the lazier made or build after market GD drives

 

sd-mod was made by SWAT, and he said he help me make driver for supporting my device. also i plan make it myself too.

so generally i'm waiting wheh my board will be made.

i think you can wait fw and lazer spcs for a long time... (eternity) )))

then, i plan discover g2 bus too. it has good advantage as external device, no need unscrew dc box.

 

sounds kinda chicken and egg to me because you need to load dreamshell to access your driver to access the G2 bus
but the lazier on the GD drive are is poor shape or already dead so you need to open the dreamcast to do the bios swap/link bios mod
to install dreamshell perminintly

oh i know very well well never see what we need for after market GD drives unless Yamaha engineers that helped design GD-ROM
spill there guts

 

i plan make multi-bios support - it means bios image loading from my device by g1 bus.

i dont care how someone will load dreamshell (by my device on g1 bus/ with bios-flash-mod /from native cd/gd-rom disc) - my purpose is the device for g2 bus. it 's like in the case of the sd-mod.

actully we are talking the same thing as in another threads)) ..we walk around but stay the same place)) will see when it start become in real

 

Just want to say good luck to all involved in this venture - I just noticed this thread now, I don't understand much of it but I get the general idea!

Great stuff!

 

ye, the luck is taking one of the most important place in this work))

 

Being lucky is a talent, a skill!

 

@ OzOnE

Nice to see you back on this again and it sounds like you are pretty fired up for it. As before you need anything (games, hardware etc etc) give me shout and I will try my best.

Rob

 

Thanks for the offer, Rob! (how's it going?)

Yep, I've got a bit of renewed motivation for this again. Let's hope it lasts the course this time. :smile-new:

I ordered the new board from China on Friday. None of the six or so sellers I e-mailed could supply the SRAM chip with the board, so I bought one in the UK instead (£10 for 512KB though!).

Not sure how long the board will take to arrive. Judging by their feedback, looks to be around 3 weeks.

I still have hope for the current board though...

I think @cybdyn is correct, it should be possible to pause the DMA transfer so the poor SD Card can keep up.
In which case, it won't need any SRAM or SDRAM at all and loading speeds will only be limited by the SD Card itself (which are FAST nowadays anyway).

The original GD Drive is suppose to be 12x-speed, so around 1800 KB/s. The average SD Card should be capable of roughly 8000 KB/s (4-bit access)!

Anyway, still progressing. With Cybdyn and others on the case, we should be able to make it happen this time.
Basically, what he's saying is, if the DC-SWAT guys modified their hard disk routines to work from the G2 bus, making a board for that would be MUCH simpler!

Loading times would be fantastic (for most games), and you'd have huge storage for your GaMeZ.

OzOnE.
P.S. Actually, "aftermarket" GD-ROM readers might not be too far fetched once this is running.
Reading real GD's could prove tricky though, maybe we could run modified laptop drives (or whatever fits in the case nicely)?

Does anyone know of any PC drives which can rip GD disks AND could be trimmed down to fit into the DC?