gbadev.org forum archive

Quote:

Hi ,
We did our best to finish doing new G6 /M3 FAT lib V3 for the developers.
Please download here .
www.handheldsources.com/Backup/G6M3 FAT32Lib_V3 13-10-06.rar
Regards
Danny

_________________
Private property.
Violators will be shot, survivors will be shot again.

Quote:

Hi ,
We did our best to finish doing new G6 /M3 FAT lib V3 for the developers.

Try harder, still no source for the G6 driver.

I wonder what their though process is:

Quote:

Let's just slip an io_g6.o, maybe they wont notice it's binary and not source.

Also, I didn't look too hard, but I think it's compiled with a different compiler than the latest devkitarm, which means it won't work too well, if at all, with new apps which are written.

Why are they so against releasing the code? Seriously, anyone who wants to haxor their cart can, from disassembling the driver, but it's a big hurdle to any legit developers who just want to write some app which is compatible with it.

Corporate culture of some kind, possibly...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

well ask for the source again

This one (io_g6.o) is at least compiled with devkitarm, the earlier ones that have been circulating were compiled with one of the commercial compilers (ADS 1.2 if I'm not mistaken) and had a whole different ABI.

In other words, with this one there is actually a chance of it working. But we still need the source, badly, to be able to support G6 in a good, reliable, fashion. (I don't see how it would harm anyone if G6 was supported by the homebrew out there.)

Who is it that we should try to convince to release these sources? :)

hawk wrote:

Who is it that we should try to convince to release these sources? :)

danny@g6flash.com

Yep, it works allright. Tested on 19b. Anyone care for a port from asm to C?

Puyo wrote:

Yep, it works allright. Tested on 19b. Anyone care for a port from asm to C?

I didn't get as far as to actually test it yet, good to hear that it works!

And yes, disassembling that object file and reimplementing it in C is of course a possibility (and also extremely tedious)...
But what would the legal status be of this supposed reimplementation? Would it be alright?

Anyway, it would clearly be much easier if they would release their sources for it... But then of course, if they put some nasty license on it, it may be impossible to include it anyway.

(Speaking of licenses, maybe Chism should have put the fat library under the LGPL or something like that instead?)

pepsiman wrote:

hawk wrote:

Who is it that we should try to convince to release these sources? :)

danny@g6flash.com

Ok, another mail pestering danny about the sources coming right up... :)

hawk wrote:

And yes, disassembling that object file and reimplementing it in C is of course a possibility (and also extremely tedious)...
But what would the legal status be of this supposed reimplementation? Would it be alright?

If developer Poo translates the disassembly into an English specification, and user Chi translates the English specification into C without seeing the original disassembly, then (at least in the United States and other countries with a similar interpretation of the idea-expression divide) the clean room rules are satisfied. Of course, if you plan on selling anything, talk to your lawyer first.
_________________
Driven from Tilwick by ice storms, couldn't fit in in Flower Bud...

Nintendo DS: With two ARMs, who needs legs?

So, reverse-engeneering the firmware to get drivers is legal, but disassembling that object file is not? I don`t understand this.
But still do we realy need it to be translated to C? Is it possible to implement it in Chism fatlib in it`s current state?

Puyo wrote:

So, reverse-engeneering the firmware to get drivers is legal, but disassembling that object file is not?

(In USA) Disassembling the object file and giving it to the public is not legal without a specific license.
_________________
Driven from Tilwick by ice storms, couldn't fit in in Flower Bud...

Nintendo DS: With two ARMs, who needs legs?

Puyo wrote:

But still do we realy need it to be translated to C? Is it possible to implement it in Chism fatlib in it`s current state?

We definitely need source code to get it integrated into anything. And having it in C would be much preferable to asm as it's just so much easier to work with (especially in the long run).

Some update:
After a bit of testing i came to this conclusion:
1)Read code works flawlessly
2)Write code doesn`t work at all, even more - it sets G6 in some WriteProtectDisable state, so only full memory wipe helps unlock it.
3)The only homebrew I could compile to test is PicoDriveDS & it worked, except the savestate features.

Have to fiddle with it some time to get this write code working.

we need emails for the actual developers dane has no idea about any thing dev related

I'm not sure that the developpers of G6 Fatlib speak English...

Lord Raptor wrote:

I'm not sure that the developers of G6 Fatlib speak English...

Well they code ASM and C which both use English so they must have at least a basic English knowledge

Puyo, what do you mean with "so only full memory wipe helps unlock it. ", can we do that ourself ?

Link_of_Hyrule wrote:

we need emails for the actual developers dane has no idea about any thing dev related

You can ask danny to forward email to developers. He forwarded my email month or two ago but I never got an answer.. Maybe someone of you can tell them more clearly what we need.

I'm afraid they perfectly know what we want : source code for G6 Fatlib, but obviously they don't want to give it :(

I hope i'm wrong...

Quote:

Well they code ASM and C which both use English so they must have at least a basic English knowledge

Exactly these 2 languages rely less on English words. Although labels in their code seem very reasonable to me.

alekmaul, it`s Start-Select-A-B combo at the screen with green text. The problem is that it takes about 11 min to reformat G6 with MPutility.

The most interesting thing that I found was that inside of G6 is a Samsung Nand flash memory chip, which is the main memory chip. So the idea is that all the G6 does to control it, is mapping the adress, data & command pins to the own registers (just like efa2). So now after finding these registers I could send commands & get responses from that chip. The main problem is that after writing, the values sometimes doesn`t change or change in a very strange way. I looked through the writing code (asm) & my guess would be that it uses something called ECC (error corection code), but I really don`t know much about what that could be. Maybe somebody here could lead the way for me?

I must say that I have a hard time believing that they haven't understood what it is that we're asking for.

It seems that they are just not interested in providing this source code. (Well, actually it appears that the code might not be finished, as has been noted the write code doesn't seem to work.)

Very interested in hearing about any progress, Puyo.

Well G6 seems to be most advanced card of them all.
Ported reading code. Trying to contact chishm for implementation specs.

Lord Raptor wrote:

I'm not sure that the developpers of G6 Fatlib speak English...

We have a few Japanese speakers here.
_________________
I'm a PSP hacker now, but I still <3 DS.

Puyo wrote:

Well G6 seems to be most advanced card of them all.
Ported reading code. Trying to contact chishm for implementation specs.

Thank you for your efforts, Puyo !

Yes, great to hear that you've been making some progress.

I found chishm highly contactable before, so that shouldn't be much of an issue, I think.

Great work Puyo!
I'm sure there are quite a lot of people who are most thankful and appreciate what you're doing.

Yeah, great work Puyo.
But do you know why the actual version put the G6 in the WriteProtectDisable state ?

alekmaul wrote:

But do you know why the actual version put the G6 in the WriteProtectDisable state ?

Don`t worry, there won`t be any writing code. Therefore it`s not possible to end up with the given state.

Puyo wrote:

Ported reading code. Trying to contact chishm for implementation specs.

any news on this?

Well, kinda sent him a working version & forgot about this :).
You can just wait for update of fatlib.

Or as alternative you can download update files for latest ( 20060813 ) fatlib here & recompile it.

And to all developers that use gba_nds_fat, you can download update files here.

Tested on G6Lite 4G. Please report any bugs.

/Puyo/

Great news !

Thank you again for all your efforts !
I hope read tests on G6 Lite will be ok, so we may have a partial G6 support in official homebrews...

Any news from Team G6 about the infamous write bug ?
Does the WriteProtectEnable function allow to avoid it ?

just recompiled scummvm with G6 support .. it works fine!!!
nice work .... looking forward of inclusion of this code in libfat ...
thank you Puyo!!!

if someone wants to test but can't compile here is dsdoom and scummvm compiled with Puyo's code for g6
http://theli.ho.com.ua/ds/dsdoom_G6.7z
http://theli.ho.com.ua/ds/scummvm_g6.7z

theli wrote:

if someone wants to test but can't compile here is dsdoom and scummvm compiled with Puyo's code for g6
http://theli.ho.com.ua/ds/dsdoom_G6.7z
http://theli.ho.com.ua/ds/scummvm_g6.7z

Thanks!
Now i can finaly use dsdoom and scummvm :)
but can you please make a g6 version of DSorganise.
the source is here: http://www.dragonminded.com/ndsdev/DSOrganize_Src.zip

Thanks,
Stefan

Wow! Thanks! =D Great work!
Puyo, are you planing to write code for writing to G6?
And are you russian? =)

Sorry for my english.

Quote:

Puyo, are you planing to write code for writing to G6?

No, i`m not. =)

Puyo wrote:

Quote:

Puyo, are you planing to write code for writing to G6?

No, i`m not. =)

