#112198 - Juglak - Thu Dec 14, 2006 8:28 am
(My final post for the night I suppose. Feels like theres an echo in a large empty room with my consecutive posts..... lol)
Another project I'd like to poke around with would be something that works in the DS Slot 1.
Poking around with my scope, I see that the SPI Clock to the DS cartridge is far too fast for any cheap microcontroller to handle... even for the unencrypted commands, forget about processing the encryption.
So, few questions. Has anyone freelance/homebrew made anything functional for Slot 1? For functional, I mean, something that would show up as a game in normal DS firmware, or be able to response to commands from homebrew software through normal DS card 8-byte commands. I did see the UART interface made by I believe masscat.
Theres obviously commercial products such as the Superkey that do this. Gutting mine, I found that it uses a Lattice MachXO FPGA/CLPD and a 3.3v serial flash chip (tied to the FPGA, not the ds directly) to do the job fast enough.
At 3.3v, none of my AVR microcontrollers (yes, I like AVRs...) are fast enough, even using their SPI Slave interfaces, to talk to the DS. Especially considering the data bus is 8-bit, and not 1-bit like their SPI interfaces would handle. (Even at 5v, 20MIPs, they still wouldnt be able to do it)
So, I'm curious as to if anyone else has interfaced anything with Slot 1 on their own. Would be interesting to know.
I'm probably going to get a Lattice MachXO starter kit (bout $99) and hammer out some VHDL and see what I come up with. Those chips are only roughly $10-$12 in single quantities, so would be pretty cool to make a slot 1 SD card interface for like, $20. Could have the SD card accessed by the chip for loading NDS files by the DS BIOS like a normal game and such. I think theres a few overpriced commrecial products that do this.
I'd love to make a cheap homebrew version that the masses could build pretty easily. Might not look as pretty, but you never know.
For the record, I don't care about the pirating community. I'm not here to benefit you! Its not a goal of mine to copy commercial DS games to my slot 1 device. Granted, it sounds a lot like that. But, honestly, I own about 8 retail games. I like them, i play them, etc. For my other retail games I must play, I have GameFly. Clean, simple... legal.
Anyways... just some thoughts from my sleepy mind.
Hope I didn't bore anyone!
_________________
My goodies: 1xDS Lite - Supercard Lite, DSi, Supercard DSONEi
#112201 - Lick - Thu Dec 14, 2006 9:12 am
I'm taking the wildest guess, don't mind if it's stupid: DSerial?
_________________
http://licklick.wordpress.com
#112204 - Juglak - Thu Dec 14, 2006 9:50 am
Surprisingly, I've been on these forums a while now and I never noticed DSerial. Interesting. Seems to need a passme though.
Hopefully when I get this MachXO kit, I'll be able to make some interesting stuff. Well, I'll be happy with "Hello World" booted from my cart to start. hehe
_________________
My goodies: 1xDS Lite - Supercard Lite, DSi, Supercard DSONEi
#112210 - felix123 - Thu Dec 14, 2006 11:01 am
Some of the new slot 1 cards are only US$25 or so.
_________________
Nintendo DS homebrew on Wikipedia
#112216 - masscat - Thu Dec 14, 2006 1:50 pm
For my SPI UART bridge I used a Zilog Z8Encore (clocked at 20MHz) which is cheap, easy to program and fast enough for the SPI interface. According to the specs over on nocash the data clock can be 4.2MHz or 6.7MHz, so I think the Z8 would not be much good but may be usable for some experimenting. If you can find an old Passme1 or 2 with a programmable device on it then that could be a cheap way to start playing around and experimenting.
I am interested in doing something similar (build a slot 1 device) so please post any findings and experiences.
#112262 - Juglak - Thu Dec 14, 2006 10:53 pm
I havent gone completely indepth on it yet, but I did notice on my scope that the pulses on the SCK line are EXTREMELY short... roughly 10-25ns. Makes it really difficult for anything, even at 20MIPS (50ns/instruction) to acurately catch all the SCK line pulses.
I'm not 100% sure on this one either, but it seems to be the same for pulses on other lines. They're all just too short to be consistantly picked up by anything running at even a couple dozen MIPS.
I was thinking about hacking up my Superkey's MachXO FPGA chip, if I can find specs for and make a cable to program it from Lattice's ispLEVER software. Since I already run custom firmware (at least FlashMe, but for mine, one of the reasons for making the download play host/client) on my DS's, I dont use it anymore anyway. If anyone has any info on that, it would be appreciated. Their tech guys wouldnt give me the specs on their programming cable. lol.
Cheers.
_________________
My goodies: 1xDS Lite - Supercard Lite, DSi, Supercard DSONEi
#112269 - josath - Thu Dec 14, 2006 11:04 pm
The clock rate of SPI can be configured in software on the DS side:
0-1 SPI Baudrate (0=4MHz/Default, 1=2MHz, 2=1MHz, 3=512KHz)
If you are just watching commercial games only, perhaps they use the fastest speed. But if you are going to write your own code, you can use a slower speed. But perhaps you need to match the fastest speed, if you wish to imitate a "nopass" device.
Right now, commercial "nopass" devices (things that imitate a DS game to the DS firmware) cost $20-$30. I highly doubt you could make something that performs the same function, and more (SD card interface) for equal or less cost. Of course, this shouldn't discourage you from trying, it might be nice to have something made by homebrewers instead of some chinese pirate company.
#112278 - Juglak - Thu Dec 14, 2006 11:30 pm
Well, I figure, if I can get a "no pass"ish device working on my own, I can easily (well, probably not easy, but possible) add a process to the FPGA for interfacing with an SD card. I've already interfaced SD cards with my AVR microcontrollers with a couple dozen lines of ASM pretty easily. (1-bit mode only, so far though)
The SPI speeds you posted are for the other SPI devices (Firmware, touchscreen, etc). The SPI bauds for the DS Slot 1 can only be approx 4MHz and 6MHz.
The header is booted at 4MHz, and the speed of the rest is determined by some bits in the header, still either 4 or 6MHz. (Ref: no$gba specs, and some scope poking)
So, way too fast for any microcontroller i have laying around... :(
_________________
My goodies: 1xDS Lite - Supercard Lite, DSi, Supercard DSONEi
#112300 - masscat - Fri Dec 15, 2006 1:38 am
To clear up a bit of confusion about clock signals seen on slot 1 and what uses what.
The clock is on pin 2.
The same pin is used for both the SPI clock and the Data Transfer clock.
The SPI clock can be configured for 4MHz, 2MHz, 1MHz, or 512KHz.
The Data Transfer clock can be configured to be 4.2MHz or 6.7MHz.
What drives the slot (SPI or Data) is determined by the setting of the register at 40001A0h.
SPI is used to talk to the saved game memory of the cart.
The Data Transfer bus is used to talk to the ROM of the cart (game code and data).
One way to put your slow microcontrollers to use would be to build a cart reader. Assuming the cart would not mind being clocked a lot slower, you would be able to get a good understanding of the DS <-> cart protocol from the DS side of things. Should be easy to switch the knowledge round to the other side when you come to build your cart.
#112302 - Juglak - Fri Dec 15, 2006 1:51 am
So, hrm. Maybe I messed up somewhere.
When exactly would the SPI clock (512khz possible one) come into play in the DS Slot 1? Just EEPROM? I've been playing with it for a day or so now and I havent seen anything below about 4MHz coming out of the DS card clock pin, even when fiddling with those settings. Perhaps I messed up somewhere, though.
As for a master side card interface, was actually already working on that as I saw your post. I'll let you know how that goes. Going to try and implement all the encryption and such on a 16KB flash AVR and see how that goes. Not that its the most useful project (can read the card easily while in the DS with the DS) but, as you said, a good way to fiddle and learn.
-J
Edit: Oh, a reason I'm asking is... isnt the SPI interface only working on the ARM7? As far as I know, the slot 1 EEPROM can be accessed from the ARM9...
Edit Again: Blah, I must be tired. Of course you are right. :P
AUXSPI interface..... *slaps forehead*
Well dang, I could easily make SOMETHING to interface to it then. Not a NoPass type deal, but i could move my NES controller slot2 interface to slot1... lol.
_________________
My goodies: 1xDS Lite - Supercard Lite, DSi, Supercard DSONEi
#112339 - masscat - Fri Dec 15, 2006 11:20 am
My SPI UART bridge gives an example of the software, DS side, to interface the slot 1 SPI bus. I configured the SPI clock to 512kHz (as I remember) to stop the ucontroller from being overwhelmed.
I separated the SPI interface code from the bridging code so feel free to use it if it is helpful.
Who has access to slot one, ARM7 or ARM9, is controlled by the WAIT_CR register (0x04000204).
#112572 - Juglak - Sun Dec 17, 2006 11:48 pm
Well, on the DS Card Host front, I've made some progress. Honestly haven't had masses of time to work on it the past few days, but, I have, as of now, been able to load the nds header of The Sims 2 to my microcontroller.
The DS Card doesnt seem to mind the super slow clock rate at all.
I was going to implement the encryption stuff directly on my microcontroller, until I realized it would take a minimum of about 4.5KB of ram, and my MC only has 1KB.
Looking back at emulating the DS card itself, the RAM for encryption wouldnt be a problem, since the gamecode would be static and the encryption tables could just be stored in flash/rom.
But for the host, the gamecode is based on the DS Card you are loading, so, the key table needs to be initialized, meaning storing the key table in flash (about 4.5KB), and then loading the initialized version into RAM.
I presently dont have any 3.3v external SRAMs, otherwise I would just employ one of those with my AVR to do it all on-chip. I have a few 5v ones, but, it don't want to risk blowing up a retail DS game, and I don't feel like making level shifting circuitry.
Now for my gameplan...
The easier solution will be to just use the AVR as an interface, and use the RS232 connection to the PC to just use software on the PC to send/receive commands to/from the DS card through the AVR.
Then I can just implement the host encryption stuff on the PC, which will be much easier, hopefully.
Once thats done, I plan on making a DS card emulator in software on the PC, and making it so my host code can "talk" to my slave code. Nothing physical in that implementation, but, just to get the stuff working and acurate before moving onto making a physical slot 1 card.
Then, using probably VHDL, I will attempt to code a true DS Card emulator into an FPGA device. Probably using an external flash chip for storing the game code and the encryption tables (since storing 4.5KB in FPGA cells would be pretty wasteful).
Finally, assuming all of the above went well, make an SD/MMC card interface into a process on the FPGA. Which, in conjuction with the card's "boot code" could work on the DS in a fashion similar to all of the retail devices which let you use SD cards in the DS.
I guestimate that the final protoype will cost (not counting PCB fabrication or a plastic case) about $14 USD.
If it were actually mass produced (which I personally dont plan on doing, but someone else probably will when this is all public knowledge), probably about $15-$18 for the entire package (chips, PCB, casing, etc), if made in high enough quantity.
So, I guess after saying all that, I still find it to be a worthwhile project.
A main reason for this is that none of the current hardware you can purchase to use SD's is open source (that I am aware of). So, this would make it possible to make nice skinned interfaces and other stuff people always want in those devices, amongst other things.
Timeframe for all this (I hope): About 2-3 weeks.
Cheers.
_________________
My goodies: 1xDS Lite - Supercard Lite, DSi, Supercard DSONEi
#116309 - Juglak - Wed Jan 24, 2007 9:05 am
Bringing back this topic...
I got ahold of the Lattic MachXO 640 and a dev board and such so I could fiddle with it.
As a test of my newly forming VHDL skills, I was easliy able to make a Slot 2 device using it. It basicly just had the header, and a few lines of ASM to switch to GBA mode to tell me it was working (when booted with flashme).
But, on to Slot 1... and trouble.
I got a working CMD input working, but, having some issues implementing KEY1/KEY2 encryption in VHDL... not an easy task.
Honestly, havent done much with KEY2 yet, since its not needed until KEY1 commands can be decoded.. but KEY2 seems like it will be a lot easier than KEY1.
I have a parallel flash chip hooked to the FPGA containing a small NDS file at 0x10000, and at 0x0 it has the key1 table from the arm7 bios, already initialized with the cardid for the NDS file...
Would be great if the KEY1 table would fit somewhere directly on the FPGA (as a ROM), but, the MachXO640 just isnt big enough for all that.
With my slow AVR based card dumper, my FPGA Slot 1 device successfully responds to the few unencrypted commands (get header, the dummy 9c command, get chip id).
But the header is pretty simple... just read a flash byte, output a byte on DS IO lines before the DSCLK toggles.
The KEY1 encryption, however... will take a lot. First, have to be able to read tons of bytes from the flash chip to do the decryption at all... all within the 0x910 dummy clocks the DS allows (can be changed, but... 0x910 SHOULD be fine).
There should be pleanty of time to do it, but, my VHDL skills just arent good enough for this I suppose... :(
I tried to tackle this by making a process in my vhdl that basicly acted as a KEY1 decoder.
| Code: |
signal KEY1_IN, KEY1_OUT: std_logic_vector(63 downto 0);
signal KEY1_BUSY: std_logic;
*snip*
KEY1DECODER: process
--*variables*
begin
--void crypt_64bit_down(unsigned int *dst) {
-- int i;
-- unsigned int X,Y,Z;
-- Y = dst[0];
-- X = dst[1];
-- for(i=17;i>=2;i--) {
-- Z = key[i] ^ X;
-- X = key[18+((Z>>24)&0xFF)];
-- X = key[274+((Z>>16)&0xFF)] + X;
-- X = key[530+((Z>>8)&0xFF)] ^ X;
-- X = key[786+(Z&0xFF)] + X;
-- X = Y ^ X;
-- Y = Z;
-- }
-- dst[0] = X ^ key[1];
-- dst[1] = Y ^ key[0];
--}
--*insert some VHDL code that does the same as this C routine,...*
end process;
|
Then if that actually worked, the CMD processor would have to just wait for all the dummy bytes to come in, and by the time they did, the decoded CMD would be ready to be processed. And presto... or so I thought.
My touble is getting a working state machine to be able to read the flash bytes when needed, continue the decryption, read more bytes, etc...
A main problem being that the flash chip has a delay of 100ns... so I have to take that into account for each byte. So a read from key[whatever] (pseudo code) would be 4 bytes, so 400ns + overhead... etc etc etc.
I tried just doing this in sequence with a non-combinational vhdl process... using a lot of wait until rising_edge(CLK)'s... but didnt have much luck with the decryption... even though it seemed to be reading the bytes right and all.
If anyone has any ideas on how to implement the KEY1 decryption of CMDs in VHDL, that'd be awesome.
Well, back to work I suppose!
-J
_________________
My goodies: 1xDS Lite - Supercard Lite, DSi, Supercard DSONEi
#116610 - GrizzlyAdams - Sat Jan 27, 2007 9:37 am
Just to tag this on to the growing list of other homebrew slot1 SPI hardware, I have also made a SPI <-> RS232 adapter.
I used a PIC16F877a clocked at 4MHz (1MIPS). As long as only one byte is sent each transfer it can keep up with a 4KB/s stream no problem.
I'm using the hblank irq (triggering SPI every 8th line currently) and a ring buffer on each side of the spi bus to keep things happy. 32 byte RS232 > SPI and 64 byte SPI -> RS232 ring buffers implemented in the PIC, and 1KB ring buffers on the DS for each way.
As long as you have a hardware driven spi port you should be ok for talking single byte transfers to the DS.
You can do useful things even at such a low speed, and I plan to get a new ceramic osc to run my pic way faster and 100% within rs232 clocks (0.16% BER at 19.2K right now) 18.432 MHz should let me get above 115.2K