- Joined
- Jan 4, 2011
- Messages
- 15
- Trophies
- 0
- Age
- 47
- Location
- Denver, CO
- Website
- Visit site
- XP
- 163
- Country
I'm a coder that has done work on DSLinux in the past, and I am interested in porting a few things to SuperCard DSTWO.
I've downloaded and looked over the SDK but I'm finding alot of things lacking that would prevent a full port of the OSes i'd like to port:
Linux, of course (I'd probably call it DS2Linux), and AROS, which would probably be called DSAROS.
I have big questions and no place i've found to ask them. Is this an official board for the SuperCard DS2 SDK? Do the DSTWO creators track this board?
Here are my questions:
1) Do you have access to the ARM9/ARM7 while code is running on the DSTWO? Can code run on the ARM CPUs and the DSTWO CPU at the same time?
2) Can you see the whole memory map and IO map? Wifi is not in the SDK but COULD it be?
I am willing to add/rewrite the SDK if need be, to accomodate new features. Also the current SDK is not very 'forward looking'. If DSi mode is broken (And theres some recent news suggesting it has been) I'd like to have a way to install a launcher on the DSiWare menu to launch the SCDS2 in DSi mode. So we should be writing the SDK in a way that assumes that later, another SD card slot will become available (fat2:/) and that additional RAM and CPU speed on the ARM side will be available.
Something else i'd like to do (I wouldn't make requests I couldn't do myself) is, assuming we can run code on the ARM9/ARM7 while the MIPS CPU is running, is load code onto those CPUs that handle things like sound and video. In particular I see the possibility of running a software OpenGL renderer on the ARM9 CPU and a sound handler (I come from Amiga coding so I'm thinking of emulating the Amiga Paula chip, where MODs come from) and also offloading all input processing to the ARM7. For DSi devices (when we can make them accessible) i'd like to offload access to those devices to the ARM9 because we'd have them at 133mhz and there'd be extra speed for these other processes. We'd load them in as modules on the ARM CPUs.
I'm writing up a spec for all of this, but, I need alot of questions answered first about how much access the DSTWO has to the DS/DSi hardware, and I suppose its a question for people who know. If there's a more technical SDK forum I should be on please let me know. I had not tried to sign up for the trial because I have not released any specific DS homebrew, I only contributed to DSLinux and released ports of some linux things to it. I have a DSTWO, I don't actually need one either.
I come from a coding background of C64, Amiga, and x86, but I do know Assembly Language.
Also, I have some interest in coding a Dingoo emulator for porting Dingoo apps to DSTWO. If it is possible i'd emulate the Dingoo hardware on the ARM CPUs, except the CPU itself which is the same as the one in the DSTWO. With the responsibility of I/O shifted to the ARM CPUs, there would be little if any performance loss, in fact there may be performance gains, if we were to port the Dingoo SDK to SCDS2 and offload all the processing to the ARMs.
I've downloaded and looked over the SDK but I'm finding alot of things lacking that would prevent a full port of the OSes i'd like to port:
Linux, of course (I'd probably call it DS2Linux), and AROS, which would probably be called DSAROS.
I have big questions and no place i've found to ask them. Is this an official board for the SuperCard DS2 SDK? Do the DSTWO creators track this board?
Here are my questions:
1) Do you have access to the ARM9/ARM7 while code is running on the DSTWO? Can code run on the ARM CPUs and the DSTWO CPU at the same time?
2) Can you see the whole memory map and IO map? Wifi is not in the SDK but COULD it be?
I am willing to add/rewrite the SDK if need be, to accomodate new features. Also the current SDK is not very 'forward looking'. If DSi mode is broken (And theres some recent news suggesting it has been) I'd like to have a way to install a launcher on the DSiWare menu to launch the SCDS2 in DSi mode. So we should be writing the SDK in a way that assumes that later, another SD card slot will become available (fat2:/) and that additional RAM and CPU speed on the ARM side will be available.
Something else i'd like to do (I wouldn't make requests I couldn't do myself) is, assuming we can run code on the ARM9/ARM7 while the MIPS CPU is running, is load code onto those CPUs that handle things like sound and video. In particular I see the possibility of running a software OpenGL renderer on the ARM9 CPU and a sound handler (I come from Amiga coding so I'm thinking of emulating the Amiga Paula chip, where MODs come from) and also offloading all input processing to the ARM7. For DSi devices (when we can make them accessible) i'd like to offload access to those devices to the ARM9 because we'd have them at 133mhz and there'd be extra speed for these other processes. We'd load them in as modules on the ARM CPUs.
I'm writing up a spec for all of this, but, I need alot of questions answered first about how much access the DSTWO has to the DS/DSi hardware, and I suppose its a question for people who know. If there's a more technical SDK forum I should be on please let me know. I had not tried to sign up for the trial because I have not released any specific DS homebrew, I only contributed to DSLinux and released ports of some linux things to it. I have a DSTWO, I don't actually need one either.
I come from a coding background of C64, Amiga, and x86, but I do know Assembly Language.
Also, I have some interest in coding a Dingoo emulator for porting Dingoo apps to DSTWO. If it is possible i'd emulate the Dingoo hardware on the ARM CPUs, except the CPU itself which is the same as the one in the DSTWO. With the responsibility of I/O shifted to the ARM CPUs, there would be little if any performance loss, in fact there may be performance gains, if we were to port the Dingoo SDK to SCDS2 and offload all the processing to the ARMs.