Hacking DS-Xtreme OpenSource Firmware Project

[arctic_flame]

Indeed Artic_Flame, AceKard a much more open system but....

From my understanding they give the "OpenSource" to the launcher and not the firmware? Is this right?




B.T.W the AceKart is on my "I want" one listÂ

where did you buy yours from?...

I'm pretty sure it's all open. http://bamboogaming.com/flash-cards/other-...g/prod_119.html

 

[reveng]

@artic_flame
Cheers M8 for the buying link/review

Still think the quote "OS" means lancher and PC app source though, guess I'll just order one and see...credit card at the ready

@pbolmstedt

I've put the binaries here:

http://ul7.info/dsx/V110_update.bin
http://ul7.info/dsx/V112_update.bin

I just downloaded them from the links in the Wiki article; I don't know if this is useful at all.

The file:// method might not work depending on the API used in the updater. It could be designed only to work with "http://" URLs. I'm afraid to try; I don't wanna brick the only flashcart I have. =]

If I was, I definitely wouldn't use my real name on the Internet. =] Regarding the team, I noticed that all the moderators on the official DS-X forums use "they" when they speak of the DS-X team nowadays. They used to use the word "we". =]

Nice one with the links,
Yeah, I know your not the

DSX/XODUS team

, way to honest with your monica to be a member of that shady lot

. It was just a little joke, no offence intended, big sorry if any was implied.

With regards to the updater, you can play patching the .exe and try it out without having your DSX cart plugged in. The updater App tries all the loading of the binaries before it does anything to the cart. It only accesses the cart when you click on the update button.

 

[golden]

B.T.W the AceKart is on my "I want" one listÂ

where did you buy yours from?...

Ya, you should get one. Bamboo is pretty reliable place to get one. I got mine from there.

The loader and everything is open source except a specific area. I forget which but I am sure TD-Linux has posted what part of the code is missing and has asked the AK team to supply him and I think they said OK or something. Go check out the AK thread for more details. But it's not a big deal. It is only like a fraction of the entire code that is not there.

 

[OSW]

er... they haven't released the bootloader source to the public as far as i know, and i do not know it it's rewritable.

i know someone requested the information, but don't know if they told him.

 

[arctic_flame]

It's in the akloader folder.

 

[Normmatt]

It's in the akloader folder.

Actually thats just the rom loader, the bootloader is what actually loads the akmenu2.nds file from the nand, and too my knowledge isn't open source although there really isn't much need to change it anyway.

 

[reveng]

O.K after many evenings of experimentation I've decided on a Disassembler to use, IDA Pro .

Tried the following:

DeDe (by DaFixer) - More of a decompiler then a disassembler, but a very interesting tool.
DE Decompiler - Nearly used this, but the payment was to a RU Site and I felt uneasy with CC details to RU, no offence intended.
IDA Pro (freeware version 4.9) - Wicked disassembler

see example disassembled portion of the PC Updater below.

Part of the WinMain function of the PC Updater application, nicely labelled also you can modify the labels add comments and even run the code.

Just looking at the example above reveals interesting possibilities, like the PC Updater can take 3 command line parameters?

The 1st parameter is [ -server ] followed by.... mmm maybe file://update.txt and file://update.bin?

Anyway I need to get over the learning curve of IDA Pro next.
Then try and get a disassembly that will recompile and work..

B.T.W IDA Pro Can also also be used to decompile the DS Launcher code

 

[joedodgy]

I started to have a look at the updater in IDA when you first started this thread. The presumed compressed areas of the updater bin don't appear to be inflate/deflate based (don't start with 'X', might have areas done with compress/uncompress functions of zlib instead if used at all) - it's possible zlib is present in the updater binary as part of the Indy socket library (zlib is used as compression method for delivery of web pages too), but need to check into that more.. A bit more tracing of the updater code and it should be (hopefully) pretty obvious what is going on (gut says LZ

).

 

[reveng]

I started to have a look at the updater in IDA when you first started this thread. The presumed compressed areas of the updater bin don't appear to be inflate/deflate based (don't start with 'X', might have areas done with compress/uncompress functions of zlib instead if used at all) - it's possible zlib is present in the updater binary as part of the Indy socket library (zlib is used as compression method for delivery of web pages too), but need to check into that more.. A bit more tracing of the updater code and it should be (hopefully) pretty obvious what is going on (gut says LZ

).

Hey Joedodgy,
Good bit of detective work, keey it up M8, funny I was doing a little Indy research yesterday. It seems recently the compression has been slightly changed.

Indy - Zlib announcement

Did you see a few posts back in this thread that the update.bin has some sort of header? We did a partial explore of it.

Isnt IDA Pro the Dogs Boll&*cks, last time I used a disassembler (1990's sourcer) it was a lot less refined.

Thanx for the info.

 

[gedly]

gedly, theoretically, yes. You can utilize the FPGA to make the DS-X more physically powerful than all the other carts.

The problem is, is there really truly a demand for it? Coders would have to dedicate their time specifically to the DS-X, thereby reducing the amount of people able to use their work. If the DS-X is dead there is even less reason to code for it.

This opensource project is fantastic, in that it may hopefully lead to a group of people dedicated to bettering the DS-X. It is more than obvious that the team that originally developed the DS-X has lost momentum. This project is the natural progression of such things. Hopefully, it is not too late.

With that said, I think we should have the knock at the DS-X forums mods removed from the Wiki. At this point, you don't know where help may be coming from, and we may be pushing away people that are interested in bettering this project. We need to appear as professional and mature as possible, to not turn any potential help away.

It's a case of whether homebrew developers would enjoy the intellectual challange of it (I think they would).

Take, for example, the various ports of mame underway - a developer might bake in "DSX processor support" so DSX owners could play later coinops, but non dsx owners could use the same software but obviously be limited to more ancient games because of the nds's speed limitations...

Of course it gets really complicated as that would also depend on an agreed standard for using the fpga as an extra processor (would a DSP or fully fledged cpu be better for such things?)...then again you might load different fpga configs depending on different requirements for different apps - wow, it's almost too much, isn't it!

I think the ability to run GBA roms without any patching and a slot 2 card might be a worthwhile line of pursuit - the gba roms are already out there, it would just be something that all dsx owners could enjoy (and stop us getting laughed at for owning one). Perfect for this project too as even if the DSX team are still out there, it's something that, with their "lets try and pretend people should be paying twice the price of other slot 1 cards but shouldn't want to play roms" philosophy, they would never implement.

 

[gedly]

I don't think that there would be a problem setting up different directories on reveng.coms server to be used for each variation of firmware. The end-user would just download whatever updater correlates to the firmware they want.

QUOTE(tropakeroro @ Jan 12 2008, 11:38 AM)Great. we need a new firm. but

Hey throwingks,
Please remember the Scope of the project, its not to make firmware updates.

06) Create a new, "OpenSource" firmware from the knowledge gained.

^
If you're going to do this, why would you not make a better firmware than the existing one? In which case, would that not be an "updated" firmware to all intents and purposes?

 

[reveng]

06) Create a new, "OpenSource" firmware from the knowledge gained.

If you're going to do this, why would you not make a better firmware than the existing one?  In which case, would that not be an "updated" firmware to all intents and purposes?

"06) Create a new, "OpenSource" firmware from the knowledge gained." is not making updates its just opening it up. O.K the new is a bit ambigious I'll reword it.

"The scope of this project is to open up the DS-Xtreme flash cartridge hardware/firmware for homebrewers to modify"


I'm only interested in the Hardware and the voyage of discovery is the simple answer. The information will be OpenSource so others can do what they like.

 

[gedly]

06) Create a new, "OpenSource" firmware from the knowledge gained.

If you're going to do this, why would you not make a better firmware than the existing one?  In which case, would that not be an "updated" firmware to all intents and purposes?

"06) Create a new, "OpenSource" firmware from the knowledge gained." is not making updates its just opening it up. O.K the new is a bit ambigious I'll reword it.

"The scope of this project is to open up the DS-Xtreme flash cartridge hardware/firmware for homebrewers to modify"


I'm only interested in the Hardware and the voyage of discovery is the simple answer. The information will be OpenSource so others can do what they like.

OK.

Just out of interest, what does the firmware 'run' on - is it in effect a rom as far as the ds is concerned and therefore can be regarded as another .nds app (a bit confusing because obviously you can then launch further roms from it) or is there more to it than that? I'm thinking about the bit that we actually see when we fire up the DSX, but is there also lower level modifiable stuff before that...?

Sorry I might not be too clear but hopefully you get the idea...

 

[reveng]

OK.

Just out of interest, what does the firmware 'run' on - is it in effect a rom as far as the ds is concerned and therefore can be regarded as another .nds app (a bit confusing because obviously you can then launch further roms from it) or is there more to it than that? I'm thinking about the bit that we actually see when we fire up the DSX, but is there also lower level modifiable stuff before that...?

Sorry I might not be too clear but hopefully you get the idea...

Good question Gedly,
After reading my answer please have a quick look at the hardware page and it'll make more sense, you'll see all the chips I'm talking about.

Wiki Hardware Page

There are maybe 3 parts to the firmware (all contained in that update.bin file)
1) The firmware for the USB Controller chip
2) The configuration for the FPGA chip (sorta like firmware)
3) The NDS launcher (maybe stored in the FPGA or on a hidden partion on the NAND ram) "the bit you see when you fire up the DSX"

Now this is speculation but I guess when you boot the DS the FPGA downloads the launcher into DS ram and then the DS executes this, like it would any game.

