(WIP) Makaron WIP - 模擬器
By Isla
at 2011-08-10T12:42
at 2011-08-10T12:42
Table of Contents
2011.08.07
And they said imitation diamond wasn't good enough :)
http://pics.livejournal.com/dknute/pic/000xekdf/s320x240
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 (wel l, 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. Tags:dreamcast, gd-rom, gdemuMusic:Empyrium
- Weiland
______________________________________________________________________________
來源:http://dknute.livejournal.com/39276.html
--
And they said imitation diamond wasn't good enough :)
http://pics.livejournal.com/dknute/pic/000xekdf/s320x240
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 (wel l, 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. Tags:dreamcast, gd-rom, gdemuMusic:Empyrium
- Weiland
______________________________________________________________________________
來源:http://dknute.livejournal.com/39276.html
--
Tags:
模擬器
All Comments
Related Posts
puNES v0.28
By Ina
at 2011-08-09T23:53
at 2011-08-09T23:53
Free Heroes2 Engine SVN r2441
By Andrew
at 2011-08-09T23:50
at 2011-08-09T23:50
GameBoy Online (2011/08/08)
By Joe
at 2011-08-09T23:44
at 2011-08-09T23:44
QEMU v0.15.0
By Eartha
at 2011-08-09T23:42
at 2011-08-09T23:42
ArcadePC Loader v1.2
By Carolina Franco
at 2011-08-09T23:38
at 2011-08-09T23:38