;-(

once again, many thanks puyo!
and thank you theli for the compiles!

Could someone help us out how to boot DoomDS on our G6? I'm just getting a black screen with the text "Survived graphic init".
I've transfered the .nds file with U-disk manager and moved manually the .cfg and .wad file to the root.

Looking forward to play this game on ny DS, thanks you all for the great work!

Dasone : you shouldn't transfer the .nds file with U-Disk Manager. Use windows explorer instead.

Tried that too, but it still dosen't work. The same text shows on the screen "Survived graphics init." I have all the file in root meny and got firmware 4.6c installed. I've even formated my G6 reasently.

I'll check for DSDoom...

For the moment, I've been busy trying ScummVM DS, and it works pretty well.
Day Of The Tentacle and Sam & Max work, but I have no speech, and the music makes the game very choppy... Does anyone have the same problem on G6 Lite with the scummvm compiled by theli ?

Anyway, good work, theli ! And thank you to have informed agentq about Puyo's G6 FatLib.

EDIT :
Same problem here for DSDoom : stuck after "Survived graphics init."
Survived not very long ;)

thats strange .. i have doom running well...

i've transfered it with manager ...
(using "direct copy" method (you should transfer SvummVM in same way so that manager would create save files) .. actually it's the best way to transfer homebrew to G6 (when it comes to sram saves) )

and i have
doom.wad
PRBOOM.CFG
prboom.wad

in root directory.... no problems at all :)

Ok, I'll try using this method !

Did you try ScummVM DS with DOTT or S&M ?

I can't save data with scumm. I used "Direct copy" on manager, can any one help me? or its imposible to save/load data?

I've reversed the writing function (as well as every functions in io_g6.o) for the G6 but I broke my G6L (don't walk on them they don't like that at all!) so I cannot test it .
Puyo can we work together to finish this ?

Viruseb

Noone thought of getting the registers from the firmware? as the firmware is able to handle SRAM, and read/write *.0-2 files with the SRAM data, you should be able to disassemble it and get what you need ;)
im just too n00bish to do it myself

Kenny - the sram writing is not the issue, that works if you add using game manager. It's the FAT writing.

Works OK with Sam n Max Talkie - but use SOU file and not SO3...

Last edited by scandal_uk on Mon Dec 04, 2006 8:24 pm; edited 1 time in total

Also - you must select Force R/W when you add the ROM in the game manager - or the Write won't work....

At least - once you get the write code in the fatlib. ROMs that require writing will just black screen if you don't patch the ROM as r/w using the game manager.

I'm available to test anything on the G6 lite - I am a programmer but I have little or no time to code a new project. Maybe in the new year I'll have more time to look into coding for the DS.

DSDoom still not working. Stuck again after "survived graphics init".
What happens after ? I think it's media detection/initialization, isn't it ?
I'll try again, but I have similar problems with MarcaDS and CrocoDS which both use Puyo's G6 FatLib...

But ScummVM DS works perfectly... The speech problem was coming from the fact I used monster.sog file which isn't supported by the DS version (my bad ! It's written in ScummVM DS mainpage !)

viruseb : great news ! (not the destruction of your G6 Lite, but the reverse engineering ;) )

I'm releasing the work I've done on R/W the G6L. Keep in mind that as I have no G6 at the moment so the code is not tested (it compils but that don't prove anything).
I've checked my code against the one Puyo released so I think the reading part is working. The writing part is an another question since if I made a mistake all chances are that you have to format your G6 or worst brick your G6. YOU HAVE BEEN WARNED.
In normal circunstance I would have done the test myself, I'm leaving it to you (until I buy a new G6). So test this code thoroughly, I'm here for any questions.

Download io_g6.c
Download io_g6.h

Good Luck !

We should ask Danny to test it on its own G6s ;)

viruseb wrote:

I'm releasing the work I've done on R/W the G6L.
Good Luck !

is it for gba_nds_fat or fatlib?

Mmmh after careful thinking I think a low level format with MpUtility will suffice if the code screws something. No way to brick the flash IMHO (but who knows...).

theli wrote:

viruseb wrote:

I'm releasing the work I've done on R/W the G6L.
Good Luck !

is it for gba_nds_fat or fatlib?

For gba_nds_fat.
By the way what is the difference ? (well I thought it was the same thing, I'm kinda a noob in NDS scene).
Anyway we can released the code for fatlib once the code is tested or if its needed I can transpose the code for fatlib for testing (once I know the difference).

scummvm compiled with your code doesn't work at all

theli wrote:

scummvm compiled with your code doesn't work at all

That's normal enough for the first run of a code. The thing is were the bug is ? I'll try to make some test programs today to test the code step by step.
Argh, I feel so helpeless without my G6 !

viruseb.. you can contact me in jabber theli@jabber.kiev.ua or ICQ 101915541 so i can help you to test if you want

viruseb : can't you ask Team G6 to provide you with a brand new G6 Lite ? After all, you're doing their job with the FatLib driver, and I think they would be pleased if you can achieve it... (as well as every G6L owners ;) )

Lord Raptor wrote:

viruseb : can't you ask Team G6 to provide you with a brand new G6 Lite ? After all, you're doing their job with the FatLib driver, and I think they would be pleased if you can achieve it... (as well as every G6L owners ;) )

But why they didn't provided the scene the informations needed to make the driver ? I read some post saying that mails asking those informations were dead letters.
I'm not so sure they want someone to put the specs of their G6 into the open and wild. So I guess they won't be pleased if someone can achieve it. But I'm loosing nothing to ask a new one for free.

You're right.

They are very uncooperative when it comes to FatLib driver.
I wonder if anyone already asked them why...

Thank to the enormous help of Theli and after a tedious day of remote debugging, we manage to get the G6 and its fat table recognized by fatlib in dsboom.
Reading still have problems and writing was not tested. If someone is willing to help I encourage him/her to test if the LookUpTable generated with my code and the one generated with Puyo's code is different. Also DMA transfers doesn't seems to work.

http://www.filecrunch.com/file/~9m9wss

Wow! I`m really impressed! You have a lot of nerve there viruseb.
Reversing & porting all of the code even that`s not used.
I can`t believe it. Documentation!! Just where the **** you were before? We could create a wiki there ;).
You even calculated LookUpTable formula. And discribed spare sector format.

Related to writing - how can you be sure that the writing function is correct? I mean the original one. It`s just wierd cos if you wanted to write 1 byte, the code would rewrite the whole block. Would that be a reliable system? Probably there is some protection mechanism. Gotta be sure before continuing. Do you have any docs related to NAND programing?

Still, very nice work indeed.

DMA doesn`t work in FATlib, chishm confirmed this, remove it from use with the define.

I bought a nds 4 month ago so I was nowhere to be seen before :)
I already used nand flash device for project so I had a fair idea what they are doing in the assembly.
Concerning the writes functions it the exact reversing of the ones in the object files and for this I'm sure of it. Even if I think they tried to obfuscate the code. Of course it's bugged because I surely misinterpreted a number of tests but the execution flow is ok.
The writing is done one a sector basic and yes if you change only one sector a whole free block (worth 256 sectors) is taken, data copied from the old to the free block (but internally in the flash so its' quite fast) and our sector data is overwritten. If you want to write one byte there is the writewordunction. And believe me it's much more reliable to do this way because ecc can be recalculated.

If you want you can download the nand datasheet here http://www.samsung.com/products/semiconductor/NANDFlash/SLC_LargeBlock/4Gbit/K9K4G08U0M/K9K4G08U0M.htm

Don't hesitate to ask any questions. This is the least I can do now.

All modern hard disks I know of write only entire sectors at a time. The solution has always been caching; keeping the disk data in memory (any reads taking the cached data when available before falling back to disk reading) and writing it back to the disk when the file is closed, system is shut down, etc. The only downside to this is you have to be sure the cache is flushed before powering off, which isn't a huge problem since the DS can soft-shutdown and most programs should be able to get away with just flushing when a file is closed. (I think even gba_nds_fat does this.) Whereas the upsides include increased performance and a lot less writes to disk which is very important on a flash medium which can only handle a few million writes (or as little as 100,000 in some cases) or a hard disk that has to seek back and forth for each write.
_________________
I'm a PSP hacker now, but I still <3 DS.

Quote:

If you want you can download the nand datasheet here

I already studied that. It covers the low-level, like command descriptions & how to use them. Doesn`t describe on how to implement programming process. Forget about this, I already got that from your source (some issues are still present).

