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.
3rd-Sep-2012 08:53 am (UTC) - How to control the board?
One word: awesome!

I just have basic groundings in electronic and this is why I tried to do a 100% software solution to boot game over the network. Things got awkward when I tried to play with DMA and I still don't have a solution for CDDA. I think your solution is just the best we can get. I've a question though: won't it be possible that your board embeds a serial if bound to the console serial if so a software running on the DC would enable US to select a game without playing with buttons on the board?
With my GDLan loader project, I've exploring the way the user can select a game with a nice interface. It results in the following impl:
- grab the soft-reset call (generated by the user when pressing A+B+X+Y+START on the game's title screen)
- make a custom syscall that the server interprets as a call to launch a menu
- mount locally (on the pc side) the Dreamone demo and keep in mind the LBA of the game list file
- boot the dreamone menu
- once the server gets the syscall for reading game list file, returns a custom list, built on the fly from the list of available GDI files in the library folder

You got my idea? I was capable of doing this but since the dc-pc connection relies on the broadband adapter, I have some issues with games that use the network stack... If you're interested in my idea, feel free to contact me.

Anyway, can't wait to play with your board!
3rd-Sep-2012 11:56 am (UTC) - Re: How to control the board?
DMA transfers need to be either completly by-passed on DC using software patches or must be handled by dedicated hardware to meet the timing requirements. And, as you noticed, there is no work-around for CDDA as it's a completly independent digital stream.

As for the idea, I guess I will need to make a post about it to make it clear to all. The point of this little project was to create a near-perfect GD-ROM replacement, but one not based on mechanical/optical media. It's meant to be such a close match that Dreamcast would never be able to tell the difference, hence the game compatibility would be 100%. That's my goal here.

Obviously it'd be rather wasteful to have just one game per card (as the cards are getting bigger and cheaper) so there is going to be some very rudimentary user interface based on a few buttons and LEDs. However, this is the extent of what I'm willing to add. There is nothing stopping anyone from writing a native DC app that would be booted as the first thing from the card to provide some sort of game list/menu. If anyone does that, and it's good enough, I'd be willing to add some talkback support so that this device could actually do what the user selected in the menu. But that's in future and not even confirmed.

What can I say, I like simple solutions. First: make it work as intended. Second: add features. Obviously some features must be taken into account when the design is being made but we are talking about a system with programmable MCU and FPGA, I'd say there is some room for improvement if the need arises.
This page was loaded Feb 26th 2017, 10:10 am GMT.