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.
24th-Oct-2012 11:01 am (UTC) - Re: Congratulations :)
Connecting Maple to PC (via USB or otherwise) it also something I was looking into. I've seen some AVR-based projects that can work with DC gamepads but only because there is little data being exchanged there. Maple is being handled by tight software loop and it kinda works but just barely.

I wanted to make better interface that could be used along with my emulator and also support VMU and PPP. Problem is, I don't really see how it could be done without some additional logic on the Maple side to handle the state changes on data lines. FPGA would be an overkill, and discrete logic is probably too complicated. So, a small PLD chip would be best, it would include a simple shift-register for that purpose. But I never really made any attempts to test this theory in practice :)
25th-Oct-2012 02:14 am (UTC) - Re: Congratulations :)

Hi Deunan,

Congratulations on the progress you've made ! Many people around the world are excited. I'm writing from Australia.

There is no doubt this'll sell like hot-cakes, and will easily generate the sales volume required for mass-production. Think about it ... those Dreamcast SD card readers (via the serial port) are in high enough demand themselves, that they're being mass-produced. How much MORE SO then, shall the demand be for your superior interface, which plays games authentically at "full speed" via the GD-ROM interface, as opposed to the competing products available today (which use the slow serial port, causing game slowdown).

Heck, I've never owned a Dreamcast before in my life, but have just purchased one off E-bay after learning of your invention. I wasn't going to purchase a console with a flaky and unreliable 13 year old optical drive, unless I knew there was a robust HDD or SD card replacement on the horizon that'll play games authentically at full speed. And soon we'll be able to purchase it !

I'm middle aged with kids, and am into old retro gaming consoles as a hobby (with the original console hardware ... I don't like PC emulators, as they don't have the nostalgia or the gameplay accuracy of the original console).

It'll be great if you can support SDHC up to 32 GB, as these cards are now commonly available and affordable. The Wii supports SDHC up to 32 GB, as with most of today's electronic devices (cameras, etc).

Cheers, and keep up the good work !


26th-Oct-2012 07:17 am (UTC) - Re: Congratulations :)
Your theory is right, on my prototype I use two shift registers one for each SDCK channel because reading byte by byte gives more time than reading bit by bit, in that way I can read and write to the bus easy, to read the resulting byte and sending to PC I use a 18F4550 at 12 MIPS.

By the way that maplebus work, write to bus can be made at any speed the slowest speed that I can remember was 900 Hz I made that test because Marcus comsted ask me for it, that was long time ago, good memories :D.

Edited at 2012-10-26 07:18 am (UTC)
26th-Oct-2012 09:26 am (UTC) - Re: Congratulations :)
Lately I've been doing a lot of projects based on ARM chips. Now that I think of it, a 24MIPS ARM7TDMI may be fast enough to do everything in software. It has 64kB of internal RAM so I can easily store long Maple packets to/from VMU (which are 128 bytes long, so a bit storage would be 8x more). I'd probably have to code the receiving loop in assembly but it sure is cheaper than to add a PLD.

Thanks for reminding me of this, I will do some more thinking now :)
This page was loaded Feb 26th 2017, 10:10 am GMT.