dslink bugfixes...

nocash
Posts: 8
Joined: Mon Sep 26, 2016 10:21 pm

Re: dslink bugfixes...

Post by nocash » Sun Nov 27, 2016 6:55 pm

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.
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: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.
I've thought about how to transfer them with minimal changes to the current dslink protocol. Currently it's done 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
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 (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
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).

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".

WinterMute
Site Admin
Posts: 1396
Joined: Tue Aug 09, 2005 3:21 am
Location: UK
Contact:

Re: dslink bugfixes...

Post by WinterMute » Wed Jan 18, 2017 1:01 am

nocash wrote:
I've thought about how to transfer them with minimal changes to the current dslink protocol. Currently it's done 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
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 (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.
This seems interesting.

We've now got the toolchain producing "dsiware ready" nds files which allows us to install a bootstrap on 3DS to boot hbmenu from SD which is working quite well. This seems to even allow wifi to work as is which is kind of nice.

Now everything is in place I've tidied up & released new dslink binaries at https://github.com/devkitPro/install-ds ... tag/v2.0.0 although I haven't yet got around to addressing your other issues. This one does set bit 16 of response & receive the DSi header and extra binaries but I have't looked at icon/title yet.

Would it be possible to get a binary from you that tests & shows the setup you're expecting?
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".
It's kind of a shame to limit the size of the arm9 binary due to the memory mapping though. There's also all the extra space taken up on an SD card by the extra 15K of header & we're currently wasting another 2K in the arm9 binary.
Help keep devkitPro toolchains free, Donate today

devkitPro IRC support
Personal Blog

ahezard
Posts: 1
Joined: Wed Feb 22, 2017 7:19 pm

Re: dslink bugfixes...

Post by ahezard » Sun Mar 05, 2017 11:19 am

nocash wrote:For best NDS compatibility on DSi you would need to disable the DSi hardware on ARM7 side (which unfortunately isn't possible with current exploits, particulary some of the Shared RAM will be forcefully overlapped by NewShared RAM). However, you can do some things: Switch to 4MByte Main RAM mode (if you aren't already doing so), and switch the touchscreen/sound controller to NDS-compatiblity mode (I've revengineered some code/flowchart for doing that, if you are interested - it's still a little bit messy, but should work).
On 3DS running in DSI mode I have access to all ARM7 registers and I am able to disable all the DSi hardware and even switch the bios from DSI to DS one but I do not know how to switch the touchscreen/sound controller mode at run-time. So I am very interested by the flow charts even if things may be a little different on 3DS in respect to the DSI. Can you share them?

WinterMute
Site Admin
Posts: 1396
Joined: Tue Aug 09, 2005 3:21 am
Location: UK
Contact:

Re: dslink bugfixes...

Post by WinterMute » Wed Sep 13, 2017 6:12 am

Latest dslink works fine with W024 boards now. https://github.com/devkitPro/install-ds ... tag/v2.1.0

I'm still interested in finding out how to switch the touchscreen to DS compatible mode too.
Help keep devkitPro toolchains free, Donate today

devkitPro IRC support
Personal Blog

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests