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

Excellent work man! Glad its at the same stage as before and this time it seems to have a more solid foundation. Hopefully you and others can make the breakthrough!

Good luck top work so far! :encouragement:

 

i think its that damn driver getting in the way
did you find a new driver?

also if this was done DIY style $1 for a pack of 10 at $0.1 ea aint to bad even at $10 for 10 thats still not bad
so basicly we only need the upper connecter a FPGA and a GPIO mass media adapter

[never mind/]i really think going back to CF would be a wise choice at this point
the first of aug i can pitch in to get you a CF adapter [never mind]

didnt see your edit that we are back to 7 months ago
now we just need to figure out the commands
or what is corrupting things

 

IIRC - The IDE devices are usually little-endian, the SH4 BIG-endian, the BUS controllers, sometimes byte-swap!
Check the docs, I remember it mentioning this somewhere...

Also - Yes, if ONLY there was a way to bit-bang some data across another bus...
(The DC MODEM uses the G2 differently, its a dumb asynch device - so perhaps if you patched one of the customized BIOS's to duplicate all data sent/received to the G2 data pins/Register and connect those to the FPGA to dump back to the dev PC or something)

It think its as simple as duplicating all the TX to the G2's address in memory (at least on the DC side).

 

I don't know why I didn't spot the byteswap before. It's been many months since I last messed with this stuff.
I only started suspecting the endian issue when I tried "gdrip" on DS and it didn't even recognize the IP.BIN (even though I could see the data going across, non-swapped of course!).

In the old code it was just doing DMA directly from the CF card and I don't think I needed to byteswap in the code?

Anywho, I haven't got much further. I can get "gdrip" and "dcsdrip" to at least start to read the sectors now (PIO).
It's getting stuck after a short time, and I think it's due to the way I'm counting the bytes.

I'm still debugging - it's a laborious process and I'm not an experienced coder as I say.
Today, I started adding the opencores SD driver code instead of the current one (btw, I always backup my previous projects!).
As expected, it's a LOT more involved. There are so many separate registers to write to because it uses a wishbone interface...

For example, this is all I had to do to set up a transfer with the old SD driver...
http://pastebin.com/eDRvDVv2

And this is my rough attempt at trying to set up the new SD driver (lots of mistakes, I was still testing)...
http://pastebin.com/G3TemYay

I don't know how many things I can set in the same clock cycle and get away with it, so I have to "play it safe" and just keep adding extra states.
I also don't know if the strobe signal can be kept high (like a chip select), or literally just strobed once per Read / Write?
The wishbone definitions are a bit hazy on the subject.

@calpis etc. do you use wishbone based stuff a lot? Any tips? Thanks. :tranquillity:

I'll probably end up borrowing parts of code and putting my own SD driver together.
Or, keep the current one (which at least appears to be working) and debug the REAL problem.
OR, go back to the old board with CF card or HDD interface.

I'm liking the sound of the later option now that I have SRAM. The only issue is the lack of pins on this new board.
I'll have to try multiplexing some pins to get it to work. Damn, it's frustrating. I just want to see a game running.

I also need to "standardize" everything by adding a proper 40-pin IDE socket to the DC (plus plug for CDDA etc.)

Man, I knew this would be difficult, but never expected it to go on so long.
One good thing is that I have a working DC Dev environment set up now so I can attempt to write my own debug code. :cocksure:

With an IDE socket on the DC, it would be seriously tempting to try a direct connection to CF or HDD too.
I know most hard drives have a 5V interface and the G1 port is 3.3v (I think?), but I think it will work OK.

So much work to do and I'm still learning.
If anyone has any experience with wishbone or SD stuff on FPGA, please chime in.


OzOnE.
Do I talk / type a lot? I can never tell. lol
I'm starting to sound like "Jordan" in my favourite movie: http://www.youtube.com/watch?v=hQkf-LmsGZw

 

Keep going mate, we are all counting on you.

 

You do "talk" a lot, yet your talking is really interesting! This thread has been officially turned into a developpement journal and I won't complain about it!

Good stuff seriously, I wish you the best of luck in the following!

FG

PS: This endianness thing caused me problems at first when I was trying to hack dc games

 

There are CF cards that work at 5V or 3.3V or 3.3Volt ONLY cards... 100% Pin-for-Pin Compatible to IDE (Plus some power pins/keys) - all you need is a 40-Pin IDC + Ribbon calbe and an adapter/bridge board - just be careful as there are TWO DIFFERENT types of CF cards; "Removable" and "Fixed" - its mostly a software distinction - but it can cause issues with some devices (I forget what ATM - it might only be PC's that have issues...) - Its WAY simpler to drive ATA than the weirdness that is the SD protocol (AKA 4 DIFFERENT protocols in one big mess)...

 

Thanks for the encouragement guys. :loyal:

@FG - Well, I thought I might as well cram this thread full of ramblings since the other one was getting full up. lol

@Melchior - I've seen that 3.3V / 5V operation on CF cards isn't guaranteed. Nice "standard" that is! (as usual), but yeah, still easier than SD.


OK, I've been adding some bits to my first ever DC code and it's doing something mildly useful now.
NOTE: This is a very rough and unfinished code, but it's good enough for my basic testing. It's actually been fun to mess with...

http://www.filedropper.com/gddebug002ozone25-7-12_2

It simply reads one sector at a time from a GD into a buffer and displays it on screen.
It's only using PIO sector transfers atm (all games seem to use DMA) but it's still helpful for debugging.

(btw, the original code was set up for both 2048 and 2352 byte sector types - this code currently only shows 2048-byte "cooked" sectors.)

The FAD address of the current sector and the buffer OFFset is shown at the top of the screen.
The FAD is basically the "native" addressing mode of the GD drive: To convert to LBA, simply take the FAD figure and minus 150.

It only fits 160 (0xA0) bytes of the sector buffer on screen, so DPAD DOWN / UP changes the start OFFset (of the "page") and shows the Next / Previous page of 160 bytes.
NOTE: The start offset simply points to the FIRST byte of the current page. This causes a few issues with the markers (see below).

Using DPAD RIGHT / LEFT changes to the Next / Previous sector (the OFFset stays the same though, so watch out for that).

If the OFFset goes past the end of a sector (2048 bytes; or a page start offset of 1920 bytes in this case), it will auto inc / dec the FAD too.

Be careful though, it doesn't read the TOC atm so I've just manually set the start sector FAD to 45150 (start of the GD data track in many games).
So, if you try to read an illegal sector that's not in the TOC, it will probably crash / freeze / burn house down etc.

If you press X, it should toggle between HEX and ASCII display. Although, the ASCII mode isn't working too great yet.

I've also started to add little markers to show which part of IP.BIN you are displaying.
This is NOT working 100% yet, so don't trust it. It doesn't currently check for things like "GD TOC is somewhere on the current page", only if the page start OFFset > GD TOC etc.
In other words, the (GD TOC) marker might only appear on the page AFTER the TOC and you'll miss the start of the TOC.

The GD drive Status and Disk Type bytes are also displayed. These are things the DC is ALWAYS checking.
You can see it change to GD_OPEN as soon as the lid is open. When you close the lid, it changes to GD_BUSY for a while before it finds the disk type.
The Disk Type byte defaults to zero when the lid is open; this happens to be the CDDA type, so don't worry about it. :tranquillity:

The default Standby time for the GDD is 3 minutes, so you should see the Status change if you leave it alone for a while.
AFAIK, the Status for a GD disk should only change to GD_PAUSE after it passes the security checks??

You can also see the Status change to GD_PLAY when the pickup is moving between sectors.
If you scan backwards (DPAD LEFT) you can see how slowly your GD Drive seeks.

btw, I've named the Status stuff starting with "GD_", so it will still say "GD_" even with a CD. I'll probably correct this in a mo.

The results of all this show that my SD Card (on the FPGA) is reading OK if I go through the sectors slowly, but if I hold DPAD DOWN and read too quickly it freezes.
It could be that I'm trying to do a new sector read before the previous one has ended (unlikely), or that this SD driver code is really as crap as I first feared.

It will take me a while to get the new opencores SD code working. It looks like my FPGA JTAG programmer has also blown up too, so I've bought another one (only £10).

I'm wondering if the JTAG was damaged by a ground loop? When the FPGA is turned on, the DC power supply makes weird hissing sounds at certain times?
Has anyone else had a hissing PSU?

I'm more and more interested in trying a CF / HDD with direct hookup. Shouldn't be too hard (he says).

It would be nice to get the FPGA working as it would have native GDI / CDI support, CDDA streaming, and would work on Retail BIOS (non-modded) DC's.

Does it really matter though if we had super fast CF / HDD storage which plugs directly in via a cheap adapter and works under DS?
(CDDA support would likely require an FPGA in this case. It would also require a DS FLASH BIOS 'cos the GDD would need to be unplugged).

The GD syscalls would need to be redirected for CF / HDD access, but I found some nice info on this. (bottom of the page)... :friendly_wink:
http://www.ludd.luth.se/~jlo/dc/

There is also some good info in the dc-load sources (included with KOS). It shows how they redirect the syscalls.

Cheers,
OzOnE.
"God DAMN, it's HOT!!"

 

you know if we get it working dirty by having to have the bios mod
theres nothing stopping us from finishing it later to make it a plug and play
stock bios compatible system

 

OzOne:
Thanks for yet again another very insight full post! Love checking the forums daily for new updates.. I'm really looking forward to what you come up with and wish you the best of luck on your project.

As far as the cheap adapter.. I'm assuming you're thinking about a possible G2 addon? That would be very interseting, but I personally believe a true GDROM emulator, as your working on currently, is the best solution for near perfect emulation. If you decided to do go with a G2 addon then we would all have to install a custom BIOS also, or load via the GDROM.

 

good work OzOnE, i hope you can help me when i start debuggin my board. i think i will have many questons to you)) and i'll show some source on AHDL and Graph if you want. if you know project can even contains mixed files. main file in hierarhy i make in graph, other elements i make in AHDL or graph too.


also if you done with success your fpga board, i can ask mr Swat to make driver or special version of DS for working with your board?!

i'm sad, i cant start with debuggin my board now, so i wonder if OzoNe make gd-emu first with such speed of development((

 

Thanks, cybdyn,

I hope I can help with your board. It would be great to support multiple systems.
(That's what I wanted to do with my first board, but it got too complex and expensive.)

I'm doing a PCB layout for the DC-to-IDE adapter atm.
I've gone for a full-sized 40-pin IDE socket to make it easier to connect a hard drive.
I suppose I could do a 44-pin laptop size as well (or on the same board) so we don't need to use extra adapters?



EDIT: Sorry, that first pic was a bit too big.

The board can have a GDD plug (bottom) and DC socket (top) at the same time.
Unfortunately, it doesn't look like you can buy a short version of the DC socket, so if you sandwich the adapter
between the DC and GDD, the GDD will float about an inch above the DC motherboard / heatsink. :moody:

I've tried to think through the possible combinations for using the adapter so it's not wasted.
For example...

1. HDD or CF direct connection (no GDD). On-board oscillator supplies the CDDA CLK so the DC will boot. (REQUIRES BIOS mod. NO CDDA STREAMING!)
2. FPGA direct connection (if we ever get it working). On-board osc can be used as a nice CDDA master clock. (Will work with Stock BIOS. CDDA streaming possible).
3. FPGA with GD Drive still connected. Allow "spying" on DC-to-GDD transfers. Or, auto switch between FPGA and real GD disks. (If GDD behaves itself when in Reset).
4. GD Drive direct to FPGA. To allow fast ripping / testing.
5. GD Drive direct to PC. Possibly allow even faster ripping / let emulators read GD disks directly. (Will require a new PC driver).

Anyway, you can see the idea.

I've also just requested some samples of the G1 port Molex connectors from Molex themselves.
I know it's a bit cheeky, but I've only asked for 8 sockets and 8 plugs. They cost pennies, so I don't think they'll care.
I'll e-mail the Chinese suppliers as well soon. They should be very cheap.

(The short GDD plug is out of stock in most places, but a slightly taller one is in stock on Mouser. The plugs / sockets are around £6 - £7 each!
You think that's expensive - the GDD plugs are £17.24 each on digikey!! :hororr: )


No joy with the FPGA yesterday. I've been studying the GD syscalls instead.
When I get the adapters made, I'll see if I can write some code to access a HDD / CF directly.

OzOnE.

 

i know its early but my thought was to have a master control GDI image
that has a master list of all the stored GD games
it would require a FPGA but basicly
the master GSI would link to the game the dreamcast would think its interacting with
the master GDI and the FPGA is just passing sector reads onto the stored GDI
rather then the master GDI

im loving the forward thinking of your swiss army knife GD drive adapter
my wonder is will a IDE to SATA connector function properly likely would need the FPGA

 

how many GPIO connectors/sockets are you plaining because the RaspberryPi has 26 and that might be a good cheap compliment for this adapter

 

Yep, the idea is to have a master menu to select the game image. Something like DS can be given direct access to the HDD / CF.
The FPGA can be set up to have some extra (hidden) registers so the master menu can set the start sector(s) of the chosen game image.

EDIT: Oh, when you say "GPIO" - the adapter will literally be a direct DC G1 port to IDE adapter. The connectors at the bottom are just to break out the power for your CF card (or SMALL HDD!). The extra pins on the right are mainly for when using the adapter with an FPGA - they only carry the CDDA signals and allow control of the GDD / IDE Reset signals.

I've laid out the extra pins in a way that you can put jumpers across certain pins when using a direct HDD / CF connection (no CDDA streaming though!).

Assuming the BIOS can be modded or DS updated to directly access HDD / CF, I would think a SATA adapter would work OK if it's "transparent" enough to the DC.
A SATA adapter should present a native IDE / PATA drive to the DC, so it should work AFAIK?

I don't think something like a Rasp Pi would be quite fast enough to interface at a low level. Although, they are fast, so it might be possible to emulate the GD drive?
The difficulty is that even if a Rasp Pi can access an IDE hard drive directly, it might not be so easy to emulate the GDD (similar problems as with the FPGA).

Having said that; many experienced programmers specialize only in software, but if they were presented with a nice ATA / ATAPI interface, it probably wouldn't take them long to emulate the GDD.
It's only because I'm slightly more "experienced" with FPGAs and hardware that I chose the direct route. I'm not so good with C/C++ yet.

That's why Deunan and cybdyn suggest adding a micro to the board, so you can program and debug your code easier in C while the FPGA takes care of the lowest-level interface stuff.

This is another reason why modding the BIOS is tempting me now - it will teach me more about C/C++ and I already have some experience with HDD / CF from the Doc V64 HDD project.

I'm defo going to hook up a HDD directly to the Dreamcast in the next few days. :friendly_wink:

OzOnE.
P.S. Thanks to @angelwolf71885 for the thanks!

 

As ever mind boggling! but still sounds like brilliant development/progress

 

I never thought this thread would get so popular. OzOnE, if you need a tester for your simple, connector, I'm game. I have several ATA HDD lying around to use.

 

Very interesting!

 

it's good to see something in real!..

...i wanna say more? but remind good words - "less talk - more doing"

 

Too bad there are so many steps (and hoops) to jump thru with the GD-drive, I was hoping it would be possible to build a simple CPLD + MCU + Flash type "bootstrapper" board that loads a 'fake' CD-Image (e.g. Dreamshell), and do the REAL data loading accross the G2 Bus.

- I betcha its a timing problem, it always is...