--- Log for 22.09.104 Server: leguin.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 26 days and 13 hours ago 00.16.59 Quit ze (Read error: 104 (Connection reset by peer)) 00.20.42 Join ze [0] (psyco@adsl-63-205-43-168.dsl.lsan03.pacbell.net) 00.28.50 Join bagawk [0] (lee@bagawk.user) 00.44.01 # hey midk 00.51.33 *** Saving seen data "./dancer.seen" 01.18.43 Quit bagawk (Nick collision from services.) 01.19.04 Join bagawk [0] (lee@bagawk.user) 01.21.43 Part midk ("Leaving") 01.25.26 Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) 01.25.26 # oops 01.39.32 Part amiconn 01.39.37 # hi midk 01.54.50 Quit bagawk ("Leaving") 02.01.01 Join midk_ [0] (~midk@c66-235-14-120.sea2.cablespeed.com) 02.01.11 Quit midk ("Leaving") 02.01.39 Nick midk_ is now known as midk (~midk@c66-235-14-120.sea2.cablespeed.com) 02.19.35 Quit AciD (Remote closed the connection) 02.51.36 *** Saving seen data "./dancer.seen" 03.02.29 Join ze__ [0] (psyco@adsl-67-123-41-229.dsl.lsan03.pacbell.net) 03.02.47 Quit ze (Nick collision from services.) 03.02.53 Nick ze__ is now known as ze (psyco@adsl-67-123-41-229.dsl.lsan03.pacbell.net) 03.11.39 Quit midk ("Leaving") 03.11.56 Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) 03.19.16 Join frsyj [0] (s336156@student.uq.edu.au) 03.19.30 Quit frsyj (Client Quit) 03.26.07 Quit midk (Remote closed the connection) 03.26.25 Join midk_ [0] (~midk@c66-235-14-120.sea2.cablespeed.com) 03.26.31 Nick midk_ is now known as midk (~midk@c66-235-14-120.sea2.cablespeed.com) 03.49.02 Join frsyj [0] (s336156@student.uq.edu.au) 03.53.45 Join bagawk [0] (Lee@bagawk.user) 03.54.17 # * frsyj is away - Automatically set away. - messages will be saved. 04.27.05 Quit plok ("Leaving") 04.37.15 # back in a bit 04.47.31 # ok 04.51.39 *** Saving seen data "./dancer.seen" 05.01.23 Nick frsyj is now known as plok (s336156@student.uq.edu.au) 05.28.04 Quit bagawk ("umount /dev/brain") 05.44.01 Part scott666_ 06.51.40 *** Saving seen data "./dancer.seen" 06.55.12 Quit midk (Remote closed the connection) 06.58.09 Join LinusN [0] (~linus@labb.contactor.se) 07.03.56 Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) 07.05.17 Quit MrMoo (Read error: 110 (Connection timed out)) 07.07.21 # Linus, I've pulled apart my AJB6k to see if the battery connections need resoldering (battery always drains very fast,unit powers off intermittently). Should I be able to see if the contacts need resoldering or would I not be able to tell just by looki 07.07.22 # ng? 07.11.17 Quit midk (Read error: 104 (Connection reset by peer)) 07.14.43 # plok: bend the small pcb outwards to see if it's firmly soldered to the chassis 07.18.40 Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) 07.21.24 # Aah, I'm at work at the moment, but from memory, when I put the batteries in the small PCB sections were visibly pushed outwards. I will check tonight to see if the connection has been compromised. Thx! 07.22.44 # you're welcome 07.57.33 # \o/ wednesday \o/ 07.59.48 # hooray 08.00.51 # nite 08.01.02 # Wednesday, orange flavored chocolate. Stuff can't be better :) 08.02.07 Join ashridah [0] (ashridah@dialup-a1-377.Melbourne.netspace.net.au) 08.18.03 Quit Nibbler (Read error: 110 (Connection timed out)) 08.21.05 Join amiconn [0] (~jens@pD9E7F048.dip.t-dialin.net) 08.27.33 # funny, since i committed my new adc code, my recorder sometimes senses OFF button keypresses when the drive spins up 08.27.50 # must be some kind of voltage drop when the drive motor starts 08.35.34 # let's hope some button filtering can cure that 08.39.31 Quit plok ("Leaving") 08.49.37 Join plok [0] (s336156@student.uq.edu.au) 08.50.00 Join [IDC]Dragon [0] (~d90a3255@labb.contactor.se) 08.51.09 # <[IDC]Dragon> 'morning! 08.51.43 *** Saving seen data "./dancer.seen" 08.52.02 # <[IDC]Dragon> LinusN: my button filter code needs to get brushed up a bit, it's more alpha than I thought, and for recorder keypad only 08.52.18 # <[IDC]Dragon> so I didn't commit it yesterday 08.53.51 Join Nibbler [0] (~andrer@port-212-202-77-253.dynamic.qsc.de) 08.55.23 # * plok is away - Automatically set away. - messages will be saved. 08.58.38 # [IDC]Dragon: i see 08.59.07 # Has anyone experienced a very "sticky" player button on the archos. Stop and Forward (down and right) are very hard to press/won't spring back into position? 09.04.46 Quit ashridah (Read error: 110 (Connection timed out)) 09.06.42 Join oxygen77 [0] (~Chris@pauguste-7-82-66-87-78.fbx.proxad.net) 09.06.54 # <[IDC]Dragon> LinusN: but the main idea is to check if the last N measurements are stable within a certain corridor, and only than do the range check 09.07.42 # <[IDC]Dragon> I can't explain your OFF button problem, because that's a digital input, lots of margin 09.08.06 # <[IDC]Dragon> (I only filter the channels with multiple buttons) 09.09.28 Join Zagor [242] (~bjst@labb.contactor.se) 09.10.13 # <[IDC]Dragon> hey Björn! 09.12.01 # hi 09.13.36 # [IDC]Dragon: yeah, the OFF button is unrelated to the ADC, so i can't explain the false detection 09.13.49 # unrelated on the v1, that is 09.13.58 # hi Zagor 09.14.34 # LinusN: how frequently does the spurious off occur? 09.15.01 # it seems to only happen when the disk spins up, and it's only occasionally 09.15.25 # happened twice on my 35-minute drive to work 09.15.26 # is it any different if charger is connected or not? 09.15.28 # ok 09.15.39 # i haven't tried with the charger 09.16.05 # people have reported similar problems with the old adc driver as well 09.16.22 # but i haven't seen it on my jukebox until now 09.16.44 # I have only seen ADC problem reports, not GPIO buttons 09.16.45 # i wonder if the adc conversion affects the current draw of the cpu 09.17.04 # spurious OFF events have been reported afaik 09.19.24 # morning 09.19.31 # morning 09.19.42 # Just saw you are talking about the OFF button problem 09.19.52 # My recorder also suffers of this 09.20.00 # v1 or fm? 09.20.09 # Only if battery is below 50% 09.20.17 # and only if disk is spinning 09.20.21 # v1 09.21.12 # i can imagine that it is a problem with inadequate decoupling or something like that 09.22.34 # i wonder if it happens if "disk poweroff" is off? 09.23.19 # hmm, it was already off on my jukebox 09.23.58 # mine too 09.25.29 # for now i "fix: it with turning keylock on :( 09.25.47 # badness 09.26.05 # Do you think it could be a battery problem? 09.26.09 # bad batteries? 09.26.15 # i don't think so 09.26.56 # i still wonder why the faster ADC conversion triggers the problem for me 09.27.06 # I wasn't sure because on disk access my backlight also gets a litte bit darker 09.27.20 # and i can't remember how it was before 09.30.37 # we need to measure the current draw with different AD use 09.34.21 # moin 09.38.27 # <[IDC]Dragon> mabe we shouldn't treat the binary port C inputs as analogue 09.39.48 Join amiconn_ [0] (~jens@pD9E7F0AE.dip.t-dialin.net) 09.42.49 # we don't use port C, we use AN[0-8] 09.43.17 # -7 09.44.48 # [IDC]Dragon: how do you mean? 09.46.47 # btw, for those who don't read the misticriver forum: the ihp100 only has 16MB ram, 120/140 32MB 09.47.28 # aha 09.48.15 # there's also a comment saying 120+ being able to drive a mic in the line-in port, while <120 can't 09.51.14 # Zagor: the analogue inputs can be read "digitally" in Port C 09.53.14 # would work with the ON/OFF buttons on the FMR, and we did that in earlier versions of the Player button code 09.54.05 # however, it is a bad idea to mix the two ways, since the port c bits are invalid during the conversion 09.55.27 # <[IDC]Dragon> LinusN: all of them, or those configured as analogue? 09.55.50 # but since this also happens on v1, which has off on a gpio port, I don't see the relevance. 09.56.22 # <[IDC]Dragon> good point 09.56.32 Quit amiconn (Read error: 110 (Connection timed out)) 09.56.32 Nick amiconn_ is now known as amiconn (~jens@pD9E7F0AE.dip.t-dialin.net) 09.57.39 # [IDC]Dragon: only those that are being converted 09.58.07 # <[IDC]Dragon> which is the whole batch of 4? 09.58.33 # <[IDC]Dragon> even if one inbetween is configured as digital in? 09.58.51 # the docs aren't clear on this, but i wouldn't trust any of the 4 during the scan 09.59.00 # hmm 09.59.01 # * [IDC]Dragon could dig it up in the datasheet, excuse laziness 09.59.23 # only the bits that are included in the scan 09.59.31 # are affected 10.00.00 # btw, there is no digital/analog configuration 10.00.19 # the portc bits are always active 10.00.45 # but the respective bits are invalid during the conversion 10.24.46 # http://daniel.haxx.se/mymake2.patch 10.25.05 # not yet "configure upgrade" compatible 10.25.23 # but a lot simpler makefiles, if I make say so 10.25.29 # may 10.31.05 # testing... 10.31.57 # the goal here is to move platform-specific knowledge to configure or keep in the sources 10.32.18 # Bagder: the current binutils CVS includes the EMAC patch for the coldfire 10.32.29 # neato 10.32.42 # i don't know how well it plays with gcc though 10.32.54 # it'll be exiting 10.33.11 # it seems like gcc 3.4 has better coldfire support 10.33.42 # <[IDC]Dragon> Zagor: I found a buglet in fat.c, panicf("Writing before data\n") doesn't work as intended 10.34.10 Join MrMoo [0] (~me@194.152.87.150) 10.34.41 # <[IDC]Dragon> because start is already offsetted by the partition start, versus fat_bpb.firstdatasector is not 10.35.23 # right, good catch. 10.35.26 # <[IDC]Dragon> I suggest to do the offset within transfer(), not by the caller 10.35.34 # <[IDC]Dragon> saves code, too 10.35.42 # <[IDC]Dragon> mefix 10.35.44 # "Code generation for the ColdFire processors family has been enhanced and extended" (gcc 3.4 changelog) 10.35.46 # good 10.36.10 # hello all, I have a question on wav playback (and I know it's on nodo and that it has been discussed a lot) 10.36.27 # :) ask away 10.36.51 # what I want to know is what is known about code that can be downloaded on the MAS 10.36.55 # (for linav) 10.37.23 # oxygen77: it is possible to d/l code to the mas 10.37.37 # and we have code for WAV playback for the 3507D 10.37.58 # I have also the code for the 3587F 10.37.59 # but that code requires a different h/w configuration than the jukebox has 10.38.12 # oxygen77: nice, can i have it? 10.38.18 # sure 10.38.20 # do you have 3587f dox as well? 10.38.28 # ? 10.38.32 # oh ok 10.38.39 # dox==documentation 10.38.46 # the one from micronas website 10.38.52 # h4ck3r lingo linus ;-) 10.38.59 # the standard data sheets? 10.39.21 # yup 10.39.56 # how is the mas connected to the cpu on the avos? 10.40.36 # <[IDC]Dragon> we'd need a microcode that can take wav input at the serial port 10.40.48 # <[IDC]Dragon> not just parallel 10.41.18 # 2 connections 10.41.19 # <[IDC]Dragon> because out parallel is input only :-( 10.41.26 # <[IDC]Dragon> s/out/our 10.41.37 # the wav code for the mas3507d is serial 10.41.47 # [IDC]Dragon: yes and the serial port is too slow for 44.1 kHz wav 10.42.00 # but it is not using the demand protocol 10.42.00 # parallel and 22c 10.42.02 # <[IDC]Dragon> I'm not sure 10.42.03 # *i2c 10.42.23 # wav playback over i2c? i doubt it 10.42.43 # no but PIO 10.42.53 # i2c is used for control 10.43.09 # <[IDC]Dragon> Zagor: we may use 3 MBit 10.44.37 # LinusN, did you disasm the wav code? 10.44.51 # i have the source 10.44.59 # [IDC]Dragon: how? 10.45.01 # k 10.45.16 # it depends on SDI and SDO having the same clock 10.45.26 # and you konw how it works? 10.45.28 # which it hasn't on the jukebox 10.45.36 # k 10.46.09 # Bagder: i don't think "configure update" is terribly important 10.46.14 # me neither 10.46.26 # its _reaaally_ hard to maintain 10.46.30 # yeah 10.46.35 # so we might be able to write a wav playback module that can use the demand protocol like the mpeg decoder does, but there is no docs on how to do that 10.46.41 # Zagor: I just tried this instead: 10.47.04 # add "2\n\2\nN\n\n" in a file, then run "../tools/configure < file" 10.47.18 # :) 10.47.28 # that is a lot easier 10.51.40 # i worked a little on wav playback some time ago, got some funny noises, but i couldn't figure out how to implement the demand protocol and the buffering 10.51.40 # k 10.51.40 # the wav module from micronas is simply a pass-through device 10.51.40 # yup 10.51.46 *** Saving seen data "./dancer.seen" 10.52.34 # Zagor: and do try my 'make clean' ;-) 10.52.49 # leaves nothing but the Makefile 10.52.58 # that's nice 10.53.11 # commit this, it's better in every way 10.54.26 # Bagder: "clean" is using wildcards? 10.54.32 # no 10.54.38 # just fixed to clean better 10.54.41 # good 10.55.00 # Bagder is a makefile ninja 10.55.59 # Zagor: i want the broken iriver NOW! 10.56.05 # ;) 10.56.17 # Zagor: will you take care of running configure on the automatic builds? 10.57.21 # we could alter the scripts to use the "configure < input" approach isntead of "configure update" 10.57.31 # since the update one isn't working anymore 10.57.33 # yes 10.57.58 # [IDC]Dragon: I now have a strong suspicion what causes the serial mmc communication problems, as I now understand some dirty trick that the archos xfer routines do. Will have to prepare some special test pattern and hook up the scope to verify this 10.58.12 # commit coming up 10.58.56 # done 10.59.00 # echo -e "2\n2\nN\n" | configure 10.59.08 # exactly 10.59.39 # but one return nire, isn't it? 10.59.40 # for language 10.59.46 # s/nire/more 11.00.24 # dine 11.00.25 # done 11.00.46 # gotta go, a little girl is waking up... 11.01.25 # ehe, can't use '2' for all builds ;) 11.01.32 # haha 11.07.30 # LinusN, do you want the code (bin version) of the wav decoder used on av3xx? 11.08.05 Join AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) 11.08.22 # oxygen77: nah, i won't have the time to analyze it, and to be honest, wav playback isn't top priority for me 11.10.39 # k 11.10.41 # <[IDC]Dragon> hey, let's not lose this 11.10.57 # I want to have it work on the av to try ogg playback 11.11.25 # could you send me the source you have? 11.11.36 # oxygen77: hang on 11.11.38 # <[IDC]Dragon> oxygen77: how about putting it intoa twiki page? 11.12.18 # [IDC]Dragon, what do you mean? 11.13.55 # <[IDC]Dragon> we should keep that code 11.14.03 # k 11.14.26 # it's only a bin code directly from archos firmware 11.15.51 # don't put archos code in the wiki. it's not legal. 11.16.14 # yup, that's why I'm asking ;) 11.18.38 Quit AciD (Read error: 104 (Connection reset by peer)) 11.19.29 Join AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) 11.48.35 # <[IDC]Dragon> oxygen77: if nobody wants it, email it to me 11.54.20 # <[IDC]Dragon> Zagor: how strict should I be with my #ifdef HAVE_FAT16SUPPORT ? 11.54.39 # <[IDC]Dragon> right now, I have bracketed every tiny extension 11.55.21 # you mean that the code could coexist without the #ifdef? 11.55.51 # <[IDC]Dragon> we could relax it a bit, leaving afew unused members and statements in case it's not defined (FAT32 only) 11.56.16 # <[IDC]Dragon> LinusN: coexist? 11.56.55 # coexist == both fat16 and fat32 in the driver, without conditionals 11.57.16 # i see no problems supporting both types 11.57.22 # <[IDC]Dragon> if I define HAVE_FAT16SUPPORT, the code can doboth, yes 11.57.33 # the only reason not to would be code size 11.57.38 # <[IDC]Dragon> if I don't define it, it's FAT32 only 11.58.01 # <[IDC]Dragon> yes, in order not to carry ballast for the HD models 11.58.55 # i think you can be the judge of that, whichever you feel is best 11.59.08 # the only problem would be cluttered code 11.59.37 # if there are lots of ifdefs, that is 11.59.40 # <[IDC]Dragon> the I'd commit the strict version first, I can still relax it 12.01.16 # <[IDC]Dragon> thedefine is currently checked at 17 places 12.07.54 # i agree, commit what you have, and we can strip the ifdefs later if we want 12.31.58 Quit oxygen77 (Read error: 110 (Connection timed out)) 12.32.25 Join oxygen77 [0] (~Chris@pauguste-7-82-66-87-78.fbx.proxad.net) 12.47.30 # whoa, $50 donation just came in 12.48.21 # \o/ 12.51.50 *** Saving seen data "./dancer.seen" 12.52.29 # wow 12.54.28 # <[IDC]Dragon> somebody we know? 12.54.50 # <[IDC]Dragon> what's the donation balance, if I may ask? 12.54.57 # i don't know him anyawy :) 12.59.19 # fund balance is about a thousand dollars 13.01.05 # <[IDC]Dragon> not bad for getting some boxes 13.01.29 # no 13.03.05 # <[IDC]Dragon> Zagor: is there some script for the fat test? 13.03.20 # yes, test.sh 13.03.21 # <[IDC]Dragon> like a regression test or so? 13.03.46 # <[IDC]Dragon> oh, I overlooked that 13.05.39 # <[IDC]Dragon> hmm, looks like I can't easily tun that on Windows 13.05.53 # <[IDC]Dragon> s/tun/run 13.06.50 # cygwin should be able to run it 13.07.03 # or even a standalone bash.exe 13.07.16 # <[IDC]Dragon> even building the disk image, mounting it, etc. ? 13.07.33 # ah, no I forgot that 13.07.52 # a great reason to switch to linux ;) 13.08.19 # <[IDC]Dragon> sigh 13.08.56 # <[IDC]Dragon> I once tried, I can say to my defense 13.09.16 # I'm just joking 13.09.20 # <[IDC]Dragon> but knoppix failed to properly install lilo 13.10.17 # <[IDC]Dragon> just a few weeks ago I gave up the 20 GB hole in my HD partitioning, which I reserved 13.11.22 # I'm thinking about displaying last 5 donations on the website. do you think people would mind having their names listed? 13.12.41 # <[IDC]Dragon> as a donator, I would welcome some "official" appreciation 13.13.19 # <[IDC]Dragon> people donate money during TV galas just to see their name scroll through 13.13.28 # [IDC]Dragon: As we discussed the way of browsing both internal & external flash at the same time and I said that I'd prefer the unix way, there is another reason why this way should be preferred: This way, the path /.rockbox would be always valid 13.13.46 # <[IDC]Dragon> Hi Jens! 13.14.03 # <[IDC]Dragon> I'd prefer that way, too 13.19.29 # <[IDC]Dragon> how's th MMC in general? 13.26.10 # [10:58:00] [IDC]Dragon: I now have a strong suspicion what causes the serial mmc communication problems, as I now understand some dirty trick that the archos xfer routines do. Will have to prepare some special test pattern and hook up the scope to verify this 13.26.53 # <[IDC]Dragon> why is the sync mode so tricky? 13.31.13 # Which the SH1 SCI, it is rather tricky to receive well-defined amounts of bytes, because (1) the SH tries to recieve (and clocks the SCI) as long as the receiver is enabled, and then stops on overrun error. (2) the SH SCI uses double buffering 13.31.25 # s/Which/With/ 13.32.28 # <[IDC]Dragon> hmm 13.33.25 # The archos routines use a rather clever trick to circumvent this problem 13.41.40 # <[IDC]Dragon> good that you peeked in... 13.41.56 # <[IDC]Dragon> sorry, I thought this would be easier 14.09.13 Quit MrMoo (Read error: 54 (Connection reset by peer)) 14.22.33 # <[IDC]Dragon> Zagor: the testsuite fails a test 14.22.41 # <[IDC]Dragon> on my FAT16 14.23.10 Join pike|| [0] (amiga@h234n1fls22o1064.bredband.comhem.se) 14.23.17 # <[IDC]Dragon> it's strange, it panics with a non-empty dir entry 14.23.28 # that's what it's for :) 14.23.52 # <[IDC]Dragon> I haven't touched the dir entry handling 14.24.03 # <[IDC]Dragon> otherwise, it went quite far 14.24.13 # try it with a fat32 disk and see if the same thing happens 14.24.35 # <[IDC]Dragon> I have no disk image at hand 14.24.48 # how are you testing fat16 then? 14.25.02 # <[IDC]Dragon> with a FAT16 disk image ;-) 14.25.15 # <[IDC]Dragon> I meant, no FAT32 image at hand 14.25.31 # <[IDC]Dragon> the one I have is the dumped Ondio 14.25.40 # I won't mention linux again, promise :) 14.25.45 # <[IDC]Dragon> ok 14.26.11 Quit pike (Read error: 104 (Connection reset by peer)) 14.26.11 Nick pike|| is now known as pike (amiga@h234n1fls22o1064.bredband.comhem.se) 14.27.16 # <[IDC]Dragon> this will have to wait for later 14.27.47 # if you send me the code I can run some tests 14.28.25 # <[IDC]Dragon> thanks, we'll do that later 14.29.00 # <[IDC]Dragon> I have to mergethe code first, unfortunately the one I modified is 2 revisions old 14.29.33 # ow 14.29.39 # <[IDC]Dragon> that was my working PC simulation, a bit aged 14.30.06 # <[IDC]Dragon> not too bad, I will patch it 14.30.48 Quit Nibbler (Read error: 60 (Operation timed out)) 14.43.57 Join MrMoo [0] (~me@194.152.87.150) 14.51.49 # <[IDC]Dragon> Zagor: I've emailed you the merged fat.c now 14.51.53 *** Saving seen data "./dancer.seen" 14.52.11 Join Poddan [0] (~d9d37d2d@labb.contactor.se) 14.52.17 # tjena alla 14.52.43 # <[IDC]Dragon> tjena Poddan 14.52.46 # vad står MDB för i Sound Settings? 14.53.03 # är det extra bas, eller något helt annat? 14.53.09 # Micronas Dynamic Bass (och prata engelska, det är en intl kanal) 14.53.12 # <[IDC]Dragon> no, I don't speak svenska 14.53.24 # oh sorry xD 14.54.40 # ich liebe apfels! 14.54.57 # <[IDC]Dragon> sorry: Äpfel 14.55.02 # * Bagder ducks to avoid the language throwing ;-) 14.55.16 # are you guys going to stop developing rockbox for archos and just move to iRiver? 14.55.25 # uh 14.55.29 # we support Archos now 14.55.31 # today 14.55.34 # yeah, i know this. 14.55.36 # iRiver is a possibility 14.55.38 # kaboofa: no 14.55.38 # in the future 14.55.39 # AH 14.55.41 # yay! 14.55.52 # * kaboofa does happy fat-polish-kid-dance 14.56.05 # <[IDC]Dragon> Zagor: you'd need to define HAVE_FAT16SUPPORT somewhere suitable 14.56.15 # ok 14.56.17 # * kaboofa goes back to programming :) 14.56.20 # see you all later. 14.57.13 # what do u think the optimal settings on MDB are for Metal, Rock etc? 14.58.26 # it all depends on your headphones/speakers. I use flat for everything. 14.58.58 # I have Sony headphones, the ones that are REALLY comfortable, the ones that look the Koss Plug 14.59.05 # so the bass is really good in those 14.59.24 # EX-70, yes. I use those too. 14.59.42 # nice :D 14.59.57 # no need for bass amplification with those, imo 15.00.06 # that's why I'm trying to configure the sound settings for that perfect sound....but that's just impossible 15.01.05 # maybe because "perfect sound" is subjective? 15.01.39 # subjetive to others, objetive to me! ;-P 15.01.55 # yeah, would be a nice function if u could set the settings for each song :D 15.02.03 # is it called "objective" ? I doubt that 15.02.41 # yeah, objective :D haha, no idea actually 15.02.52 # Bagder: it is 15.03.04 # ok 15.03.15 Join maikeul [0] (~gromit@ALagny-151-1-43-82.w83-114.abo.wanadoo.fr) 15.03.28 # "a. Uninfluenced by emotions or personal prejudices: an objective critic. b. Based on observable phenomena; presented factually: an objective appraisal." 15.04.03 # <[IDC]Dragon> wikipedia? 15.04.20 # dictionary.com 15.05.07 # <[IDC]Dragon> not open, boo 15.05.23 # I like wikipedia 15.05.29 # so happy that I have my Jukebox back...the HD failed on me for about 4 months ago...but now it's upgraded to a 40 GB =) 15.06.15 # open? as in editable? 15.07.03 # <[IDC]Dragon> I thought w're so open here, it'll match 15.08.29 Join elinenbe [0] (~elinenbe_@65.115.46.225) 15.09.04 Part elinenbe 15.09.14 Join elinenbe [0] (~elinenbe_@65.115.46.225) 15.09.19 # yeah, but I don't know of any such open dictionary. wikipedia is more of an encyclopedia. 15.10.50 # wikipedia has a dictionary as part of the site 15.11.42 Quit gromit` (Read error: 110 (Connection timed out)) 15.11.48 # not a good one. try looking up "objective" and get a distinct definition and some synonyms 15.17.32 Quit Poddan ("CGI:IRC") 15.21.34 Join R3nTiL1 [0] (~zorroz@162-250-30-217.kgts.ru) 15.23.22 # <[IDC]Dragon> Zagor: running fat.c already? 15.23.30 # <[IDC]Dragon> ;-) 15.23.49 # * LinusN is checking out binutils from CVS, to fix an assembler bug 15.24.01 # * [IDC]Dragon whistles, looks up in the sky 15.24.26 # <[IDC]Dragon> LinusN: what bug? 15.24.41 # <[IDC]Dragon> what CPU? 15.25.02 # coldfire, internal error 15.25.04 # [IDC]Dragon: sorry, have to do some other stuff first 15.26.41 # <[IDC]Dragon> np 15.33.25 # * oxygen77 is away: chui pas là 15.36.31 Join srn [0] (~82e13707@labb.contactor.se) 15.37.46 # Hi Linus. Why did you change the UDA1380TT Stereo audio coder/decoder info back in the Wiki. Is it not correct that it can NOT decode mp3? 15.39.51 # srn: because the Philips official name is like that. check the philips web page 15.40.05 # none of us believe that it can decode mp3 15.40.17 # yeah, I know but it can confuse. 15.40.42 # never mind, you can change it back if you wish 15.40.43 # well it's a misleading name. just because we know what it is doesn't mean other people will be confused by a chip claiming to be a codec 15.40.55 Join ze__ [0] (psyco@adsl-63-205-43-192.dsl.lsan03.pacbell.net) 15.40.56 # *will not* 15.41.07 # i agree, my bad 15.42.24 # i have reverted my change 15.42.41 # oy, the bleeding build table is confused by all my test builds... :) 15.42.44 # cool, Linux. I am looking forward to hear about the BDM interface - I hope it works. c u :) 15.44.26 Quit srn ("CGI:IRC (EOF)") 15.44.31 # fixed 15.51.28 Quit ze (Read error: 110 (Connection timed out)) 15.51.28 Nick ze__ is now known as ze (psyco@adsl-63-205-43-192.dsl.lsan03.pacbell.net) 15.51.54 Nick R3nTiL1 is now known as R3nTiL (~zorroz@162-250-30-217.kgts.ru) 15.55.54 # * LinusN just fixed his first gas bug :-) 15.56.29 # EMAC register handling bug 15.57.15 # * LinusN is fixing emac bugs with emacs :-b 15.59.07 # gotta go 15.59.09 Part LinusN 16.08.02 Quit R3nTiL () 16.09.13 # <[IDC]Dragon> Zagor: I have a suspicion about the FAT16 bug, because the root dir changes the cluster when it happens :( 16.17.09 # <[IDC]Dragon> grmph, the compiler should warn when I check an unsigned for < 0 16.18.37 # found the bug? 16.19.44 # <[IDC]Dragon> better now 16.20.48 # <[IDC]Dragon> changed the parameter of get_next_cluster() to signed 16.20.58 # ah 16.21.15 # <[IDC]Dragon> it wasn't detecting the root dir case 16.21.32 # * [IDC]Dragon re-runs the suite 16.23.08 # the compiler does warn for that if you pass on pickier flags 16.23.21 # gcc that is 16.23.34 # [IDC]Dragon: Does changing the cluster numbers to signed not break FAT32 compatibility? It would if cluster numbers > (2^31 - 1) are allowed with FAT32... 16.24.51 # yes but 2^31 is 65 TB with 64 sectors/cluster... 16.24.53 # <[IDC]Dragon> no, clusters are 28 bit 16.25.08 # ah, correct. bad memory 16.25.20 # Ah ok. 16.25.29 # <[IDC]Dragon> they are just internally signed, this doesn't go to disk 16.25.42 # Should be called FAT28 then... 16.25.51 # <[IDC]Dragon> :-) 16.26.08 # <[IDC]Dragon> still a lot of data 16.26.17 # luckily, they are not stored with 28 bits each... 16.26.34 # Zagor: you know what debian package that has mkfs.vfat ? 16.26.37 # <[IDC]Dragon> upper 4 are reserved to M$ 16.28.05 # Bagder: dosfstools contains mkdosfs, which is what mkfs.vat uses. can't login to my home machine right now 16.28.21 # (to check if it's changed in unstable vs. testing) 16.28.25 # 8 TB with 32 KB/ cluster. 2 TB is the limit for 32 bit sector numbers anyway... 16.28.41 # * Bagder just upgraded his harddisk 16.28.53 # <[IDC]Dragon> the suite completes now 16.29.00 # excellent 16.29.09 # <[IDC]Dragon> no filesys checks in cygwin, though 16.29.18 # ah 16.29.20 # <[IDC]Dragon> it's just not bailing out 16.29.33 Join methangas [0] (methangas@0x50c61c29.virnxx10.adsl-dhcp.tele.dk) 16.30.00 # <[IDC]Dragon> Zagor: can you remove the unsigned,or shall I send the file again? 16.31.37 # send it again, but I found the machine i use for testing doesn't have vfat in the kernel(!) so I can't test properly until tonight :( 16.33.08 # <[IDC]Dragon> no hurry, while no MMC driver 16.33.54 # <[IDC]Dragon> it'll probably take a while to run, anyway 16.35.42 # Vendor: FUJITSU Model: MHT2080AT 16.35.48 # and it even works! ;-) 16.35.58 # congrats 16.36.23 # I noticed it was a Hitachi I took out 16.38.19 # <[IDC]Dragon> that's a nice one 16.38.28 # <[IDC]Dragon> the new one, I mean 16.39.58 # <[IDC]Dragon> 100GB are outrageously expensive 16.40.44 # indeed 16.41.04 # There are 2.5" 100 GB disks now? 16.41.25 # yes 16.41.40 # about 2 - 2.5 times the price of the 80GB 16.41.59 # Insane :) 16.42.06 # Insane pricing for insane people :) 16.43.21 # <[IDC]Dragon> I payed $1000 for 2GB, 10 years ago 16.44.06 # * [IDC]Dragon stops telling old war stories now 16.46.44 Join Lynx_ [0] (lynx@134.95.189.59) 16.51.55 *** Saving seen data "./dancer.seen" 17.13.36 # * oxygen77 is back (gone 01:40:11) 17.20.46 Join webguest44 [0] (~c71d0602@labb.contactor.se) 17.21.01 Quit webguest44 (Client Quit) 17.21.28 Part Zagor 17.24.58 Join mecraw [0] (~lmarlow@69.2.235.2) 17.43.41 Join teej [0] (~teej@modem-1894.snake.dialup.pol.co.uk) 18.00.18 Quit pike (Read error: 54 (Connection reset by peer)) 18.20.11 Join pike [0] (amiga@h234n1fls22o1064.bredband.comhem.se) 18.25.35 Quit [IDC]Dragon ("CGI:IRC") 18.44.34 Join ze__ [0] (psyco@adsl-67-123-41-128.dsl.lsan03.pacbell.net) 18.51.56 *** Saving seen data "./dancer.seen" 18.59.36 Quit pike ("2.0 Build 3515") 18.59.36 Quit elinenbe (Read error: 104 (Connection reset by peer)) 19.00.00 Quit ze (Read error: 110 (Connection timed out)) 19.00.00 Nick ze__ is now known as ze (psyco@adsl-67-123-41-128.dsl.lsan03.pacbell.net) 19.02.50 Join kaouete [0] (~menfou@dyn-83-155-213-141.ppp.tiscali.fr) 19.02.51 # hi 19.03.05 Part Lynx_ 19.04.52 Join pike [0] (amiga@h234n1fls22o1064.bredband.comhem.se) 19.04.54 # i have a strange behavior with my archos, i think it's linked to the battery, but its' strange. When i am listening music, when i reach about 70% of battery, the music stops for 1/2 sec, play 1/2 sec and stop completely :/ 19.05.07 # is it linked to rockbox or maybe should i change my battery ? 19.06.06 Quit pike (Client Quit) 19.08.08 Quit teej (Read error: 60 (Operation timed out)) 19.08.33 # (and i cant even start it now without re-charging it) 19.42.41 # try a new set of batteries 19.56.33 # ok, are 2200mAh supported now ? 20.36.50 Join elinenbe [0] (~elinenbe_@65.115.46.225) 20.39.12 # wiggler! 20.51.57 *** Saving seen data "./dancer.seen" 21.29.15 Join HenrikB [0] (~HenrikB@as4-2-2.sjom.b.bonet.se) 21.30.09 # Hi! 21.35.22 # kaouete: 2200 mah has always been supported 21.37.28 Quit HenrikB (leguin.freenode.net irc.freenode.net) 21.37.28 NSplit leguin.freenode.net irc.freenode.net 21.37.28 Quit mecraw (leguin.freenode.net irc.freenode.net) 21.37.28 Quit MrMoo (leguin.freenode.net irc.freenode.net) 21.37.28 Quit oxygen77 (leguin.freenode.net irc.freenode.net) 21.37.28 Quit Sebulba02 (leguin.freenode.net irc.freenode.net) 21.38.57 NHeal leguin.freenode.net irc.freenode.net 21.38.57 NJoin HenrikB [0] (~HenrikB@as4-2-2.sjom.b.bonet.se) 21.38.57 NJoin mecraw [0] (~lmarlow@69.2.235.2) 21.38.57 NJoin MrMoo [0] (~me@194.152.87.150) 21.38.57 NJoin oxygen77 [0] (~Chris@pauguste-7-82-66-87-78.fbx.proxad.net) 21.38.57 NJoin Sebulba02 [0] (~Sebulba02@Darth-Sebulba04.active.supporter.pdpc) 21.39.23 Join mecraw_ [0] (~lmarlow@69.2.235.2) 21.39.53 Join HenrikB_ [0] (~HenrikB@as4-2-2.sjom.b.bonet.se) 21.41.43 Join [IDC]Dragon [0] (~idc-drago@pD9FF890F.dip.t-dialin.net) 21.42.12 # <[IDC]Dragon> Hello Henrik(s) 21.44.48 # hello [IDC]Dragon 21.44.59 # <[IDC]Dragon> Hi Eric 21.51.21 Quit oxygen77 (leguin.freenode.net irc.freenode.net) 21.51.21 NSplit leguin.freenode.net irc.freenode.net 21.51.21 Quit MrMoo (leguin.freenode.net irc.freenode.net) 21.51.21 Quit mecraw (leguin.freenode.net irc.freenode.net) 21.51.21 Quit HenrikB (leguin.freenode.net irc.freenode.net) 21.51.21 Quit Sebulba02 (leguin.freenode.net irc.freenode.net) 21.51.52 Join scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) 21.52.32 NHeal leguin.freenode.net irc.freenode.net 21.52.32 NJoin HenrikB [0] (~HenrikB@as4-2-2.sjom.b.bonet.se) 21.52.32 NJoin mecraw [0] (~lmarlow@69.2.235.2) 21.52.32 NJoin MrMoo [0] (~me@194.152.87.150) 21.52.32 NJoin oxygen77 [0] (~Chris@pauguste-7-82-66-87-78.fbx.proxad.net) 21.52.32 NJoin Sebulba02 [0] (~Sebulba02@Darth-Sebulba04.active.supporter.pdpc) 21.53.24 Quit oxygen77 (leguin.freenode.net irc.freenode.net) 21.53.24 Quit MrMoo (leguin.freenode.net irc.freenode.net) 21.53.24 Quit mecraw (leguin.freenode.net irc.freenode.net) 21.53.24 Quit HenrikB (leguin.freenode.net irc.freenode.net) 21.53.24 Quit Sebulba02 (leguin.freenode.net irc.freenode.net) 21.54.04 Join Zagor [0] (foobar@h254n2fls31o265.telia.com) 21.54.07 NJoin HenrikB [0] (~HenrikB@as4-2-2.sjom.b.bonet.se) 21.54.07 NJoin mecraw [0] (~lmarlow@69.2.235.2) 21.54.07 NJoin MrMoo [0] (~me@194.152.87.150) 21.54.07 NJoin oxygen77 [0] (~Chris@pauguste-7-82-66-87-78.fbx.proxad.net) 21.54.07 NJoin Sebulba02 [0] (~Sebulba02@Darth-Sebulba04.active.supporter.pdpc) 21.54.40 Quit mecraw (Connection timed out) 21.55.46 # [IDC]Dragon: how is the Ondio progress coming? 21.59.04 Quit HenrikB (Read error: 110 (Connection timed out)) 22.01.45 # <[IDC]Dragon> elinenbe: pretty good, I've implemented FAT16 now, needs testing 22.03.06 # <[IDC]Dragon> Jens is working on the MMC driver, these 2 things are the key components 22.03.19 # Grmpf 22.03.22 # [IDC]Dragon: fat.c line 294 is missing 'int'. it gives a warning in gcc. 22.03.50 # <[IDC]Dragon> Hi Zagor, I didn't notice you're here 22.04.04 # i just came in 22.04.07 # <[IDC]Dragon> amiconn sounds no good 22.04.21 # <[IDC]Dragon> ah, with that split 22.04.52 # <[IDC]Dragon> missing int's go unnoticed in MSVC 22.05.03 # [IDC]Dragon: I got an MMC today, so I can test external access 22.05.47 # It is indeed the case that when you plug in USB with an MMC inserted, the original firmware asks you to remove the card (for reset). 22.06.32 # <[IDC]Dragon> yeah, I'm afraid without a power switch it has to be that annoying 22.07.25 # You can then insert and extract the card at will while in USB mode. When the card is not inserted, the PC presents you with the contents of the built-in flash 22.09.41 # ahhh, the test case creates a too big root dir... :) 22.09.48 Part oxygen77 ("Cho") 22.10.15 # <[IDC]Dragon> oh, it runs that far? 22.10.29 # <[IDC]Dragon> does it gracefully fail? 22.10.47 # it never runs the fat driver at all. it fails creating the test disk :-) 22.11.04 # [IDC]Dragon: While this does work with the USB mode of rockbox, rockbox doesn't notify the PC host that the card was changed 22.11.05 # <[IDC]Dragon> how can? 22.11.36 # it sets up the test disk by creating lots of files on it, and many files with long names. too many to fit in a fat16 root dir. i need to make a subdir for this instead. 22.11.37 # <[IDC]Dragon> amiconn: the partition is re-mounted after USB anyway, iirc 22.12.22 # <[IDC]Dragon> Zagor: ah, that part, I had to skip that (no ext dir, no mounting) 22.12.24 # Of course. I mean that the archos fw disables and re-enables the usb bridge whenever a card is inserted or removed while in USB mode 22.17.07 # Any makefile ninjas here? No rocks are created for me after Bagder's makefile update 22.17.17 # <[IDC]Dragon> Zagor: it would be a more inteesting test case if some of the "seed files" get deleted, too, to create FAT holes 22.19.49 # yes. but this is enough to make it fail anyway 22.19.52 # :) 22.20.07 # mkdir error: file exists 22.20.07 # Failed creating directory 22.22.23 # rather strange error 22.23.28 # HenrikB_: plain recorder build? 22.24.02 # <[IDC]Dragon> no good 22.24.20 # <[IDC]Dragon> in the driver this time, I guess? 22.24.27 # yes 22.24.44 # plain recorder on cygwin 22.25.59 # HenrikB_: any error message? 22.26.56 # Bagder: Same here; tried FMR and player so far. No error message for FMR, the player build generates plenty of them :( 22.27.47 # Bagder, nope it just enters and leaves the plugin directory. The libplugin.a is built though. 22.27.51 # Player build doesn't even complete, exits with error on building sysfont.o 22.28.04 # amiconn: then rebuld convbdf 22.28.12 # Same for me 22.28.20 # run make in tools 22.28.22 # Bagder: Did you change it today? 22.28.25 # yes 22.28.58 # it now produces #ifdef have_lcd_bitmap 22.29.00 # in the code 22.29.14 Quit methangas (" Try HydraIRC -> http://www.hydrairc.com <-") 22.29.24 # "make clean" errors out too... 22.30.04 # I need details 22.30.18 # $ make clean 22.30.18 # make[1]: Entering directory `/home/Administrator/rb-patched/firmware' 22.30.18 # cleaning firmware 22.30.18 DBUG Enqueued KICK amiconn 22.30.18 # make[1]: Leaving directory `/home/Administrator/rb-patched/firmware' 22.30.18 # make[1]: Entering directory `/home/Administrator/rb-patched/apps' 22.30.18 *** Alert Mode level 1 22.30.18 # make[1]: *** [/home/Administrator/rb-patched/build/player/dep-apps] Error 1 22.30.20 # make[1]: Leaving directory `/home/Administrator/rb-patched/apps' 22.30.22 # make: *** [clean] Error 2 22.31.07 # does dep-apps get created and contain dependencies? 22.31.50 # Building just failed.. cleaned dir and try building from scratch.. 22.32.09 # Building still doesn't work (player, that it): 22.32.18 # $ make >make.log 22.32.18 # make[1]: *** [/home/Administrator/rb-patched/build/player/dep-apps] Error 1 22.32.18 # make: *** [all] Error 2 22.32.49 # The file "dep-apps" gets created. 22.32.51 # ah, it fails for me too now 22.32.54 # for player 22.33.55 # Possibly a hint: while most paths in that file are absolute, some are not? 22.35.57 # it is used within the respective dir, so it can use relative path names 22.36.05 # [IDC]Dragon: Really interesting finding: Initializing the card into SPI mode *works* *with my transfer routines* for external MMC, but not for internal flash :/ 22.36.47 # Maybe I have to reset the flash beforehand... 22.38.11 # ... but if I invoke make again it works 22.40.01 # Hmm, same here. Strange 22.40.19 *** Alert Mode OFF 22.40.39 # After using "make clean" or building in a new dir, it fails. A second make call completes the build 22.40.55 # I'm on it 22.41.27 # Plugins are missing for player too 22.51.59 *** Saving seen data "./dancer.seen" 23.03.28 Quit AciD (Connection reset by peer) 23.04.56 # <[IDC]Dragon> Zagor: I need a way of reproducing that error 23.05.24 # <[IDC]Dragon> how small of an image can you generate? 23.05.48 # <[IDC]Dragon> maybe we can transfer one, plus the next failing command 23.06.59 # hang on a bit, i'm debugging a little first 23.07.37 # <[IDC]Dragon> ok, hang me ;-) 23.11.09 # heh, my 128MB disk image compressed to 305KB :) would you like it? 23.11.40 # <[IDC]Dragon> if it check ok and fails the next command, yes 23.12.22 # well it's not quite that polished. i'll see what I can do... 23.13.24 # <[IDC]Dragon> certainly I don't mind if you find the problem :-)) 23.13.39 # :) 23.14.12 Join AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) 23.14.24 # oops... it was actually a bug in the test script :) 23.14.52 # <[IDC]Dragon> bug found then :-) 23.16.35 # yeah, now the test runs further but fails a bit later on 23.16.44 # <[IDC]Dragon> :-( 23.17.06 # <[IDC]Dragon> I'm running out of smileys 23.17.46 # hehe. well be happy, the test script makes debugging a lot nicer than having to rely on angry users who just crashed their disk :) 23.18.31 # <[IDC]Dragon> yes, the script is great 23.18.49 # <[IDC]Dragon> with those checkdisk's inbetween every step 23.19.16 # <[IDC]Dragon> but that's for Linux only 23.21.11 Quit scott666_ (Read error: 110 (Connection timed out)) 23.21.42 Join scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) 23.21.52 # looks like it's rename that fails 23.22.02 # <[IDC]Dragon> hmm 23.22.31 # Goodnight and happy (bug) hunting 23.22.38 # good night! 23.22.41 # <[IDC]Dragon> maybe the root is full? 23.22.49 # <[IDC]Dragon> what does it say? 23.23.20 # it's not clear what is happening, there is no error message 23.23.35 # so i have to debug the test code also :) 23.23.36 Quit HenrikB_ ("Lämnar") 23.24.04 # <[IDC]Dragon> I'm not doing debug output on full root dir, perhaps I should 23.25.08 # i think we've changed file.c since the test script was last used... 23.25.53 # <[IDC]Dragon> for me, it complained when renaming, pathnames not starting with / 23.26.03 # yeah, that's it. rename() used to not take a dir in the second argument. now it must be present. 23.26.34 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 23.26.34 # * [IDC]Dragon is relieved, sees hope 23.26.34 # all tests completed for images with 4 and 32 sectors/cluster. failed on 1 sector/cluster. 23.27.09 # <[IDC]Dragon> hmm 23.27.19 # ah, simply too many clusters. not a driver issue. 23.27.30 # <[IDC]Dragon> how soon does it fail? 23.27.56 # <[IDC]Dragon> too many clusters would give FAT32 23.28.15 # right, so mkdosfs complains because I told it to make fat16 23.28.38 # <[IDC]Dragon> you need to stay below 64 MB then 23.29.04 # <[IDC]Dragon> no, 32 even 23.29.14 # same thing happens with 128 sectors/cluster, although in the opposite direction 23.29.31 # <[IDC]Dragon> is that allowed? 23.29.33 # so everything works in the 4, 8 and 32 sectors/cluster tests 23.30.00 # I don't think so, no. :) 23.30.07 # <[IDC]Dragon> very good! 23.30.14 # indeed 23.30.45 # <[IDC]Dragon> let's check the legal corner cases 23.31.14 # Zagor: For fat16, up to 64 sectors/cluster are allowed and understood by all OS'es that support fat. However, WinNT allows 128 sectors/cluster 23.32.47 # <[IDC]Dragon> 2 GB, that is 23.33.03 # yes, but the fat32 spec says never to use more than 32KB/cluster 23.33.07 # With WinNT it's 4 GB 23.33.19 # We're talking FAT16? 23.33.33 # sorry, the fat spec 23.34.26 # This feature of WinNT is called "NT large clusters". I think this does not need to be supported by rockbox, but it should not mount such partitions then 23.34.31 # "Values that cause a cluster size greater than 32K bytes do not work properly; do not try to define one." 23.34.52 # <[IDC]Dragon> I'm facing the same spec :-) 23.34.58 # we support them, i just didn't make an image that had them correctly 23.35.14 Join iriver_srn [0] (root@lada.kom.auc.dk) 23.35.31 # Ah ok. Perhaps I should fire up a NT4 VM and create one? 23.35.56 # is the Ondio flashable? 23.35.57 # no need, you can do it with mkdosfs. I tested the fat32 code on it. 23.36.02 # <[IDC]Dragon> I'm forced to goto bed 23.36.08 # [IDC]Dragon: ok, good night 23.36.11 # night. 23.36.17 # night! 23.36.18 # <[IDC]Dragon> very sorry to leave this interesting moments 23.36.39 # <[IDC]Dragon> c u, will read the logs tomorrow 23.36.47 # nite Jörg 23.36.50 Quit [IDC]Dragon () 23.37.20 # make fixes coming up in a few minutes 23.37.25 # excellent 23.40.52 # btw [idc]dragon: the additions to support fat16 are so small I think we should not #ifdef them. and that will allow us to make the changes even smaller, by combining the 16- and 32-bit code in fat_recalc_free, find_free_cluster, update_fat_entry and fat_read_entry. 23.41.03 # amiconn: now try my fixed version, just committed 23.41.38 # works better 23.41.58 # now I tried the Ondio build too ;-) 23.41.58 # Bagder: Do I have to redo configure? 23.42.01 # yes 23.49.41 # - 23.54.40 Quit iriver_srn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 23.55.28 # Bagder: Seems to work correctly now for all targets I tried. However, I noticed some things: 23.55.35 # weird slashdot story: "Iriver H320 almost hits the market". Haven't people had it for weeks, at least? 23.55.51 # Bagder: (1) target builds do use dep-xxx files now, while the simulator builds still use the .deps directory 23.56.10 # yes, I've left the sim build as-is for now 23.56.56 # (2) Creating/removing the dependencies (make/ make clean) for the target is way slower than for the sim? This was also the case with the old build system though 23.57.54 # I can't explain that though...