After thinking over that WriteProtectEnable state I mentioned previosly, I now understand that`s not the case, simply because it is volatile 8). I think it`s ecc generation code, that you marked as possible deadlock. Although the function returned after some time, I think it was marking all sectors as defective. That explains why I couldn`t write to G6 neither in windows or on DS. Avoiding this should solve the locking problem.

Quote:

The solution has always been caching

Caching... How didn`t i thought of this before :). I thought it was only used for reading, for faster access. The only problem i see is flushing before the console is powered off. What do you mean by soft-shutdown? Does DS somehow inform program that it`s shutting down?

Oh, and we have exactly the case - 100,000 writes & unreplaceable memory. So writing should be handled as with much care as possible.

Puyo wrote:

After thinking over that WriteProtectEnable state I mentioned previosly, I now understand that`s not the case, simply because it is volatile 8). I think it`s ecc generation code, that you marked as possible deadlock. Although the function returned after some time, I think it was marking all sectors as defective. That explains why I couldn`t write to G6 neither in windows or on DS. Avoiding this should solve the locking problem.

You mean that the WriteBlockFunction they provided is defective ? That possible cause I found it weird the code doesn't calculate the ECC by himself but use something provided by the FPGA.
I'd rather prefer supress this portion of code (the one I marked as deadlocking) and do the ECC calc ourself. But we don't know the spec of the ecc...

Puyo wrote:

What do you mean by soft-shutdown?

Software can turn the system off without any user interaction. You'd just present a "Shut down" option in your program that flushes cache and powers off, instead of using the actual power button, just like a PC.
_________________
I'm a PSP hacker now, but I still <3 DS.

Any news on this ?
How can we help ?

I've bougth a new G6, I'm waiting the parcel for now...

Hope you'll get it for Christmas :)

Theli, could you send me the zipped ds doom project we used for debugging ?
Thanks

sooo where are all the ports?! :)

Received a new G6 this morning, back to work :).

also here to test any time :)

New guy to the forum thats curious when it comes to coding (that will eventually maybe try to learn some) signs up for testing some different ports/apps/games using this new information (can you call the lib for that?).

Since I enjoy homebew and have been interested in and used it since I got my G6 Lite for about five months ago I thought that aiding you magnificient developers on this forum is the least I can do.

So I'll keep my eyes open for new homebrew to test.

/Mirakel_Jocke

I've debugged the reading functions. It appears that gcc is not very fond of u64, making some strange conversion sometime.
Anyway if you can test this dsdoom version for G6, it's working on my ds (don't forget to add doom.wad in you root directory).
suppressed, bugged version
Now some cleanup, optimizations... of reading code. Next writing function.

Arrr, I break the user agrement by not giving the io_g6 code.... well wait a little bit it's coming.

ps : Of course no warranty whatsoever, don't complain if your ds melts in your hand.

Last edited by viruseb on Sat Dec 23, 2006 11:36 am; edited 1 time in total

Having some problems getting the doom.wad down at a decent speed, but as soon as it's down I'll test the G6 L DSdoom verision.

(And it is the doom1.wad that I'm looking for and is then supposed to rename to doom.wad right?)

/Mirakel_Jocke

mirakel_jocke wrote:

Having some problems getting the doom.wad down at a decent speed, but as soon as it's down I'll test the G6 L DSdoom verision.

(And it is the doom1.wad that I'm looking for and is then supposed to rename to doom.wad right?)

/Mirakel_Jocke

You're right

The reading code is stable enough now. The reading speed without using DMA is about 2Mo/s so I think it is more than enough.

Download io_g6.c

Thank you again for your efforts, viruseb !

EDIT :
DSDoom : still stuck after 'survived graphics init.'... I'm starting to hate G6 Lite...

viruseb : can you compile a ScummVmDS version with your G6 FatLib driver please ? It's the only version I know to have worked on my G6 using G6 FatLib driver... (DSDoom, CrocoDS and MarcaDS never worked on my G6).

the dsdoom I've posted is working on a G6 with a lot a free space because of a bug.
I can compile it with the new version along with scummvm but as I'm in holiday and nowhere near my computer for 2 weeks I can't do it easely.
Anyway I'll try cause it's Chrismas isn't it :)

What do you mean by 'lot of free space' ? I have 40MB free. Isn't it enough ?

Anyway, I'll try to free more space on my G6...

EDIT :
doesn't work with 200MB free... I feel it's more a device initialization bug than a free space problem...

Last edited by Lord Raptor on Sat Dec 23, 2006 10:58 am; edited 1 time in total

I mean that the doom.wad must be in the first 512 block of the device to work (ie 512*64*2048=67Mo). No worry I'll recompile doom with the good io_g6.c in the next few minutes...

Download dsdoom.nds

EDIT : which version fo scummVM ?

Last edited by viruseb on Sun Dec 24, 2006 10:53 pm; edited 4 times in total

Quote:

which version fo scummVM ?

The one compiled by theli (page 3 of this thread).
I think it was a 0.9.1, but I'm not sure...

Debugging writing code is going to kill me, each time I test something my G6 is good to be formatted... (meaning I can write something but alas not the good thing).
And it's slow because each time you want to write one sector it is the whole block (256 sectors) which is replaced. Usually we can reprogramm 4 times a page without erasing but have to check where is this information (in the out of bound data I think).

Lord Raptor wrote:

Quote:

which version fo scummVM ?

The one compiled by theli (page 3 of this thread).
I think it was a 0.9.1, but I'm not sure...

i've compiled http://prdownloads.sourceforge.net/scummvm/scummvm-0.9.1.tar.bz2?download
as i remember

How stupid I am ! I didn't see you've released a new version of DSDoom, viruseb.

This one works with my G6 ! Great work !

Did you use the io_g6.c you provided here ? http://www.filecrunch.com/file/~ihwybp

Lord Raptor wrote:

How stupid I am ! I didn't see you've released a new version of DSDoom, viruseb.

This one works with my G6 ! Great work !

Did you use the io_g6.c you provided here ? http://www.filecrunch.com/file/~ihwybp

yep

theli wrote:

Lord Raptor wrote:

Quote:

which version fo scummVM ?

The one compiled by theli (page 3 of this thread).
I think it was a 0.9.1, but I'm not sure...

i've compiled http://prdownloads.sourceforge.net/scummvm/scummvm-0.9.1.tar.bz2?download
as i remember

Could you do it again ? I've some difficulties to pass the make configure.

viruseb wrote:

Could you do it again ? I've some difficulties to pass the make configure.

here you go ;)
http://www.filecrunch.com/file/~7ed6y4

theli wrote:

viruseb wrote:

Could you do it again ? I've some difficulties to pass the make configure.

here you go ;)
http://www.filecrunch.com/file/~7ed6y4

Working, nice !

theli and viruseb, thank you alot for this nice christmas present !

Scumm starts fine on my G6, but when I choose "add game...", nothing appears in my directory :(

MoonShell Ver1.6beta5
G6L support... *finally*
Thanks Virus...

Yeah, Moonshell is using the DLDI drivers now, so it finally supports the G6, among other devices.

well I cant get the Doom game to work.I have downloaded the G6 lite version in placed Dsdoom.nds,DOOM1.WAD,And prboom.cfg but when I load the Dsdoom file it say's CHECKIWAD: IWAD tag \doom.wad not present.

Any help why isnt it working?
_________________
Nintendo ds (PHAT) =Silver= Flashme V.7
G6 lite/Passcard 3 (512MB Built-in memory)
GBAMP V.2 SD/ 1 GB SD card/Passcard 3
Gp2x/ 2GB SD Card
PSP V. 2.71(Memory card Broken)

seems to work fine for me!

more non-working homebrew ports please :)

Killamurk07 wrote:

well I cant get the Doom game to work.I have downloaded the G6 lite version in placed Dsdoom.nds,DOOM1.WAD,And prboom.cfg but when I load the Dsdoom file it say's CHECKIWAD: IWAD tag \doom.wad not present.

Any help why isnt it working?

rename doom1.wad to doom.wad
_________________
GTAMP.com/DS

Thx that worked!
_________________
Nintendo ds (PHAT) =Silver= Flashme V.7
G6 lite/Passcard 3 (512MB Built-in memory)
GBAMP V.2 SD/ 1 GB SD card/Passcard 3
Gp2x/ 2GB SD Card
PSP V. 2.71(Memory card Broken)

Hi guys, back from Romania I've some (4 exactly) days left before working again. I hope to get the writing code working by then.
Happy new year and all.

viruseb wrote:

Hi guys, back from Romania I've some (4 exactly) days left before working again. I hope to get the writing code working by then.
Happy new year and all.

nice to hear from you :) .. we're waiting for any news ;)

sorry for a silly question but how do u incorporate the 2 files for g6 into the fat library prior to compilation?

Too bad, I just managed to get my first sector written that my new G6 (3weeks of activity) is now mute to any writting. Windows format and MpUtility doesn't work. So no further advance until I find a way to recover the full functionnality of the flash.
Someone have encountered such problem ?

