--- Log for 12.11.105 Server: kornbluth.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 7 days and 19 hours ago 00.00.16 # is it any different from the battery in H120? 00.00.33 # I've no idea. But I would expect them to be the same 00.01.15 # Battery runtime might be *slightly* higher for h120 than h140 00.02.34 # due to disk? 00.03.03 # Two reasons. (1) The disk probably needs less energy to spin up (1 platter instead of 2) 00.03.25 # (2) The RAM refresh needs less bandwidth 00.03.41 # Bah, (2) is for h100 00.03.45 # ...only 00.03.58 # The h100 has 16MB RAM? 00.04.02 # yup 00.04.36 # i was looking at my PS2 the other day and realized that it, too has 32MB ram... 00.05.02 # Do we have any stats on how many downloads there have been for each target? 00.05.21 # btw, what's the unicode status? 00.05.41 # linuxstb: not really 00.07.52 Join len0x [0] (n=len0x@193.113.235.183) 00.09.54 Quit len0x (Client Quit) 00.10.54 Join matsl [0] (n=user@1-1-4-2a.mal.sth.bostream.se) 00.27.13 Join DJDD [0] (n=DJDD@CPE-143-238-11-25.vic.bigpond.net.au) 00.28.25 Quit DJDD_ (Read error: 110 (Connection timed out)) 00.50.58 Join ashridah [0] (i=ashridah@220-253-121-15.VIC.netspace.net.au) 00.57.27 *** Saving seen data "./dancer.seen" 00.58.38 # w00t! 01.02.53 # My asm monster finally works as intended 01.03.06 # Congratulations. Is an ARM version next? :) 01.03.15 # haha 01.07.35 # hmmm... i look at trickle chrger in ihp120.. and see that it has usb pin... so, does it mean that player can be chrged from usb? 01.09.02 # from what i see there will be nothing hard at all to make a player charge and work from usb.. 01.09.13 # it is just a matter of one wire. 01.21.07 Quit DJDD ("Trillian (http://www.ceruleanstudios.com") 01.27.31 # ideally, any kind of usb-drawing charger will actually have a usb device built in in order to control current flow. 01.28.00 # but i've heard of people hacking usb 1.1 cables in order to do usb-drawn charging 01.28.08 # just make sure you do it on a port you don't mind frying ;) 01.40.09 Quit dpassen1 () 01.44.35 Quit ender` (Read error: 104 (Connection reset by peer)) 01.49.54 Join _aLF [0] (n=Alexandr@mut38-2-82-67-66-128.fbx.proxad.net) 02.12.39 Quit actionshrimp ("a bird in the bush is worth two in your house") 02.14.05 # ashridah, usb-calble-hacking doesn't look very good. one wire inside of a player looks much nicer. :) 02.15.06 # anyway, i will not do it just because i don't really need it. btw, i could fit my rtc schema inside of my player 02.15.39 # it barely fit, but it is inside now. 02.16.24 # i didn't connect any wires yet, i don't have solder in my room, i will solder it tomorrow. :) 02.16.48 # and will start writing a driver for it. 02.17.29 # pretty easy, since it is connected using i2c to the same bus tuner is using. 02.24.29 Quit matsl (Remote closed the connection) 02.35.20 # xshock: where exatcly to solder the cable for charge and sybc? 02.35.33 # also it would need a switch 02.39.13 # pin number 2 on TI trickle charger goes directly to usb cable.. adding a cap is also not a bad idea. 02.39.25 # that is for charging. 02.39.40 # ground i think is already connected. 02.39.59 # no need for switch then? 02.40.04 # no. 02.40.12 # no switches.. 02.40.46 # so already roclbox has the option to charge from other targets. 02.41.14 # hmm. i dont' understand what you mean. 02.41.29 # Iyeah I said it very wrong 02.42.56 # I mean that rockbox option "tickle charge" will controll the charging when this wire is added, right? 02.43.45 # no. 02.43.51 # or I completely misundestood what you said. 02.44.25 # that addition of the wire will make your battery charge whenever you connect your player to computer using usb. 02.44.38 # it has nothing to do with software and rockbox in particular 02.44.56 # exaplain this: If you add the wire that you say, which part of hardware (or software) will control if the user wants to charge? 02.45.05 # so there will be no option. 02.45.19 # when you insert USB you charge without an option. 02.45.22 # yes. no option.. it will charge automatically.. 02.45.26 # yes 02.45.49 # but I think that this is not acceptable. 02.45.56 # obviously you don't want to charge all the time. 02.46.31 # hmm. why not? 02.47.07 # bad for the battery? 02.47.25 # imagine that you charged fully and then you remembered to put some new files 02.48.00 # I guess that li-ion is not spoiled by continous charging but.... 02.49.04 # i guess that TI trickle charger will terminate the charge.. 02.49.29 # I just had my worst nightmare with those modded USB cables that charge and sync 02.49.32 # i didn't read the documentation very deep. 02.49.51 # I made one of those when I first got the player and it worked quite fine. 02.50.05 # but now something went wrong. 02.50.20 # how do you control chargin in those ipods that have the feature of usb charging? 02.50.35 # when I coupled it on my my PC, Windoze crashed 02.50.49 # hmm. 02.50.57 # then my player crashed in a way that no led was lit 02.51.17 # So I didn't realised that iriver had crashed too. 02.51.24 # sdtrange 02.51.28 # then I pushed play only to see that nothing happens 02.51.30 # i gotta go. 02.51.41 # have a meeting at 9pm. 02.51.42 # ok good night 02.51.51 # u2. cya 02.52.37 # anyway I then realised that the HD was spinning and the reset did the work. For one sec I really thought that my unit died...! 02.57.28 *** Saving seen data "./dancer.seen" 03.02.54 # linuxstb: Your table.c commit is incomplete => red builds 03.07.31 # Sorry - forgot SOURCES. It's committed now. 03.09.39 # Why didn't the sim builds turn red as well? 03.11.04 # Good question... 03.11.52 # do the platforms all rebuild whenever there's a commit, or daily? 03.12.08 # All platforms after every commit 03.12.42 # whoa. how long does the build process take for all of them? 03.13.10 # About half an hour, depending on the server load and how much was changed 03.13.20 # aah, does it does incrementals if it can? 03.13.32 # It uses some compiler cache 03.13.38 # right 03.14.58 # And it's going to get worse with the ipod targets. We could quite quickly have 4 or 5 new targets 03.15.19 # All with codecs to build 03.15.28 # Yes, and some sims as well... 03.15.41 # And bootloaders for each ipod. 03.16.26 # Even today not all possible combinations are built 03.16.54 # The ipods are very very similar. I'm sure you've noticed the minor differences between the two ipods 03.18.15 # I'm not sure the ipod sims would need building. They would probably be very close to the H3x0 03.18.55 # At least the lcd resolution is different 03.19.02 # ...and the buttons 03.19.19 # Then we might decide to run the H300 lcd in 18bit 03.19.22 # Yes, I forgot the buttons. I thought the resolution was the same (for the color ipod) 03.19.35 # My ipod is 220x176 03.19.56 # So I guess we will need some sims. 03.20.02 Quit _aLF ("^^") 03.20.18 # The nano is less 03.20.26 # Then there are the greyscale ipods 03.20.46 # Yes - the nano is less. But I think the greyscales are the same as the H1x0 03.20.54 # Two resolutions 03.21.06 # Standard ipod is same as H1x0 03.21.10 # Mini is again less 03.22.18 # So we're back to needing all the sims then? 03.22.24 # I wonder whether the pixel-flicking greyscale technique would be possible on these ipods... 03.22.50 # I can tell your tempted to buy one :) 03.22.59 # s/your/you're/ 03.23.31 # Hmpf. I already have 5 rockboxes, more than enough for my limited time :/ 03.25.11 # Then I don't really like the ipod design (well, mostly the available colours) 03.25.52 # I heard that the nano is available in black though 03.26.26 # Yes - the Nano comes in black and white 03.28.12 # Hmm, afaik ipodlinux doesn't have the pixel-flicking greyscale... 03.28.39 # The lack of buttons is my biggest criticism. Also, the non-standard USB connector, but charging via USB is very useful. 03.29.00 # Hmm, no standard connector? 03.29.09 # How many buttons? 03.30.12 # There are four real buttons and the scroll-wheel which is touch-sensitive giving (i think) 96 values depending on where you press it. 03.30.31 # So you could argue there are 100 buttons... 03.31.01 # So you basically have a wheel that turns in two directions and 4 buttons. 03.31.20 # Plus a hold switch 03.31.58 # That's not much... 03.32.41 # ...but a tiny bit better than the Ondio, which has 6 buttons, one of which is the power button 03.32.54 # I guess the ipod has no separate power button? 03.33.12 # No - a long press on PLAY sends it to sleep. 03.33.31 # And there is the hardware reset key combination as well. 03.33.35 # Do you know whether button combos are restricted somehow? 03.33.49 # I don't know. 03.34.39 # I haven't really looked at the button driver yet. 03.35.04 # I've been working tonight on getting Rockbox itself to compile. I've now reached the plugins. 03.35.42 # I'm curious how the wheel is handled in the firmware 03.36.00 # Which firmware? 03.36.08 Quit ]RowaN[ (Read error: 104 (Connection reset by peer)) 03.36.34 # I mean, how is it hooked up, what signals are received when the wheel is operated? 03.37.53 # I think the hardware provides an integer between 0 and 95, with all the hard work done in the hardware. 03.38.44 # There was a thread on the IPL forums about it, but the IPL website is down at the moment so I can't find it. 03.40.55 # I'm undecided whether I should commit the memcpy() monster. 958 bytes... 03.44.36 Quit ghode|afk (Read error: 110 (Connection timed out)) 03.45.38 # I forgot the middle (select) button on the ipod. It's 5 buttons, plus the wheel, plus hold. 03.46.25 # Are you planning on putting the memcpy in iram? 03.46.51 # It always was in iram 03.51.08 # I think you should - it's very well-used function. 03.51.37 # Afaik, some codecs use an own function instead 03.51.58 # These should then use the new memcpy() 03.54.07 # Yes, that shouldn't be a problem to fix. 03.54.53 # Apart from the plugins, Rockbox now builds for the ipod. I now need to write some startup code. 03.57.24 # I think it's time for sleep. Goodnight. 03.57.42 # night 04.01.24 Quit ashridah ("out") 04.08.45 Part linuxstb_ 04.30.59 Join solexx_ [0] (n=jrschulz@c196109.adsl.hansenet.de) 04.41.56 Quit solexx (Read error: 110 (Connection timed out)) 04.50.17 Quit DangerousDan ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 04.57.31 *** Saving seen data "./dancer.seen" 05.10.58 Join andy [0] (i=golbeck@h72n2fls304o1033.telia.com) 05.11.32 # iriver recording committed, waiting for build results :) 05.21.46 Join DJDD [0] (n=DJDD@CPE-143-238-11-25.vic.bigpond.net.au) 05.48.50 Join webguest64 [0] (n=18d79b85@labb.contactor.se) 05.49.51 Quit webguest64 (Client Quit) 05.57.24 Quit andy () 06.06.08 Quit RotAtoR () 06.57.34 *** Saving seen data "./dancer.seen" 07.03.54 Quit BirdFish ("reboot") 07.08.00 Join psycho_maniac [0] (n=cfe6da9a@labb.contactor.se) 07.08.21 Join BirdFish [0] (n=bradbox8@64.108.5.134) 07.26.13 Quit psycho_maniac ("CGI:IRC") 07.56.43 Quit BirdFish ("reboot (back in a minute)") 08.06.46 Join BirdFish [0] (n=bradbox8@64.108.5.134) 08.28.49 Quit DJDD (Read error: 104 (Connection reset by peer)) 08.31.26 Join DJDD [0] (n=DJDD@CPE-143-238-11-25.vic.bigpond.net.au) 08.57.35 *** Saving seen data "./dancer.seen" 09.32.09 Join ashridah [0] (i=ashridah@220-253-122-224.VIC.netspace.net.au) 09.34.46 Join LinusN [0] (n=linus@labb.contactor.se) 09.34.57 # XShocK: u there? 09.39.22 # last time i investigated usb charging on the h100, the AC and USB inputs were connected, so it's not a matter of connecting a wire, you have to lift the (tiny) pin from the charging chip 09.39.51 # pretty hard to do without breaking the pin 09.40.06 # yes 09.40.37 # hi 09.40.42 # hi :-) 09.40.43 # hmm. i didn't think about it.. 09.41.09 Join amiconn_ [0] (n=jens@p54BD49C5.dip.t-dialin.net) 09.41.24 Join StrathAFK [0] (n=mike@dpc674681214.direcpc.com) 09.41.33 Quit amiconn (Nick collision from services.) 09.41.33 Nick amiconn_ is now known as amiconn (n=jens@p54BD49C5.dip.t-dialin.net) 09.41.39 # XShocK: still, it's not impossible 09.42.32 # hi amiconn 09.42.46 # Good morning 09.43.02 # good morning 09.45.15 # 10 codecs now supported in iriver rockbox. A true multi-codec jukebox :-) 09.47.27 # coooooool 09.53.14 # Red build alert 09.54.32 # gah 09.54.59 # amiconn: saw my mail in the dev list? 09.55.36 # * amiconn checks 09.56.28 # Yeah, totally wrong 09.56.47 # I wonder what the bool monitor is for anyway 09.57.04 Quit Strath (Read error: 110 (Connection timed out)) 09.57.54 # It seems this selects whether the signal is put on the DAC, but imho this should always be done 09.58.04 # i think so too 09.58.20 # ...and the volume should be changeable from the recording screen 09.58.25 # yes 09.58.45 # i'll fix that bug 09.59.16 # There's a (imho sensible) suggestion in the Ondio forum: http://forums.rockbox.org/index.php?topic=1779.0 10.00.02 # saw that too, a great idea 10.00.34 # I think the proper fix would be to completely remove the 'bool monitor' 10.01.05 # i think so too 10.01.24 # Of course the renaming of functions in mpeg.c should stay 10.01.29 # i believe you can control the monitor volume in the iriver recording screen, can't you? 10.01.36 # (mpeg_* -> audio_* ) 10.01.43 # agree 10.01.57 # If it's the same recording screen as on archos, you can't (yet) 10.03.05 # it is 10.04.14 # yes, and you can't toggle monitor mode in the screen, only in the settings 10.04.50 # Hmm, so volume in the recording screens would be really useful, and the monitoring should be always enabled and the option dropped 10.05.11 # LinusN: so it is 'possible' to do USB Charging on H1xx ? :x 10.05.33 # ...and I have an idea how to make the gain settings look more 'professional' and take one line less 10.06.31 # Instead of having separate 'Gain', 'Left' and 'Right' for line recording, we could have 'Left' and 'Right' only, with the option to couple them 10.06.55 # The coupling would be clearly indicated by inverting both lines 10.08.29 # Hmm, and two pointers when using pointer mode? 10.08.40 # Maxime: yes, but you need to do some pretty tricky hardware modifications 10.09.02 # LinusN: hum, how? some soldering and else? 10.09.02 # amiconn: good idea 10.09.41 # Maxime: unsolder and lift a pin on the charging chip, and connect it to the USB 5V with a wire 10.09.58 # ah yes I see.. 10.10.04 # unfortunately not as easy as it sounds 10.10.37 # yeah :x 10.10.39 # the pin is horrendously small 10.11.11 # LinusN, that was a QFN package right? trickle charger 10.11.18 # i think it was 10.11.38 # ah. it actually isnt 10.12.45 # sorry. it is late here 10.13.47 # i hope tomorrow i find someone to open electronic laboratory for me. doh.. they only give access to the building only yo graduate students with electrical engineering major. 10.20.31 # XShocK: how come you call it trickle charger? 10.21.01 # it can charge at full rate too 10.38.08 # mm.. i just looked at documentationv very quickly... 10.38.46 # sorry for confusion 10.39.20 # i gotta go sleep. 10.39.29 # good night all 10.39.34 # nite 10.50.43 Join arkascha [0] (n=arkascha@xdsl-195-14-221-188.netcologne.de) 10.52.06 # amiconn: imho, it might be simpler to have one gain gauge when l&r are coupled 10.52.35 # Hmm, but then it's not obvious that left & right can be set separately 10.52.56 # no, not in the rec screen itself 10.54.24 # Hmm, I have 2 variants of superfast coldfire memcpy(), one is 718 bytes, the other is 958 bytes 10.54.46 # The larger one is of course faster 10.55.16 # I'm undecided which one to commit... 10.57.17 # i don't think 200 extra bytes is a problem 10.57.37 *** Saving seen data "./dancer.seen" 10.57.57 # if that is a problem, we'll just reduce the stack with 200 bytes 10.58.13 # Hmm, memcpy() is in iram, and my next step (memmove) will double the size again 10.58.35 # For SH1 memmove() is already working 10.58.36 # still a few hundred bytes isn't much imho 10.58.47 # sh1 is worse, since the iram is so small 10.59.30 # On sh1 the full memmove() is 464 bytes 10.59.55 # It still fits in iram, even with debug builds 11.00.31 # The problem why the coldfire memcpy is so big is that we have to keep line alignment in order to profit from burst mode 11.01.22 # So memcpy has to deal with 256 possible alignment combinations (start address at line_start + 0..15 each for source and destination) 11.01.51 # The source alignment is handled in head loops, after which the source is always line aligned 11.02.24 # -> 16 possible alignments for the main loops 11.03.04 # All main loops read full lines with burst mode 11.04.05 # The big memcpy() has a total of 10 main loops. For all longword and word aligned destinations it also writes full lines in burst mode 11.04.38 # For byte alignment, writing is only done as longwords (still quite fast) 11.05.38 # The smaller memcpy() version ditches burst writing for the word aligned destinations, and only does longword writes there as well 11.05.47 # -> Number of main loops reduced to 7 11.07.20 # how different do you think the performance would be? 11.11.20 Join amiconn_ [0] (n=jens@p54BD77B9.dip.t-dialin.net) 11.13.53 Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) 11.19.14 Quit amiconn (Nick collision from services.) 11.19.15 Nick amiconn_ is now known as amiconn (n=jens@p54BD77B9.dip.t-dialin.net) 11.21.30 # LinusN: 50% faster for word aligned destinations 11.22.46 # Note that I did all my measurements in sdram so far, I still have to test with iram destination 11.23.04 # and how would the real life performance gain be do you think? 11.23.26 # i mean, how many word aligned memcpy() are there? 11.23.35 # hard to say i guess 11.23.50 # That's hard to say... the codecs do quite some copying, but I don't know about the alignment 11.24.11 # i'd say go for the maximum optimization 11.24.27 # no need to work that hard for an incomplete optimization 11.25.12 # I can leave the alternative in. It's a simple #ifdef 11.26.49 # Copy speed in sdram (full version) is 10MB/s for longword aligned dest, 9MB/s for word aligned, and 6 MB/s for byte aligned 11.27.38 # ...versus the C version: 4 MB/s for longword alignment (only when aligned right at the start), 1 MB/s otherwise 11.28.12 # amiconn: half-hearted test of the recording gui (only for archos): http://linus.haxx.se/rec_gain.patch 11.28.23 # try it in the sim 11.28.53 # amiconn: commit! commit! :-) 11.33.58 # (all speeds measured at 45 MHz) 11.40.49 # Btw, I just tried it: it is very easy to trigger folder skip with short-long right if you intend to skip to next track and seek there 11.41.30 # ok, then i am old and slow :-) 11.42.04 # for me, it mostly takes about a second to hear which track it is and realize that i want to seek at all 11.42.50 # Of course, if you want to hear first what track it is then it doesn't happen 11.43.10 # The problem arises when you *know* that you want to seek in the next track 11.44.57 # Hmm, your recording screen patch is a slightly different idea than mine. 11.45.19 # oh? 11.45.36 # I meant that the channel coupling could be selected within the recording screen, just with up/down like before 11.45.53 # aha, how? 11.46.27 # i.e. the screen would have 'Left' and 'Right' and start with the channels coupled (both lines inverted/with cursor) 11.46.48 # ok, and how do you decouple? 11.47.00 # Going Up would select Left only, going down Right only 11.47.28 # how do you change the volume then? 11.47.31 # Left <=> coupled <=> Right, starting with 'coupled' 11.47.43 # The volume would be an additional line 11.48.09 # ah, so you essentially want the "gain" to be between the left and right? 11.48.21 # Yes, as a 'virtual' line 11.49.01 # that leaves us with a screen estate problem, doesn't it? 11.49.07 # Nope 11.49.26 # Currently there is one spare line, so we can put volume in even without removing 'Gain' 11.51.13 # ah, i thought the empty line was used for prerecording or trigger info 11.51.19 # Ony the recorder there's currently no button bar in the recording screen. If we want one (would make sense), we can only put volume in with removing 'Gain' 11.53.56 # No, prerecording is displayed instead of 'size' in line 2, and trigger info isn't displayed in the recording screen 11.53.59 # you're right, it seems the empty line isn't used at all, silly me 11.54.39 # ...but the bottom line is used for showing quality & sample rate, which is covered by the gain when recording from line in 11.57.11 # hmm, so the bottom line could be there if we coupled the gain like in my suggestion 11.58.02 # gotta go, bbl 11.58.08 Part LinusN 11.58.26 Join einhirn [0] (i=Miranda@bsod.rz.tu-clausthal.de) 12.03.47 Join ender` [0] (i=ychat@84.52.165.220) 12.30.55 Quit ender` (Read error: 113 (No route to host)) 12.57.38 *** Saving seen data "./dancer.seen" 12.57.52 Join linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 13.08.13 Join ender` [0] (i=ychat@84.52.165.220) 13.13.02 Quit linuxstb (Read error: 110 (Connection timed out)) 13.17.50 # hmmh, i think i somehow now managed to brick my player. I still don't understand how, because i haven't touched the original boot loader area 13.17.56 # but it broke after i pressed reset 13.18.16 # still it reacts to hold somehow, but it displays nothing on the screen 13.18.22 # won't turn back on? hold play while you press reset? 13.18.35 # still nothing on the screen 13.18.46 # darn :/ 13.19.02 # and it will not turn off. If i press play with hold in, the disk spill spin down but unit still remains on 13.19.05 # that's weird 13.19.40 # and i verified with a hexdump that i haven't replaced the original boot loader and reset vectors was ok.. but somehow the flash got corrupted 13.21.12 # but i will try to get the unit powered off and then try again. Maybe the reset button doesn't reset everything 13.23.23 # and yes, it did boot at the first time but then when i pressed reset, it no longer boots at all.. that is interesting :) 13.25.32 # yay, a challenge! :) 13.25.46 # anyway, i probably need a bdm now 13.26.32 # I found that i wrote the rombox into wrong position (it still didn't overwrite anything). But maybe it caused cpu to excecute some wrong commands that erased the flash 13.26.35 # :-( 13.26.56 # You now see why flashing routines in the core can be bad? 13.27.14 # yes, but those routines were not in core (yet) :/ 13.27.16 # only in plugin 13.28.01 # hmm, but maybe the plugin remained in ram.. at least i have noticed that short power cycle does not erase the dram 13.29.08 # Yeah, the RAM is guarantted to hold the data for 64 milliseconds, but often it holds the data much longer 13.29.13 Quit arkascha (Read error: 110 (Connection timed out)) 13.29.16 # Not all bits are reliable this way 13.29.36 # (guaranteed to hold the data without refresh, that is) 13.30.04 # amiconn: i found out that it holds the audio buffer even over 5s-10s 13.31.31 # i think it might be a good idea to erase the whole dram on bootloader before executing anything from the ram.. 13.31.43 # or erasing on shutdown 13.31.52 Quit DJDD ("Trillian (http://www.ceruleanstudios.com") 13.32.06 # Why? 13.32.15 Nick StrathAFK is now known as Strath (n=mike@dpc674681214.direcpc.com) 13.32.22 # to prevent that kind of things happening :) 13.32.22 # The startup code clears the bss anyway 13.32.51 # Well, maybe the plugin ram should be cleared after running a flash plugin 13.33.27 # true 13.41.13 # amiconn: btw, what is the meaning of %vbr register? 13.41.43 # It's the vector base register, pointing to the exception vector table 13.41.47 Join paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) 13.41.57 # ah, ok 13.41.59 # It can only point at 1MB-aligned destinations 13.43.03 Nick paugh is now known as AliasCoffee (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) 13.43.22 # Does anyone know anything about databox? Building it for ARM generates a couple of serious compiler warnings, and I'm not sure the best way to fix it. 13.44.00 # The problem is that the TOKEN_ defines are in the range -1 to 131, but they are stored in a "char". 13.44.27 # This gives me: "databox.c:133: warning: comparison is always true due to limited range of data type" 13.44.44 # (and in editparser.c:55) 13.45.35 # -1 to 131 is clearly out of range for chars 13.46.52 # Could it be that a char on ARM is always unsigned? 13.47.11 # It's out of range either way 13.47.45 # I get a similar warning in libfaad for the line "if (x < 0)" where x is defined as a char - Comparison always false 13.48.01 # But of course it can be that char defaults to unsigned on arm 13.48.36 # char is the only type whose signedness depends on the platform 13.48.52 # You can explicitly change that to 'signed char' as a workaround 13.49.13 # Yes - I've just done that (in inttypes.h) and that fixes it. 13.50.06 # I mean it fixes libfaad. But that's still a problem in databox. 13.50.39 # * amiconn sees something he didn't expect at all 13.51.07 Join yngwi [0] (n=chatzill@chello080109107064.1.15.vie.surfer.at) 13.51.42 # * amiconn is silly 13.56.08 # hi, anyone online, i've a question concerning compiling the uisimulator with cygwin 13.58.52 Quit yngwi ("Chatzilla 0.9.68a [Firefox 1.0.7/20050919]") 14.02.07 # Anyone know if there is a reason why some functions have the explicit "__attribute__ ((section(".icode")));" instead of using the ICODE_ATTR define? Or is it just historical and should be changed? 14.02.16 # amiconn: hmm, is it possible that reset button doesn't reset everything? Something that might cause the kernel to crash 14.02.50 # I guess it hard-resets the cpu (only) 14.02.59 # linuxstb_: which ones? 14.03.06 # sleep() for example. 14.03.23 # yep.. the bootloader certainly starts because it reacts to the hold button but cannot go so far that it could show anything on the display 14.03.28 # amiconn: Plus I think the ata functions. I don't have a clean source tree at the moment - but grep will find them for you. 14.04.11 Join Sandking [0] (n=jacek@ogorek.akron.wroc.pl) 14.04.12 # Hmm. I guess this is just historical 14.04.15 # I'm wondering if that's used to put some functions in iram for all platforms, and some functions only for iriver. 14.04.48 # ICODE_ATTR is defined for all targets 14.04.57 # ...for the core 14.05.09 # Apart from iPod - I have a problem with that at the moment. 14.05.14 # The only difference is that ICODE_ATTR is not defined on archos for plugins 14.05.50 # (too little iram to share between core and plugins) 14.07.34 # So it's fine for me to change them then? 14.10.48 # I think so 14.11.18 # Btw, in order to put code in iram, you need a proper crt0.S implementation. Maybe that is the problem on ipod? 14.11.38 # It's a compile-time problem. 14.12.15 # Give me a second, and I'll quote the error message from the linker. 14.12.25 # bookmark.c:(.text+0x13e8): relocation truncated to fit: R_ARM_PC24 against symbol `strlen' defined in .icode section in /home/dave/devel/rockbox-cvs/build-ipod/librockbox.a(strlen.o) 14.13.01 # DRAM is located at 0x1000000 and IRAM is at 0x4000000 - I think this large jump is causing problems. But I haven't investigated it properly yet. 14.13.52 # I have changed app.lds for ipod to be more or less identical to the iriver. 14.14.24 # It seems gcc generates pc-relative jumps, with a 24-bit displacement 14.14.51 # The option -mlong-jumps sounds like it should fix it - but it doesn't. 14.15.06 # s/jumps/calls/ 14.27.55 # Hmm, -mlong-calls should indeed fix the problem, and in fact it shouldn't even arise: http://gcc.gnu.org/onlinedocs/gcc-3.4.4/gcc/ARM-Options.html#ARM-Options 14.28.17 # "The exception to this rule is that weak function definitions, functions with the `long-call' attribute or the `section' attribute, and functions that are within the scope of a `#pragma long_calls' directive, will always be turned into long calls." 14.30.05 # amiconn: huh, i think the might be not bricked. It has just a problem with the reset cookie. Original bootloader initially booted my secondary bootloader, but that crashed. When i pressed reset, the reset cookie was set and now it tries to load immediately my secondary bootloader and that crashes.. So i have to wait the battery to run out (i haven't T5 screw driver at home so i could disconnect the power) 14.30.17 # +player 14.35.23 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 14.36.33 Join linuxstb__ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 14.38.37 # amiconn: Yes, I read that it in the man page (about it being enabled for functions with the section attribute). 14.40.42 # I've just tried adding -mlong-calls again, and that actually causes it to fail with the same error, but in a different function - lcd-16bit.c instead of bookmark.c 14.41.59 Join frederic [0] (n=chatzill@i577B89A5.versanet.de) 14.45.31 Join Superman [0] (n=51ccca31@labb.contactor.se) 14.45.45 # hi 14.47.16 Quit linuxstb__ (Read error: 104 (Connection reset by peer)) 14.47.48 Join linuxstb__ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 14.47.50 # how can I see when progress is made for the h300 port? 14.49.34 # check the wiki 14.49.36 # http://www.rockbox.org/twiki/bin/view/Main/IriverPort 14.49.50 Join linuxstb [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 14.50.08 # ah thanks :) 14.51.12 # whats a I2C driver? 14.52.12 Quit linuxstb_ (Read error: 110 (Connection timed out)) 14.52.58 # http://en.wikipedia.org/wiki/I2C 14.57.39 *** Saving seen data "./dancer.seen" 14.58.32 Quit frederic ("Chatzilla 0.9.68.5.1 [Firefox 1.5/undefined]") 15.04.58 Quit ashridah ("Leaving") 15.05.45 # amiconn: the problem was that the vbr was not 1M aligned.. So the secondary bootloader crashes on kernel system calls 15.05.58 # It should be fine when the player runs out of battery 15.06.26 Quit linuxstb__ (Read error: 110 (Connection timed out)) 15.07.00 Join amiconn_ [0] (n=jens@p54BD77B9.dip.t-dialin.net) 15.11.05 Join ep0ch| [0] (n=ep0ch|@84.12.168.31) 15.11.44 # Slasheri: if you have some very small flat head screwdrivers you can get away with using that instead of a T5 15.12.36 # ep0ch|: probably i have somewhere but it could be still hard.. I think i will just wait the battery to go empty. Fortunately the disk is continuously spinning 15.13.05 # i hope you aint bricked it :) 15.13.12 # hehe, i hope too :) 15.16.16 Join linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 15.23.32 Join muesli_- [0] (i=muesli_t@Bbcba.b.pppool.de) 15.23.53 # linuxstb: What function was that? (in lcd-16bit.c) 15.24.32 Join andy [0] (i=andy@h72n2fls304o1033.telia.com) 15.25.02 # Slasheri: I hope you're right and your iriver isn't bricked. Too bad that the crash prevention cookie turned into a crash-trigger cookie, since you're using the bootloader 'the other way round' 15.25.26 Quit amiconn (Read error: 110 (Connection timed out)) 15.25.26 Nick amiconn_ is now known as amiconn (n=jens@p54BD77B9.dip.t-dialin.net) 15.25.29 Join preglowII [0] (n=c39fb25e@labb.contactor.se) 15.26.12 # amiconn: I'm removing the monitor option from audio_set_recording_options.. 15.26.24 # Goodie. 15.26.41 # The monitor function within the mas is something completely different 15.26.49 # aha, sorry =) 15.27.18 # It doesn't switch the output signal on and off, but selects whether the mas is ready-to-record or actually encoding 15.28.17 # ok 15.28.23 # The ready-to-record status is called monitoring, and it saves energy to use this status as long as the recording did not actually start 15.28.34 # (energy consumption similar to decoding mode) 15.28.48 # Slasheri: careful... 15.30.12 # hi preglowII 15.32.58 # re 15.33.04 Quit linuxstb (Read error: 110 (Connection timed out)) 15.33.12 # Hello preglowII. You'll be pleased to know that the ipod bootloader now compiles cleanly (in CVS), and rockbox itself is now very close to a clean compile. 15.33.43 # ahh, excellent 15.33.55 # i'll start hacking again when i'm back tomorrow 15.34.43 # printing some arm manuals as we speak, hehe 15.34.46 # Okay, iram destination with sophisticated bitshifting isn't significantly slower than simple unaligned copy, so no need to handle it as special case 15.35.02 # Sounds like I'll commit memset tonight 15.35.11 # arm is a dream come true for fixed point maths 15.35.22 # amiconn: memcpy, you mean? 15.35.30 # Yes of course 15.35.38 # hehe 15.35.40 # looking forward to it 15.35.52 # Read the numbers in today's log? 15.36.03 # yup 15.36.06 # speeeed :-) 15.36.21 # should be most excellent with regard to the codecs and voice ui 15.36.26 # andy: Do you have plans to try to incorporate the wavpack encoder into your recording code? 15.36.57 # away again 15.36.58 # btw, i take it we wont support simultaneous playback and recording? 15.37.18 # linuxstb_: is the encoder working? 15.37.26 # Recording from radio whilst playing back files could be a nice feature. 15.37.34 # andy: Yes - see the wav2wv plugin 15.37.44 # i'm just wondering about iram 15.37.45 # It's much faster than realtime, so should work well. 15.37.52 # we'll need plugins for encoders as well 15.37.58 # and there's not too much iram left for them... 15.38.31 # linuxstb_: nice.. i'm personally more interested in speex but we need a plugin api anyhow.. hm 15.38.59 # andy: Yes, the main work is creating a recording codec api 15.39.21 # shouldn't be too much work, to be honest 15.39.38 # we already have the codec plugin system 15.40.03 # so the ground work is done 15.40.15 # andy: the speex encoder might be a tough nut, but i'm interested in speex too 15.41.01 Join Paul_The_Nerd [0] (n=paulthen@cpe-66-68-93-2.austin.res.rr.com) 15.41.10 # preglowII: maybe someone on the speex-team is interested? :) 15.43.15 # problem is that libspeex has quite a lot of floating point code left 15.43.26 # perhaps they are interested, i haven't asked 15.44.10 # preglowII: ok.. 15.45.26 Quit Superman ("CGI:IRC (EOF)") 15.45.48 # but i gotta go 15.45.49 # later 15.45.53 Quit preglowII ("CGI:IRC") 15.52.00 # andy: Does your "fix for broken simulators" commit also need to be applied to the other targets - h100, h300, ipod* ? 15.53.49 # andy: Hmm, i think we can use the playback codec api with little modifications for recording too 15.59.25 Quit Paul_The_Nerd ("Chatzilla 0.9.68a [Firefox 1.0.7/20050915]") 16.06.42 Join len0x [0] (n=len0x@mobileweb02.london.02.net) 16.09.45 Part len0x 16.17.03 # Slasheri: Sure. There are some differences though - such as a codec-specific configuration screen, byte/time-splitting the output at an appropriate place for each codec, making sure that all recorded data is safely written to a file. 16.30.41 Quit ender` (Read error: 104 (Connection reset by peer)) 16.31.10 Join ender` [0] (i=ychat@84.52.165.220) 16.35.54 Quit ehntoo (Remote closed the connection) 16.38.18 Join linuxstb [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 16.40.32 Join ehntoo [0] (n=ehntoo@24-177-146-220.dhcp.mrqt.mi.charter.com) 16.41.00 Quit linuxstb (Read error: 104 (Connection reset by peer)) 16.41.34 Join linuxstb [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 16.43.22 Join mashalla [0] (i=mashalla@p5498D91C.dip.t-dialin.net) 16.44.15 Quit ehntoo (Remote closed the connection) 16.44.42 Join ehntoo [0] (n=ehntoo@24-177-146-220.dhcp.mrqt.mi.charter.com) 16.46.59 Quit ehntoo (Remote closed the connection) 16.47.47 # linuxstb_: no, that fix (config-h120.h) was because I enabled HAVE_RECORDING on h120 och that broke the h120 simulator 16.50.58 # andy: OK, thanks for clarifying. 16.51.14 # Maybe you should enable it for the h100 as well though. 16.51.41 # But I don't know anything about the h100. 16.53.03 Quit linuxstb_ (Read error: 110 (Connection timed out)) 16.53.16 Join arkascha [0] (n=arkascha@xdsl-195-14-204-206.netcologne.de) 16.55.06 Join ehntoo [0] (n=ehntoo@24-177-146-220.dhcp.mrqt.mi.charter.com) 16.57.43 *** Saving seen data "./dancer.seen" 16.58.25 Quit andy () 17.16.41 Quit ehntoo ("Leaving") 17.16.58 # looks like enabling replaygain adds about 2.5% to the boost ratio 17.18.41 Join ehntoo [0] (n=ehntoo@24-177-146-220.dhcp.mrqt.mi.charter.com) 17.18.49 Join RotAtoR [0] (n=e@12-210-82-91.client.insightBB.com) 17.21.22 Join _FireFly_ [0] (n=FireFly@p54A472CE.dip.t-dialin.net) 17.23.18 Join muesli- [0] (i=muesli_t@Bbc8f.b.pppool.de) 17.24.16 Quit muesli_- (Read error: 110 (Connection timed out)) 17.25.14 Quit korpse (Remote closed the connection) 17.25.41 Join korpse [0] (i=korpse@rrba-146-77-149.telkomadsl.co.za) 17.26.19 Join linuxstb_ [0] (n=5343d4aa@labb.contactor.se) 17.26.52 Quit linuxstb_ (Client Quit) 17.26.59 Join linuxstb_ [0] (n=5343d4aa@labb.contactor.se) 17.27.44 # amiconn: Does the tools/ipod_fw.c utility compile OK for you in cygwin? 17.28.04 # Someone has mentioned a problem on the forums - I'm guessing cygwin is involved. 17.30.33 Join Mxm`Pas`Bien [0] (n=flemmard@fbx.flemmard.net) 17.30.46 Quit korpse (Remote closed the connection) 17.31.09 Join _arkascha [0] (n=arkascha@xdsl-213-168-116-67.netcologne.de) 17.36.16 Join korpse [0] (i=korpse@rrba-146-77-149.telkomadsl.co.za) 17.36.23 Quit korpse (Client Quit) 17.38.32 Quit Maxime (Read error: 110 (Connection timed out)) 17.43.55 Quit arkascha (Read error: 110 (Connection timed out)) 18.03.53 Quit ep0ch| (Read error: 104 (Connection reset by peer)) 18.12.10 Quit _arkascha (Read error: 104 (Connection reset by peer)) 18.18.26 Quit muesli- (Read error: 110 (Connection timed out)) 18.18.29 # linuxstb: I just tried (no need to rebuild the tools everytime) 18.18.43 # ipod_fw compiles cleanly on cygwin 18.19.38 # amcionn: Thanks for checking. It's fine on Linux as well. I'll ask the poster for more details. 18.20.20 # I have a fairly recent cygwin installation, I'm updating it regularly 18.20.27 # Perhaps it's a gcc problem 18.27.09 Quit XavierGr (Read error: 110 (Connection timed out)) 18.31.43 Quit _FireFly_ (Read error: 113 (No route to host)) 18.31.45 Join _FireFly_ [0] (n=FireFly@p54A472CE.dip.t-dialin.net) 18.32.18 Join webguest17 [0] (n=18d79b85@labb.contactor.se) 18.32.26 Quit webguest17 (Client Quit) 18.33.29 # linuxstb: The idea behind the LCD_BLACK and LCD_WHITE macros was that you don't need to #ifdef between colour and b&w lcds 18.34.28 # Just #define LCD_WHITE ((struct rgb){LCD_MAX_RED-1, LCD_MAX_GREEN-1, LCD_MAX_BLUE-1} 18.34.54 # and #define LCD_BLACK ((struct rgb){0, 0, 0} 18.40.10 # 18.40.51 # amiconn: OK. I just copied that code from elsewhere in the same file. But I'll look at fixing it. 18.42.49 Join Philip_0729 [0] (n=Miranda@user-3285.lns3-c10.dsl.pol.co.uk) 18.55.03 # argh, the player is still running.. Almost 6 hours now with hd continuosly spinning.. :) 18.57.08 Join dpassen1 [0] (n=dpassen1@resnet-233-61.resnet.umbc.edu) 18.57.46 *** Saving seen data "./dancer.seen" 19.01.24 # <_FireFly_> ;) 19.01.55 # i can't boot it again before the battery goes empty :P 19.03.08 # <_FireFly_> ?? why 19.03.28 Join ravelo [0] (n=martin@INODEB149.kfunigraz.ac.at) 19.04.08 # because i flashed a secondary boot loader which crashes, and now the reset cookie prevents booting before it's reset.. And only power off can do that 19.04.36 # <_FireFly_> moep ;) 19.07.34 # <_FireFly_> argh sf.net connecting to sf.net is currently very slow 19.10.27 # <_FireFly_> i will only update my wps-widget on the patch-tracker 19.13.27 Join muesli_- [0] (i=muesli_t@Bbc82.b.pppool.de) 19.22.19 # <_FireFly_> ah updated :) 19.27.06 # smee? 19.27.24 # <_FireFly_> ?? 19.30.20 # ;) 19.32.07 # <_FireFly_> i didn't get it 19.32.15 # <_FireFly_> what smee means 19.32.23 # is me 19.32.24 Join arkascha [0] (n=arkascha@xdsl-213-196-213-14.netcologne.de) 19.32.27 # its me 19.33.07 # <_FireFly_> ah ok but my "ah updated" doesn't related to you ;) 19.33.19 # ah ok ;) 19.36.33 Join Maxime [0] (n=flemmard@fbx.flemmard.net) 19.48.39 Quit Mxm`Pas`Bien (Read error: 110 (Connection timed out)) 20.02.03 Join muesli- [0] (i=muesli_t@Bc148.b.pppool.de) 20.06.27 Quit ravelo (Connection timed out) 20.09.16 Join XavierGr [0] (n=XavierGr@ppp12-adsl-16.ath.forthnet.gr) 20.15.05 Quit AliasCoffee ("bbl") 20.15.51 # hahaha 20.16.00 # it works! 20.16.01 # ;) 20.16.25 # I just soldered in the new audio-connector LinusN sent me 20.16.37 # and the connection was still bad 20.16.42 # so I poked around a little 20.16.51 # and found that the ground channel was bad 20.17.15 # so I reheated/resoldered the tiny smd resistors that were the first inline with it 20.17.19 # and .. it works:) 20.17.24 # I feel like a pro 20.17.26 # heh;) 20.21.15 # what was the problem? 20.22.06 # well 20.22.13 # it seems it was not the connector itself 20.22.18 # but the small smd resistors 20.22.26 # they sit on the "screen" side of the pcb 20.22.57 # I mean why you resoldered again? What was you problem in the first place? 20.22.59 # if you look at the pcb with the screen towards you, they are the two small components at the very top left 20.23.04 # well 20.23.09 # the sound was breaking up 20.23.15 # I thought it was the connector itself 20.23.50 # breaking up? Like one time you have sound and then you don't ? 20.24.01 # yeah 20.24.04 # actually 20.24.07 Quit muesli_- (Read error: 110 (Connection timed out)) 20.24.09 # it was only the ground channel 20.24.15 # so the sound was "hollow" sometimes 20.24.17 # hmm interesting... 20.24.19 # I could bend the connector 20.24.23 # and it would sound fine 20.24.42 # I have something like this whenver I poke the plug with my finger 20.24.46 # turns out the reason the sound was fine when I was bending, was because I was bending the pcb itself 20.24.48 # mhm 20.25.08 # I got like this when I once dropped the iriver, with my headphones plugged in, and it landed on the plug itself 20.25.40 # also I hear clicks when a fadein/out is commenced or I change the volume (very faint clicks) 20.25.57 # I have never dropped mine 20.26.42 # <_FireFly_> the faint clicks have i also when changing the volume sometimes when i navigating in the tree 20.26.50 # but maybe I will need your advice about that, maybe my problem with clicks is related to yours (well at least I have the same with you when I poke the plug so) 20.27.00 # I dont have clicks 20.27.11 # _FireFly_: not with the remote 20.27.16 # main unit 20.27.30 # and these clicks appear on fade out it on the iriver fw too. 20.27.35 # so it is harware related and not a rockbox bug. 20.27.59 # _FireFly_: But please play with fade in/out settings on iriver fw and teel me your results 20.28.03 Quit Philip_0729 ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 20.30.39 # <_FireFly_> i can find only fade in on the iriver fw 20.30.47 # <_FireFly_> as option 20.31.25 # when I say clicks on fade in/out: It is like very small gaps with no sound (very very small but audible) 20.31.31 # yes I must be wrong 20.31.39 # only fade in for the iiver 20.32.09 # does it maks those little faint gaps when it fades in after a pause or stop? 20.32.45 # <_FireFly_> no or i can't hear it 20.33.09 # then my plauer is faulty as I thought 20.34.04 # also sometimes I can hear a very faint click on track changes (on iriver firmware) but I am not sure about it. (I think that in the past I hadn't such problem.) 20.34.16 # maybe I will look at the audio connector again 20.35.08 # sounds very wierd that the connector would do anything like that 20.35.39 # yes 20.35.47 # that might not a be a connector problem 20.35.56 Quit Kohlriba ("Leaving") 20.36.01 # and as I think more of it, it can't be the connector to blame 20.36.10 # but what can it be? 20.37.34 # I don't know;) 20.39.24 # for the record, the resistors that caused my problems were L5 and L6 20.40.45 Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-136-189.pools.arcor-ip.net) 20.40.53 Quit Kohlrabi (Client Quit) 20.42.08 Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-136-189.pools.arcor-ip.net) 20.43.39 Quit Kohlrabi (Client Quit) 20.44.59 # ok thanks 20.45.48 Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-136-189.pools.arcor-ip.net) 20.47.50 Join POP|OPP|PPO [0] (i=OPP@c-24-12-189-55.hsd1.il.comcast.net) 20.47.51 # Hello 20.47.58 # do Archos' use 2.5 ide? 20.48.04 # for hard drives 20.48.42 Quit Kohlrabi (Client Quit) 20.48.50 Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-136-189.pools.arcor-ip.net) 20.48.52 Quit Kohlrabi (Read error: 104 (Connection reset by peer)) 20.49.50 Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-136-189.pools.arcor-ip.net) 20.57.49 *** Saving seen data "./dancer.seen" 20.59.06 Quit Kohlrabi ("Leaving") 21.01.29 Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-136-189.pools.arcor-ip.net) 21.01.37 Quit Kohlrabi (Read error: 104 (Connection reset by peer)) 21.02.06 Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-136-189.pools.arcor-ip.net) 21.24.22 Quit muesli- (Read error: 110 (Connection timed out)) 21.56.27 Join TiMiD [0] (n=TiMiD@asgard.valombre.net) 22.00.52 Quit Kohlrabi (Nick collision from services.) 22.00.56 Join Kohlriba [0] (n=Kohlrabi@dslb-082-083-136-189.pools.arcor-ip.net) 22.09.34 Quit mashalla (Read error: 110 (Connection timed out)) 22.11.07 Join muesli_- [0] (i=muesli_t@Bc154.b.pppool.de) 22.12.51 Join muesli- [0] (i=muesli_t@A98d9.a.pppool.de) 22.20.33 # TiMiD ? 22.22.18 # yes ? 22.22.23 # hi all ! 22.22.35 # we will french fried tonite ;) 22.22.38 # have 22.23.07 # oww 22.23.20 # ->soccer ;) 22.24.57 # soccer ? 22.25.02 # football 22.25.03 Quit _FireFly_ (Read error: 113 (No route to host)) 22.25.31 # you go to play football in the night oO 22.25.54 # naah...its france vs germany tonight 22.26.07 # but 0:0 so far 22.26.09 Join Moos [0] (i=DrMoos@m79.net81-66-158.noos.fr) 22.26.18 # mooos 22.26.21 # Hello all! 22.26.22 # okkkkk 22.26.28 # hi Moos 22.26.32 # another fried french ;) 22.26.37 # Salut 22.26.40 # * TiMiD doesn't like soccer ... 22.26.41 # yeah :) 22.26.56 # 0-0 but Germany play fine 22.27.47 # muesli: french team is'nt like few years old 22.28.14 # now it's "easy" to win it 22.29.02 # but they can still feed from their credits 22.29.16 # henry is a god 22.29.24 # :) 22.29.30 # I don't like it 22.29.41 # doesnt matter how bad the rest it he can win the game alone 22.30.48 # muesli: Zidane is a God XD 22.31.32 # true too :D 22.31.39 # zizou 22.31.41 # ;) 22.31.43 # :) 22.32.24 # but henry got 3 times best scorer in premiere league..thats awesome either 22.33.03 # 1st league it's easier to make goal 22.33.14 # not like in Italia or Espana ;) 22.33.31 # ;) 22.33.42 # but i guess france will win today anyway 22.34.14 # Olympique Lyonais is a good team, maybe it will do a good Champions League 22.34.20 # they are doing next to nothing at the moment but once they will have a chance france will use it 22.34.57 Quit muesli_- (Read error: 110 (Connection timed out)) 22.35.10 # yeah..moderator told they won the french champiosnship 4x in a row 22.35.45 # 2 years ago AS Monaco 2nd best team in Champions League 22.35.54 Quit Kohlriba ("Leaving") 22.36.03 # anyone upgraded the archos HD? 22.36.25 Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-136-189.pools.arcor-ip.net) 22.36.49 # muesli: OL is a good team cause his president is bilionaire 22.36.55 # lol 22.36.59 # who is it? 22.37.10 # money rulez the world ;) 22.37.21 # Jean Michel Aulas, one of the french who have got the more of euros :) 22.37.39 # POP|OPP|PPO i guess you want to know if archos' are using 2.5 drives 22.37.40 # ? 22.38.42 # muesli: Aulos is a bit like Chelsa Russian presidant ;) 22.38.57 # ;) 22.39.08 # no i know that 22.39.16 # ok 22.39.16 # I want to know if anyone as upgraded 22.39.26 # I read the manual on the website 22.39.32 # it makes a little sense.. 22.39.34 # the firmware? 22.39.40 # HD upgrade 22.40.14 # you probably can change your HD yes with the same size of original one 22.40.18 # did you tried it here http://forums.rockbox.org/index.php#1 22.40.42 # do any retailers still sell the old archos' 22.40.50 # i saw one at compusa but no one helped me.. 22.42.29 Join paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) 22.45.49 Join ashridah [0] (i=ashridah@220-253-121-144.VIC.netspace.net.au) 22.46.27 # stand by for my BMP change commit 22.47.02 Join _FireFly_ [0] (n=FireFly@p54A472CE.dip.t-dialin.net) 22.51.08 # what does it do? 22.51.36 # http://www.rockbox.org/mail/archive/rockbox-dev-archive-2005-11/0100.shtml 22.52.06 Quit ehntoo (Remote closed the connection) 22.52.12 Quit POP|OPP|PPO () 22.52.58 Join ehntoo [0] (n=ehntoo@24-177-146-220.dhcp.mrqt.mi.charter.com) 22.53.19 # so we get a bmp-dir for gfx= 22.53.20 # ? 22.53.26 # yes 22.53.37 # and a wps dir 22.53.52 # the bmp dir should be named like the wps itself 22.54.03 # very kewl :D 22.54.24 # so abc.wps ->abc directory? 22.54.30 # yeps 22.54.43 # do we have to change our wps? 22.54.48 # yes 22.54.54 # hm, no 22.55.02 # not if you didn't use any path before 22.55.15 # just create a dir and move the bmps to that 22.55.15 # no, i did not 22.56.16 # very good idea 22.56.29 # I think it is a step forward 22.57.01 # definitively..those x bmps in .rockbox are quite messy 22.57.07 # indeed 22.57.50 *** Saving seen data "./dancer.seen" 22.59.09 # That's one small step for Bagder ; one giant leap for rockbox 22.59.12 # :) 22.59.17 # :-) 22.59.20 # lol 22.59.34 # and the patch for it was surprisingly small 23.00.17 # btw didnt know that Bagder is an animal before i'Ve seen it in a dictionary ;) 23.00.29 # badger is an aminal 23.00.32 # bagder is not 23.00.43 # ah 23.00.46 # tricky ;) 23.01.31 # Bagder: Do you have any ideas about my ARM and ICODE problem? (see today's IRC logs) 23.05.03 # no idea 23.05.57 # I noticed your commit about it and was a bit curious ;-) 23.09.36 Quit ender` (Read error: 113 (No route to host)) 23.14.06 Join ender` [0] (i=ychat@84.52.165.220) 23.21.21 # Bagder: Yellow build alert 23.22.26 Quit _FireFly_ (Read error: 113 (No route to host)) 23.25.15 Quit muesli- (Read error: 110 (Connection timed out)) 23.34.02 # i soldered RTC in my iriver ihp120 23.34.13 # now need to write a driver for it 23.35.07 Join _arkascha [0] (n=arkascha@xdsl-195-14-205-192.netcologne.de) 23.41.28 Quit arkascha (Read error: 110 (Connection timed out)) 23.45.44 # nice XShocK 23.47.03 Join lokki [0] (n=d5bd9cb5@labb.contactor.se) 23.49.01 # so does this basically mean you will have all the cool features like clock calendar wakeup in the morning etc? 23.53.43 # i didn't add wakeup. 23.53.53 # will add it later 23.55.09 # have a floating pin of an interrupt. i first want it to work just ac a calendar and clock, when everything is bug free will add wakeup 23.55.21 # ok 23.56.11 # that would/will be amazing 23.57.45 # can you set up a wiki page about it? 23.58.08 # pic could be fun :) 23.58.49 # ok. i will