gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS Flash Equipment > New and updated utils for Flash Advance Pro carts

#72930 - Stonebone - Wed Feb 22, 2006 2:47 pm

I've made some utils for us who still use old Flash Advance Pro carts.

1. Updated Jeff Frohwein's GBA FLinker to work on XP and Linux.

2. tftpds, a new app to transfer a file and program a Flash Advance Pro cart over wifi on Nintendo DS.

See my new page: http://www.itstud.chalmers.se/~larssten/nds/

#72945 - qw3rty - Wed Feb 22, 2006 3:51 pm

This is an awesome app, if only my old Visoly-Card would fit in the DS :-/

#73072 - The 9th Sage - Thu Feb 23, 2006 5:16 am

qw3rty wrote:
This is an awesome app, if only my old Visoly-Card would fit in the DS :-/


It will if you take the casing off or shave the sides of the casing down like I did.
_________________
Now with 20% More Old Man from Zelda 1 than ever before!

#73242 - Joat - Fri Feb 24, 2006 1:39 am

I took a GBC case from a game I'd already destroyed for another project and liberally applied an x-acto, then put the visoly pcb in it.
_________________
Joat
http://www.bottledlight.com

#74227 - Stonebone - Fri Mar 03, 2006 6:28 pm

I've released tftpds v2.0. Changes:
* A GUI which lists files on cart
* Boots gba files
* Read and write sram
* Using paths to select where to write
* Fixed a bug in dswifi which prevented large files from working correctly

[Images not permitted - Click here to view it]

#74439 - grovedabg - Sun Mar 05, 2006 5:27 am

I get a header error reading on both files when trying unzip them.

I have an old Flash Linker/Flash Advance Pro 128 cart but the Flash Linker for some reason no longer works, is it possible through use of tftpds to flash a program on the cart without the Flash Linker?

#74465 - Stonebone - Sun Mar 05, 2006 9:37 am

grovedabg wrote:
I get a header error reading on both files when trying unzip them.

What program are you unpacking with? Make sure you use a program that supports "tar" and "bzip2". On Linux you would unpack with "tar xjvf tftpds-2.0.tar.bz2". If you're using Windows you can use a program like 7-zip (haven't tried though).

grovedabg wrote:
I have an old Flash Linker/Flash Advance Pro 128 cart but the Flash Linker for some reason no longer works, is it possible through use of tftpds to flash a program on the cart without the Flash Linker?

Yes absolutely. The only problem is that you need a way to run tftpds, but after starting tftpds swap whatever you have inserted in the gba slot for your flash cart, then upload a file according to the instructions in the readme.

#74477 - MaHe - Sun Mar 05, 2006 11:25 am

Could you add some support for X-ROM? I've always wanted to buy one(GBA homebrew dev. on GBAmp simply sucks), but I haven't got a GBA to write data on it ...

#74483 - Stonebone - Sun Mar 05, 2006 11:43 am

MaHe wrote:
Could you add some support for X-ROM? I've always wanted to buy one(GBA homebrew dev. on GBAmp simply sucks), but I haven't got a GBA to write data on it ...

There are two problems
1. I don't have any info on how to write to an X-ROM cart.
2. I don't have one to test with.

#74488 - MaHe - Sun Mar 05, 2006 11:56 am

Ummm ... What about eCube?

BTW, awesome application ;)

#74490 - Stonebone - Sun Mar 05, 2006 12:12 pm

MaHe wrote:
Ummm ... What about eCube?

BTW, awesome application ;)

Thanks. Unfortunately I only have a Flash Advance Pro 256M cart. I don't know how to flash any other cart. Sorry.

#74494 - grovedabg - Sun Mar 05, 2006 12:48 pm

Stonebone wrote:
grovedabg wrote:
I get a header error reading on both files when trying unzip them.

What program are you unpacking with? Make sure you use a program that supports "tar" and "bzip2". On Linux you would unpack with "tar xjvf tftpds-2.0.tar.bz2". If you're using Windows you can use a program like 7-zip (haven't tried though).

