Hacking SuperCard DSTwo SDK v1.2 released!

[Costello]

I dont know if asiekiera has anything to do with it, because for all I know romman (Supercard team) accepted to release the stuff after a continued email discussion with me
no offense though. And thanks to Jakob95 for making me do this.

 

[s4mid4re]

I dont know if asiekiera has anything to do with it, because for all I know romman (Supercard team) accepted to release the stuff after a continued email discussion with me
no offense though. And thanks to Jakob95 for making me do this.

We appreciate your work. Thanks.

*likes Costy's post*

 

[Mbmax]

I dont know if asiekiera has anything to do with it, because for all I know romman (Supercard team) accepted to release the stuff after a continued email discussion with me
no offense though. And thanks to Jakob95 for making me do this.

I don't count the number of time i asked romman for the iSmartMM SDK without luck. Could you give a try please ?

 

[Buleste]

I dont know if asiekiera has anything to do with it, because for all I know romman (Supercard team) accepted to release the stuff after a continued email discussion with me
no offense though. And thanks to Jakob95 for making me do this.

I don't count the number of time i asked romman for the iSmartMM SDK without luck. Could you give a try please ?

I second that emotion.

 

[Pate]

Has anyone managed to get the DS side (mp4play_test_16_souok_min30) compiled yet? I have been hunting for the proper devkitpro revision (using the svn repository) to get it to compile, and with my latest attempt using svn revision 1950 (from around July-August 2007) I managed to get the ARM7 side to compile (with a lot of warnings), but linking fails with the following problem:

linking mp4play_test_16_souok_min30.arm7.elf
c:/devkitpro/devkitarm/bin/../lib/gcc/arm-eabi/4.6.1/../../../../arm-eabi/bin/ld.exe: cannot find ds_arm7_mp4_crt0.o: No such file or directory
collect2: ld returned 1 exit status

I don't know how to create the ds_arm7_mp4_crt0.s. There are similar files in the \buildscripts\dkarm-eabi\crtls directory of devkitpro (again from revision 1950), but nothing with mp4 in their name.

I suspect I might be using too new devKitARM tools, as I have been trying to cut some corners and only use the old version of libnds with the latest versions of everything else (which may turn out to be a bad idea), but that mp4 in the name makes me suspect that this might be something specific to DSTwo.

Has anyone gotten further?

Pate

Ps. I have found out that devkitpro r1899 is too old, and r2599 is too new for this project, but I haven't narrowed down the correct revision further than that.

 

[Mbmax]

The change log of this project is soooooo huuuuuuge.
i can imagine it's not easy to find the proper devkitARM r17 inside that ...

Edit : Seems that the r17 appeared at the changeset 1132 according to this trac : http://sourceforge.n.../changeset/1132

http://devkitpro.svn.sourceforge.net/viewvc/devkitpro/?view=tar&pathrev=1132

 

[Luigi2012SM64DS]

hope what people have been waiting for was worth it

 

[Normmatt]

Has anyone managed to get the DS side (mp4play_test_16_souok_min30) compiled yet? I have been hunting for the proper devkitpro revision (using the svn repository) to get it to compile, and with my latest attempt using svn revision 1950 (from around July-August 2007) I managed to get the ARM7 side to compile (with a lot of warnings), but linking fails with the following problem:

linking mp4play_test_16_souok_min30.arm7.elf
c:/devkitpro/devkitarm/bin/../lib/gcc/arm-eabi/4.6.1/../../../../arm-eabi/bin/ld.exe: cannot find ds_arm7_mp4_crt0.o: No such file or directory
collect2: ld returned 1 exit status

I don't know how to create the ds_arm7_mp4_crt0.s. There are similar files in the \buildscripts\dkarm-eabi\crtls directory of devkitpro (again from revision 1950), but nothing with mp4 in their name.

I suspect I might be using too new devKitARM tools, as I have been trying to cut some corners and only use the old version of libnds with the latest versions of everything else (which may turn out to be a bad idea), but that mp4 in the name makes me suspect that this might be something specific to DSTwo.

Has anyone gotten further?

Pate

Ps. I have found out that devkitpro r1899 is too old, and r2599 is too new for this project, but I haven't narrowed down the correct revision further than that.

I managed to get it to compile using some old devkitarm and libnds. I can package it all up if you want it.

EDIT: however it doesnt seem to encrypt the file so i can't test it out.

 

[Pate]

I managed to get it to compile using some old devkitarm and libnds. I can package it all up if you want it.

EDIT: however it doesnt seem to encrypt the file so i can't test it out.

Yes please! Hopefully we can figure out the encrypt part as well.

Pate

 

[Mbmax]

I managed to get it to compile using some old devkitarm and libnds. I can package it all up if you want it.

EDIT: however it doesnt seem to encrypt the file so i can't test it out.

Yes please! Hopefully we can figure out the encrypt part as well.

Pate

Isn't that already done ? http://gbatemp.net/topic/304420-dstwo-tool-for-windows/

 

[spinal_cord]

