?

Log in

Deunan
Genesis 
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.

EDIT:

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.
Comments 
20th-Oct-2012 10:37 pm (UTC)
I may be forced to impose a limit in order to keep the code simple. We'll see. So far I've tested it on 8GB SDHC without problems. I don't have any bigger cards at the moment :)
As for the BIOS, it stays as-is. The whole idea was to just swap the drive for a 100% compatible replacement and not have to worry about anything else. It's also why there won't be any fancy GUI - because the BIOS stays unmodified.

There's a way to convert GDI or CDI into new format and it takes just a minute or even less. You only need to do it when you put the image on the card (though I suppose Makaron will support that format as well), so it's not a big deal. I really with people would understand that it's not a PC, there are no gigabytes of RAM for file caching, and even keeping track of multiple open files is slowing things down.
21st-Oct-2012 09:47 am (UTC)
Do you think it can work on Naomi Arcade board ? (with a dimm bord , just in replacement of the GDROM drive) ?
21st-Oct-2012 09:58 am (UTC)
It should. In fact NAOMI makes little use of the GD drive, it's only used at boot and only to read data from track 3. I haven't actually tested on my box but I'm pretty sure there won't be problems.
The only thing it might need is some cable hacking to connect it properly to the DIMM, so that the original interface PCB and plastic assembly would not be required.
21st-Oct-2012 10:04 am (UTC)
that's a good news, i'm actually trying to see to found a way to have multiple Games on 1 compact flash (with the compact flash mod)
The best way would be to load first a menu, and then load the selected game (loading all the card will be too long and the dimm will certainly going out of memory (sorry for my bad english)
21st-Oct-2012 10:14 pm (UTC)
Now that might be a bit tricky. You see, NAOMI does not control the DIMM, it has it's own firmware and does all the loading on it's own as the first thing when the power comes on. So, in order to have any sort of menu you'd need a way to tell DIMM to load a different image. That means custom firmware and I'm not planning on doing that.
22nd-Oct-2012 08:43 pm (UTC)
oh ok i see, so the only way ll be to add more ram to the netdimmboard.
And then to load the entire CF content (+ menu)?
Well let's get back to your project who is awesome and keep up the good work ;)
22nd-Oct-2012 11:41 pm (UTC)
That could work... I'm not sure if DIMM can be extended beyond 512MB though and that is enough for just two games. Could be more with smaller games but as a rule that would be a very limited choice even if we used some sort of initial data compression.
The NAOMI was never designed to operate with many games at once, which is rather obvious considering that SEGA wanted to prevent bootleg software from being used. So the purpose of any cart or DIMM is just to boot one game from original media and that's it.
23rd-Oct-2012 07:56 am (UTC)
So the only way will be to have a modified bios that comes with a menu in to select the game to load (001.bin, 002.bin, etc)
BTW at 5$ the 2Gb CF card ... have one card for one game is not that hard ;)
23rd-Oct-2012 09:27 pm (UTC)
You can't modify BIOS on NAOMI. Well, you can, but it won't work properly :)
The idea you proposed now would require a custom BIOS and a custom DIMM firmware. Way too much work, even if it could be done.
25th-Oct-2012 02:16 am (UTC) - It'll be great if you can support SDHC up to 32 GB.
Anonymous

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).

This page was loaded Feb 26th 2017, 10:09 am GMT.