@marovada : I think now you can use the dldi patching system so don't bother about incorporating the 2 files, just patch with the G6 dldi.

Viruseb check out the M3-Forum (google around a bit to find it). It has a guide to fixing the G6).
_________________
[ Crimson and Black Nintendo DS Lite | CycloDS Evolution | EZ-Flash 3-in-1 | 1 GB Transcend microSD ]

MaHe wrote:

Viruseb check out the M3-Forum (google around a bit to find it). It has a guide to fixing the G6).

Thank you so much you save my day !
I didn't known the L+R+select+start to format the G6 with the DS.

K back to work.

Don`t write to the 0-100 sectors, because that`s where the boot sector & fat table resides. And I would recommend you to not to touch spare part, because you can only view them on DS. Also ECC is only used by PC, so data may be different for DS & PC if you won`t edit ECC accordingly. For ECC algorithms look for "samsung_new_ecc_for_512byte_256word.c" on samsung`s site. It`s almost correct.
Then about writing. I don`t know if this is the main idea of nand, but you can only turn 1 bits to 0 bits when writing. That`s why all the unused (clean) sectors initialised with $FF value. And that`s why you have to erase block before using it. On clean sectors you can use standart programming routines (80h - LTadress - Data - 10h) and get the correct results. I didn`t understood how to use this 4 times writing before erasing, but when you try to write over values that have been written you get something like this: WrittenValue=OldValue AND NewValue.
Hope that helps.

Puyo wrote:

Don`t write to the 0-100 sectors, because that`s where the boot sector & fat table resides. And I would recommend you to not to touch spare part, because you can only view them on DS. Also ECC is only used by PC, so data may be different for DS & PC if you won`t edit ECC accordingly. For ECC algorithms look for "samsung_new_ecc_for_512byte_256word.c" on samsung`s site. It`s almost correct.
Then about writing. I don`t know if this is the main idea of nand, but you can only turn 1 bits to 0 bits when writing. That`s why all the unused (clean) sectors initialised with $FF value. And that`s why you have to erase block before using it. On clean sectors you can use standart programming routines (80h - LTadress - Data - 10h) and get the correct results. I didn`t understood how to use this 4 times writing before erasing, but when you try to write over values that have been written you get something like this: WrittenValue=OldValue AND NewValue.
Hope that helps.

Thank puyo I'll check for the ECC on samsung site. There is also some code in the linux tree about this. What do you mean by "it's almost corect" have you tested the result of the code against the ECC that ECCcodecommand give ? The weird thing is when I dump the extra buffer (where the ECC is supposed to be stored) I found no difference whatever the data. And also ECCcodeCommand seem to give always the same result.
But I'm not sure that you can only convert the '1' to '0' have to read a bit about this.

No, I wasn`t testing it by ECCcommand. Writing in windows produces ecc too. Then I compared it with the ecc produced by same data on PC. It was ok, for the most of times I checked. But i`m really confused here, because for describing 512 bytes (1 sector) you need only 3 bytes of ecc. And I can confirm that from 16 bytes of spare data that described 1 sector last 3 bytes was ecc data. So this doesn`t go right against yours 8 bytes per sector.

Quote:

The weird thing is when I dump the extra buffer (where the ECC is supposed to be stored) I found no difference whatever the data.

Are you sure that data that you changed is in the same page?

viruseb wrote:

Too bad, I just managed to get my first sector written that my new G6 (3weeks of activity) is now mute to any writting. Windows format and MpUtility doesn't work. So no further advance until I find a way to recover the full functionnality of the flash.
Someone have encountered such problem ?

@marovada : I think now you can use the dldi patching system so don't bother about incorporating the 2 files, just patch with the G6 dldi.

viruseb, the rom I am using doesn't support dldi. It is SNEmulDS:

http://snemul.free.fr/ds/

I have told the developer (on his forum) about your great work and about the dldi patching but he hasn't responded yet.

SNEmulDS is a DS SNES emulator with the best game compatibility (because it is based on an already functional ms-dos version) but I have a G6 card, therefore I have to use the GBFS version (instead of the FAT version) which doesn't have save state support (I like playing Civilization on the DS, which is terrible without save state support).

The developer is trying to fix this. His source code is available to download.

I can code in C but I'm an amateur and I don't think I'm capable of fixing the code myself. I was thinking that the 2 files you posted for G6 may be easy to incorporate into the FAT lib prior to compilation.

Also, someone on the SNEmulDS forum suggested using Moonshell changes to FAT for g6: see

http://boards.pocketheaven.com/viewtopic.php?t=5029

This may help you if you are not already able to download the Moonshell changes.

Thanks - sorry for the sob story.

Marovada

Puyo wrote:

Are you sure that data that you changed is in the same page?

I put a big file full of random numbers into the G6 and when I check the spare buffer for all the pages that the file is stored I find no change.

For me they use 3bytes ECC per 256bytes because on their writing function to write a sector they write 256byte of data and take 3byte ecc of it and then write the other half of the sector and take 3byte ecc.

Quote:

No, I wasn`t testing it by ECCcommand. Writing in windows produces ecc too. Then I compared it with the ecc produced by same data on PC.

So if I understand well you write something into the G6 using the U-disk and compare the ECC you found in the spare buffer and the result of the samsung code.

I'm thinking of something maybe my G6 was messed up by all the test writing I've done. I'll check again with a low formated G6.
EDIT : after formatting it's ok. The ECC inside the flash and the ECC given by samsung are equal.

Last edited by viruseb on Sat Jan 06, 2007 3:10 pm; edited 1 time in total

marovada wrote:

viruseb, the rom I am using doesn't support dldi. It is SNEmulDS:

http://snemul.free.fr/ds/

I have told the developer (on his forum) about your great work and about the dldi patching but he hasn't responded yet.

SNEmulDS is a DS SNES emulator with the best game compatibility (because it is based on an already functional ms-dos version) but I have a G6 card, therefore I have to use the GBFS version (instead of the FAT version) which doesn't have save state support (I like playing Civilization on the DS, which is terrible without save state support).

The developer is trying to fix this. His source code is available to download.

I can code in C but I'm an amateur and I don't think I'm capable of fixing the code myself. I was thinking that the 2 files you posted for G6 may be easy to incorporate into the FAT lib prior to compilation.

Also, someone on the SNEmulDS forum suggested using Moonshell changes to FAT for g6: see

http://boards.pocketheaven.com/viewtopic.php?t=5029

This may help you if you are not already able to download the Moonshell changes.

Thanks - sorry for the sob story.

Marovada

Ok so the better is IMHO that they add the support of DLDI to Snemulds. But for now G6 driver is still read only so I don't think that the save states will work.

Per 256 bytes you say? Than i think the format of spare data for 1 sector is:

Code:

1-6 bytes : ??? (bad block info)
7-8 bytes : SuperBlock
9-11 bytes : ECC for first part
12-13 bytes : SuperBlock
14-16 bytes : ECC for second part

And maybe you should use "samsung_new_ecc_for_256byte.c" instead.

Quote:

So if I understand well you write something into the G6 using the U-disk and compare the ECC you found in the spare buffer and the result of the samsung code.

Correct.

endianess aside I agree with your spare buffer organization Puyo. What do you mean by superblock ?

And good new I've got a dsdoom version with savegame working ! I still have some bugs when I want to write big files (>>size of a block) but I'm not worried by that.
The bad new is that the writing code is sloooooowwww, about 30ko/s...
Two reason for this slowlyness. First the code to use the hardware ECC (Ecccodecommand function) is not working so I have to calculate it with the samsung code. Second the fact we have to write an entire block for even a single byte.

I've just tested Moonshell latest version on my G6 and it works flawlessly.

I've also tested again ScummVM compiled by theli, with io_g6 from Viruseb : scummvm-B and scummvm-C seem to work well, but scummvm-A doesn't work (nothing appears in my directory) Very strange... I think it's a compilation mistake or something like that. I'm still confident, as DoomDS and Moonshell work on my G6.

viruseb : the saving speed shouldn't be a big issue for the moment as most of the homebrew write very little on cards (except FTP utilities).

viruseb wrote:

Ok so the better is IMHO that they add the support of DLDI to Snemulds. But for now G6 driver is still read only so I don't think that the save states will work.

viruseb,

the DLDI page says:

"If you are still using gba_nds_fat, you can use a backported IO_INTERFACE. Copy it to your gba_nds_fat source directory and add io_dldi as the first driver in the initialization list."

The first part is easy. But in which file do you add io_dldi as the first driver in the initialization list?

Thanks

viruseb wrote:

Second the fact we have to write an entire block for even a single byte.