grovedabg wrote:
I have an old Flash Linker/Flash Advance Pro 128 cart but the Flash Linker for some reason no longer works, is it possible through use of tftpds to flash a program on the cart without the Flash Linker?

Yes absolutely. The only problem is that you need a way to run tftpds, but after starting tftpds swap whatever you have inserted in the gba slot for your flash cart, then upload a file according to the instructions in the readme.


Thanks, now I just got to find me a wifi USB cable.

#74495 - Stonebone - Sun Mar 05, 2006 1:04 pm

grovedabg wrote:
Thanks, now I just got to find me a wifi USB cable.

Wifi USB cable?

#74514 - grovedabg - Sun Mar 05, 2006 3:10 pm

I meant the Wifi USB connector, I don't have a wireless router.

#74515 - Stonebone - Sun Mar 05, 2006 3:31 pm

grovedabg wrote:
I meant the Wifi USB connector, I don't have a wireless router.

You must have an wireless access point. It might be possible to use the official Nintendo USB connector but I have not tried this. Take a look in this thread:
http://forum.gbadev.org/viewtopic.php?p=64212#64212

#74522 - The 9th Sage - Sun Mar 05, 2006 5:01 pm

Joat wrote:
I took a GBC case from a game I'd already destroyed for another project and liberally applied an x-acto, then put the visoly pcb in it.


Hmm...that's an even better idea. :) I'm sure I have a GB/GBC game floating around here I wouldn't mind destroying.
_________________
Now with 20% More Old Man from Zelda 1 than ever before!

#74724 - grovedabg - Tue Mar 07, 2006 3:52 am

Stonebone wrote:
grovedabg wrote:
I meant the Wifi USB connector, I don't have a wireless router.

You must have an wireless access point. It might be possible to use the official Nintendo USB connector but I have not tried this. Take a look in this thread:
http://forum.gbadev.org/viewtopic.php?p=64212#64212

I think I'll try my luck with this product

http://us.codejunkies.com/shop/product.asp?c=US&cr=USD&cs=$&r=0&l=1&ProdID=710&CountryID=US

..I hope it works with curl.

#75668 - GragonSon - Wed Mar 15, 2006 1:22 am

I wonder this app will work with flash2advance Ultra 512M and PowerWritter 2.61 ? could someone please tell me. thank you

#75753 - Ilomoga - Wed Mar 15, 2006 7:10 pm

It didn't work with my F2A Pro, so I doubt it will work with Ultra ...
_________________
The future of gaming is mobile Handheld Gaming.

#75756 - Stonebone - Wed Mar 15, 2006 7:43 pm

Ilomoga wrote:
It didn't work with my F2A Pro, so I doubt it will work with Ultra ...

What was the error?

#75865 - Ilomoga - Thu Mar 16, 2006 5:46 pm

Stonebone wrote:
Ilomoga wrote:
It didn't work with my F2A Pro, so I doubt it will work with Ultra ...

What was the error?


Tried it again with the latest version and when I try to send something via curl I get the error

"Detecting flash type:
Unknown

Error: Unupport 2c"

(something like that)[/code]
_________________
The future of gaming is mobile Handheld Gaming.

#75879 - Stonebone - Thu Mar 16, 2006 7:26 pm

I've uploaded a test version that does not stop when it cannot detect the flash cart. The reason for this is that there is a chance that writing to an F2A cart is done in the same manner as with the older FA carts.

It would be interesting if you could test this with your F2A Pro cart and see if it works. I don't know what will happen but it will probably just fail.

http://www.itstud.chalmers.se/~larssten/nds/tftpds/tftpds-test.ds.gba

#75880 - Ilomoga - Thu Mar 16, 2006 8:27 pm

I tried it and when I want to write something I'll get following messages:

Code:
TFTP server ready...
192.168.2.100:32873 connected
Detecting flash type:
  Unknown
Unsupported flashcart (0xff)Writing at offset 0x100000
Received:     0 ktimeout3

Error: Failed to erase flash at 0x8100000


But SRAM reading and writing seems to work fine (tried to write some text which I sent and then read and the text is the same)
_________________
The future of gaming is mobile Handheld Gaming.

