Hacking Need detailed technical information

[Alynna]

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.

 

[asiekierka]

The DSTwo SDK is one of the worst I've ever seen.

To find answers to your questions, we have to find out about the inner workings of the DSTwo (the code for which is not open-source

)

 

[Alynna]

At this point, the idea of rewriting the SDK is an option. There isn't alot there, sadly. If the DSTWO creators are willing to be fully forthcoming about how the DSTWO works, i'll work on it, i'll even open a repository so others can too.

I don't actually know how to get a hold of them though ..

 

[Alynna]

Here's another question I forgot to ask. Does the SCDS2 CPU have an MMU? It makes alot of difference.

If the SCDS2 has no MMU, then I will probably forget about Linux and just port DSAROS (Which will be just as useful in a world without an MMU, as its designed not to require one).

The fact is, we had linux on DS, without an MMU, and it IS possible, but its also.. it deforms Linux so much it limits what you can do with it.

On the other hand, AROS will actualy be useful (because an MMU is optional for AROS) and a surprising amount of software is already available for it.

 

[Alynna]

Also if anyone has this information:
Can the SCDS2 transfer data directly to the RAM of the DS? Or does the DS need to initiate all transfers?

 

[loby]

The SCDS2 has mmu.

 

[loby]

In SCDS2, DS as a device of display and sound, the data transfer to DS through the audio channel and video channel.

 

[asiekierka]

@loby yes, but i think if there's a little bit of code added it could be possible to send any kind of data (slowly, but still) from and to the DS.

I'd propose

u8 read8(u32 addr)
u16 read16(u32 addr)
u32 read32(u32 addr)
void write8(u32 addr, u8 val)
void write16(u32 addr, u16 val)
void write32(u32 addr, u32 val)

 

[Gh0sti]

@Alynna
good luck trying to contact the SC team, they are very secretive like ninjas, anyways if you can get a hold of them, talk to them about getting the gba emu open source,

also the talk of DSi mode, even the team cyclops will not be able to access SD card slot, if you read up on what the DSi mode of iEvo can do its very limited other than it can access DSi's RAM and CPU, other than that game roms might not be playable,

if the DS2 could emulate or be able to port the tech the cyclops team found it would still be limited, other than just pure homebrew working

Rumor has it that another team of hackers/flash card makers have a hack that they ran unofficial code on the DSi and created a channel, now we dont know anything else, other than an image from ozmodchips, this year hopefully is the year the DSi is fully hacked.

 

[Alynna]

Well, I think it depends, if someone can make a channel on the DSi, then theres the possibility of booting the SCDS2 in DSi mode, by making a channel that boots the DSTWO. It would be in DSi mode because the DSi would already be in that mode when booting it.. But it depends on the channel hacks they've been talking about lately..

With the information I have now I don't see any easy way to make an OS for the DS that employs the DSTWO CPU. I've emailed for information but no response yet..

 

[Alynna]

As it is, I see no way with this SDK to boot an OS like Linux or AROS on DSTWO, I hope they will release more info..

 

[loby]

I think you need to write a linux device driver for exchanging data with the sdk underlying drivers.
You do not need to know how the underlying drivers communicate with the DS.
In addition, you need to consider is what kind of root file system, ramfs may be the better choice.
Maybe you need some info of hardware's initialization.

 

[Vigilante]

why not just send an email to the supercard team,they probably know more about a product than all of us

 

[sebastiaan4489]

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?

I don't think so. I remember reading this somewhere on the SC forum:
The ARM9 and/or ARM7 are kept busy processing the data retrieved from the DSTWO. (or something like that)

 

[Almamu]

I think you need to write a linux device driver for exchanging data with the sdk underlying drivers.
You do not need to know how the underlying drivers communicate with the DS.
In addition, you need to consider is what kind of root file system, ramfs may be the better choice.
Maybe you need some info of hardware's initialization.

ERROR: When you are programing an SO for any platform you need to know how the hardware works because you need to use IRQ's fired by the processor, you cant let the SDK manage them, you need a total control of them...

 

[Alynna]

i have emailed them and so far no response..

So far the SDK is inadequate, for one thing, theres no access to the wifi yet. This is kind of a showstopper.

Now to be right honest, if they are 'keeping the ARM CPUs busy' then i'd like to know 'what are they doing' and how can it be improved.

I hope they will open dialog with us about possibly rewriting the SDK and the arm7/arm9 code that communicates with the DSTWO so we might do more with it..

 

[Almamu]

i have emailed them and so far no response..

So far the SDK is inadequate, for one thing, theres no access to the wifi yet. This is kind of a showstopper.

Now to be right honest, if they are 'keeping the ARM CPUs busy' then i'd like to know 'what are they doing' and how can it be improved.

I hope they will open dialog with us about possibly rewriting the SDK and the arm7/arm9 code that communicates with the DSTWO so we might do more with it..

It's supossed that they are busy sending and receiving data between the DSTwo and the video and sound hardware

 

[Alynna]

this lends credence to a theory I had, that the DSTWO has no direct access to the DS/i hardware, and that for the DSTWO to do anything on the DS side, they have to shunt data into the DS all the time, meaning some kind of BIOS gets loaded onto the ARM9/7 so that they can poll the DSTWO constantly and see what needs to be transferred to the DS side.

This would be a design limitation of the DS, not the DSTWO, because the DS probably doesn't expect any kind of hardware that could transfer data to it, in slot 1.

Most of the work I want to do involves some kind of networking. I want Pidgin on DSTWO for example, and having Linux and AROS on DSTWO won't be nearly as useful without networking, so, hopefully they will respond to my emails.

 

[Alynna]

I think you need to write a linux device driver for exchanging data with the sdk underlying drivers.
You do not need to know how the underlying drivers communicate with the DS.
In addition, you need to consider is what kind of root file system, ramfs may be the better choice.
Maybe you need some info of hardware's initialization.

ERROR: When you are programing an SO for any platform you need to know how the hardware works because you need to use IRQ's fired by the processor, you cant let the SDK manage them, you need a total control of them...

It MAY be possible to port AROS, but only because AROS comes in native and hosted varieties, and the hosted varieties do not assume it has direct access to hardware. As soon as I see some evidence that networking is implemented (even if it is just high level bsd socket access) I'll start work on porting AROS to DSTWO.

 

[Pate]

Welcome Alynna!

I have also been very frustrated about the lack of low-level information on how the SDK works. I have done some digging of my own into the internals of the SDK, using the dump files and some testing. The results are on my blog at http://dsx86.patrickaalto.com/ but I have only scratched the surface.

As has been mentioned, there does not seem to be proper access to the DS side of things from the MIPS side. I would very much prefer using my existing ARM7 code in my DS2x86 project, instead of rewriting everything for the MIPS processor, and I have sent several emails to the SC team about this, but they have pretty much stalled all my attempts to discuss this matter.

It looks like the communication between the DS and MIPS is done with interrupts and DMA, so perhaps after studying those further some tricks could be found to send/receive data to/from other locations in the DS memory than the screen/audio buffers currently used.

Looking forward to hearing what you can come up with!

Pate