#46684 - chishm - Wed Jun 29, 2005 2:42 am
Hi all,
I have finished with the compact flash part of the GBA movie player, so now I am moving onto the firmware. Has has been previously discussed the firmware shows up as a repeat of 512 bytes if dumped without booting the GBAMP first. I have so far been unable to figure out how to unlock the rest of the memory without booting the GBAMP first. My question is: if someone has a corrupted GBAMP (ie it won't boot at all) and a multiboot cable of some kind (MBV2, Xboo) could you please
1) Start the GBAMP normally even if it won't boot
2) Quickly power cycle the GBA and press START + SELECT to enter multiboot mode
3) Dump the firmware
4) Examine the firmware to check if it still has the repeating 512 byte block.
5) If allowed, post the dump.
Thankyou.
#46689 - Lynx - Wed Jun 29, 2005 3:44 am
You might want to check with DF, as I think he's working on writing his own Firmware.. I'd guess he was able to dump and decrypt to learn how to write his own firmware. But I'm just guessing.
#46695 - chishm - Wed Jun 29, 2005 5:08 am
I know Darkfader has already flashed his GBAMP, but he is also only able to access the first 512 bytes in DS mode. I am trying to figure out how to access all of the memory. I can already dump the proper firmware in its entirety, but only if I boot the GBAMP normally first. I am trying to figure out how to do it without having to boot into GBA mode first.
In GBATek it mentions that the BIOS performs a sequence of reads based on the header. Does anyone know what addresses it reads from and how to work out which sequence is used? I think this is going to be important information.
#46701 - tepples - Wed Jun 29, 2005 6:15 am
| chishm wrote: |
| In GBATek it mentions that the BIOS performs a sequence of reads based on the header. Does anyone know what addresses it reads from and how to work out which sequence is used? I think this is going to be important information. |
Dump your GBA's BIOS, load it into an emulator, and log ROM accesses during the first few seconds.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#46703 - chishm - Wed Jun 29, 2005 6:19 am
| tepples wrote: |
| Dump your GBA's BIOS, load it into an emulator, and log ROM accesses during the first few seconds. |
I've already dumped my GBA's BIOS and tried it with VBA dev, but I can't figure out how to log address reads with it. Are there any emulators that allow me to do this that are free (I can't send money over the internet)?
#46704 - tepples - Wed Jun 29, 2005 6:39 am
| chishm wrote: |
| (I can't send money over the internet) |
Under 18? Or not in a first world country?
You could always get the VBA source, edit it to log all cart reads while r15 is within the BIOS, and recompile it.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#46745 - chishm - Thu Jun 30, 2005 1:10 am
| tepples wrote: |
| chishm wrote: | | (I can't send money over the internet) |
Under 18? Or not in a first world country?
You could always get the VBA source, edit it to log all cart reads while r15 is within the BIOS, and recompile it. |
I am 18, and unless Australia is not a first world country, those aren't the reasons. Its actually because I have no credit card and I am not going to give bank account details over the net, money transefers cost something like $5 to $20, and since No$GBA hobby version is $15 its not worth it.
I took your advice with the VBA source. I had to download like 600MB of SDKs on a 300MB 256/64 ADSL plan (maybe I am in a third world country) to get it to compile. It was worth it though, as I now have a log of the reads performed by the BIOS. If anyone wants them I could post it here, but its a bit long.
#46747 - tepples - Thu Jun 30, 2005 1:22 am
If you could narrow it down to those reads that change based on the title of the ROM (see gbafix) and based on bits 0 and 1 of byte 0x0800009E, there should be only 16 possibilities.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#46753 - chishm - Thu Jun 30, 2005 5:24 am
I actually took the log after loading the firmware dump, so it should have the correct set of reads required for the cartridge.
I've been examining the hardware in the GBAMP and I know what one of the chips is (39VF400A : 16 * 32KiB flash ROM) but I am not 100% on the other. I think it might be a PIC used to protect the firmware, only ollowing the low 9 bits of the firmwarew bus through until it is unlocked by the BIOS.
#46763 - darkfader - Thu Jun 30, 2005 6:26 am
Wow.. much talk here again. hehe.
512 bytes -> 8 address lines.
And there are also 8 address lines that are locked.
I previously tried the logged accesses too.. but no success. Already mentioned that somewhere on the DS hardware forum.
Anyway, it's unlocked by only the init sequence that GBA BIOS makes, since I can read everything fine using my own app that I flashed.
Perhaps it's not just the sequence, but also some low-level thingy.
Check http://cvs.sourceforge.net/viewcvs.py/devkitpro/tools/nds/bootstrap/flashmp/ for flashing details.
You _can_ use that reinsert trick in DS mode to unlock it, but the chance of success is very small. So you'd have to reinsert a lot.
And that other chip is not a PIC, but some CPLD. Don't know the exact type, but I have some suspect. Not really useful though, since it's difficult to modify it.
I still haven't set up a CVS for your FAT code... oh well.
#46769 - chishm - Thu Jun 30, 2005 10:43 am
I forgot the lowest bit address line is not connected. After experimenting with it I have found the following about reading the firmware:
1) Once it is locked, it will not unlock until the power has been removed for a sufficient time (a few seconds)
2) Once it is unlocked, it remains unlocked (see above)
3) It becomes locked by reads to memory outside a certain range
4) If the firmware is locked, not even booting normally will work
5) If the firmware is unlocked and a soft reset is issued it will boot normally, however if it is locked the GBA will freeze (see #4)
Does a soft reset actually execute the entire boot routine again or does it simply jump back to 0x08000000? How could I force a jump to 0x0800000 without a reset?
Darkfader:
I have looked at your flashing code, and from what I see the flash addresses are not mapped sequentially to the GBA bus. That is the flash address lines are not connected in ascending order to the GBA address lines, even with the non connected A13, A14 and A15. Is this correct?
And does this mean that if a block of data is written to the flash chip properly it will appear scrambled when accessed from the GBA?
If I flash my GBAMP using your tool, do you currently have a way to recover back to the normal firmware without using Repair.nes?
#46785 - darkfader - Thu Jun 30, 2005 3:17 pm
It's correct that the addresses are scrambled. But it really only affects on how you send the erase and programming codes to the flashchip. I could change the calls to the addresscalculator function with fixed values to make it faster. Then if you write in sequental cart addresses using the GBA/DS, data will be written scrambled in flashchip. And this vice-versa of course.
And yes, I do have a backup of the data and could also restore it.
#46812 - chishm - Fri Jul 01, 2005 2:10 am
| darkfader wrote: |
Anyway, it's unlocked by only the init sequence that GBA BIOS makes, since I can read everything fine using my own app that I flashed.
Perhaps it's not just the sequence, but also some low-level thingy.
|
Can you explain this to me. Say you overwrite the firmware completely, including the header. What happens when you try to dump it without the BIOS unlocking it first? Is it still locked? And say you have changed the header so that the startup read sequence is changed. Does it still unlock properly? I am just trying to figure out whether it is a specific sequence of reads by the BIOS that unlocks it, as opposed to the timings of the reads.
EDIT:
I have worked out how to jump to the cart start without a reset. Here is the code I use:
| Code: |
// Jump to cart start
asm ("ldr r4, =1<<27");
asm ("bx r4"); |
I know it is not the best way to do it, but it is just a quick way to know that I am not executing any BIOS code before the cart starts.
Using this I have written a program that waits until a cart is inserted before jumping to the start address. The point? Simple, I multiboot the program with no cart inserted, then insert the GBAMP. It boots normally, proving that it is unlocked. What is more is that there is no way that it could possibly have been unlocked by the BIOS, as it is not inserted until the BIOS has finished executing. This shows that the BIOS does not unlock the GBAMP.
Another thing I have done with this is lock the GBAMP.
Executing this code:
| Code: |
for (u32 i = 300; i < 400; i+=2)
temp16 = *((vu16*)(0x08000000 + i));
|
will lock the GBAMP. After those reads have completed it will not boot until it has had time for the power to drain. What's so interesting about this? It seems that rather than the BIOS unlocking the GBAMP, attempts to read it actually lock the firmware. All very interesting...
Last edited by chishm on Fri Jul 01, 2005 5:11 am; edited 1 time in total
#46832 - Dwedit - Fri Jul 01, 2005 5:07 am
Is it possible to read the first 512 bytes from other pages even when it's locked? I remember being able to do that easily.
If so, there should be 16k of rom to play around with!
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#46836 - chishm - Fri Jul 01, 2005 5:21 am
Yes you can read the first 512 bytes every 0x4000 bytes. There are 32 such pages available. This gives us 16K to work with. The only problem is that the firmware happens to store bookmarks in some of those pages, so it is too dangerous to use the normal firmware at the same time (if this is even possible)
More info on locking / unlocking: Before the firmware is locked or unlocked reads to memory outside of the first 512 bytes result in 0 data. Reading certain addresses will lock it though, so you have to be careful. If only I could work out how to unlock it.
#46955 - darkfader - Sat Jul 02, 2005 5:06 pm
The fail-safe part is 32KBytes. And I got the unlock sequence too :P
I'll put it into the flashing tool...
#46975 - chishm - Sun Jul 03, 2005 12:23 am
| darkfader wrote: |
The fail-safe part is 32KBytes. And I got the unlock sequence too :P
I'll put it into the flashing tool... |
So what is the unlock sequence? Is it done by the BIOS or by the firmware? I'm really curious about this one. I've spent ages trying to figure it out, as you can probably guess from my previous posts.
#46981 - darkfader - Sun Jul 03, 2005 1:31 am
Got something upped to that CVS.
Do you have MSN/IRC ? :)
#47091 - chishm - Tue Jul 05, 2005 1:59 am
| darkfader wrote: |
The fail-safe part is 32KBytes. And I got the unlock sequence too :P
I'll put it into the flashing tool... |
I have checked it out. It works quite nicely. You can shrink that unlock sequence down to 108 bytes if you wanted to. You only need to do a 32 bit read with every first out of two addresses. You can also store each read address as a byte shifted down by 1. It is then possible to unlock the entire firmware from code within the first 512 bytes.
There are a few tricks to this, though. First, you will have to read the data backwards, from halfwords 510 down to 250 (aprroximately). If you tried to read it in ascending order you will lock the firmware. Then you will have to run the unlock code from RAM, as running from ROM will cause additional reads, ruining the unlock sequence (you probably knew this).
#47121 - darkfader - Tue Jul 05, 2005 12:59 pm
Ok, changed to bytes now.
I could make my loader use the flash so it doesn't get in the way when loading programs to RAM, but putting on CF is more versatile so I'll stick to that.
I continued my FAT driver a little more and can read long filenames. yay....
#47160 - DiemetriX - Tue Jul 05, 2005 11:23 pm
So how long do you think it's before we can boot homebrew from the MP via software or Wifi Darkfader?
_________________
www.home.no/diemetrix/1337.htm
#47193 - zubiac - Wed Jul 06, 2005 7:45 am
| DiemetriX wrote: |
| So how long do you think it's before we can boot homebrew from the MP via software or Wifi Darkfader? |
yeah I wonder that too.
This will be so roxor cause after frying 2 GBA flash cards in a row(>_<) I'm not willing to spend another 100euros for another flash card.
My GBAMP sits here with 5 different CF cards and has no real job yet(beside watching "Powerpuff girls").
I can't thank darfader and chism enough for hacking the GBAMP cause it will save tons of people's money once released.
I ?know for sure that the first thing I will do(once the hack works) is FINALLY flashing the hacked firmware(FlashMe) on my DS.
_________________
Abusing Cube and DS with all sorts of homebrew and hacks.
#47319 - chishm - Thu Jul 07, 2005 10:46 am
| darkfader wrote: |
Ok, changed to bytes now.
I could make my loader use the flash so it doesn't get in the way when loading programs to RAM, but putting on CF is more versatile so I'll stick to that.
I continued my FAT driver a little more and can read long filenames. yay.... |
While I was trying to figure out the firmware unlock sequence I was disassembling the firmware startup. In the first 512 bytes it sets up the display and stack (unimportant) but the reads it does from the cart obviously unlock it. It then copies the rest of the firmware "cluster" (from 512 B to 4 KiB) to EWRAM and jumps there. This part basically DMAs the next cluster to IWRAM (which is where the update code is) then jumps to it.
My point? At the moment you are only using the first sector of the firmware for your boot loader, which limits its abilities like you rely on there being startup code in the MBR of the CF card. However, since the first cluster only loads the second cluster there should be more than enough space to check the CF card for a boot loader file. If it doesn't find a boot loader, it can then continue loading the GBAMP software. This retains the functionality of the GBAMP while incoporating a DS loader.
#47320 - zubiac - Thu Jul 07, 2005 12:00 pm
| chishm wrote: |
| My point? At the moment you are only using the first sector of the firmware for your boot loader, which limits its abilities like you rely on there being startup code in the MBR of the CF card. However, since the first cluster only loads the second cluster there should be more than enough space to check the CF card for a boot loader file. If it doesn't find a boot loader, it can then continue loading the GBAMP software. This retains the functionality of the GBAMP while incoporating a DS loader. |
So the original GBAMP firmware will still survive after the hack?
which means: you are still able to use the MP for its purpose?
wow just wow. awesome if true
_________________
Abusing Cube and DS with all sorts of homebrew and hacks.
#47362 - skabio - Fri Jul 08, 2005 3:09 am
It appears that the new version of the movie player, M3, is about to be released.
http://www.m3adapter.com/
It looks like it now supports full gba and nds games and emulators as well as saving. There are now apparently separate versions for the gba and nds. No sign of how much they will cost however.
?
#47389 - chishm - Fri Jul 08, 2005 2:38 pm
Okay, after some more testing, it seems that the GBAMP firmware is more sensitive to changes to the boot cluster than I thought. Replacing the boot cluster with custom code, even if it emulates the firmware, does not work. Trying to jump immediately after the GBAMP jumps to the loading code does not work.
I have managed to insert my own code. To do this I insert my code at offset 0x3CA0. Then I change the BX at 0x023C to a B to my code. Once the code is finished running I then BX to 0x03000000.
Problems:
This limits the custom code to 0x360 bytes in size, much smaller than originally hoped, but still bigger than before. It also could create problems when running in DS mode. I cannot test this as I don't have a pass through, but the more code executed that was meant for the GBA, the more likely it is to freeze.
Benefits:
You can still use the GBAMP for its original purpose. It is also completely compatible with the updates. Also, depending on the code, this may be the only time a hack needs to be applied, as it can load the rest from the CF card.
#47581 - chishm - Mon Jul 11, 2005 1:05 am
Okay, I have written my own bootloader. It will run _BOOT_MP.GBA from the root directory. If the file is not found then it runs the normal firmware. _BOOT_MP.GBA is simply a multiboot compatible rom. I have used it with TOD (great game), PocketNES and some custom code. I have not been able to test it in DS mode (see above post) but it won't work anyway, as it is using the GBA IWRAM.
Quick question:
1) What is the easiest way to detect if it is running in DS mode?
2) What happens if I try to use the GBA IWRAM address (0x0300:0000) in DS mode?
#47583 - tepples - Mon Jul 11, 2005 1:31 am
REG_VCOUNT will go from 0 to 228 in GBA mode or 0 to 262 in Nintendo DS mode.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#47589 - chishm - Mon Jul 11, 2005 3:48 am
| tepples wrote: |
| REG_VCOUNT will go from 0 to 228 in GBA mode or 0 to 262 in Nintendo DS mode. |
Unfortunately that would require me to monitor REG_VCOUNT to check its values, or use an interupt to check it. I was wanting something like a memory address that has one definite value on the GBA and another on the DS.
EDIT: Now posted in DS forum.
I have also managed to hijack the GBAMP bootloader ealier on. Now it will jump to my code right after loading it. This should increase the compatibility with DS mode, as less code is executed.
#48048 - dovoto - Sat Jul 16, 2005 5:05 pm
I just ordered my gbaMP and would like to encorperate this fat code into libnds. I would also like to get it up and running for booting nds files with some form of multiboot loader.
Could someone explain the general process required to reflash the firmware and to modify it for my own purposes (including what ever links are appropriate)
...Idealy I would like to use Chishms but with a slight modification that it boot _BOOT_MP.gba or _BOOT_MP.ds depending on the mode it detects. (I assume this is also Chishms goal). It should not be too difficult to detect DS mode and if you have not allready found a simple enough way then i can look into it.
I am basicaly going to use this device for testing in hopes of developing my own SD based equivalent that will include natriums serial port. Hopefully everything will fit flush inside the the gba cart as apposed to hanging out like the MP.
_________________
www.drunkencoders.com
#48074 - darkfader - Sun Jul 17, 2005 12:19 am
:(
#48075 - dovoto - Sun Jul 17, 2005 12:21 am
darkfader if you have a more interesing idea for getting access to CF than putting the code in ndslib please let me know...I am pretty lazy when it comes down to it so if prevents me from having to import and test the source code I am all for it.
_________________
www.drunkencoders.com
#48079 - darkfader - Sun Jul 17, 2005 12:41 am
Ideally, I would like to put the system calls on the movie player itself. I think I have some generic way to make the system call stub. It would be nice if it worked for both gba and nds libs.
#48080 - dovoto - Sun Jul 17, 2005 1:02 am
hmm...a generic method would be nice although i am not sure exactly how you would go about implementing it with the code on the CF firmware. Would this aid us in getting generic file access so we can use fopen("wifi:/dir/file.txt", "w") and
fopen("gbamp:/dir/file.blah", "r") and
fopen("nds:/dir/blah.blah", "wb") ...
?
_________________
www.drunkencoders.com
#48081 - chishm - Sun Jul 17, 2005 1:10 am
| dovoto wrote: |
I just ordered my gbaMP and would like to encorperate this fat code into libnds. I would also like to get it up and running for booting nds files with some form of multiboot loader.
Could someone explain the general process required to reflash the firmware and to modify it for my own purposes (including what ever links are appropriate)
...Idealy I would like to use Chishms but with a slight modification that it boot _BOOT_MP.gba or _BOOT_MP.ds depending on the mode it detects. (I assume this is also Chishms goal). It should not be too difficult to detect DS mode and if you have not allready found a simple enough way then i can look into it.
I am basicaly going to use this device for testing in hopes of developing my own SD based equivalent that will include natriums serial port. Hopefully everything will fit flush inside the the gba cart as apposed to hanging out like the MP. |
To flash the GBAMP firmware, you will need Darkfader's flashing tool. It is in the tools section of the DevKitPro CVS, under Tools\nds\bootstrap\flashmp.
My firmware is already doing that, but it has a few bugs that need to be fixed. The FAT code still has a few bugs, but you can add it to libnds. However, it would probably better to add it as a separate part of DevKitPro, because it is for both NDS and GBA roms.
I have worked out how to detect DS mode, with the help of tepples. It is based on the principle that the byte at 0A00:0000 will be different depending on whether it is in NDS or GBA mode. This requires that there is no SRAM on the cart.
#48082 - dovoto - Sun Jul 17, 2005 1:14 am
| chishm wrote: |
| To flash the GBAMP firmware, you will need Darkfader's flashing tool. It is in the tools section of the DevKitPro CVS, under Tools\nds\bootstrap\flashmp. |
Thanks :)
| chishm wrote: |
My firmware is already doing that, but it has a few bugs that need to be fixed. The FAT code still has a few bugs, but you can add it to libnds. However, it would probably better to add it as a separate part of DevKitPro, because it is for both NDS and GBA roms. |
This sounds good to me although not sure if this is the same thing as DarkFader was suggesting. Would be nice to see a few smaller libraries pop up for general utility.
| chishm wrote: |
I have worked out how to detect DS mode, with the help of tepples. It is based on the principle that the byte at 0A00:0000 will be different depending on whether it is in NDS or GBA mode. This requires that there is no SRAM on the cart. |
Nice
_________________
www.drunkencoders.com
#48086 - darkfader - Sun Jul 17, 2005 1:38 am
It's not the same thing.
Bah. I can't seem to be able to unlock the flash somehow. Although it works in my flasher :(
#48089 - chishm - Sun Jul 17, 2005 2:46 am
| darkfader wrote: |
It's not the same thing.
Bah. I can't seem to be able to unlock the flash somehow. Although it works in my flasher :( |
How exactly are you trying to unlock it? From the firmware itself, or from a multiboot binary loaded with the GBAMP sitting idle in the slot?
I am having troubles with my firmware hack. It consistently works using WifiMe, but doesn't work with FlashMe. It also only seems to work with homebrew software, not commercial demos.
#48100 - darkfader - Sun Jul 17, 2005 4:19 am
Oh... I now edited 3 words like you said and added some code to go to GBA mode @ 08000200 and it worked :)
Guess it cannot be unlocked even with that long unlocking sequence after it has been locked by a wrong reading order.
@dovoto:
What do you think about linux-style path? Using /mnt/ for stuff :)
/mnt/ndssave/
/mnt/gbasave/
/mnt/save/ (auto link to either nds- or gbasave)
/mnt/nds/ (nds file system)
/mnt/mp/ (media player, CF/SD... normally mounted as root)
/mnt/mpflash/ (rom file system)
Perhaps not as flexible and might clutter the tree... hmm... or perhaps an option to make them hidden :)
I'll think about it some more after I got something working at least...
#48103 - tepples - Sun Jul 17, 2005 5:00 am
A better syntax for wifi (once someone disassembles SM64DS) would be fopen("http://host/dir/file.txt", "r"), no?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#48107 - chishm - Sun Jul 17, 2005 5:24 am
| tepples wrote: |
| A better syntax for wifi (once someone disassembles SM64DS) would be fopen("http://host/dir/file.txt", "r"), no? |
Should that be "wftp://host/dir/file.txt"?
http = hypertext transport protocol
wftp = wi fi transfer protocol or wireless file transfer protocol
Maybe we could just use UNC for everything, with each nds assigned a unique name. This could be confusing, but I'm just thinking what the best method would be.
Ideally, all file drivers (GBFS, GBAMP FAT, NDS) would use the same naming convention, for files and functions, so that it is easy to switch between them.
#48108 - tepples - Sun Jul 17, 2005 5:28 am
| chishm wrote: |
| tepples wrote: | | A better syntax for wifi (once someone disassembles SM64DS) would be fopen("http://host/dir/file.txt", "r"), no? |
Should that be "wftp://host/dir/file.txt"?
http = hypertext transport protocol
wftp = wi fi transfer protocol or wireless file transfer protocol |
Wouldn't FTP over TCP/IP over Wi-Fi just be FTP over TCP/IP over Wi-Fi?
| Quote: |
| Maybe we could just use UNC for everything, with each nds assigned a unique name. This could be confusing, but I'm just thinking what the best method would be. |
Super Mario Brothers Protocol?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#48110 - chishm - Sun Jul 17, 2005 6:02 am
| tepples wrote: |
| Wouldn't FTP over TCP/IP over Wi-Fi just be FTP over TCP/IP over Wi-Fi? |
It wouldn't necessarily be FTP. It may end up being a custom protocol with a server running on the PC. However, it would probably be better just to use FTP, for compatibility.
On the other hand, the protocol should not need to be specified. Depending on the host being accessed, the driver would choose the protocol invisibly to the caller.
#48112 - tepples - Sun Jul 17, 2005 6:16 am
| chishm wrote: |
| On the other hand, the protocol should not need to be specified. Depending on the host being accessed, the driver would choose the protocol invisibly to the caller. |
That would work only if the hostname starts with "www" or "ftp" or the like. Or would it portscan the host, looking for HTTP then FTP then whatever? Or if I'm missing something fundamental, what am I missing?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#48914 - chishm - Sun Jul 24, 2005 3:13 am
Tepples:
Well if it is accessing files within a game then it is always going to be ftp. If it is browsing web pages then it is always going to be http. If it is accessing the CF card then it will always be file. Maybe the protocol should be optional, just in case the caller wants to access the file in a specific way.
#48916 - tepples - Sun Jul 24, 2005 4:39 am
| chishm wrote: |
| Well if it is accessing files within a game then it is always going to be ftp. If it is browsing web pages then it is always going to be http. |
HTTP is in general a more efficient protocol than FTP, as FTP has much more setup and teardown per file. HTTP uses only one connection, unlike FTP which uses one connection for commands and another for each file transfer. Even for larger files, notice that most commercial sites that offer files for download offer them over HTTP rather than FTP.
Here is a Slashdot thread debating the merits of HTTP and FTP.
| Quote: |
| If it is accessing the CF card then it will always be file. |
Granted, but the name 'file' is also associated with UNC paths to CIFS resources.
| Quote: |
| Maybe the protocol should be optional, just in case the caller wants to access the file in a specific way. |
Most files can be accessed only in a specific way. How would you suggest to guess the protocol given the rest of the URL?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#48918 - dovoto - Sun Jul 24, 2005 4:49 am
I would like to see explicit paths for the filesystem.
_________________
www.drunkencoders.com
#48928 - chishm - Sun Jul 24, 2005 6:46 am
| tepples wrote: |
| Most files can be accessed only in a specific way. How would you suggest to guess the protocol given the rest of the URL? |
If URLs are used for every file access, then accesses to the CF card could only be file, for instance. What I am saying, is that rather than having to explicitly specify the protocol for every file access, some (like the CF card) could be implicit in the URL.
However, you make a good point, and explicit protocol specification is a lot better for reducing ambiguity, but less efficient. Say I wanted to access a specific file, but I don't know where it is. If the user of the program pointed to the location then rather than the program trying to figure out which protocol to use, the file driver could.
#49068 - binarystatic - Tue Jul 26, 2005 4:41 am
im a noob when it comes to cvs, is there any easy way to download all associated files with the flashmp other than manually recursing through every directory and downloading each file one by one? or does anyone have a pre-compled version of flashmp?
#49076 - chishm - Tue Jul 26, 2005 6:41 am
I will include an NDS version in the next release.