#75884 - Stonebone - Thu Mar 16, 2006 9:19 pm

Ok too bad, but it was worth a try I guess. The reason I wanted to test is that some page said that "The Flash2Advance flash cards are virtually identical to the Flash Advance Pro". Unfortunately they must have changed the unlock sequence or the flash chip itself. The only page I know of with this kind of information is this page but it does not contain information about F2A.

I guess the information about how to write to a Flash Advance cart was obtained through reverse engineering. One could in theory disassemble the PowerWriter and find the unlock sequence, but I'm not skilled enough to do that kind of thing, even if I had an F2A cart.

#75901 - NorQue - Thu Mar 16, 2006 10:33 pm

Dunno if that helps, but my 256 MBit F2A Cartridge (first generation, I think, it has a weird spelling mistake on the label) is being recognized as 256 MBit FA Pro, using an old Flash Advance Linker and FA Writer 3.2NT (which was released before F2A, IIRC). Actually I don't even have a F2A cable, so that's what I always use to flash my Cartridge. Can't test it with your application, though, as I don't want to turn off WEP encryption on my WLAN router :( .

-- NorQue

#75913 - Stonebone - Thu Mar 16, 2006 11:26 pm

When sgstair releases the next version of his library there will be WEP support.

#75924 - tepples - Fri Mar 17, 2006 1:08 am

I seem to remember that the F2A is just the FA Pro's ASIC in front of a different brand of flash chip.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#75974 - Stonebone - Fri Mar 17, 2006 8:24 am

In that case someone needs to figure out exactly what the name of the chip is. (like "Intel 28F640J3A")

#75976 - NorQue - Fri Mar 17, 2006 9:22 am

There are two flash chips, both are labled with:

28F128J3A150
A0520025B
10433370LA

#75977 - Vince - Fri Mar 17, 2006 9:23 am

Check www.if2a.free.fr. It supports Ultra carts writing. You could contribute code as well ;)
_________________
Reclaim control of your F2A/F2AU with if2a !!

#75980 - Stonebone - Fri Mar 17, 2006 10:14 am

Vince wrote:
Check www.if2a.free.fr. It supports Ultra carts writing. You could contribute code as well ;)

Interesting project but the unlocking etc is still not known, right? I mean how the multiboot side interacts with the cart?

#76146 - cory1492 - Sat Mar 18, 2006 5:33 pm

http://if2a.free.fr/ works better

it seems to me that there is some multiboot known for ultra, at least up to 256MBit since I can multiboot stuff with pogoshell up to that point (see the if2a site for the last pogoshell source), which should be sufficient for homebrew at least.

There is also info in the if2a source package/svn about the chips that were found in different carts.

#76170 - kenny - Sat Mar 18, 2006 10:04 pm

would it be able to write to the G6?
ask this guy for a free G6 for development: danny@g6flash.com

#76849 - Stonebone - Sat Mar 25, 2006 10:38 am

I've released tftpds v2.1. Changes:
* Added gba menu. It's now possible to boot on a gba. (see readme)

http://www.itstud.chalmers.se/~larssten/nds/

#77514 - STAKED - Sat Apr 01, 2006 12:15 pm

Thanks for posting FLinker. I've been trying for literally months to get a decent working .sav read from my old Flash Advance Pro 128 cart (for some reason it corrupts as soon as it leaves the flash cart with every single other linker app I could find). Now I can finally play with the AC:WW map editor... and it reads/writes a hell of a lot quicker too.
:)

#95973 - freemaan - Mon Jul 31, 2006 7:39 pm

I tried to recompile it with the latest wifilib, but i got some errors:

Code:

