Re: dslink bugfixes...
Posted: Sun Nov 27, 2016 6:55 pm
Agreed, when developing new code. The thing is that around 99% of all older DS homebrews don't support the new touchscreen mode, and don't expect 16Mbyte RAM, and it would be nice to be able to run them on DSi by using its DS-backwards compatibility mode (as far as it's possible).WinterMute wrote:Personally I'm much more interested in having DS code run regardless of whether it's booted in DSi mode or DS mode so actually I'd rather not have something automatically switch.
I've thought about how to transfer them with minimal changes to the current dslink protocol. Currently it's done like this:WinterMute wrote:adding extra binaries to the nds file ... I'll do it at some point but there are other demands on my time right now unfortunately & it's not something straightforward. There are a lot of decisions to be made about if and how the tools should support extra binaries.
My idea would be use the upper response bits to request the extra DSi data to be transferred, and if we are there, it would be also nice to be able to request the icon/title structure to be transferred, so the DS/DSi could (optionally) display the icon and/or title during the transfer. Like this:
Code: Select all
receive 200h-byte header send 4-byte response (00000000h=okay, 00000001h=error) receive ARM7 binary receive ARM9 binary receive cmdline
Does that look okay to you? It should even work when somebody mixes up old/new dslink versions (as long as the new flag bits are zero, ie. when using the old software on the console side, and (when using bit17), it would also work whenever uploading non-DSi titles, or whenever uploading to non-DSi consoles).
Code: Select all
receive 200h-byte header send 4-byte response (xxxx0000h=okay, xxxx0001h=error, bit16,bit17=new flags) receive 1000h-byte header when response.bit16=1 receive icon/title when response.bit17=1 receive ARM7 binary receive ARM7i binary when response.bit16=1 receive ARM9 binary receive ARM9i binary when response.bit16=1 receive cmdline
I would like to support that stuff, and it would be nice if we could use on some standard transfer protocol for it. For example, I am planning to add some "Wifi Upload to DS/DSi" function in the no$gba debugger, and it would be neat to have that function compatible with your exploits installed at the console side.
Ah, and I've tried your new dslink beta. It's now booting my code for testing the initial register settings : ) whereof, the test results are: the stacks are still all wrong (all off by 40h bytes, or 44h bytes in one case) and the scaling values are all zero (defaults would be [400x020h]=100h and [400x024h]=1000000h for getting an "unscaled" picture in rotation/scaling/bitmap modes on LCD A and B).
Concerning initialization & headers, I've no problem with following the standards from nintendo. There isn't too much reason to do things differently, and parts of the fun in making homebrew games is to produce something that "could be manufactured as real cartridge".