Why would they use such an old kit? That probably rules out a DSi compatible version

 

[Buleste]

Why would they use such an old kit? That probably rules out a DSi compatible version

They never like to make things easy for developers?

 

[Pate]

I managed to get it to compile using some old devkitarm and libnds. I can package it all up if you want it.

EDIT: however it doesnt seem to encrypt the file so i can't test it out.

Thanks again for that! It does indeed compile, and the resulting nds file seems to contain pretty much (though not quite) the same data as the original ds2_firmware.dat. I quickly compared the files with a hex editor, to see if the result is at all similar to ds2_firmware.dat.

I tested creating DS2x86.plg using that new .nds file created by your DevKitPro version, but it does not quite work. Both screens show random data and there is a constant screeching sound. It somehow seems like the MIPS side is running and sending data to the NDS side properly, as the top screen contents change at the same speed as the cursor should blink in DS2x86, but there is still some issue with the compilation.

Anyways, we are almost there! I would very much like to start converting the NDS side to use the latest DevKitPro, but it would be good to get it to work properly with the original sources first.

Pate

 

[Mbmax]

Pate, be very careful when you play with the plg compilation. I bricked my dstwo when i tried the ismart linux plugin encrypted with the ds2 firmware.

Maybe you know what you are doing, but be aware that there is no proper unbricker released by sc team.

Good luck.

 

[jimmyemunoz]

I've been following this thread and will continue to do so because I have faith in the developers in this community. Good luck guys and I hope you keep us posted with your progress and set backs, should there be any more. A+++

 

[Pate]

@mbmax: I have no idea what I am doing, so thanks for the warning.

It annoyed me quite a bit that even in the old DevKitARM version that Normmatt provided me, the ds_arm7_mp4_crt0.o still only existed in object format with no source. So, I decided to reverse-engineer it to see what is the difference between that and the normal ds_arm7_crt0.s. This is my best guess as to what the difference is:

First, the original code has this:

mov r0, #0x1F @ Switch to System Mode
msr cpsr, r0
ldr sp, =__sp_usr @ Set user stack

ldr r0, =__bss_start @ Clear BSS section to 0x00
ldr r1, =__bss_end
sub r1, r1, r0
bl ClearMem

In the mp4 -version, between those two code snippets is a new code that does some copying of the whole arm7 code area. I have no idea why, I just posted it here in case anyone is interested.

mov r0, #0x1F @ Switch to System Mode
msr cpsr, r0
ldr sp, =__sp_usr @ Set user stack

ldr r2, =__iwram_start @ mp4 stuff (__iwram_start = 0x37f8000)
ldr r1, =0x027ffe34 @ mp4 stuff
ldr r1, [r1] @ mp4 stuff
cmp r2, r1 @ mp4 stuff
ldrne r4, =__bss_end @ mp4 stuff
blne CopyMemCheck @ mp4 stuff

ldr r0, =__bss_start @ Clear BSS section to 0x00
ldr r1, =__bss_end
sub r1, r1, r0
bl ClearMem

I am just doing some preliminary work in trying to learn what I would need to do if/when I attempt to convert the NDS side to work with the latest DevKitPro.

I hope I am not the only one working on the new SDK, I would like to hear about your findings as well!

Pate

 

[Pate]

Okay, some progress. It turned out that the problem with the corrupt screen and screeching audio was caused by my using DSTwo SDK version 0.13 on the MIPS side, and the new SDK 1.2 version only on the NDS side. Those two do not have a compatible I/O layer.

I switched to SDK 1.2 on both sides, and the NDS-side (compiled with the old DevKitPro) seems to almost work. DS2x86 boots up fine, and I can run some DOS programs, but every time there is disk activity the lower screen flashes strangely, until the system hangs. This does not happen with the original ds2_firmware.dat that is included in the 1.2 version package, so it seems that the compilation of the NDS side still does not go quite correct.

Strange that the SDK version 1.2 seems not to contain the changes they added to version 0.13. I had to change the DS2x86 code to work like in SDK 0.11 to get it to work with SDK 1.2!

Pate

 

[DiscostewSM]

They already do have a good SNES emulator. BAGSFC and CATSFC are far better than Snemul but now maybe they can be improved even further.

Like moving the SPC700 emulation to the ARM7, since the SPC700 hardware unit can basically operate independently from the rest of the system.

 

[Auryn]

Sorry for the stupid question but i never used a SDK.
Does any part of this release allow to edit/modify commercial games graphics in NCGR, NCER, NSCR or NANR format???

 

[Mbmax]

Sorry for the stupid question but i never used a SDK.
Does any part of this release allow to edit/modify commercial games graphics in NCGR, NCER, NSCR or NANR format???

Not at all.
Maybe take a look at this tool : http://filetrip.net/file.php?id=23649

@pate : if you have any contact with romman or some coder at SC team please give them this link : http://forum.superca...=8384&pid=68351
I think they should really consider to make an unbricker so every coders/beta testers feel secure to mess with this last sdk.