c:\devkitpro\devkitarm\arm-eabi\bin\ld.real.exe: region iwram is full (h:/tftpds-2.1/arm7/tftpds-2.1.arm7.elf section .text)
c:\devkitpro\devkitarm\arm-eabi\bin\ld.real.exe: section .init [03800000 -> 038000e7] overlaps section .fini [03800000 -> 03800017]
c:\devkitpro\devkitarm\arm-eabi\bin\ld.real.exe: section .rodata [03800018 -> 038014f3] overlaps section .init [03800000 -> 038000e7]
c:\devkitpro\devkitarm\arm-eabi\bin\ld.real.exe: section .text [038000f0 -> 0381020b] overlaps section .rodata [03800018 -> 038014f3]
c:\devkitpro\devkitarm\arm-eabi\bin\ld.real.exe: section .ARM.extab [038014f4 -> 038015ef] overlaps section .text [038000f0 -> 0381020b]
c:\devkitpro\devkitarm\arm-eabi\bin\ld.real.exe: h:/tftpds-2.1/arm7/tftpds-2.1.arm7.elf: section .init lma 0x3800000 overlaps previous sections
c:\devkitpro\devkitarm\arm-eabi\bin\ld.real.exe: h:/tftpds-2.1/arm7/tftpds-2.1.arm7.elf: section .rodata lma 0x3800018 overlaps previous sections
c:\devkitpro\devkitarm\arm-eabi\bin\ld.real.exe: h:/tftpds-2.1/arm7/tftpds-2.1.arm7.elf: section .text lma 0x38000f0 overlaps previous sections
c:\devkitpro\devkitarm\arm-eabi\bin\ld.real.exe: h:/tftpds-2.1/arm7/tftpds-2.1.arm7.elf: section .ARM.extab lma 0x38014f4 overlaps previous sections
c:\devkitpro\devkitarm\arm-eabi\bin\ld.real.exe: h:/tftpds-2.1/arm7/tftpds-2.1.arm7.elf: section .ARM.exidx lma 0x38015f0 overlaps previous sections
c:\devkitpro\devkitarm\arm-eabi\bin\ld.real.exe: h:/tftpds-2.1/arm7/tftpds-2.1.arm7.elf: section .init_array lma 0x3801a70 overlaps previous sections
c:\devkitpro\devkitarm\arm-eabi\bin\ld.real.exe: h:/tftpds-2.1/arm7/tftpds-2.1.arm7.elf: section .fini_array lma 0x3801a74 overlaps previous sections
c:\devkitpro\devkitarm\arm-eabi\bin\ld.real.exe: h:/tftpds-2.1/arm7/tftpds-2.1.arm7.elf: section .eh_frame lma 0x3801a78 overlaps previous sections
c:\devkitpro\devkitarm\arm-eabi\bin\ld.real.exe: h:/tftpds-2.1/arm7/tftpds-2.1.arm7.elf: section .jcr lma 0x3801a7c overlaps previous sections
c:\devkitpro\devkitarm\arm-eabi\bin\ld.real.exe: h:/tftpds-2.1/arm7/tftpds-2.1.arm7.elf: section .data lma 0x3801a80 overlaps previous sections
collect2: ld returned 1 exit status
make[2]: *** [/h/tftpds-2.1/arm7/tftpds-2.1.arm7.elf] Error 1
make[1]: *** [build] Error 2
make[1]: Leaving directory `/h/tftpds-2.1/arm7'
make: *** [arm7/tftpds-2.1.elf] Error 2

#96080 - Stonebone - Tue Aug 01, 2006 8:55 am

Nice, someone is still interested in this.

The problem is that it runs out of memory on arm7. Renaming the files from .cpp to .c in arm7/source solves that problem.

I've released a new version for you which has some other fixes as well. I haven't released it before since it has some other problems (like some strange checksum bug in dswifi that was fixed ages ago which appears again when you send a file that is >14 MB), but if you really need the lastest dswifi it's still useful.

Anyway, download it here:
http://www.itstud.chalmers.se/~larssten/nds/

Tell me if you find any bugs.

#96091 - freemaan - Tue Aug 01, 2006 10:01 am

Thanks!! :) It's a lot faster!
The only bug i've found is I always get an error after the transfer completed : "Error: Unexpected operation"
But it works perfectly apart from this.

Edit: can you add this: "Replace cart and press A to continue" ? :)
It's because i have a SuperCard, and i have to replace the carts after tftpds started... and it doesn't work too well after it detects the cart (i have to remove it and start transfer 3 times).

#96102 - wintermute - Tue Aug 01, 2006 11:23 am

Stonebone wrote:


The problem is that it runs out of memory on arm7. Renaming the files from .cpp to .c in arm7/source solves that problem.


adding -fno-exceptions -fno-rtti to the CXXFLAGS in the arm7 makefile will also fix this. Exceptions appear to bloat the code quite badly with gcc 4.1.x.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#96459 - freemaan - Thu Aug 03, 2006 2:30 pm

When i try to write a bigger file (28mb), it always stops at about 14-15mb with "Out of order" and "Transfer timed out" error :(

#96490 - smoothingeye - Thu Aug 03, 2006 4:05 pm

can i use the ftpds using official NDS drivers and the offical NDS wireless ?

#96522 - Vince - Thu Aug 03, 2006 6:05 pm

Quote:

Interesting project but the unlocking etc is still not known, right? I mean how the multiboot side interacts with the cart?

Yes. We sill have to figure out how the multiboot binary orders the "descriptor" on the cart (the descriptor tells where to find ROMs on the cart and how to bankswitch to access them).
This is IIRC, as it's been some time I've worked on the project.
_________________
Reclaim control of your F2A/F2AU with if2a !!

#96582 - Stonebone - Thu Aug 03, 2006 11:48 pm

freemaan wrote:
Thanks!! :) It's a lot faster!
The only bug i've found is I always get an error after the transfer completed : "Error: Unexpected operation"
But it works perfectly apart from this.

This is harmless, it's just some duplicate packages.

freemaan wrote:
Edit: can you add this: "Replace cart and press A to continue" ? :)
It's because i have a SuperCard, and i have to replace the carts after tftpds started... and it doesn't work too well after it detects the cart (i have to remove it and start transfer 3 times).

Next version.

freemaan wrote:
When i try to write a bigger file (28mb), it always stops at about 14-15mb with "Out of order" and "Transfer timed out" error :(

Yes I think it's a bug in dswifi, but I'm not sure. I have written an example that triggers the bug every time which I've asked sgstair to look at. It's here if anyone is interested. Look at the traffic in Ethereal.
http://www.itstud.chalmers.se/~larssten/wifi_bug.7z

smoothingeye wrote:
can i use the ftpds using official NDS drivers and the offical NDS wireless ?

If it works with dswifi it works with tftpds (note the "t", it's not ftp).

Vince wrote:
Yes. We sill have to figure out how the multiboot binary orders the "descriptor" on the cart (the descriptor tells where to find ROMs on the cart and how to bankswitch to access them).
This is IIRC, as it's been some time I've worked on the project.

And unfortunately I can't help with this.

#111592 - RadicalAns - Fri Dec 08, 2006 2:52 am

I'm attempting to compile your source for tftpds and I'm running into some errors with boot7.c and gbamenu.c

boot7.c errors:

Code:

C:\nds\tftp\tftpds>make
make -C arm7
make[1]: Entering directory `/c/nds/tftp/tftpds/arm7'
boot7.c
arm-eabi-gcc -MMD -MP -MF /c/nds/tftp/tftpds/arm7/build/boot7.d -g -Wall -O2 -mc
pu=arm7tdmi -mtune=arm7tdmi -fomit-frame-pointer -ffast-math -mthumb-interwork -
I/c/nds/tftp/tftpds/arm7/include -I/c/nds/tftp/tftpds/arm7/build -I/c/devkitPro/
libnds/include -I/c/nds/tftp/tftpds/arm7/include -I/c/nds/tftp/tftpds/arm7/build
 -DARM7 -c /c/nds/tftp/tftpds/arm7/source/boot7.c -o boot7.o