Caching would solve this, if it can be done with DLDI.
_________________
I'm a PSP hacker now, but I still <3 DS.

HyperHacker wrote:

viruseb wrote:

Second the fact we have to write an entire block for even a single byte.

Caching would solve this, if it can be done with DLDI.

libfat does sector caching, so writes are less excessive. I'd be very careful with any driver-level caching, as the shutdown function is only called when the partition is unmounted, and clearStatus is intended for recovering from an error state.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

chishm wrote:

libfat does sector caching, so writes are less excessive. I'd be very careful with any driver-level caching, as the shutdown function is only called when the partition is unmounted, and clearStatus is intended for recovering from an error state.

I will not implement any sort of catching but something bother me. If the user can switch off the DS with the poweroff button anytime how can we be sure that we have flush the cache in time ?
Anaway I've still an annoying bug to solve before bothering with catching.

viruseb wrote:

I will not implement any sort of catching but something bother me. If the user can switch off the DS with the poweroff button anytime how can we be sure that we have flush the cache in time ?

The cache is flushed when a file is closed or when a directory is created. Control is not passed back to the app until the file is written. It is at this time that a "DO NOT TURN OFF POWER" message should be displayed.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Here we go, I give you a dsdoom with writing support for testing. It's slow (10sec for saving sigh..) but it's working (well at least on my ds).
Of course no warranty. If something gets wrong don't panic just push L+R+select+start during the green screen in GBA mode to wipe out the flash memory, then format, then MpUtility. So save your games before !

Download dsdoom.nds

I'm cleaning the code by now and I have some questions. Are the buffers always word aligned ? There is #define _CF_ALLOW_UNALIGNED which is always commented so I guess yes.
Also libfat supports DMA ?

Have (safe) fun !

Great job - Works very nicely on my G6 - Only 10 mins testing but I rebooted several times and the saves came back every time very nicely. The slight pause when saving is no issue.

I think DoomDS 1.0.1 had a feature so that I did not have to type anything into the save name? All my saves were '2Y' in this version ;)

Thanks so much for all the work that you put in on this. I for one really appreciate it.

Tolax

And now the dldi for G6 and its source.
I'll try to improve the writing speed in the next version. But don't expect miracle....

Download g6fl.zip
Download g6fl.dldi

I already tested it with Moonshell and no problem whatsoever.

Great work viruseb!!

is anyone able to add DLDI to the source for Snemulds?

The source is available here: http://snemul.free.fr/ds/

viruseb wrote:

Are the buffers always word aligned ? There is #define _CF_ALLOW_UNALIGNED which is always commented so I guess yes.
Also libfat supports DMA ?

No they aren't always word aligned, which can become a real problem if you assume they are. DMA is possible but I advise against its use. You'll often be transfering small (halh KiB) blocks of data, the ARM9 cache will need flushing/invalidating, and you need to wait for the transfer to be complete anyway, negating any gains from concurrently running the transfer.

EDIT: Great work on the DLDI. I'll update the web page when I can.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

hm .. dsorganize not working for me with this dldi :(
hm .. and neither with previous :D

and moonshel isn't working with this one too :(

chishm wrote:

No they aren't always word aligned, which can become a real problem if you assume they are. DMA is possible but I advise against its use. You'll often be transfering small (halh KiB) blocks of data, the ARM9 cache will need flushing/invalidating, and you need to wait for the transfer to be complete anyway, negating any gains from concurrently running the transfer.

EDIT: Great work on the DLDI. I'll update the web page when I can.

Thanks, exactly the informations I needed to finish the transfer functions.

Last edited by viruseb on Thu Jan 11, 2007 9:24 am; edited 1 time in total

it seems i've figured issue

You're a genius, viruseb !

best! will test out everything when i get home after work (in approx 10 hours) :(

viruseb wrote:

And now the dldi for G6 and its source.
I'll try to improve the writing speed in the next version. But don't expect miracle....

This is in fact the miracle I didn't expect. Seriously, I can't wait to get my replacement G6 now. Many thanks to you, Viruseb! You are my homebrew hero.

I have made some improvements and bugs corrections. Unaligned R/W is supported and I'm using cache programming (writing a page while transfering another) for some speedup.

Download g6fl.dldi
Download iointerface.c

A question for chishm. When I want to write 256 sector at a time, fwrite divide the write in 16sectors chunks. Is there any reasons ?

I'm very happy you keep working on DLDI for G6, viruseb ! Thanks again !

Hope this will solve saving problems with ScummVM DS :)

do you think you could upload it somewhere else because filecrunch doesn't seem to work for me :/
thanks

viruseb wrote:

A question for chishm. When I want to write 256 sector at a time, fwrite divide the write in 16sectors chunks. Is there any reasons ?

Good to see you are still working on this :-)
The write() function (called by fwrite()) writes at most a cluster at a time. Id say that your card is formatted with 8KiB clusters, which is why it'd be writing 16 sectors at a time. You'll only get 256 sectors on a card formatted with 128KiB clusters which, although possible, is very unlikely.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

mobad wrote:

do you think you could upload it somewhere else because filecrunch doesn't seem to work for me :/
thanks

I've tried several times before succeeding in downloading these files from filecrunch. Try again ! :)

Lord Raptor wrote:

I'm very happy you keep working on DLDI for G6, viruseb ! Thanks again !

Hope this will solve saving problems with ScummVM DS :)

I was not aware of this problem... I usually test with moonshell, DSO and DSdoom. Have to take a look at this.

Last edited by viruseb on Sun Feb 04, 2007 11:51 am; edited 1 time in total

Lord Raptor wrote:

mobad wrote:

do you think you could upload it somewhere else because filecrunch doesn't seem to work for me :/
thanks

I've tried several times before succeeding in downloading these files from filecrunch. Try again ! :)

