Log in

30th-Aug-2012 02:44 pm
Let there be light:
2012-08-30 GD-EMU proto V2 #1

And there was light:
2012-08-30 GD-EMU proto V2 #2

More pictures to follow soon :)

Status so far:
Voltage regulators - check
MCU starts - check
Bootloader operational using 3V3 UART - check
MCU JTAG - check
C runtime stub + simple exception handling - check
Status LEDs - check
UART 115200 8N1 console - check
Interrupts - check (need to investigate if registers are really properly saved though)
External RAM - check (problem found, should be fixed now)
High speed SD interface - in progress

Random fun fact: Many SD/SDHC cards exhibit various little quirks in SPI mode so the code needs to be aware of those to work properly in every case. One would think the native SD protocol is so tightly standardized that there should be no such surprises. Well, I just found a bunch of 2GB Kingston SDs that respond to ACMD41 with bad CRC7...

EDIT: Turns out the R3 answer is the only one not protected by CRC7, that space is marked as reserved and just filled with all-ones. I'm still not getting the busy bit within reasonable times on these Kingstons but I suppose reading the docs few more times might teach me something new again.

Anyway, here's the actual thing:
2012-08-30 GD-EMU proto V2 #3

Now it's a proper prototype, with all these wires and blinking LEDs. A few things are still missing on the PCB but right now I need to get SD protocol working so I can fetch FPGA configuration image and test it.


High speed SD interface - check
DMA on SD i/f - check
Basic FAT support - check
FPGA - in progress

I'm using my own FAT library, which has no write support but it was designed to be fast while consuming as little RAM as possible. In fact current SD cards are so fast it makes sector buffering impractical, since the lookups and LRU queues kill any gains with additional overhead. I suppose it'd be different if the CPU was clocked above some 400MHz and had some fast L1 cache.
Right now I get average of ~10MB/s in test that seeks to random part of 1.2GB file and reads 1-3500 consecutive 2352-byte long chunks. This is to simulate RAW image reads for GD-ROM. So pretty well I'd say, a nice boost compared to 2.5MB/s I got over SPI.

The native SD interface required a pretty much complete rewrite of some code, so I'm not 100% sure it's stable and all, but seems to work for hours without problems so far.
2nd-Sep-2012 08:29 pm (UTC)
What? This is a GD-ROM drive emulator project. How is that even remotely connected to 4 player support? What game?
2nd-Sep-2012 10:53 pm (UTC)
I apologize I thought you had posted something about 1 or 2 controllers, perhaps I misread. So you have booted games? What games have you tried and do they work 100% or do they have issues? Thanks. Can't wait to purchase one of these.
3rd-Sep-2012 11:15 am (UTC)
All games will work, although prototype V1 did not have a proper CDDA support (I was too lazy to add it). This one should make it much easier anyway.
The only issue was the limited ~1MB/s transfer rate that I was getting, there were some games like SF3A that had problems loading the music for the demo screens between fights. This should also be solved now.
30th-Sep-2012 03:58 pm (UTC)
Can I run Gundam DX with this hardware in the future?
Is it feasible to support the 4 machines linkage? (Communication board emu?)

I would really love to donate to this project, even without any promise of deliverable, somehow "kickstart" your development if possible.
3rd-Oct-2012 02:18 pm (UTC)
It's meant for Dreamcast, not NAOMI. Although I suppose it will be good enough for both systems. You will still need NAOMI box and DIMM addon, DC hardware is not exactly the same thing.

In other words, it will not add any functionality beyond being GD-drive replacement. If the game had multiplayer support it will still have it. If it didn't... nothing more is going to happen.

As for possible donations, still thinking about that :)
This page was loaded Feb 26th 2017, 10:11 am GMT.