c:/nds/tftp/tftpds/arm7/source/boot7.c: In function 'BootGbaARM7':
c:/nds/tftp/tftpds/arm7/source/boot7.c:140: error: 'SERIAL_CR' undeclared (first
 use in this function)
c:/nds/tftp/tftpds/arm7/source/boot7.c:140: error: (Each undeclared identifier i
s reported only once
c:/nds/tftp/tftpds/arm7/source/boot7.c:140: error: for each function it appears
in.)
c:/nds/tftp/tftpds/arm7/source/boot7.c:142: error: 'SERIAL_DATA' undeclared (fir
st use in this function)
make[2]: *** [boot7.o] Error 1
make[1]: *** [build] Error 2
make[1]: Leaving directory `/c/nds/tftp/tftpds/arm7'
make: *** [arm7/tftpds.elf] Error 2


gbamenu.c errors:

Code:

gbamenu.cpp
arm-eabi-g++ -MMD -MP -MF /c/nds/tftp/tftpds/gbamenu/build/gbamenu.d -g -Wall -O
3 -mcpu=arm7tdmi -mtune=arm7tdmi -fomit-frame-pointer -ffast-math -mthumb -mthum
b-interwork  -I/c/devkitPro/libgba/include -I/c/nds/tftp/tftpds/gbamenu/build -c
 /c/nds/tftp/tftpds/gbamenu/source/gbamenu.cpp -o gbamenu.o
c:/nds/tftp/tftpds/gbamenu/source/gbamenu.cpp: In function 'int main()':
c:/nds/tftp/tftpds/gbamenu/source/gbamenu.cpp:134: warning: 'InitInterrupt' is d
eprecated (declared at c:/devkitPro/libgba/include/gba_interrupt.h:120)
c:/nds/tftp/tftpds/gbamenu/source/gbamenu.cpp:134: warning: 'InitInterrupt' is d
eprecated (declared at c:/devkitPro/libgba/include/gba_interrupt.h:120)
c:/nds/tftp/tftpds/gbamenu/source/gbamenu.cpp:135: warning: 'SetInterrupt' is de
precated (declared at c:/devkitPro/libgba/include/gba_interrupt.h:129)
c:/nds/tftp/tftpds/gbamenu/source/gbamenu.cpp:135: error: 'IE_VBL' was not decla
red in this scope
c:/nds/tftp/tftpds/gbamenu/source/gbamenu.cpp:136: warning: 'EnableInterrupt' is
 deprecated (declared at c:/devkitPro/libgba/include/gba_interrupt.h:136)
c:/nds/tftp/tftpds/gbamenu/source/gbamenu.cpp:158: error: 'ScanKeys' was not dec
lared in this scope
c:/nds/tftp/tftpds/gbamenu/source/gbamenu.cpp:159: error: 'KeysDown' was not dec
lared in this scope
make[1]: *** [gbamenu.o] Error 1
make: *** [build] Error 2


Am I missing some type of library?

Thanks,
Dave

#111606 - Stonebone - Fri Dec 08, 2006 8:47 am

No I think it's just that the source doesn't compile with the latest libs. I have fixed this problem but I cannot send you the source because I don't have access to Internet at home. I also have some other improvements I think. I'll try to bring the source to a friend or something next week.

#114441 - Stonebone - Sun Jan 07, 2007 11:34 pm

Sorry for not giving you the source sooner. I've released 2.4 beta now at least. See our new blog for details:
http://blog.dev-scene.com/flatware/

#117872 - mateom199 - Thu Feb 08, 2007 4:47 am

Im getting lots of errors trying to compile with devkitARM r20, I'll trying working through them...

#117945 - mateom199 - Thu Feb 08, 2007 10:00 pm

Edit - got it working with different tftp client.

Getting alot of out of order errors, gonna have to look into that

So it looks like data is being sent faster than it can write, and tftpds loses
packets and aborts- the "out of order" errors I keep getting.

#118098 - Dwedit - Sat Feb 10, 2007 4:01 am

Can you make a .NDS version available, so I can boot it off a GBAMP?
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

#118112 - mateom199 - Sat Feb 10, 2007 5:55 am

Yea here you go. Its untested. It contains no GBA loader/multiboot menu, but it should boot on a ds and let you flash.

so far, most tftp clients I've tried mess up with anything over 300k. I believe theres some bug in how tftpds is handling the tftp protocol, but I haven't
put my finger on it yet.

tftp.nds

Oh, does anyone know how to contact the author of DSFTP? I emailed but got no response. I was thinking of adding an ftp server to this program, but the DSFTP lib thats currently available uses the old gba_nds_fat routines, and its a pain to get working with libfat.

#118181 - Dwedit - Sat Feb 10, 2007 10:27 pm

(I managed to get it the stock version to boot on a GBAMP by chopping off the first 512 bytes off the file)

I've been using this tool to flash a pogoshell compilation to a F2A 256 cartridge. After it received it, all the SRAM was blank. Is this tool messing around with SRAM content? I'd appreciate if there was a way to turn that off.

Also, DHCP requests fail 95% of the time, but I see a temporary IP address assigned in the wireless router's client table.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

#118231 - mateom199 - Sun Feb 11, 2007 8:15 am

Not sure about the DHCP problems, works fine for me on my equipment. I'll look into it though.

Attached is a new version, it *should* leave the SRAM alone. I've included a button that will execute the SRAM code that it used to execute on startup.

Basically, the SRAM code will take whatever is in the first bank, and archive it in either bank 2, 3, or 4. When you load a program, it will copy its corresponding sram back into bank 1. Its pretty buggy right now though, as you have obviously seen.

EDIT: squashed a bug, sram shouldn't be affected anymore.

tftpds archive

#147546 - Smiths - Sat Dec 22, 2007 5:39 pm

Sorry to dig up an old thread, but I've just gotten inspired to get my FlashAdvance256 to have some use on my NDS, now that I have no LPT port for my old Flinker device.

I am getting the >15mb timeout error, and am wondering if anything has been fixed in that regard recently?

Also, the Arm7 code still seems incompatible with the latest devkit... so any ideas on fixing that?

Just kinda inspired right now but jumping in blindly!

And that old old "no sram modifying" build.. can that be uploaded again somewhere? zshare got rid of it by now, obviously.
Thanks!

Update: Well for the >15mb thing I just programmed a little frontend in VB that will split the file at 14 meg intervals and wifi flash the parts sequentially, making sure the offset changes for each part. I flashed a full 256mb pogoshell compilation in 3 parts and it worked just dandy.
Still would like the source to compile in the latest devkit so I can play with the save managing thing

#147555 - mateom199 - Sun Dec 23, 2007 12:00 am

I dont have a copy of it anymore, but I'll take a stab at compiling a new copy when I get a chance.

#147556 - Smiths - Sun Dec 23, 2007 12:45 am

Actually, I got even more programming focused and fixed what was not working for the new devkitARM+libnds, so I have it compiling.

But I gotta say, weeding through the code to insert a simple "get me 256KB of sram starting at 0x0000" is actually being more of a ***** than I'd prefer. I'll keep taking stabs at it, but at least it's compiling and not init'ing the sram anymore.

#147570 - Stonebone - Sun Dec 23, 2007 6:14 pm

The 15 mb bug was fixed a long time ago in dswifi I think.

And I thought I disabled the save manager...

But if you got it compiling it shouldn't be a problem to access the sram? I'm curious what the problem is.

PS. Why didn't I get an email? I'm watching this topic...

#147573 - Smiths - Sun Dec 23, 2007 8:42 pm

Stonebone wrote:
The 15 mb bug was fixed a long time ago in dswifi I think.

I used 2.4 and still got the error, which led to the little frontend that split the file before uploading in multiple stages. I am using the latest devkitpro libs from the updater, too.

Quote:

But if you got it compiling it shouldn't be a problem to access the sram? I'm curious what the problem is.


Oh I'm just looking through how you're doing the sram thing. It's based on file names and headers... but PogoShell isn't the cleanest with that. For a Pogoshell dump, all I need is to get 256kb of SRAM starting at 0x0000, but it seems to be entirely "name" based vs. 'starting position and size', so I'm just poking around.

#147608 - Stonebone - Mon Dec 24, 2007 11:44 am

Hmm I should probably revert the changes for the failed save management system and release a new version which compiles with the latest devkit. Good thing I used a local svn repository for this project, so there shouldn't be a problem.

I didn't bring my flash cart so I cannot test anything right now though.

#147615 - Stonebone - Mon Dec 24, 2007 3:23 pm

I've created a Google Code project so we can work on this together. I've reverted the save system changes and made sure it compiles with the latest libnds. I have however not tested that it still works.

http://code.google.com/p/tftpds/

#147616 - Smiths - Mon Dec 24, 2007 3:38 pm

svn is compiling (ignore old post saying it wasn't.. had to copy fwgui from old compiled source to svn.. duh)

I'm mainly interested in figuring out the stages of the save system to try and convert it from a filename checking/size calculating system to more of a FLinker "get [bank] [size] [file]" or "put [bank] [file]".
To be honest I cannot trace how the "get sram/" commands are parsed... it seems to go through like 4 different source files between tftpds receiving the command, filefactory getting the file, sramsystem checking the file's existence, sram getting the bytes and header, then it goes back the opposite way!

I love the program though since I can flash my FlashAdvance again, thank god!

#147617 - Stonebone - Mon Dec 24, 2007 3:57 pm

Hmm fwgui should be pulled from the tetattds repo since i set a svn:externals property.

Anyway, the file stuff is pretty over-designed :-)

#147618 - Smiths - Mon Dec 24, 2007 4:02 pm

Yeah, I posted way too early in the last post, now I've actually begun digging through what's changed.
I can see the sram path now being /ram/ and it seems to just try starting at 0x00000 and going to the end.

I have tested it with a "tftp 10.0.1.5 get /ram/ pogoshell.sav" and it begins getting data, but gives me an "error:" on the DS screen and a "Received bad opcode. Opcode = 4" after a variable amount of bytes... max i've gotten is 32KB.

Opening the file in a hex editor I can see it is getting the SRAM.
I'm currently playing a bit in the code... again this is only from like 10 mins of playing.

But whatever you've changed is definitely a lot cleaner than the 2.4 source.

#147620 - Smiths - Mon Dec 24, 2007 5:10 pm

Ya know... the tftp seems to be awesome for writing files to the card... receiving, especially SRAM, seems to be very picky.
What would be really tight would be not using tftp for sram, but just backing up the save to a Slot-1 device. Of course, I'm not sure how easy that is. I'm just brainstorming.

I set the SRAM end to 64KB, and after many attempts over and over I managed to get bank 1 xferred. It ain't flawless, but at least I can (after entering the command over and over :) ) get saves off my flash cart.

---
Update:
Got even more bored, put in libfat stuff and added a small routine to the beginning when it first loads to back up bank 1 to a file on the flash cart (backup.sav).

Code:

void BackupSRAM() {
FILE * test = fopen ("fat1:/backup.sav", "wb");
printf("Backing up Bank 1\n", test);
u8* start = SRAM_START;
u8* bank1 = SRAM_START+65535;
u8* end = SRAM_END;
char strbuffer[8];

while (start < bank1 - 1) {
   memcpy(strbuffer, start, sizeof(strbuffer));
   fwrite((u8*)strbuffer, 1, sizeof(strbuffer), test);
   start = start+8;
   }

fclose (test);
printf("Done!\n", test);
}


It's ugly, but it's my first coding for DS in uhhh... lord I dunno. For some reason if I set the end of file to be the end of SRAM, it still won't backup anything past 64KB (00s after that). This may have to do with bank switching or something, I don't know.
for now, I have a working program to flash my FA256 via wifi, a GUI for that, and a backup of bank1 of my flash card when I load the program.
Get bored enough, the startup routine will just become a button.

Thanks for your hard work on this, it seriously is exactly what I needed!

#147872 - Smiths - Sat Dec 29, 2007 5:09 pm

I want to update saying after several days of annoyance (and a locked flash card that I had to take to an old computer with LittleWriter and format), I've got this ding-dang thing flashing the DS cart from a file "rom.bin" in the root of the Slot-1 card.

So yay, once everything is cleaned up, you can flash a FlashAdvance cartridge without using WLAN or anything... just put the file on your slot-1 device and load the program.

Wheeeeeeeeeeeee

#147911 - Stonebone - Sun Dec 30, 2007 1:17 pm

Nice!