If you have a better place (and I'm sure they is) to upload files I'll take it !

If you have problems with ScummVM DS and not other apps, you should probably check that you're not assuming the data is 16-bit aligned. ScummVM uses a lot of serialised objects, and often the pointers are not aligned.

The previous version didn't check for unaligned data so could be the problem.

viruseb wrote:

If you have a better place (and I'm sure they is) to upload files I'll take it !

Gigeshare.com is pretty decent.

Hmmm... Still have problems with ScummVM DS
In both versions (0.15 and 0.16) of G6 DLDI, ScummVM succeeds in creating configuration file (scummvm.ini) on my G6L.
With 0.15 version, ScummVM writes an (about) 100 Kb savegame file on my G6L for DOTT, but is unable to read it after
With 0.16 version, ScummVM writes a 0 Kb savegame file (tested with DOTT and Sam & Max)

I have transfered ScummVM DS to my G6L with the U-Disk Manager, using Direct Copy option.
Maybe I've done something wrong ?

Lord Raptor wrote:

Hmmm... Still have problems with ScummVM DS
In both versions (0.15 and 0.16) of G6 DLDI, ScummVM succeeds in creating configuration file (scummvm.ini) on my G6L.
With 0.15 version, ScummVM writes an (about) 100 Kb savegame file on my G6L for DOTT, but is unable to read it after
With 0.16 version, ScummVM writes a 0 Kb savegame file (tested with DOTT and Sam & Max)

I have transfered ScummVM DS to my G6L with the U-Disk Manager, using Direct Copy option.
Maybe I've done something wrong ?

mmh, strange. I'll look at this issue this week. I think it's word aligmenent related.
And did your card working perfectly after. I mean did chkdsk complain because of a corrupted FAT/files. Files names in uppercases. Have to reformat your card... ?

My G6L seems to be ok. I've copied some files on it, and played few homebrews, without any problem.

DSLiveWeather doesn't write with 0.16. Program freezes when writing weather data or profile. Works perfectly with 0.15.

Norpa wrote:

DSLiveWeather doesn't write with 0.16. Program freezes when writing weather data or profile. Works perfectly with 0.15.

Ok, then I think I "should" have tested more thoroughly the new dldi :)

I finally found some time to finish the debugging.
I tested this version (V0.17) of g6fl.dldi with :
scummvm v09.1a beta 2 (SAM and DOTT)
dsdoom v1.1.0
dso v2.5
moonshell v1.6
And it works without problems (just a little bit long to save IMO).
So help yourself and report any bugs (and make a backup before).

Download g6fl.dldi
Download g6fl.zip

have fun !

I've seen that 20 or so peoples has downloaded the new dldi, does it mean that it's working ?
If so can you update the dldi homepage Chishm ?

No more problems than before, but no fewer. I'm guessing any problems I'm having aren't with your DLDI patch but with the homebrew itself.

Liquidnumb wrote:

No more problems than before, but no fewer. I'm guessing any problems I'm having aren't with your DLDI patch but with the homebrew itself.

Just to be sure can I know in which homebrews you are experiencing bugs (related of course to reading and writing from/to G6).

DSFTP likes to leave a mess on my card. Works fine most of the time I suppose, but sometimes I write a file that gets broken or it leaves a little mess of gibberish in my directory tree.

DSO has some problems launching code from it's browser which nobody will get back to me about. I'm still lost on that one. I get the usual, super-descriptive error.
"For some reason, the file was not loadable"
I can't even get anyone with a G6 to confirm this feature works or does not work with their card. It happens with anything I launch from DSO, DLDI or not.

Those are the only two problems I can think of with my homebrew that are definitely file system related.

Well, hard to tell who is faulting...
As the reading code is much simpler I would say that your DSO problem is DSO related.
Usually when the writing code is buggy it mess up your card entierely, meaning you have to low reformat it. For DSFTP I really don't know, we'll see if other people complain about it.
Anyway thanks for thoses precisions.

I was using the new SNEmulDS patched with the 0.17 G6 DLDI driver last night and after trying out a few games, the emulator froze up while loading a ROM. I turned my DS off and back on and when I got back to the G6 menu, nothing was showing up either in the main NDS menu or under MyCard (directories were there, but no files showed).

On connecting the G6 to my computer, I found the kind of junk files that Liquidnumb mentioned and which I'd seen two times before since I started using 0.17 (both times were with DSOrganize). Previous times running Scandisk solved the problem, though now I wonder if I shouldn't have reformatted the card as well. Scandisk does not work this time and neither does formating. In both cases the progress bar goes all the way to 100%, but then the blue LED on the G6 U-Disk starts to flash and after a minute or two I get a failure message (specifically, when formatting I get a message that says "Could not write to BOOT"). Trying to simply delete files, folders or anything else from the G6 does not work either. Nor does adding new files. I also tried the G6 Maintenance Utility, but it is not able to format the card, either. FDISK seems to allow me to delete the primary partition, but when I remove and re-insert the cart, everything is still there. In short, nothing seems to be able to affect the cart in anyway.

Of course, I know that this might just be a coincidence and have nothing at all to do with the new DLDI driver, but since I wasn't having any problems with my G6 prior to switching over to 0.17 and directly after that I started getting the garbage files caused by DSOrganize and now this, it seems like I should at least put a warning out.

Either way, I understand the nature of software like this and I knew the risks of using it, so I wouldn't blame viruseb even if it was the G6 DLDI driver that caused this. If I blame anyone other than myself it's the damn G6 Team for not properly releasing the docs for their FAT system.

Anyway, that's the story. Anyone know of a really really low level utility that I might try to see if I can recover the cart? Is it possible that some sort of write-protect bit is turned on? I think the G6 Maintenance Utility is supposed to check for that and that part of the process does seem to work with no issue, so maybe that's not the problem at all.

...word is bondage...

Puyo wrote:

alekmaul, it`s Start-Select-A-B combo at the screen with green text. The problem is that it takes about 11 min to reformat G6 with MPutility.

Try this combo (when entering GBA mode) to reformat your card with your G6 lite.

Sorry for your saves Sweater,
Do as Lord Raptor said at it will work just fine after don't worry.
This kind of bug is typical when the G6 dldi writing code messed up something. But here you were just reading roms so i don't understand how possibly the G6 dldi writes something on your card.
I have to check SNEmulDS to see if it writes something while loading a ROM.
Thanks for reporting bugs

Ps : You were reading or writing something when DSO messed your card ?

Thank you so much Lord Raptor. I hadn't even thought of those button combinations. I've seen people talking about them in the past but since there was never anything wrong with my G6 I didn't pay a lot of attention. The correct button combo for this is actually START+SELECT+L+R to erase the memory not START+SELECT+A+B (which is for updating the firmware). It seems to have worked. At least I was able to format the card in Windows after doing it. I don't have the G6 maintenance utility on this computer and everyone suggests using it after having a problem like this, so I'll wait before trying to re-write the firmware or anything else to the cart, but it seems like this has solved my problem, which is definitely excellent.

I have a Supercard SD as well, but I like the G6 so much better, so I was quite sad about losing it.

viruseb, the previous problems I had when using DSOrganize did come when I was writing (saving PNGs from Scribble). With SNEmulDS, I wasn't writing anything at all, I hadn't even been using save states with the previous games I'd loaded, so I don't know what in your DLDI driver would have caused the problem unless it was just general file system or TOC instability caused by the previous problems I'd been having when using DSOrganize. Either that or maybe it really was just a coincidence. The G6 seems to be prone to the corruption problem judging form how many people have had them. It's just a good thing that the cart almost always seems to be recoverable.

I'm not worried about the saves I lost (a couple, but that's the price of piracy, isn't it?), however I did lose a bunch of custom icon images I'd made for various homebrews. Hopefully I'll be able to recreate them.

...word is bondage...

Sweater Fish Deluxe wrote:

viruseb, the previous problems I had when using DSOrganize did come when I was writing (saving PNGs from Scribble). With SNEmulDS, I wasn't writing anything at all, I hadn't even been using save states with the previous games I'd loaded, so I don't know what in your DLDI driver would have caused the problem unless it was just general file system or TOC instability caused by the previous problems I'd been having when using DSOrganize. Either that or maybe it really was just a coincidence. The G6 seems to be prone to the corruption problem judging form how many people have had them. It's just a good thing that the cart almost always seems to be recoverable.

...word is bondage...

Tell me if you have another problem after reformating your card . Because maybe V0.15 could have corrupted your card in a way that V0.17 revealed it.
I'll make a couple of png tonight :)

I've just tested a bit ScummVM (0-9-1a-beta3), and saves seem to work fine on my G6L (using 0.17 version of DLDI) with Sam&Max and Day Of The Tentacle. The previous version I tested (0.15) never succedeed in writing a correct savefile for ScummVM on my G6L.
Good work viruseb !!

About SNEmulDS, the latest version (0.4 final) automatically saves SRAM contents before loading a rom. Maybe that's what corrupted Sweater Fish Deluxe's G6L...

EDIT :
I've also tested DSFTP.
Transfered 5 pictures on my G6L, each about 2MB. The transfer rate was about 12.4 KB.
At the end of the transfer, my G6L wasn't corrupted nor messed up. My 5 files were present on my G6L with their right size, but I wasn't able to read them with Moonshell nor Paint .NET on Windows. It seems that parts of the files are corrupted.

This happened to me with a Transcend 4GB CF card, and I was never able to get it working again. Nothing could write to it at all. Interestingly, this was a replacement for another one of their cards that had the same problem as well as suddenly shrinking to 2GB.
_________________
I'm a PSP hacker now, but I still <3 DS.

Lord Raptor wrote:

I've just tested a bit ScummVM (0-9-1a-beta3), and saves seem to work fine on my G6L (using 0.17 version of DLDI) with Sam&Max and Day Of The Tentacle. The previous version I tested (0.15) never succedeed in writing a correct savefile for ScummVM on my G6L.
Good work viruseb !!

About SNEmulDS, the latest version (0.4 final) automatically saves SRAM contents before loading a rom. Maybe that's what corrupted Sweater Fish Deluxe's G6L...

EDIT :
I've also tested DSFTP.
Transfered 5 pictures on my G6L, each about 2MB. The transfer rate was about 12.4 KB.
At the end of the transfer, my G6L wasn't corrupted nor messed up. My 5 files were present on my G6L with their right size, but I wasn't able to read them with Moonshell nor Paint .NET on Windows. It seems that parts of the files are corrupted.

If SNEmulDS saves something then Sweater Fish Deluxe bug makes sense to me.
The problem is I can't reproduce the bug. I've done a dozen png using scribble yestersday and no problem. So hard to tell what's going on.

@Lord Raptor : If you still have them can you send me the original and transferred pictures ? Maybe I'll find something.

Ok inside Raptor's pictures sometime a bit is flipped. I have 2 explanations for this.
Either the CRC used by G6 is not exactly the same as Samsung. Leading that the chip erorr correction inside U-disk sometime flip a bit when reading the flash. But what I don't get if why moonshell cannot read those pictures since g6 dldi doesn't check the CRC nor does error correction.
Or it's a wifi problem. I don't know if DSFTP protect the data with a CRC but if not it can be the explanations cause wifi transmissions are not error free. There is about 1 error every 500bytes=4000bit leading to a BER (Bit Error Rate) of 2.5*10^-4 which a lot but not irrelalistic if you have a concrete wall between the ds and the source.
If have a question for Lord raptor. Your files are corrupted after 200Kb, did you move your ds after beginning the transfer ?

I'll do some tests this weekend to see where is the problem.

viruseb wrote:

I have a question for Lord raptor. Your files are corrupted after 200Kb, did you move your ds after beginning the transfer ?

Nope. And I had the same problem with different files transfered at different times.
To exclude wifi problems, I'll try writing some png with DSO.
Also, writing a test program for DLDI could help (ie : writing 1000 '0' in a file, and checking it after)

Lord Raptor wrote:

Also, writing a test program for DLDI could help (ie : writing 1000 '0' in a file, and checking it after)

I've done this kind of apps to test the dldi with random number. I will try with the jpg you give me so I can see if it's a CRC problem or not.
Anyway I'm interested by any bug report so I can track down thoses bugs more easely.

Hi,
I've resolved a bug in the g6 dldi. Lord Raptor reported that the new version works with dsftp. In the mean time I've improved the writing speed (about a 3x factor).

Here you can download the V0.19 of g6fl.dldi.

http://www.gigeshare.com/preview/5dfd8ddc1778d78cfa7nn812a121157c/

As usual make a backup and report any bugs.
Hope this version will be the last !

That's great that you got the writing speed improved.

I haven't had any corruption problems of any sort with the 0.17 version since I did the reformat a couple weeks ago, by the way. Switching to 0.19 now.

...word is bondage...

Just to post the V0.19 source code

Download g6fl.dldi
Download g6fl.zip

Many, many, many thanks viruseb, you're doing a fantastic job!

And good news it works with Dslinux :)

I have stopped finding corrupt bits of data since using the latest version. I thought it was just my g6 crapping out again. Thanks, viruseb!

viruseb wrote:

And good news it works with Dslinux :)

strange .. i still couldn't get linux working with g6 dldi

theli wrote:

viruseb wrote:

And good news it works with Dslinux :)

strange .. i still couldn't get linux working with g6 dldi

I was able to. What went wrong?

well.. obviously DSLinux couldn't mount FS :)

Really impressive work!

I just tried the 0.19 G6 DLDI with ScummVM 0.9.1a and a few other things with great success.

I do however have the same problem as theli with DLinux.
DSLinux (latest dslinux-dldi.tgz as of this posting) fails to mount the flash card.

Quote:

...
hda: unknown partition table
...
mount: Mounting /dev/hda1 on /media failed: Unknown error 6
FAT: invalid media value (0xb9)
VFS: Can't find a valid FAT filesystem on dev hda
mount: Mounting /dev/hda on /media failed: Unknown error 22
...

hawk wrote:

Really impressive work!

I just tried the 0.19 G6 DLDI with ScummVM 0.9.1a and a few other things with great success.

I do however have the same problem as theli with DLinux.
DSLinux (latest dslinux-dldi.tgz as of this posting) fails to mount the flash card.

Quote:

...
hda: unknown partition table
...
mount: Mounting /dev/hda1 on /media failed: Unknown error 6
FAT: invalid media value (0xb9)
VFS: Can't find a valid FAT filesystem on dev hda
mount: Mounting /dev/hda on /media failed: Unknown error 22
...

use the WMB version of DSLinux

I heard that worked for G6

tondopie wrote:

hawk wrote:

Really impressive work!

I just tried the 0.19 G6 DLDI with ScummVM 0.9.1a and a few other things with great success.

I do however have the same problem as theli with DLinux.
DSLinux (latest dslinux-dldi.tgz as of this posting) fails to mount the flash card.

Quote:

...
hda: unknown partition table
...
mount: Mounting /dev/hda1 on /media failed: Unknown error 6
FAT: invalid media value (0xb9)
VFS: Can't find a valid FAT filesystem on dev hda
mount: Mounting /dev/hda on /media failed: Unknown error 22
...

use the WMB version of DSLinux

I heard that worked for G6

But that makes no use of DLDI, does it?

To me the main point was to test the "new" 0.19 version of the G6 DLDI driver.. :)

I'm still puzzled why half of people' G6 doesn't work with dslinux. It would be easier for me If my card also didn't worked but "unfortunately" I have no issue with dslinux.
I'm still beleving it's a partitionning problem but I havn't the faintiest idea of what is going on...

viruseb wrote:

I'm still puzzled why half of people' G6 doesn't work with dslinux. It would be easier for me If my card also didn't worked but "unfortunately" I have no issue with dslinux.
I'm still beleving it's a partitionning problem but I havn't the faintiest idea of what is going on...

When I get home from work I would be happy to try reformatting again and see if I can get it working (I posted on the dslinux forums about this previously).

I used the U-disk manager to transfer the dldi-patched .nds over using the direct copy method. Is this incorrect?

EDIT: Mine is a G6-Lite, the smaller one

Last edited by bnice7 on Tue Apr 10, 2007 8:39 pm; edited 1 time in total

I don't know what's different other than the physical real estate of the parts, but my G6 (which works with dslinux) is an older model. It's a phat version, and it certainly isn't a lite in a phat shell since it takes up all the space in the phat shell.

Besides that and formatting I don't know what could possibly be that different about the cards. My configuration should be stock. I haven't changed anything serious on this one since I got it.

Mine, which doesn't work with DSLinux (but the G6 DLDI generally seems to work fine otherwise), is a "G6 Flash3" 4Gbit card. It's one of the "Lite" ones that don't stick out on the NDS Lite.

Liquidnumb wrote:

I don't know what's different other than the physical real estate of the parts, but my G6 (which works with dslinux) is an older model. It's a phat version, and it certainly isn't a lite in a phat shell since it takes up all the space in the phat shell.

Besides that and formatting I don't know what could possibly be that different about the cards. My configuration should be stock. I haven't changed anything serious on this one since I got it.

I've an another G6 which was recently manufactured I'll try with it tomorrow.

@bnice7 : I usually drag and drop the .nds directly without using G6 U-Disk manager. Another thing to try.

I just copied the file over manually.

For what it's worth, this is what the patching looked like for me, including an md5sum of the untouched and patched .nds file, for comparison:

Quote:

$ md5sum dslinux.nds
2b3ac4cf8c3e4bfb331563867aec626c dslinux.nds

$ ../../tool/linux/dlditool ../../g6_dldi_0.19/g6fl.dldi dslinux.nds
Dynamically Linked Disk Interface patch tool v1.10 by Michael Chisholm (Chishm)

Old driver: Default (No interface)
New driver: G6 Lite DLDI V0.19

Position in file: 0x000BA240
Position in memory: 0x02000000
Patch base address: 0xBF800000
Relocation offset: 0x428BA040

Patched successfully

$ md5sum dslinux.nds
30ce30ab1815d2b9192f5963ca50fb45 dslinux.nds

If you're using the DLDI version of Linux, you need to be sure to copy over the "linux" folder to the root of your card as well. Make sure it has all the correct folders as described in the DSLinux wiki (as some extracters will remove the empty /home/ and /var/ folders that need to be there). I've found that 7Zip Portable works well.

For what it's worth, the DLDI version doesn't work for me on my old Supercard miniSD that does work with the RAM builds.

viruseb wrote:

@bnice7 : I usually drag and drop the .nds directly without using G6 U-Disk manager. Another thing to try.

I dragged and dropped the file, and interestingly it won't even launch unless I use the "Add Header" function. And still no luck loading the filesystem.

The linux folder structure is properly in place in the root dir., including the necessary empty linux/home and linux/var/run subdirectories.

I have the full "linux" directory structure, but the error doesn't look like it's a problem with finding directories, but rather with mounting the filesystem itself.

One thing I just realized is that there is a discrepancy between how my PC sees the partition table on the flash card (through the USB adapter) and how DSLinux sees it.

As seen in my previous post, DSLinux says "hda: unknown partition table" in my case. This suggest that there is no partition table, which I just assumed meant that the filesystem lies on the raw device itself ("hda" rather than "hda1" from DSLinux point of view).

However, when plugged into my PC and checked, there is a partition table (so there should be a "hda1" partition). I guess this might be the problem...?

I've done some test with a brand new g6.
Using dslinux.nds directly copied on a brand new G6 (firmware 4.6C) I have the same errors as bnice7.
Upgrading to 4.7 -> no improvements
Low formating -> Working !

Ok here how I usually reformat my cards :
- Low reformat using L+R+start+select with the DS
- Windows format with fat16 (the right-click format option on your cards drive name in windows explorer)
- MPutility (no options change)
- Windows format with fat16 (yeah again)

Try reformating your cards to see if it's working.

hm .. it worked for me

theli wrote:

hm .. it worked for me

Didn't seem to make any difference for me... Hmm...

Nice, I will definitely try this as soon as I get home and I'll edit this post with my (..hopeful..) success. I didn't realize there was so many steps for a low level format, I assumed the dos fat16 would be plenty.

EDIT: That worked!! Thanks a ton viruseb, I offer my services as a beta-tester for whatever potentially destructive R/W functionality you might come up with in the future :)

I still get the error #6, but everything seems to work just fine.

[quote="bnice7"]
EDIT: That worked!! Thanks a ton viruseb, I offer my services as a beta-tester for whatever potentially destructive R/W functionality you might come up with in the future :)
[quote]

:) I have just in mind to manually replace the 4G flash chip for a 8G flash chip. The firmware should handle it as well as the dldi. I think it is destructive enough ! I have to find a 1Go usb key with an K9K8G08U0M chip before though (It is not the kind of question you ask to the seller, "Did it have a K9K8G08U0M inside?" or " Can I open the key before buy it ?").

viruseb wrote:

:) I have just in mind to manually replace the 4G flash chip for a 8G flash chip. The firmware should handle it as well as the dldi. I think it is destructive enough ! I have to find a 1Go usb key with an K9K8G08U0M chip before though (It is not the kind of question you ask to the seller, "Did it have a K9K8G08U0M inside?" or " Can I open the key before buy it ?").

Hmm, sounds like a plan. I will do some investigating. I actually have a 1GB flash drive around here somewhere. I'll open it up and look to see if it has a samsung IC.

as now dslinux has workign viewml i've trie to test it ... without any success :(
reformtting doesn't help this time
viruseb, are you still working on it?

i've asked a question at dslinux forums and that's what amadeus said

Quote:

I have looked at the sourcecode of the driver. It is buggy.
The author is using DMA for read and write functions, and is not calling the propper data cache flush/invalidating functions.

The DLDI driver in DSLINUX is so "clever" to call the data cache functions for the driver (just in case the driver author has forgotten it), but THIS driver is using DMA for the Nand flash ECC also, and this is nothing a DLDI framework can take care of.

Seems you should give the driver author a hint to improve it...

theli wrote:

as now dslinux has workign viewml i've trie to test it ... without any success :(
reformtting doesn't help this time
viruseb, are you still working on it?

i've asked a question at dslinux forums and that's what amadeus said

Quote:

I have looked at the sourcecode of the driver. It is buggy.
The author is using DMA for read and write functions, and is not calling the propper data cache flush/invalidating functions.

The DLDI driver in DSLINUX is so "clever" to call the data cache functions for the driver (just in case the driver author has forgotten it), but THIS driver is using DMA for the Nand flash ECC also, and this is nothing a DLDI framework can take care of.

Seems you should give the driver author a hint to improve it...

mmh I have not put my nose in the dldi source code recently but I will investigte the case.

That's strange because I don't use DMA at all...

EDIT : Well I didn't rename the R/W functions properly. I use a function called DMAReadWordData() but in fact it is just a direct transfer function. I think it confuses Amadeus.

Anyway something is wrong Theli can you give me some details of the pb?

gbadev.org forum archive

DS development > M3/G6 read/write code

#105937 - LiraNuna - Fri Oct 13, 2006 11:22 am

#105943 - pepsiman - Fri Oct 13, 2006 1:39 pm

#105953 - josath - Fri Oct 13, 2006 4:09 pm

#105959 - OOPMan - Fri Oct 13, 2006 5:46 pm

#106108 - Link_of_Hyrule - Sun Oct 15, 2006 9:45 am

#106367 - hawk - Wed Oct 18, 2006 12:02 pm

#106411 - pepsiman - Wed Oct 18, 2006 7:55 pm

#106418 - Puyo - Wed Oct 18, 2006 8:47 pm

#106435 - hawk - Wed Oct 18, 2006 11:36 pm

#106438 - hawk - Wed Oct 18, 2006 11:56 pm

#106439 - tepples - Thu Oct 19, 2006 12:21 am

#106475 - Puyo - Thu Oct 19, 2006 2:44 pm

#106486 - tepples - Thu Oct 19, 2006 5:21 pm

#106555 - hawk - Fri Oct 20, 2006 3:57 pm

#106640 - Puyo - Sat Oct 21, 2006 9:14 pm

#106962 - Link_of_Hyrule - Wed Oct 25, 2006 7:38 am

#106996 - Lord Raptor - Wed Oct 25, 2006 4:17 pm

#107069 - Normmatt - Thu Oct 26, 2006 5:15 am

#107083 - alekmaul - Thu Oct 26, 2006 11:48 am

#107086 - porkotron - Thu Oct 26, 2006 12:03 pm

#107095 - Lord Raptor - Thu Oct 26, 2006 3:08 pm

#107100 - Puyo - Thu Oct 26, 2006 3:51 pm

#108751 - hawk - Sat Nov 11, 2006 9:44 pm

#108763 - Puyo - Sat Nov 11, 2006 11:18 pm

#108838 - HyperHacker - Sun Nov 12, 2006 8:09 am

#108909 - Lord Raptor - Mon Nov 13, 2006 12:06 am

#109045 - hawk - Tue Nov 14, 2006 11:11 am

#109086 - ne1 - Tue Nov 14, 2006 11:38 pm

#109126 - alekmaul - Wed Nov 15, 2006 9:21 am

#109187 - Puyo - Wed Nov 15, 2006 11:09 pm

#110568 - theli - Wed Nov 29, 2006 9:12 am

#110700 - Puyo - Thu Nov 30, 2006 6:16 pm

#110762 - Lord Raptor - Fri Dec 01, 2006 10:18 am

#110770 - theli - Fri Dec 01, 2006 12:00 pm

#110775 - theli - Fri Dec 01, 2006 1:39 pm

#110846 - monkey1987 - Sat Dec 02, 2006 4:57 am

#110916 - Cluster - Sat Dec 02, 2006 8:56 pm

#110939 - Puyo - Sun Dec 03, 2006 1:49 am

#111011 - theli - Sun Dec 03, 2006 5:05 pm

#111032 - ne1 - Sun Dec 03, 2006 7:49 pm

#111048 - Dasone - Sun Dec 03, 2006 8:36 pm

#111058 - Lord Raptor - Sun Dec 03, 2006 9:17 pm

#111063 - Dasone - Sun Dec 03, 2006 9:52 pm

#111079 - Lord Raptor - Sun Dec 03, 2006 11:58 pm

#111129 - theli - Mon Dec 04, 2006 8:27 am

#111136 - Lord Raptor - Mon Dec 04, 2006 10:18 am

#111186 - qazx - Mon Dec 04, 2006 6:57 pm

#111189 - viruseb - Mon Dec 04, 2006 7:31 pm

#111192 - kenny - Mon Dec 04, 2006 7:56 pm

#111193 - scandal_uk - Mon Dec 04, 2006 7:57 pm

#111194 - scandal_uk - Mon Dec 04, 2006 7:58 pm

#111205 - Lord Raptor - Mon Dec 04, 2006 9:28 pm

#111256 - viruseb - Tue Dec 05, 2006 9:18 am

#111257 - Lord Raptor - Tue Dec 05, 2006 9:31 am

#111258 - theli - Tue Dec 05, 2006 9:52 am

#111259 - viruseb - Tue Dec 05, 2006 9:53 am

#111260 - viruseb - Tue Dec 05, 2006 9:58 am

#111261 - theli - Tue Dec 05, 2006 10:10 am

#111263 - viruseb - Tue Dec 05, 2006 10:26 am

#111264 - theli - Tue Dec 05, 2006 10:36 am

#111273 - Lord Raptor - Tue Dec 05, 2006 11:35 am

#111277 - viruseb - Tue Dec 05, 2006 11:50 am

#111280 - Lord Raptor - Tue Dec 05, 2006 12:12 pm

#111312 - viruseb - Tue Dec 05, 2006 5:21 pm

#111369 - Puyo - Tue Dec 05, 2006 10:58 pm

#111402 - viruseb - Wed Dec 06, 2006 8:20 am

#111410 - HyperHacker - Wed Dec 06, 2006 9:20 am

#111456 - Puyo - Wed Dec 06, 2006 6:58 pm

#111470 - viruseb - Wed Dec 06, 2006 8:54 pm

#111608 - HyperHacker - Fri Dec 08, 2006 9:12 am

#112016 - Lord Raptor - Tue Dec 12, 2006 1:35 pm

#112034 - viruseb - Tue Dec 12, 2006 6:18 pm

#112107 - Lord Raptor - Wed Dec 13, 2006 10:25 am

#112545 - viruseb - Sun Dec 17, 2006 9:03 pm

#112580 - springah - Mon Dec 18, 2006 5:00 am

#112601 - viruseb - Mon Dec 18, 2006 12:35 pm

#112604 - springah - Mon Dec 18, 2006 2:56 pm

#112637 - mirakel_jocke - Tue Dec 19, 2006 1:01 am