The firmware is upgradable by the PC Updater.

Hope that makes sense?

 

[gedly]

OK.

Just out of interest, what does the firmware 'run' on - is it in effect a rom as far as the ds is concerned and therefore can be regarded as another .nds app (a bit confusing because obviously you can then launch further roms from it) or is there more to it than that?  I'm thinking about the bit that we actually see when we fire up the DSX, but is there also lower level modifiable stuff before that...?

Sorry I might not be too clear but hopefully you get the idea...


Good question Gedly,
After reading my answer please have a quick look at the hardware page and it'll make more sense, you'll see all the chips I'm talking about.

Wiki Hardware Page

There are maybe 3 parts to the firmware (all contained in that update.bin file)
1) The firmware for the USB Controller chip
2) The configuration for the FPGA chip (sorta like firmware)
3) The NDS launcher (maybe stored in the FPGA or on a hidden partion on the NAND ram) "the bit you see when you fire up the DSX"

Now this is speculation but I guess when you boot the DS the FPGA downloads the launcher into DS ram and then the DS executes this, like it would any game.

The firmware is upgradable by the PC Updater.

Hope that makes sense?

Sure does - I guess that what most users perceive as "firmware" then is actually the launcher - to rectify the main concerns of dsx owners (lack of compatibility [e. g. arm7 fix], slow startup time, no soft reset etc) would be more of a ds programming project than a machine language/microcoding/fpga configuration effort? And in that respect would be "easier", or is reverse engineering the hardware actually more feasible?

On another point, regarding the fpga, what do you think the dsx team thought could be done with it?

You see, I wonder if they just used an off the shelf part that was over the top for the function required but easier for them to go straight from prototype to production, then tried to make promises of future functionality to justify the higher price.

After all, as discussed, if they provided some kind of enhanced functionality via the FPGA and it was available to .nds software, only code written specially for the dsx would work and you'd have to freeze that functionality once developers started using it. If the functionality is only available prior to the launcher, well, however powerful it might be, how much use could it be put to?

 

[reveng]

in that respect would be "easier"
Unfortunately the launcher seems to buried in the update.bin with the rest of the firmware. So ya kinda need to decipher either the update.bin or crack the updater ( which will give you the info for deciphering update.bin ).

Once thats done, and the launchers disassembled/extracted, all the functionality you like could be put into a new launcher. I believe thats how the R4DS works they get new versions of the launcher (they call it firmware).

FPGA's are very, very powerfull chips, but it all depends on how the FPGA is physically interfaced to the DS as to what the FPGA could do and the imagination of the designer. Unfortunately the chip housing has its connectors under the chip, so you cant make an electrical schematic without ripping the FPGA off the circuit board.

QUOTEpromises of future functionality to justify the higher price

Dont know the answer to that, one can only speculate.

The FPGA will be connected to "whatever" and always be running, so I suppose it can do whatever the actual cart connections can let you do (sounds jibberish but sorta makes sense). You could also have the FPGA running as a second DSP/Processor... doing what is upto the imagination (3D, MPEG decoder, full blown emulator of ?)

 

[gedly]

The FPGA will be connected to "whatever" and always be running, so I suppose it can do whatever the actual cart connections can let you do (sounds jibberish but sorta makes sense). You could also have the FPGA running as a second DSP/Processor... doing what is upto the imagination (3D, MPEG decoder, full blown emulator of ?)

I wonder how big a memory space it could be configured to pretend to be? I'm thinking opera browser without needing a slot 2 card.....

 

[throwingks]

The FPGA will be connected to "whatever" and always be running, so I suppose it can do whatever the actual cart connections can let you do (sounds jibberish but sorta makes sense). You could also have the FPGA running as a second DSP/Processor... doing what is upto the imagination (3D, MPEG decoder, full blown emulator of ?)


I wonder how big a memory space it could be configured to pretend to be? I'm thinking opera browser without needing a slot 2 card.....

It depends on how Opera was coded. It probably wouldn't work though. But, it could be very beneficial for a homebrew web browser.

 

[arctic_flame]

The FPGA will be connected to "whatever" and always be running, so I suppose it can do whatever the actual cart connections can let you do (sounds jibberish but sorta makes sense). You could also have the FPGA running as a second DSP/Processor... doing what is upto the imagination (3D, MPEG decoder, full blown emulator of ?)


I wonder how big a memory space it could be configured to pretend to be? I'm thinking opera browser without needing a slot 2 card.....

I'm prety sure this is impossible due the relative speeds of the DS and GBA Slots.

 

[reveng]

If Opera is already on the GBA then it just needs porting from GBA to DS in a homebrew project.
Contact the developer and ask him for the source, then start a homebrew project.

Does not need any inner secrets of the DSX cart to do that, a simple homebrew project.

Sorry not been around much, some new projects kicking off at work.