wraggster
August 9th, 2011, 23:30
via http://dknute.livejournal.com/39276.html
And they said imitation diamond wasn't good enough :)
http://pics.livejournal.com/dknute/pic/000xekdf/s320x240 (http://pics.livejournal.com/dknute/pic/000xekdf/g50)
So, does it work? Sure. It's a very early version though. I've hit some metastability problems so I switched from external ARM7 MCU to NIOS2 running on FPGA to speed up debugging. After I reversed my main clock polarity (yeah, Star Trek style) and it worked better I finally realised that I'm running a synchronous system with asynchronous inputs. Which is basically the same as having two different clock domains since I have no control over setup/hold times... So I've added two-stage synchronizers to /DIOR and /DIOW but that's additional latency and Dreamcast has a bad habit of deasserting /CS signals shortly after rising /DIOx. These things always work so well on paper :)
In the end the hardware side of GD interface is pretty small, should fit in EP2C5 (that's Cyclone II FPGA with 5k logic elements) and that's pretty cheap. The downside is I only have so much internal RAM so the main data buffer is just 8kB. While external SRAM could help here, I'm not yet sure it's worth the trouble. We'll see.
Digital audio is completly not supported yet (but is part of the design, so it will be added eventually) and I just wanted to test it out ASAP so I went with slow, PIO-only SD card access and very inefficient CPU buffering. Also, external MCU needs to be connected to FPGA with some sort of data bus and this becomes a bottleneck for the transfers, as it turns out. For example my ARM7 doesn't have a dedicated external memory interface so I have to do everything myself using a PIO port. With only 30 pins (minus a few for SPI and clock output) all I could manage was 8-bit shared address/data bus. Not very fast, unfortunately.
Because of the slow transfers games exhibit various issues, like missing textures, slowdowns, stuttering sound. This will get better as the project matures. In fact, with proper buffering I'm sure I can get it working as well as original GD drive and perhaps even faster - up to some 2x, which is the limit of what one can do with SD cards in SPI mode. Well, there's always the USB route I suppose.
By the way - I get simply tons of spam in the comments now. I've enabled LJ CAPTCHA but that only cut it in half or so. Worst of all, the spam looks (at the first sight) as proper comments, pretty nice English, capital letters, periods. I might accidentaly delete some actual comments while cleaning so keep that in mind when posting here. And if the situation gets even worse I'll probably disallow anonymous comments completly... though that's the last resort.
EDIT: Okay, a small explanation on what this does.
I started this project long time ago but lost interest after hitting some walls. Recently I had a few good ideas and decided to work on it a bit.
What you see on the photo is Dreamcast with it's cover off and the GD drive assembly removed. I cut some holes and soldered wires directly to the mainboard to avoid messing with the original connector. This way I can always plug the drive back in and use it as before - or even better, I can use FPGA as logic analyzer to watch the traffic.
In this configuration there is no real drive and FPGA runs a soft-core CPU that emulates it. Obviously there's some glue logic in there as well or I wouldn't need an FPGA in the first place :) Data is being pulled from SD card - you can see it inserted just over the flat cables. With this I can run any dumped game, and unlike CD rips I actually emulate a GD media so the Dreamcast can't tell the difference. The USB is used to program the FPGA and I can't disconnect it because I don't have a license for that NIOS2 soft-CPU core, it will stop working after the PC uplink is lost. Other than that I can't use it for data transfers unfortunately.
The idea is to have a much smaller (and cheaper) FPGA here with fast external MCU. Data would be stored on SD media or pulled via USB 2.0 uplink to PC.
So far I've tested a couple of games for EU region, and a few JP ones after I hacked them to be multi-region :) I do have Japanese Dreamcast mainboard (well, two actually) but this is the only one I have modified for the project. Once this goes out of prototype phase I'd like to find a matching connector and just make it a plug-in replacement for the GD drive.
So... Skies of Arcadia works, at least EU version. Hacked US one shows no picture but I can hear it running. It works on Makaron but I'm starting to wonder if there is a problem with this particular dump... Anyway, the GDEMU is good enough to not freeze the intro sequence like the ripped version does. There is about 3 seconds of video/audio desync at the end of the intro due to the transfer speed being a bit too low. Same things happens in Dead or Alive 2 intro, which is also pretty long. But other than that it seems to work. Street Fighter Alpha 3 has some sound issues in the attract mode but not during actual fights. This is all after a few improvements I made today, I still need to run SPI link closer to 25MHz to get better transfers from SD card. Buf for many games, like Soul Reaver 2 this is already enough to play without any problems. MPEG movies work OK as well.
And they said imitation diamond wasn't good enough :)
http://pics.livejournal.com/dknute/pic/000xekdf/s320x240 (http://pics.livejournal.com/dknute/pic/000xekdf/g50)
So, does it work? Sure. It's a very early version though. I've hit some metastability problems so I switched from external ARM7 MCU to NIOS2 running on FPGA to speed up debugging. After I reversed my main clock polarity (yeah, Star Trek style) and it worked better I finally realised that I'm running a synchronous system with asynchronous inputs. Which is basically the same as having two different clock domains since I have no control over setup/hold times... So I've added two-stage synchronizers to /DIOR and /DIOW but that's additional latency and Dreamcast has a bad habit of deasserting /CS signals shortly after rising /DIOx. These things always work so well on paper :)
In the end the hardware side of GD interface is pretty small, should fit in EP2C5 (that's Cyclone II FPGA with 5k logic elements) and that's pretty cheap. The downside is I only have so much internal RAM so the main data buffer is just 8kB. While external SRAM could help here, I'm not yet sure it's worth the trouble. We'll see.
Digital audio is completly not supported yet (but is part of the design, so it will be added eventually) and I just wanted to test it out ASAP so I went with slow, PIO-only SD card access and very inefficient CPU buffering. Also, external MCU needs to be connected to FPGA with some sort of data bus and this becomes a bottleneck for the transfers, as it turns out. For example my ARM7 doesn't have a dedicated external memory interface so I have to do everything myself using a PIO port. With only 30 pins (minus a few for SPI and clock output) all I could manage was 8-bit shared address/data bus. Not very fast, unfortunately.
Because of the slow transfers games exhibit various issues, like missing textures, slowdowns, stuttering sound. This will get better as the project matures. In fact, with proper buffering I'm sure I can get it working as well as original GD drive and perhaps even faster - up to some 2x, which is the limit of what one can do with SD cards in SPI mode. Well, there's always the USB route I suppose.
By the way - I get simply tons of spam in the comments now. I've enabled LJ CAPTCHA but that only cut it in half or so. Worst of all, the spam looks (at the first sight) as proper comments, pretty nice English, capital letters, periods. I might accidentaly delete some actual comments while cleaning so keep that in mind when posting here. And if the situation gets even worse I'll probably disallow anonymous comments completly... though that's the last resort.
EDIT: Okay, a small explanation on what this does.
I started this project long time ago but lost interest after hitting some walls. Recently I had a few good ideas and decided to work on it a bit.
What you see on the photo is Dreamcast with it's cover off and the GD drive assembly removed. I cut some holes and soldered wires directly to the mainboard to avoid messing with the original connector. This way I can always plug the drive back in and use it as before - or even better, I can use FPGA as logic analyzer to watch the traffic.
In this configuration there is no real drive and FPGA runs a soft-core CPU that emulates it. Obviously there's some glue logic in there as well or I wouldn't need an FPGA in the first place :) Data is being pulled from SD card - you can see it inserted just over the flat cables. With this I can run any dumped game, and unlike CD rips I actually emulate a GD media so the Dreamcast can't tell the difference. The USB is used to program the FPGA and I can't disconnect it because I don't have a license for that NIOS2 soft-CPU core, it will stop working after the PC uplink is lost. Other than that I can't use it for data transfers unfortunately.
The idea is to have a much smaller (and cheaper) FPGA here with fast external MCU. Data would be stored on SD media or pulled via USB 2.0 uplink to PC.
So far I've tested a couple of games for EU region, and a few JP ones after I hacked them to be multi-region :) I do have Japanese Dreamcast mainboard (well, two actually) but this is the only one I have modified for the project. Once this goes out of prototype phase I'd like to find a matching connector and just make it a plug-in replacement for the GD drive.
So... Skies of Arcadia works, at least EU version. Hacked US one shows no picture but I can hear it running. It works on Makaron but I'm starting to wonder if there is a problem with this particular dump... Anyway, the GDEMU is good enough to not freeze the intro sequence like the ripped version does. There is about 3 seconds of video/audio desync at the end of the intro due to the transfer speed being a bit too low. Same things happens in Dead or Alive 2 intro, which is also pretty long. But other than that it seems to work. Street Fighter Alpha 3 has some sound issues in the attract mode but not during actual fights. This is all after a few improvements I made today, I still need to run SPI link closer to 25MHz to get better transfers from SD card. Buf for many games, like Soul Reaver 2 this is already enough to play without any problems. MPEG movies work OK as well.