--- Log for 02.10.108 Server: card.freenode.net Channel: #rockbox --- Nick: @logbot Version: Dancer V4.16 Started: 18 hours and 59 minutes ago 00.03.11 # linuxstb: did you investigate the decompressing of SansaV2 OF on an emulator ? 00.03.36 # funman: No, but I think I found the problem... 00.04.20 # In "uclpack", the so-called "in-place" decompression function requires an "overhead" of (block_size / 8) + 256 - so about 16KB for our image... 00.04.54 # So I think we need to "memcpy" it somewhere (e.g. the end of DRAM) before uncompressing. 00.05.22 # what's the D in DRAM ? 00.05.22 Quit toffe82 ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092417]") 00.05.41 # Err.... Not sure ;) 00.05.46 # :o 00.05.50 # Dynamic... 00.07.00 # let me try this trick 00.07.29 # ... it's also typically SDRAM these days 00.07.43 # like in Static AND Dynamic ? 00.07.54 # no, synchronous 00.08.06 # ok 00.10.01 # windows Ipod - plays wma too ;) 00.11.32 # oh bounce! ;-) 00.11.50 Join toffe82 [0] (n=chatzill@h-74-0-180-178.snvacaid.covad.net) 00.12.41 Quit lacrstech (SendQ exceeded) 00.13.23 Join midgey_ [0] (n=tjross@141.211.151.61) 00.17.15 Quit bertrik ("Leaving") 00.17.46 Quit ender` (" If at first you don't succeed, skydiving is not for you.") 00.19.29 Join MarcGuay_ [0] (n=chatzill@ip216-239-89-167.vif.net) 00.20.43 # linuxstb: I think you are right .. 00.21.52 # funman: It's working now? 00.22.20 # anyone else get the following flyspray error when attempting to log in? 00.22.20 # Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 35 bytes) in /usr/share/flyspray/htdocs/adodb/adodb.inc.php on line 2859 00.22.23 # if I use an infinite loop instead of branching to #0, it 'works' 00.22.30 # let me dump the memory to check 00.23.44 Join freqmod_qu [0] (n=quassel@iskrembilen.com) 00.24.09 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 00.24.11 Join Zarggg [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 00.24.18 # yes it works 00.24.29 # * funman looks frag damn ! 00.25.12 Join perrikwp [0] (i=d1a8d351@gateway/web/ajax/mibbit.com/x-22d0d12bb023089c) 00.25.38 # funman: OK, now flash it to your Clip ;) 00.25.56 # * linuxstb looks around for fragilematter 00.25.56 # hm I'm still a bit reluctant 00.26.24 # So what happens when you remove the infinite loop? 00.27.01 # SKYEYE:Error in mem_read_word, no bank found, NumInstrs 12930564, mem_read_word addr = c80f0014 no bank 00.27.26 # pc was 0x100, maybe we can check what this is in the firmware 00.27.54 # Which OF version are you using? 00.28.01 # 17 00.28.18 # RandalSchwartz: http://www.rockbox.org/twiki/bin/view/Main/IpodConversionToFAT32 00.28.21 # if it's the same than v29 : vector software interrupt ? 00.29.21 # (an infinite loop) 00.30.10 # isn't there a way to address a register so it is incremented by the offset we give after the instruction ? 00.30.27 # Ok, little bug: http://www.rockbox.org/tracker/task/9428 killed by me in two different ways. Take your pick! (Requesting commit) 00.30.41 Quit midgey (Read error: 110 (Connection timed out)) 00.31.11 Join midgey [0] (n=tjross@141.211.88.159) 00.31.20 Quit domonoky (Read error: 104 (Connection reset by peer)) 00.32.09 Quit mcuelenaere () 00.32.26 Quit MarcGuay (Read error: 110 (Connection timed out)) 00.32.27 Join webguest04 [0] (n=4cf40cba@gateway/web/cgi-irc/labb.contactor.se/x-68c39dba2142a026) 00.32.47 Nick HBK- is now known as HBK (i=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 00.33.51 # funman: Hmm, yes. So I would be quite confident - it looks like the OF is running fine, and then hitting an exception when an invalid memory access is attempted 00.34.27 # It is running fine - in a simulator 00.34.34 Quit webguest04 (Client Quit) 00.34.43 # choose your pill 00.35.17 # We could just test it on another target 00.36.12 # hm now it says something else: pc 0x1390 (but I have modified my memcpy code) 00.38.21 # well the decompressed firmware is OK 00.39.40 # Weird, one of the c100s I got is showing up as a TCC7801... 00.39.53 # Err, revert that. 00.40.03 # well it loops waiting for some hardware register to change 00.40.41 # http://paste.ubuntu.com/52998/ 00.41.07 # I'm not sure of the ram size .. 00.41.10 Quit FRiZzO (Read error: 110 (Connection timed out)) 00.42.25 # Does sendfirm just drop whatever you give it in the drive root? 00.42.37 # this floss weekly should post on friday, watch twit.tv/floss for details 00.42.41 Quit tvelocity (Read error: 104 (Connection reset by peer)) 00.42.44 # 2.5Mbit 00.42.52 # RandalSchwartz: good show! 00.42.53 Quit midgey () 00.42.54 # funman: you copy the whole firmware to the end of the ram? linuxstb only talked about an overhead of 16K 00.42.57 # thanks 00.43.01 # that was fun 00.43.02 # I like demo 00.43.05 # RandalSchwartz: did you spot the conversion link I posted? 00.43.11 # kugel: Read my later comments 00.43.13 # yes thanks 00.43.17 # kugel: why not using the maximum ? :) 00.43.54 # RandalSchwartz: Thanks again for having me. 00.44.15 Quit midgey_ (No route to host) 00.44.17 # Ahh. thanks for offering yourself! 00.44.24 # "So I think we need to "memcpy" it somewhere (e.g. the end of DRAM) before uncompressing." did you refer to memcpy to firmware or the overhead? 00.44.30 # * Bagder offered Llorean, a very handy approach ;-) 00.44.40 # kugel: funman did what I suggested... 00.44.45 # anyone else wants him? B) 00.44.46 # Yes, the world works better when you can volunteer someone else for the job. :) 00.45.01 # Bagder: im sure some forum users might want him for a bit.... 00.45.07 # yes 0x50000 seems to be 2.5 Mbit . :) 00.45.40 # Maybe 0x40000 would be safer - I seem to recall the OF using memory after that 00.46.01 # scorche: really? Now why would you ever think that? ;) 00.46.48 # [Reg], #1 => will Reg be incremented after being addressed that way ? 00.46.53 Quit bluebrother ("bye") 00.47.23 # I'm glad we did 3.0 before this interview anyway ;-) 00.47.42 # funman: Yes, I think so 00.47.55 Quit faemir (Remote closed the connection) 00.47.55 # Bagder: Yeah, having 3.0 out in time for it is kinda nice. 00.48.05 # Next time, though, I'll skip the hurricane and just ask if we can do it a little later. 00.48.27 # :-) 00.48.30 # you arranged the hurricane? 00.48.39 # Of course 00.49.03 # You just need to catch the right butterfly 00.49.26 # linuxstb: why do you think 0x40000 would be safer ? 00.51.02 Quit herrwaldo ("Konversation terminated!") 00.51.18 # funman: Why not copy it just far enough that it decompresses without overlap? 00.51.37 Quit DerDome (Read error: 104 (Connection reset by peer)) 00.51.50 # why bother ? 00.51.53 Join DerDome [0] (n=DerDome@dslb-082-083-192-224.pools.arcor-ip.net) 00.51.57 # Iiuc the goal is to keep changes in memory to a minimum, because you don't know yet what is where? 00.52.07 # nope 00.52.17 # funman: Those was my thoughts... 00.52.28 Join midgey [0] (n=tjross@141.211.88.159) 00.52.43 # well I assume the AMS bootloader doesn't initialise memory 00.53.03 # so when the OF runs it is presented with memory in an 'unknown' state, and initialises it when needed 00.53.28 # funman: I did think that maybe there was more than just the main firmware block loaded into RAM, but I think that's unlikely now. 00.54.13 # that may be possible 00.54.46 # * amiconn wouldn't assume such things about bootloaders 00.55.16 # The ipod OF relies on several things initialised properly by its bootloader (e.g. the LCD) 00.55.37 # the clip firmware clears ~ 0x7000 bytes after the end of the firmware 00.55.47 Join tvelocity [0] (n=tony@gw1.mycosmos.gr) 00.56.00 # bss, probably 00.56.06 # amiconn: but those are hardware settings, not memory ? 00.56.19 Join einhirn [0] (n=Miranda@p5B031183.dip0.t-ipconnect.de) 00.56.21 # amiconn: Although the AMS SoC seems to have a more generic bootloader in the internal ROM, rather than a device-specific bootloader like our other targets. 00.56.29 Quit matsl (Remote closed the connection) 00.56.52 # So I think it will just do the minimal hardware initialisation, and load the firmware from the NAND flash. 00.57.03 # linuxstb: do you understand how the compressed and decompressed datas can 'overlap' ? 00.57.12 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 00.57.28 # Yes. We basically need to memmove the OF image 16KB forwards in RAM. 00.57.44 # Just 16KB? 00.57.47 # 0x7000 > 2*16KB 00.57.58 # it's funny, but we're still on twice the pre-release daily visitor amount on the main web site 00.58.07 # maybe a 4th word in the test.S which says how much we have to shift ? 00.58.09 # Yes, if we compress with a block size of 12KB 00.58.13 # I mean 128KB 00.58.13 # I thought you need to move the compressed data upwards so that it end lines up with where the decompressed data will end 00.58.22 # oh, it's fixed 00.58.22 # *its end 00.58.28 # exactly 16kB 00.58.58 Join perrikwp [0] (i=982137d4@gateway/web/ajax/mibbit.com/x-aafba863378953a7) 00.58.58 # funman: It's technically (block_size / 8) + 256 - so a little more than 16KB if we compress with a 128KB block size 00.59.01 # amiconn: this appears to not be enough 00.59.33 # amiconn: I was wrong - I missed the "overhead" added in the official uclpack when performing so-called "in-place" decompression 00.59.53 # See the "do_decompress()" function in uclpack.c 01.00.05 # Bagder: Well, I mean I would expect it to settle at a point at least somewhat higher than the original value. 01.00.07 # Is this an additional overhead? 01.00.35 # Yes - the buffer to decompress a block needs to be "block_size + overhead", with the compressed data located at the end of that buffer 01.00.36 # Llorean: I can't say I expected it, but I'm enjoying it! ;-) 01.00.45 # aha 01.01.06 Join JamesR87 [0] (n=5205fcf3@gateway/web/cgi-irc/labb.contactor.se/x-0c1ed527f6c67a0c) 01.01.07 # Bagder: I had the numbers for hits and unique visitors sitting in front of me in case the topic of expanded notice since 3.0 came up 01.01.08 # Why not just compress into a single block, like we do for archos, btw? 01.01.17 # Yes, we do. 01.01.27 # linuxstb: is 'MAINT' a define of rockbox, or something from the original UCL package ? 01.01.41 # linuxstb: So the OF is <128KB? 01.01.42 # Quick question: Is my 80Gb iPod classic still not supported by Rockbox? 01.02.08 # funman: Everything in that .S file is from the original UCL package - I committed the unmodified version to SVN first, so you can see what I changed. 01.02.12 # amiconn: Yes, about 110KB 01.02.17 # wow 01.02.19 Join n17ikh|Lappy [0] (n=n17ikh@130-127-73-84.lightsey.resnet.clemson.edu) 01.02.23 # linuxstb: no I meant in uclpack.c (I was checking the block size used) 01.02.33 # amiconn: Or rather, there's a main firmware block which is that size, plus lots of library blocks, taking the entire image to about 5MB 01.02.51 # JamesR87: The supported players are listed on the front page of the site. 01.02.56 # We'll update that list if things change. 01.03.05 # We're just manipulating the main firmware block of the OF image. 01.03.54 # Le sigh, just seeing if there was any updates :> Cheers anyway! *Goes to find a different alternate firmware* 01.04.12 Quit bmbl ("Woah!") 01.04.26 *** Saving seen data "./dancer.seen" 01.04.37 # i don't think there is any alternative firmware for classics yet 01.04.52 # JamesR87: If you do find one, let us know. We haven't gotten to the point where we can even load our own code, so any information they have would be useful to us. 01.07.18 # funman: It works ;) 01.08.17 # funman: I changed your 0x50000 to 0x40000, flashed it to my Clip, and rebooted fine... 01.08.44 Quit MethoS- (Remote closed the connection) 01.08.55 Quit JamesR87 ("CGI:IRC (Ping timeout)") 01.09.33 Quit n1s () 01.11.17 # :) 01.11.42 # please commit and retest, so I'm sure I didn't make a typo since 01.12.24 # * linuxstb pours a large whisky 01.12.39 # * funman 'll go for rhum 01.14.18 Quit Thundercloud (Remote closed the connection) 01.14.26 # cheers linuxstb ! 01.15.24 # Cheers... Second test worked as well, so I'll commit. 01.18.18 Join kugel_ [0] (n=chatzill@e178108180.adsl.alicedsl.de) 01.18.33 Quit kugel (Nick collision from services.) 01.18.46 Nick kugel_ is now known as kugel (n=chatzill@e178108180.adsl.alicedsl.de) 01.18.55 # Exactly how unacceptable is increasing RAM usage on PP and iMX31 by about 500 bytes to allow for easier merging of the TCC USB stack? I don't like it at all, but the alternative seems to be lots of static configuration which I'm afraid will bite us later on 01.19.20 Quit einhirn (Read error: 104 (Connection reset by peer)) 01.19.54 # gevaerts: If it makes the code simpler and easy to maintain, then I think it's worthwhile. 01.20.01 # s/easy/easier/ 01.20.43 # funman: Committed. 01.21.21 # funman, linuxstb: great work 01.22.05 # does this work on any firmware and for every v2? 01.23.11 # linuxstb: patched 01.23.37 # kugel: no 01.23.50 # linuxstb: it's not exactly simpler than it is now (although it's not really more complicated either), but the current code has some assumptions about how a usb controller works that aren't true for tcc 01.24.10 # current code assumes that the decompressor function will fit in the last block of your firmware 01.24.11 # kugel: It should be easy to adapt to any firmware though. However, currently it requires about 170 bytes in the padding. 01.24.38 # But we can just memcpy that function as well, so store it in the main firmware block area 01.25.35 # or just calculate compressed OF offset so the function just fits 01.25.46 # IIRC there's only 88bytes in the fuze firmware 01.25.59 # in the firmware block 01.26.09 # funman: No, the function will then get overwritten when it's busy decompressing the OF 01.26.14 Part toffe82 01.26.21 # oops right 01.26.50 # But we could just put it before the compressed OF image, and memcpy them both together 01.26.58 # btw can you close FS#9396 ? it's useless now 01.28.17 # funman: Done. 01.28.17 Quit ZincAlloy ("CGI:IRC (EOF)") 01.28.18 Quit DerDome ("Leaving.") 01.28.48 Join krazykit [0] (n=kkit@host-69-145-35-234.static.bresnan.net) 01.28.50 Join Bawitdaba [0] (n=Sphinx@cpe-72-224-114-36.nycap.res.rr.com) 01.29.57 # funman: I think it's now time to create a Clip target in the build system and work on the drivers... Is atomicpunk also hacking the Clip, or another target? 01.30.43 # linuxstb: yes it's a good idea. atomicpunk is only hacking the Clip (his m200 is dead) 01.31.09 # gevaerts: I think you're worrying too much - unless others disagree... If you're making the code more general (with good reason), then I don't see any reason to object. 01.31.42 # * scorche wonders if it is about time to take his clip out of his sock drawer 01.31.44 # linuxstb: ok. I'll make it work tomorrow (it doesn't currently), and then commit. 01.32.22 # scorche: I had forgotten how tiny it is... 01.32.36 # linuxstb: indeed...nice screen though 01.32.48 # linuxstb: I can start doing that tomorrow 01.33.37 Join saratoga [0] (n=9803c264@gateway/web/cgi-irc/labb.contactor.se/x-8b2db7d04ba69816) 01.33.38 # funman: So any chance for this to work on the fuze firmware? 01.33.59 # kugel: yes, it will require just a bit more hacking 01.34.17 # congrats guys 01.34.49 # indeed 01.35.17 # thanks ;) 01.36.07 # saratoga: seems like we have to get it to work on our fuzes first 01.36.28 Quit moos ("Rockbox rules the DAP world") 01.37.58 # kugel: Did the old mkamsboot work on the fuze? 01.38.30 Quit Schmogel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 01.38.30 # only the c200 was untested I think 01.41.26 # linuxstb: yes, but the the code inserted wasn't 170KB 01.41.33 # bytes* 01.41.58 # so the fuze firmware might not have enough space available? 01.42.16 # saratoga: With SVN mkamsboot, yes. But we can fix it now. 01.42.24 # it turned out the padding in the firmware block can give 88bytes 01.42.39 # i.e. we won't use the padding at all. 01.43.02 # how about waiting to use proper crt0 and the linker ? 01.43.08 # where to store the decompressor else? 01.43.30 # anywhere in our 40kB available 01.43.47 # and copy it in RAM, after the OF size, before executing it 01.46.46 # ah 01.46.48 # dang 01.46.50 # right 01.47.30 # forgot that the compression gives us space for the decompression :S 01.48.25 Join setkeh [0] (n=setkeh@CPE-124-181-6-74.vic.bigpond.net.au) 01.48.31 # hola 01.48.42 # linuxstb: I think as a first step we can use the git repository for Clip code 01.49.28 # and when we make significant progress you can check-in into the rockbox SVN repository 01.49.38 # fdinel: hola (: 01.50.22 # funman: I would prefer to see things committed to Rockbox SVN - that way, lots of eyes will see the code as it develops. 01.50.26 # funman: so why exactly does this not work on the fuze out-of-the-box again? 01.50.29 # how can i get .wps files to work ??? 01.50.50 # kugel: Because the ucl decompression function is stored in the padding. 01.51.22 # linuxstb: ok .. 01.51.28 Quit PaulJam (".") 01.51.29 # now I'm confused 01.53.05 # kugel: About what? 01.53.20 # setkeh: what's happening, what did you try, what player do you have, how did you install them etc... please give more information 01.54.16 # ok: is this right: as of the decompression code is in the padding, but in the future, we're going to put it right before the compressed OF where then ~40KB is available 01.54.40 # pixelma, 5g ipod video in copyed the files for the theme into there respective folders the theme file seems to be working fine but the .wps looks like its not working 01.55.08 Quit krazykit ("Connection reset by beer") 01.55.10 # ? 01.55.13 # kugel: yes 01.55.23 # ok cool 01.55.30 # linuxstb: yeah I'm also hacking on the clip ;) 01.55.33 # and we are gonna copy this code somewhere else in case we want to decompress the OF over it 01.55.38 # * fdinel is atomik punk 01.56.01 # is it big? 01.56.04 # have you noticed the great success? 01.56.17 # the clip port will be very interesting 01.56.28 # fdinel: The uncompress code is about 166 bytes 01.57.08 Join chibiluke [0] (n=516338ab@gateway/web/cgi-irc/labb.contactor.se/x-d4fb1de449d25f4f) 01.57.08 # funman: I'm working on that now, so I'll be asking you to test on your emulator setup shortly... 01.57.10 # setkeh: I guess you got a broken theme/wps then. There was a change in wps syntax a short while ago that broke a lot of them. You could either try other ones or try to fix them yourself. Where did you get the themes from by the way - Rockbox wiki or something else? 01.57.31 # linuxstb: ok nice, then hmm why not put it (in RAM) past the OF "section"? 01.57.54 # saratoga: hopefully linuxstb and fdinel won't do all the work and leave a bit to the others ! 01.57.55 Quit chibiluke (Client Quit) 01.58.13 # pixelma, http://rockbox-themes.cleansoap.org/index.php?res=320x240x16 thats the place i got them from i think ill just go to the wiki to get them :P 01.58.20 # funman: they'll need Nico_P's buffering from flash patch at least 01.58.24 # linuxstb: ok - I'll get to bed shortly 01.58.36 # funman: no worry, you're coding too fast for me :P 01.58.43 # Well, better someone does more than others instead of many people doing nearly nothing 01.58.45 # funman: how difficult is it to setup the skyeye anyway? 01.58.58 # pixelma, does the wiki have an updated tutorial like this http://www.rockbox.org/twiki/bin/view/Main/CustomWPS for makeing .wps files ?? 01.59.01 # saratoga: what's nico_p's flash patch ? 01.59.26 # funman: a different version of the buffering code for ultra-low mem targets 01.59.26 # saratoga: the most difficult part is finding the rare, badly translated from chinese documentation 01.59.43 # setkeh: yes. the CustomWPS page is up to date and there is also a thread in the forums that explains the changes 01.59.49 # does it run an OS inside the emulator, or do you just point it at an elf binary? 01.59.56 # saratoga: http://forums.rockbox.org/index.php?topic=14064.msg135946#msg135946 02.00.09 # pixelma, thank you heaps mate :D 02.00.22 # it uses an elf binary, but I load the firmware at offset 0 and my elf binary is mov r0, #0; bx r0 02.01.24 # is it expandable if we wanted to try faking hardware and running binaries? 02.01.47 # Probably, but it may involve hacking skyeye 02.02.24 # There is a number of boards supported, an lcd screen (which I didn't use) 02.03.03 # we have documentation for most of the V2 hardware right? 02.03.10 # might be fun to try emulating a sansa 02.03.21 # uart, touchscreen, network, sound .. 02.03.26 # Do we have an arm v5(te) target? D2, maybe? 02.03.27 # flash .. 02.03.35 # looks quite complete 02.03.44 # bah a WMA bug report 02.03.48 # saratoga: do we have infos about the different LCDs? 02.03.50 # i need to get caught up on those 02.04.07 # kugel: i assume thats handled by the AMS controller? 02.04.24 # uart, touchscreen, network, sound, flash <= that's what skyeye can emulate, not which docs we have 02.04.33 # I haven't read the docs (I didn't ask for them yet), so I don't really know 02.05.12 # theres no other chips on some of the V2 parts (clip) so I think its all AMS stuff 02.05.22 # funman: I've done it very quickly, so it's likely to be wrong, but here's a first attempt - http://www.davechapman.f2s.com/rockbox/quick.diff 02.05.31 # SanDisk added their own chips 02.05.47 # yeah 02.05.57 # seems like the Soc got "upgraded" 02.06.14 Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) 02.06.24 # we suspect they inserted an SD-to-NAND interface somewhere 02.06.27 # amiconn: All the telechips devices are armv5, so yes, the D2, plus the m200, DAX etc 02.06.47 # Plain v5 or v5te? 02.07.51 # linuxstb: oops 02.07.59 # In at91rm92_io_read_word, io error, addr=0xfffffff0 02.08.18 # skyeye exits so I don't have any control on the debugger 02.08.31 # amiconn: I believe its the 946 which is v5te 02.08.31 Join mmadia [0] (n=chatzill@pool-138-89-96-141.mad.east.verizon.net) 02.08.34 # amiconn: The D2 has an arm946e-s (v5te) and ARM926EJ-S (v5tej) 02.08.40 # goodie 02.09.19 # yes should give the Gigabeat F a run for it money, once for each core 02.09.19 # Of those, only the D2 already plays music 02.09.45 # now is time to sleep, and tomorrow time to code :=) 02.09.46 # * amiconn was asking because of the SMLA instruction 02.09.59 # see you guys 02.10.02 # keep up ! 02.10.12 Quit funman ("leaving") 02.10.20 # saratoga: Yeah, the F and X are arm9, but only v4t 02.10.21 # And the tcc77x devices (DAX etc) are arm946es as well 02.10.36 Join Strife89 [0] (n=michael@204.116.245.152) 02.10.37 # Isn't the iaudio7 using a similar cpu? 02.10.44 # Yes, tcc77x 02.10.56 # And it already plays music... 02.11.06 # The "x" just defines what peripherals there are - codecs, NOR flash, built-in RAM 02.11.14 # This is odd. I tried to apply the "Pong Upgrades" patch and this happens. 02.11.16 # http://pastebin.com/m44b6ded1 02.11.49 # Removing the patch (with --remove) doesn't fix it, so...... I'm stuck. 02.12.21 # amiconn: I'm not sure if it plays music - maybe just test sounds... The flash driver isn't working very well. 02.12.54 # seems like USB is well along though 02.13.05 # can't be long before vitja turns his attention to flash 02.13.43 # Everyone seems to be avoiding the challenge... 02.14.07 # Pong upgrades patch is here if someone wants to look: http://www.rockbox.org/tracker/5855 02.15.05 Quit tvelocity (Remote closed the connection) 02.15.07 # amiconn: Presumably the beast has those instructions as well? 02.15.32 # linuxstb: v6 has even better instructions for speeding up the demac filters 02.16.10 # But I mean if you wanted to implement it, you could test on the beast... 02.16.18 # But on v5te the mentioned instruction would at least allow a bit of speedup versus C code or the armv4 code 02.16.24 # yeps 02.17.17 # Have you done any APE benchmarks yet on the S? 02.17.24 # But comparing the speeds on a v6 wouldn't give a realistic comparison of how it would behave on a v5te 02.17.33 Quit maddler ("connection reset by beer!") 02.17.38 # Yes, I'm aware of that, but at least you could get it working. 02.17.43 # yup 02.17.56 # No, I didn't do speed measurements yet. 02.18.00 # For those who didn't catch the pastebin, I applied a patch and, when I make, make skips almost everything. This wouldn't be a problem if --reverse worked, but.... it didn't. Now what? 02.18.08 # * amiconn needs to do quite a bit of other stuff before 02.18.13 # do a make clean 02.18.54 # Strife89: it only recompiles files which have changed since the previous compilation 02.18.55 # Thanks, saratoga. Didn't think about that..... 02.19.06 # so, everything was fine 02.19.13 # * amiconn wonders why linuxstb didn't use post-increment in his el cheapo memcpy... 02.19.32 # amiconn: Because it was funman's code, and I just committed it because it worked... 02.19.39 # I'm still very new to patching and making (obviously). 02.19.41 # (for r0 at least) 02.19.46 # (and my ARM-fu is rusty...) 02.20.14 # change ldrb r3, [r0] to ldrb r3, [r0], #1 and remove adds r0, r0, #1 02.20.36 Join jfb9301 [0] (n=jfb9301@cpe-67-49-143-82.hawaii.res.rr.com) 02.20.43 # Eh, you can do that for r2 too, as there's a 'cmp' anyway 02.21.03 # Hmm, or is that thumb code? 02.21.09 # No, that ARM code 02.21.17 # ^that's 02.21.37 # How did it go for Llorean today? 02.21.50 # linuxstb: Okay, so reclaim those 8 bytes... 02.21.57 # ;) 02.22.32 # Heh, who was squeezing the decompressor? 02.23.23 Quit saratoga ("CGI:IRC (EOF)") 02.23.42 # Strife89: he performed exceptionally well 02.23.46 # * amiconn wonders why funman even used 'adds' instead of 'add' 02.23.54 # kugel: Good to hear. :) 02.24.56 # amiconn: Yes, I noticed that, but forgot to remove it. But I expect that code will get significantly changed in the near future anyway... Once it gets merged with Rockbox, we can just call memcpy 02.26.08 Quit jfb9301 () 02.26.39 Join jfb9301 [0] (n=jfb9301@cpe-67-49-143-82.hawaii.res.rr.com) 02.26.47 Quit culture (Read error: 110 (Connection timed out)) 02.26.56 # * linuxstb sleeps 02.27.45 Quit webguest54 ("CGI:IRC 0.5.9 (2006/06/06)") 02.27.57 Join mc2739 [0] (n=mc2739@cpe-67-10-238-175.satx.res.rr.com) 02.29.50 Quit Strife89 ("Leaving") 02.31.12 Nick mc2739 is now known as mc2739_ (n=mc2739@cpe-67-10-238-175.satx.res.rr.com) 02.31.34 Nick mc2739_ is now known as mc2739 (n=mc2739@cpe-67-10-238-175.satx.res.rr.com) 02.33.39 Quit jfb9301 () 02.35.08 Join goffa_ [0] (n=goffa@216.220.23.105) 02.35.50 Part mc2739 02.38.26 Join mc2739 [0] (n=mc2739@cpe-67-10-238-175.satx.res.rr.com) 02.41.19 Join toffe82 [0] (n=chatzill@70.135.35.67) 02.44.19 Quit n17ikh|Lappy () 02.45.30 Quit Wictor (Read error: 104 (Connection reset by peer)) 02.45.40 Join Wictor [0] (n=Wictor@0x57366a52.bynxx19.dynamic.dsl.tele.dk) 02.46.23 Quit goffa (Read error: 110 (Connection timed out)) 02.46.31 Join kronflux [0] (i=kronflux@blk-138-78-15.eastlink.ca) 02.49.27 Part pixelma 02.49.59 Join pixelma2 [0] (n=marianne@rockbox/staff/pixelma) 02.50.38 Quit midgey () 02.57.32 Join Waldo000000 [0] (n=roy@203-219-228-242-gee-ts1-2600.tpgi.com.au) 03.02.19 Quit kugel ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092417]") 03.04.28 *** Saving seen data "./dancer.seen" 03.04.31 Join massiveH [0] (n=massiveH@ool-44c48a1e.dyn.optonline.net) 03.06.17 Quit m0f0x (Read error: 60 (Operation timed out)) 03.10.06 Join webguest94 [0] (n=4aaa3bc7@gateway/web/cgi-irc/labb.contactor.se/x-e0664581d1a37406) 03.16.26 # Hi all, for some reason the word acksaw: was already in the field for the web client. hmm. but that's not why I joined. I jsut updated Rockbox to the latest current build as of 15 minutes ago and now can't get it to say anything. I've tried turning the battery switch off and back on (holding down the power button for over 10 seconds didn't do anything) and it still isn't working. I can browse my player throug 03.17.48 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 03.18.13 # webguest94: Did you install the voice file as well? 03.18.25 # Yes 03.19.18 # Also the build I updated from is only maybe 3 weeks old. 03.19.37 # And it spoke fine before? 03.19.52 # Yeah. 03.20.21 # How did you re-install? 03.20.48 # I even tried selecting several times to get to something playable and holding down the volume up button and didn't hear anything 03.21.15 # Using the latest utility, installed a current build 03.21.23 # So there's no sound at all, even music? 03.22.02 # Nope. Should I try putting the old .rockbox back? (I backed it up before updating.) 03.22.13 # It might help to track down the problem. 03.22.34 # ok. 03.23.55 # If it will recognize the player that is... grrr. 03.24.29 # What player do you have? 03.24.50 Quit JdGordon (Read error: 104 (Connection reset by peer)) 03.25.11 # Ah, there we go, ahd to turn teh battery switch off and back on. A gigabeat F 03.25.16 # hi, stupid question: from the file browser, i want to play all files in the selected directory - how do i do that? 03.25.26 # (couldn't see an obvious answer in the manual) 03.26.22 # Press and hold select, then select playlsit, insert. 03.26.38 # Waldo000000: In the context menu you can choose Playlist->Insert. Too slow. 03.27.08 # thanks. kinda non-intuitive. but thanks :) just installed rockbox for the first time :D 03.27.24 # Waldo000000: You'll get used to it. 03.28.47 # and now of course windows Vista won't let me rename the old backup, saying I must type a filename. 03.29.12 # MarcGuay_: yeah, i'm thinking i definitely will, very impressed so far. especially when i'm using an m:robe which was discontinued years ago by olympus, now i have something that is still being updated! love it 03.29.55 # webguest94: you can rename it from a command prompt 03.30.17 # is anyone here using an olympus m:robe, and if so do you mainly use the file browser or database? is it good to avoid using the database if you don't need to, to save battery? 03.31.09 # mc2739: ah. What command would I use? I sometimes mess around with the prompt, but haven't renamed files/folders before 03.31.20 Join MrHacks [0] (n=bushidoh@97-85-145-160.static.stls.mo.charter.com) 03.31.45 # Hey guys. I have a status update on my H120 03.32.24 # My time is limited. The laptop I am temporarly using is bad. If I were on my main computer it would be different. 03.32.26 # mc2729: ah never mind, got it 03.32.29 # webguest94: move .rockbox rockbox-bu 03.32.56 # I decided to do the last thing you should ever do with the device: Disassembly 03.33.06 Join montag_ [0] (n=18bd042c@gateway/web/cgi-irc/labb.contactor.se/x-89b5d4fb05110c85) 03.33.46 # After removing the harddrive, I found out that the problems with the firmware 03.34.03 # Battery is OK. Harddrive is OK. 03.34.10 # hmm. the old build works perfectly. 03.34.12 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 03.35.17 # webguest94: That's odd. I don't have an F but I'll give it a try and see if I have the same problem. 03.35.20 Join kugel [0] (n=chatzill@unaffiliated/kugel) 03.35.27 # should I try reinstalling the new build? 03.37.25 # JdGordon: ping 03.37.38 Join Hillshum [0] (n=chatzill@75-165-238-40.slkc.qwest.net) 03.37.39 # ping??? 03.38.09 # I have been trying to add album art to my music files but they do not show up in my ipod video with Rockbox 03.38.21 # how do i make it work 03.38.28 # AlbumArt wiki page. 03.39.06 # can't find that page, where is it? 03.40.11 # JdGordon: (for the logs) It seems you've been quite interested in FS#6800 a while ago. I'm wondering if you still are. I've done some work on it, including enabling it for c200 and gigabeat S. You might want to take a look at it. 03.40.21 Quit kugel ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092510]") 03.41.11 # Search the Docs Index. 03.41.36 Join m0f0x [0] (n=m0f0x@189-47-20-8.dsl.telesp.net.br) 03.41.56 # webguest94: Okay I updated to the most recent build, what am I looking for? I presume you had you config.cfg file set to voice? 03.42.09 # thank you soooooo much marcguay 03.43.05 # webguest94: I just turned voices on and they seem fine. Sansa e200 + r18679 03.43.46 # Hmm, just remembered it's not a voice problem, you're getting no sound at all. 03.45.34 # Sorry, was in a noterh window. It shouldn't be a problem, even if RB was completely removed and reinstalled, voice would be enabled by default 03.45.45 Quit montag_ ("CGI:IRC (EOF)") 03.46.16 # * ameyer is not amused by the new sansa usb trick 03.46.36 # * ameyer rebuilds to see if he just had a bad build 03.46.53 # quick! The commands for mounting a usb device! 03.47.38 # webguest94: If you simply install over your old one, the config.cfg which contains your settings should remain. For instance, I have voicing off, and when I update, it remains off. 03.48.26 # webguest94: Oh wait, I just got your point. Ignore me. 03.52.29 # ok - I think I have my 80G ipod FAT-32 and put the ipod software back on 03.52.42 # next step - rock install! 03.52.45 Join Darksair [0] (n=user@221.221.154.208) 03.53.42 # oh, I have to restore my music lib as well 03.54.43 # should I be worried that disk util is reporting it as mac os extended again? 03.54.46 # that doesn't sound right 03.55.08 # did itunes reformat it back as mac? 03.55.14 # (on the restore) 03.56.45 # RandalSchwartz: I presume you've been following the wiki page...? 03.56.54 # Yeah. 03.57.07 # even "mount" shows it sas hfs too 03.57.10 # this can't be good 03.57.53 # Doesn't sound like it took. 03.57.53 # after newfs_msdos -F 32 -S 2048 -v iPod /dev/rdisk2s2 03.58.03 # itunes offered to restore it 03.58.13 # so I said yes, beacuse I want the itunes software on there 03.58.23 # apparently itunes forced it back to hfs. :( 03.58.23 # RandalSchwartz, please do not use the "Enter" key in place of a comma. There is no need for you to post 8 lines in a row. Please consolidate your thoughts. 03.58.59 # RandalSchwartz: iTunes restore (on mac) reformats to HFS+, yes. 03.59.13 # so I can't use itunes with rockbox? 03.59.19 # RandalSchwartz: If you follow all the directions on the wiki page, you *should* end up with iTunes software on there. 03.59.20 # or is there another step? 04.00.04 # But I think I've heard reports similar to yours, where it boots the Apple firmware fine, but iTunes on the Mac just doesn't want to work with it anyway. 04.01.21 Quit Wictor (Read error: 104 (Connection reset by peer)) 04.01.32 Join Wictor [0] (n=Wictor@0x57366a52.bynxx19.dynamic.dsl.tele.dk) 04.03.04 # well - I'll give it another try tomorrow after I read the rest of everything better 04.03.11 # RandalSchwartz: Maybe try the "older, alternative" method...? 04.03.26 # it definitely ended up as HFS though. I don't need that. I need FAT. :) 04.05.56 # so should I just use the older build for now? 04.10.10 # webguest94: Are there any messages on the screen when you try to play music and it fails? 04.10.21 # Not sure, can't see it 04.10.37 # how do i veiw photos from the ipods photo database 04.10.39 # ?? 04.10.41 # webguest94: It would help if you could get someone sighted to check, we need more information before we can give you any better advice. 04.10.54 # setkeh: Rockbox just views jpeg files, accessed through the file browser. 04.11.31 # Llorean, ok thanks mate ill have to remove the photo database then lol cuz i have like 8gb of pics :P 04.11.32 Quit XavierGr () 04.13.02 Join miepchen^schlaf_ [0] (n=miepchen@p579ECEB1.dip.t-dialin.net) 04.14.52 Quit kronflux ("Leaving") 04.20.09 Quit miepchen^schlaf (Connection timed out) 04.20.23 Join webguest64 [0] (n=48afa203@gateway/web/cgi-irc/labb.contactor.se/x-88c33d47d1b0d314) 04.20.47 Quit webguest64 (Client Quit) 04.21.51 # do i need the original ipod firmware to make rockbox work ??? what i mean is if i formatt the ipod using the windows partitioner and install rock box will it still work ?? 04.22.47 # The Rockbox install tools expect a "working" iPod 04.23.22 # While it's possible to install Rockbox on a "clean" iPod, it's considerably more work since you still need to get the partition layout set up in a way that the Apple in-ROM code likes it. 04.24.07 Quit mmadia (Read error: 104 (Connection reset by peer)) 04.25.33 # k, aparently after booting the new fbuild, it said rockbox and then went completely blank, nothing I pressed or touched did anything 04.25.54 # the HD is still spinning though, but doesn't sound like it's trying to access anything 04.27.15 # webguest94: What do you have the backlight time out set to? 04.28.17 # not sure, from looking at it (I have light perception) maybe 5 seconds or so. 04.28.42 # Llorean, do you know of any partition editors that will format the ipod so the in-ROM code will work ?? 04.30.37 # setkeh: After that you need to put the Rockbox bootloader image in the right place in the hidden partition. It's not a simple process, and it doesn't make much sense to try to do it. 04.30.50 # webguest94: If you press buttons, does the backlight come back on? 04.31.15 # hmm. the hd is still spinning. It's been like 5 minutes since I touched the player, nd I have it set to spen down after 3 seconds. 04.31.39 # Llorean, ty 04.32.53 Quit mc2739 () 04.33.44 # llorean: not that I can tell. It's completely froze with the hd still spinning 04.34.38 # webguest94: Do you know the revision numbers of the current build and the previous build? 04.37.54 # general question: i think i've found a bug with the m:robe - where's my first point of call/where should i first report the bug? specifically, the button backlighting is quite erratic 04.37.59 # just a sec, have to turn off and back on the battery and restore the previous build. My pc wwon't even recognize the player so have to "hard boot" the player. 04.38.43 # Waldo000000: Check to see if it's a known problem first by looking at the mrobe port page. Then read the FlySprayHowto wiki page. 04.39.15 # MarcGuay_: will do, thanks 04.39.33 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 04.43.32 # k, the old, working build is r18546 04.44.19 # is r18679 the official 3.0 release? i used the rockbox utility to install, but apparently you can't use that to install the official release, only the latest build (although i have no idea whether the latest build was the official release when i installed) 04.44.33 # where can I get the number for the current build? 04.45.04 # webguest94: It's 18679. 04.45.15 # Waldo000000: the rb Utility has been updated. 04.45.25 # Waldo000000: You can use the utility to install the official release, just go to the "Install" tab, choose to install rockbox, and pick "Stable" 04.46.48 Quit Hillshum ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092417]") 04.46.58 # webguest94: I suggest you try to update again tomorrow and if the problem persists, file a bug report, or continue searching for someone who can reproduce it. 04.47.15 Join blkhawk- [0] (n=blkhawk@g228004064.adsl.alicedsl.de) 04.47.31 Join perrikwp [0] (i=d1a8d351@gateway/web/ajax/mibbit.com/x-8fde74bce867ce4a) 04.47.54 Join potato [0] (n=potato@c220-237-157-51.brodm1.vic.optusnet.com.au) 04.48.31 # MarcGuay: k, will use the old build for now. Thanks. 04.49.17 Quit webguest94 ("CGI:IRC (EOF)") 04.49.24 # Llorean: do you mean i have to go "Installation" then "Install Rockbox", rather than "QuickStart"->"Compete Installation" to install a stable release instead of a current build?? 04.49.27 Part potato 04.51.47 # Waldo000000: if you're running rbutil 1.0.6 or before, you need to upgrade to 1.0.7 to be able to install 3.0 04.52.34 # for what it's worth, I suggest that you run the current CVS if you're on a PP-based target. 04.53.02 # ameyer: We use SVN. 04.53.34 # ameyer: i downloaded and ran 1.0.7 on ubuntu this morning (first time user of rockbox), and the "Complete Installation" prompted me that it would install the "current build", not necessarily a supported release 04.54.42 # you may need to do "Installation"->"Install Rockbox" 04.54.52 # Llorean: yeah, sorry 04.55.09 # * ameyer isn't sure where that CVS came from 04.55.55 # still, there's a legitimate reason to use the svn build if you're on a dual-core target and you run mp3 04.56.01 # erm, use mp3 04.56.17 # Waldo000000: As i said, you need to use it from the Installation tab. 04.56.21 # ameyer: so you'd recommend i do that before filing a bug? i just ran system->version and i've got r18679-081002 - is that the supported release, or should i do "installation"->"install rockbox"? 04.56.41 # Llorean: ok, i'll do that now. wierd. but thanks :) 04.56.45 # r18679 == current svn 04.57.20 # ameyer: as opposed to 3.0? 04.57.25 # * ameyer wonders what string 3.0 gives 04.57.38 Join midgey [0] (n=tjross@c-68-42-68-108.hsd1.mi.comcast.net) 04.57.40 # Waldo000000: 3.0 isn't current svn 04.58.19 # ameyer: It gives revision-3.0-date, I believe. 04.58.21 # * Llorean isn't certain. 04.58.56 # ameyer: k cheers, i'll try it out. hopefully that will fix this problem - basically the button lights on m:robe are completely whack, generally not coming on at all 05.00.53 # um... should my computer still detect my m:robe? i just booted into rockbox, then plugged in the usb - the m:robe showed a cute little picture of a USB cable, then that disappeared and went to the old "battery charge" screen - no USB device detected by ubuntu - help? 05.01.31 # ah, n/m, key is to plug in before turning on 05.01.49 # it *should* boot into the OF when you plug in the USB 05.02.01 # should != does in all cases 05.02.11 Nick jfc^3 is now known as jfc (n=john@dpc691978010.direcpc.com) 05.02.58 Quit blkhawk (Read error: 110 (Connection timed out)) 05.03.13 Nick blkhawk- is now known as blkhawk (n=blkhawk@g228004064.adsl.alicedsl.de) 05.03.30 Quit ajonat (Read error: 104 (Connection reset by peer)) 05.03.37 # for what it's worth, 3.0 seems to be r18607-3.0-080923 05.04.02 Join ajonat [0] (n=ajonat@190.48.123.108) 05.04.15 # ameyer: k :). OF = original firmware? 05.04.22 # yes. 05.04.31 *** Saving seen data "./dancer.seen" 05.05.51 # ameyer: Only about half of our MP3 players boot into the OF when USB inserted. M:Robe-100 happens to be one of them, but many don't need to. 05.06.36 # I think the "boot to OF" is a PP thing, and I'm pretty sure the M:Robe is PP 05.06.42 # i guess i've already made it obvious, but if any of you are involved in the documentation, it might be a good idea to have the rockbox utility "Complete Installation" install the supported release by default - because 99.9% of newbies will be doing this, and then later whinging about bugs 05.06.57 Join Skail [0] (n=user@static24-72-51-82.regina.accesscomm.ca) 05.07.06 # PP = ? 05.07.12 # PortalPlayer 05.07.15 # ah, k 05.07.46 Join sarixe [0] (n=sarixe@ool-435407e9.dyn.optonline.net) 05.10.32 # ameyer: It is a PortalPlayer thing, but I just wanted to make sure you knew it wasn't an all-players thing 05.11.39 # right, it's not. you could probably even argue it's not all PortalPlayer targets, depending on how you classify the iPod's disk mode. 05.12.17 # hey guys, I'm trying to write a plugin, and it says "Incompatible version" when I run it. Do I need to install my compiled .mi4 just to run my compiled .rock ? 05.12.25 # iPod's disk mode still qualifies as the OF. 05.12.51 # Hopefully soon, a significantly smaller portion of PP devices will need rebooting. 05.12.51 # OF part deux 05.13.14 # well, the button light is still completely whack. guess i'll file a bug, unless you guys have any debugging advice?... 05.13.17 # If anything the disk mode is more "firm" than the normal firmware, which is really just software 05.13.27 # Skail: Often, yes. 05.13.35 # * ameyer wonders out loud whether ipodlinux needs the of's disk mode 05.13.41 # ameyer: Yes. 05.14.08 # Waldo000000: "whack" isn't a particularly useful phrase. I'd recommend being more descriptive in the bug report. 05.14.43 # * ameyer vaguely remembers seeing a bug about the mrobe's lights being broken 05.15.19 Join potato [0] (n=potato@c220-237-157-51.brodm1.vic.optusnet.com.au) 05.17.00 # ...or not. 05.17.05 # why has the (s)nes flyspray "2008-02-04: A task closure has been requested." ? i thouhgt it was a good project =[ 05.17.29 # Llorean: basically, they turn on momentarily on bootup, for a little while they turn on, turn off as expected depending on input, but then at some point they flash off/on quickly, then don't turn back on again, ever, except for some strange little flashes here and there. sometimes they momentarily come on when you flick the hold button on or off 05.18.00 # in other words "whack" 05.21.05 # Waldo000000: No, "whack" really doesn't meant that, and we ask you try to use real English in here. 05.21.09 Join Hillshum [0] (n=4ba5ee28@gateway/web/cgi-irc/labb.contactor.se/x-a9968b6dd24c5323) 05.21.47 # potato: That just means some person _requested_ closure. We can't really read everyone's minds. If a developer wanted it closed, there'd be no "requested" about it, it'd just be closed. 05.21.48 Quit Hillshum (Client Quit) 05.22.00 Join Hillshum [0] (n=Hillshum@75-165-238-40.slkc.qwest.net) 05.22.38 # j 05.22.45 # oh, ic. 05.22.47 # Llorean: ty. (yay, I've now surmounted "Hello, World") 05.22.47 Quit Hillshum (Client Quit) 05.23.20 # Remember guys, Real English. That includes "ic" and "ty" 05.23.26 # sorry. 05.23.38 # Llorean: lol that was a joke dude, i mean, that was a joke, fellow :P so was that. i'm just filing a bug - category for button lights would be.... LCD? 05.23.59 # Waldo000000: The LCD category is for the LCD screen. 05.24.25 # Probably drivers. 05.26.50 # Llorean: Drivers, roger that 05.32.50 # just posted a bug report at http://www.rockbox.org/tracker/task/9441. Thanks for your help guys, let me know if there's anything i can do or further information i can provide to help get this resolved 05.34.03 Join Glert [0] (n=Mool@i577B694C.versanet.de) 05.35.43 Quit MarcGuay_ ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092417]") 05.36.00 Quit massiveH ("Leaving") 05.37.13 # ok, i have posted antibomb.c and fingersofrock.c to flyspray as patches. I hope i have made the patches crorectly... 05.40.41 Part potato 05.44.28 Join Transience39 [0] (n=Leo@resnet161-21.resnet.buffalo.edu) 05.45.38 # i've got an iPod video with rockbox which is getting stuck during boot 05.45.51 # my xp machine won't recognize it either 05.45.57 # can anybody help me? 05.46.20 # Transience39: What happens exactly? 05.46.47 Part Waldo000000 05.48.05 # i get a black screen with some text in the top corner 05.48.16 # one sec, i'll get what it says 05.49.45 # ok, so the bootloader starts, it reads off the hardware, and then says "error! can't load rockbox iPod, file not found." 05.49.51 # and then tells me how to put it into disc mode 05.49.52 # How did you install? 05.50.03 # i used the automated installer 05.50.19 # Which install choice? 05.50.48 Quit Mooloo (Read error: 110 (Connection timed out)) 05.51.25 # iPod video 30gb 05.52.08 Quit MrHacks ("Leaving") 05.52.48 # Transience39: No, I mean, "Quick Install" or did you go to the Install tab and choose one of the other options? 05.54.02 # quick install 05.54.51 # Where is the file "rockbox.ipod" located on your device? 05.55.24 # .....it's not coming up when i search 05.55.55 # How are you searching? 05.55.59 # should i just re-copy the .rockbox directory? 05.56.05 # windows explorer 05.56.12 # i got it to connect finally 05.56.16 Quit Zarggg () 05.56.27 # You can just re-run the utility, go to the "Install" tab, and just choose "Install Rockbox" since the bootloader is fine. 05.56.33 # okay 05.56.35 # thanks 05.57.10 Part Transience39 05.59.04 Quit Skail ("Concoction recent by Pier.") 06.13.52 # does anyone know where i can get the source code for the ipod patcher??? 06.15.56 # * ameyer points at http://www.rockbox.org/twiki/bin/view/Main/IpodPatcher#Download 06.16.07 # more specifically, the svn command given there 06.18.01 # ty 06.21.52 # setkeh: Basically, all the official project tools, and the manual, and the Rockbox and bootloader source code, are all in Rockbox SVN 06.22.52 Join n17ikh|Lappy [0] (n=n17ikh@130-127-73-84.lightsey.resnet.clemson.edu) 06.23.04 # it should also be in the compressed source code archive rockbox releases 06.23.41 # I don't know how much that includes. 06.25.01 # Llorean, yeah im trying to work it out :P i only need it to know how it scans for the ipod because im going to attemp to build a rock boxinstaller that you click on and ita all done lol 06.26.50 # setkeh: How's that going to handle whether or not to download all the extra stuff (fonts, Doom, etc)? 06.27.00 # Why not contribute by improving the user experience of the existing installer? 06.27.47 Join jfb9301 [0] (n=jfb9301@cpe-67-49-143-82.hawaii.res.rr.com) 06.31.01 # Llorean, i can add it to the pacage so when the exe file extracts it will extract thoes files too 06.32.26 # setkeh: So the point is to distribute outdated files, just for iPods? 06.33.02 # Llorean, what do you mean outdated ??? 06.34.11 Quit midgey () 06.34.15 # setkeh: Well, if you package them with the installer, it's only good once. If those files change, your installer will still be using old ones. 06.34.49 # As well, auto-detect could easily mess up another device if it mistakes it for an iPod, so it doesn't seem very safe not prompting the user at all. 06.34.58 # Llorean, well once i build the pacage ill just repack it when an update comes out and suply that file also 06.34.59 # What, exactly, is your goal, and why? 06.35.15 # Are you going to repack it every time Rockbox updates, or is it going to download the Rockbox build? 06.35.55 # Llorean, ill have to repack it i have no idea how to make it download the latest relese 06.36.07 # Rockbox is updated several times a day. 06.36.58 # And there are 9 different versions for iPods alone. 06.37.53 # Llorean, do you seriously update you rockbox several times a day tho ?? 06.38.18 # No, but that means that the vast majority of the time, you'll be giving people an outdated version. 06.38.38 # Even if you update your installer once a day, something like 20 hours a day, it'll be giving old and possibly buggier versions. 06.38.46 # You still haven't told me why you don't want to just contribute to the official installer 06.41.15 # because im not an immensly experianced coder i know enough c++ to package a folder and make it extract to a folder but i cant put F:\ because it varys from pc to pc what driveletter the ipod is 06.42.44 # So what are you going to do with this installer? It's either only going to support one iPod, or it's going to be immensely bigger than it needs to be, and it's basically just going to extract the zip? 06.43.28 # And being bigger, people will have to redownload it every time they want to install, even if they don't need 90% of the stuff taking up its size. 06.46.05 # Llorean, diferent relese for diferent ipod so its not stupidly big 06.46.18 # And then a version without extras for every iPod as well? 06.47.32 # Honestly, it sounds like you're setting yourself up for an awful lot of work that serves no purpose. 06.48.18 # Once you download RBUtil, you need to set it up once. Then you just click "Install" and it downloads the latest version and installs it for you, you don't have to keep going to a webpage, and then hoping the version he packaged has the feature you wanted listed on the front page. 06.49.34 Join saratoga [0] (n=41becb3b@gateway/web/cgi-irc/labb.contactor.se/x-4f133801c17dcb12) 06.59.30 Quit saratoga ("CGI:IRC (Ping timeout)") 07.04.34 *** Saving seen data "./dancer.seen" 07.05.13 Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) 07.07.38 Quit Darksair ("ERC Version 5.3 (IRC client for Emacs)") 07.08.38 Join tvelocity [0] (n=tony@195.167.65.111) 07.17.47 Join n1s [0] (n=nils@rockbox/developer/n1s) 07.20.02 Quit jhulst (Read error: 113 (No route to host)) 07.21.09 Quit jfb9301 () 07.24.04 Join Adduc^Desktop [0] (i=John@c-98-206-243-195.hsd1.il.comcast.net) 07.25.52 Quit setkeh (Read error: 110 (Connection timed out)) 07.26.11 Join J-23 [0] (n=aldwulf@a105.net128.okay.pl) 07.26.46 Quit Adduc^Desktop (Client Quit) 07.30.16 Quit fdinel (Read error: 110 (Connection timed out)) 07.33.03 Join Bagderr [241] (n=daniel@rockbox/developer/bagder) 07.33.30 Nick Bagderr is now known as B4gder (n=daniel@rockbox/developer/bagder) 07.41.31 Part J-23 07.46.07 Quit AndyIL (Read error: 60 (Operation timed out)) 07.46.13 Join AndyI [0] (i=AndyI@212.14.205.32) 07.50.22 Part toffe82 08.12.44 Quit miepchen^schlaf_ () 08.19.10 Join LinusN [0] (n=linus@rockbox/developer/LinusN) 08.19.45 Join reacocard [0] (n=reacocar@WL-431.CINE.HMC.Edu) 08.30.00 Quit Glert ("Leaving") 08.39.43 Join Lambdumb [0] (n=Lambda@12-203-112-233.client.mchsi.com) 08.39.58 # Llorean: Hmm, maybe the problem with the wrong disksize reported in the bootloader and the "rockbox.ipod" not found problem when it's actually there is due to the blocksize guessing 08.41.01 # Somehow disk.c finds a sector that resembles a proper fat bootsector close enough to try to mount it, even if it's not the correct one 08.42.02 # amiconn: It seems it's always the same wrong size when it happens, could this have something to do with, maybe, the installed OF version? 08.42.09 # If that happens again, a dump of such a disk would be helpful (sector 0 .... a bit after the start of the fat32 partition should be enough) 08.42.42 Join Rob2223 [0] (n=Miranda@p4FDCE6CB.dip.t-dialin.net) 08.42.48 # I don't remember the exact size of the G5.5 firmware partition, so dump maybe 100MB to be on the safe side 08.42.49 # I mean, my first guess, originally, was that it had to do with the way we were having people format to fat32, but it seems to happen on "properly" restored iPods as well 08.43.09 # and it's happened on the Gigabeat S too don't forget 08.43.12 # G5.5 FW partitions are as much as 120 MB aren't they (on the 64MB units) 08.43.33 # GodEater: That one might relate to the fact that it's not a pure FAT32 partition, though? 08.43.43 # Isn't it some FAT variant? 08.43.59 # Yes, TFAT 08.45.43 # very possibly yes 08.45.56 # but if we're ever to support the beast we need to handle it right ? 08.46.15 Join Waldo000000 [0] (n=roy@203-219-228-242-gee-ts1-2600.tpgi.com.au) 08.46.20 # GodEater: I just meant to say, there could be other explanations on the Beast as well 08.46.44 Quit BigBambi (Read error: 113 (No route to host)) 08.47.03 # Llorean: oh certainly 08.47.25 # It would be best if we wouldn't need to guess at all 08.47.35 # But isn't the blocksize guessing that amiconn is referring to only enabled for the 5g? 08.47.50 # linuxstb: correct 08.48.05 # Perhaps using the ipod hardware revision... 08.48.25 # there's a guy posting in FS#9369 with the ipod.rockbox not found error on a 1g iiuc 08.48.35 # Could a G5.5 (both 30GB and 80GB) consistently be distinguished from a G5 using that? 08.49.15 # amiconn: you mean the checking that ipodpatcher does ? 08.49.41 # No, ipodpatcher doesn't know the difference between the different Video models 08.50.07 # it does check the sector sizes though still right ? 08.50.09 # linuxstb: I think though he's asking *could* we in the future using the hardware revision number? 08.50.31 # GodEater: Yes, using the scsi "get disk geometry" ioctl or similar. 08.50.36 # If we could check the sector size from the PC, couldn't we just write the value somewhere during bootloader install for the bootloader to use later? 08.51.07 # linuxstb: yes I remember writing that patch orignally ;) 08.52.08 # Llorean: It may make sense to build two different bootloaders in that case - it would be easy for ipodpatcher to install the right one. 08.52.45 # that makes more sense imo too 08.52.48 # The problem is that the MBR just contains the start sector and number of sectors of each partition, but these are logical sector numbers/counts, and there's no hint to what logical sectors size these values are based on 08.53.08 # linuxstb: Main rockbox also needs to know the difference 08.53.37 # And the 7700 or so value is 1/4 the size the 30G iPod actually should be. 08.53.52 # Llorean: Unless you have a CF mod or.... 08.53.53 # GB 08.54.00 # * GodEater foresees complications if we start offering yet another set of rockbox builds to differentiate the models 08.54.11 # linuxstb: Yeah, but I'm just talking, "they're getting reports of 7700 or close to that from the bootloader" 08.54.40 # So disk.c just probes when large logical sector support is enabled: First it tries to mount using 512 byte sectors. If it cannot mount a partition using that, it retries with 1024 byte sectors, and then 2048 byte 08.54.47 # GodEater: Yes, I wouldn't want to split the builds, just the bootloaders (which the user never needs to choose). But a better solution would be to fix the auto-detection,... 08.55.27 # amiconn: but doesn't ata.c already know by that stage what size the sectors are ? 08.55.28 # amiconn: Would it be possible then, if rockbox.ipod isn't found with 512 to then try mounting with the next size up? 08.55.29 # Problem is that with the (effectively) halved or quartered (?) offsets, it tries sectors within the firmware partition. They can contain anything 08.55.58 # amiconn: shouldn't we reverse the order we try mounting in then ? 08.56.03 # GodEater: That's the physical sector size, which could give a *hint* on an 80GB G5.5, but not on the 30GB 08.56.04 # i.e. start larger and work down 08.56.15 # amiconn: ah yes - I see 08.56.17 # Maybe it should detect the Apple (C) at the start of the firmware block, rather than the start of a FAT32 partition 08.56.27 Join ender` [0] (i=krneki@foo.eternallybored.org) 08.56.33 Quit Lambduh (Read error: 110 (Connection timed out)) 08.57.14 # s/block/partition/ 08.57.15 # Maybe there actually *is* a hint in the mbr. We'd need a bunch of dumps from G5s and G5.5's to compare 08.57.49 # If there is, it's not an official standard though 08.58.30 # GodEater: Trying the reverse order could also cause false positives (on plain G5s) 09.00.18 Quit Rob2222 (Read error: 110 (Connection timed out)) 09.00.20 # A simple hack could be to make ipodpatcher/rbutil write the sector size to sector 1... 09.00.53 # But I think that's a hack... 09.01.03 # We could compare the partition size and the total disk size, but that's not really reliable either (partition could be smaller on purpose, e.g. if ipl is installed as well, or a user could have an extra partition for data, formatted ntfs or somesuch) 09.01.42 Quit nuonguy ("Leaving") 09.01.52 # As I said, I think locating the firmware partition would be more reliable than locating a FAT partition. 09.02.02 # yes, I think you're right there 09.02.10 # That has lots of unique magic - e.g. the Apple (C) header 09.02.26 # That would make Rockbox absolutely dependent on the presence of Apple though 09.02.46 # Llorean: But it is - the flash-based bootloader requires that firmware partition. 09.03.22 # I guess, it just seems something that'll have to be rethought if we ever start flashing them 09.03.24 # Well, our bootloader resides in that partition 09.03.36 # * amiconn wonders how apple does it 09.03.42 # Llorean: Yes, but that will be the easiest thing to solve... 09.04.36 *** Saving seen data "./dancer.seen" 09.05.48 # * linuxstb notices Apple have different firmware downloads for the 5g and 5.5g 09.06.16 # that's cheating! 09.06.39 # But could make it easier for us to detect things... 09.06.39 Join BigBambi [0] (i=86ceaf40@rockbox/staff/BigBambi) 09.06.43 Join kushal_12_27_200 [0] (n=kushal@12.169.180.178) 09.08.04 Join petur [50] (n=petur@rockbox/developer/petur) 09.08.24 # * linuxstb compares the flash dumps from a 5g and 5.5g and sees the 5g has the text MA146, and the 5.5g has MA446 09.09.20 # that would do then 09.09.42 # The hwrev also appears to differ - 0x000b0005 (5g) and 0x000b0011 (5.5g) 09.10.11 # But we should do more checks - I think the debug screen shows the hw revision if there are any 5g/5.5g owners here.... 09.11.30 # Didn't you say the hw rev can't be used? 09.12.00 # If I did, then I've forgotten why. Or maybe I was thinking of the RAM detection... 09.12.28 # * GodEater doesn't remember linuxstb saying we couldn't use the hardware rev 09.13.49 # Maybe I misread that 09.14.38 # Iirc LinusN's G5.5 has 0x000b0010 09.14.54 # * GodEater will check on his 5.5G 09.15.11 # Could have been 0x000b0011 though - Nico_P could check that... 09.15.31 # I have a very early 5.5G 09.15.37 # I bought it pretty much as they came out 09.16.03 # b0011 here 09.23.09 Join AndyIL [0] (i=AndyI@212.14.205.32) 09.23.28 Quit AndyI (Read error: 104 (Connection reset by peer)) 09.25.31 # Llorean: Btw, if the displayed partition size is exactly 1/4 of what it should be, it cannot be a coincidence 09.26.17 # This could imo only happen if some (buggy) conversion program writes the fat bootsector into the wrong position (512-byte based instead of logical sector size based) 09.26.24 # amiconn: I don't know if it's exactly one fourth, but I'm sure it's close so it seems likely it was. 09.27.02 # This would also mean it's being written into the firmware partition, and hence do some damage to the OF 09.27.50 Quit dan_a () 09.28.22 # Did this happen only on manually converted ipods, or also ones which aleady were winpods (or converted by restoring via windows itunes)? 09.29.00 # I am absolutely positive it happens on converted ones. I know the "rockbox.ipod not found" problem happens on restored via itunes ones, but I don't recall what disk size those ones have reported. 09.29.50 Quit sarixe ("Ex-Chat") 09.29.55 # If the user incorrectly converted with the wrong MBR, then formatted as FAT32, then converted correctly with itunes, that could leave the FAT signature in the wrong place... 09.30.40 Join Abzy [0] (n=pascho@60-242-55-2.static.tpgi.com.au) 09.30.47 # I'm pretty sure we've seen this error with people who've always had winpods, and upgraded the apple firmware on them with iTunes too 09.30.58 Join Zagor [0] (n=bjorn@rockbox/developer/Zagor) 09.31.37 # I know we've seen the rockbox.ipod error (we just "saw" it today), I just don't know if that includes the wrong size disk message 09.32.07 # amiconn: It's reporting as 7130MB apparently 09.32.46 # hi 09.33.02 # i need help 09.33.13 # Abzy: just ask, if someone here can help - they will 09.33.14 # hey, does morse input mode actually work in text editor? "Display + Power" doesn't seem to do anything for me 09.33.16 # Llorean: On a 30GB G5.5? 09.33.48 # amiconn: yes. 09.33.55 # this is on an m:robe, by the way 09.34.06 # the wps doesn't work for my 30gb video ipod except the original one 09.34.30 # Abzy: that just means the others you've tried are currently "broken" - keep trying others 09.34.36 # amiconn: It looks like this is happening on ones people haven't had to convert using our manual conversion process. 09.34.55 Quit tvelocity (Read error: 60 (Operation timed out)) 09.35.08 # is there any way to fix it? 09.35.24 # Abzy: They're just outdated WPSes. Some in the gallery will work, some won't. 09.35.32 # Look for ones updated recently, in the last couple months. 09.36.08 # ok 09.36.11 # thank you 09.37.11 # anyone here used morse input mode in the Text Editor plugin? (last time i'll ask, thanks) 09.37.16 # and yes, there are ways to fix it 09.37.31 # Abzy: if you check in the WPS section of the forums, there are posts dealing with how 09.38.04 # is it that perl script thing? 09.38.19 # i have no idea how to use it 09.38.22 # Abzy: there may be such a script, but you don't need it - they can be fixed manually 09.41.05 Quit pixelma2 ("-") 09.41.19 Join pixelma [50] (i=pixelma@rockbox/staff/pixelma) 09.51.23 Quit AndyIL (Read error: 104 (Connection reset by peer)) 09.53.21 Quit Twisty (Read error: 110 (Connection timed out)) 09.53.43 Join goffa [0] (n=goffa@216.220.23.105) 09.53.44 # hello, I have a sandisk sansa c250. I need to put an mi4 file in the 16 MB recovery partition. I am using Intel Macbook 10.4.11. I cannot use the GUI to do it. Could someone help me copy and paste the mi4 from the terminal, please? 09.54.06 Join AndyI [0] (i=AndyI@212.14.205.32) 09.54.10 Quit ruskie (Read error: 104 (Connection reset by peer)) 09.54.14 Part Waldo000000 09.58.46 Quit Abzy ("Ex-Chat") 10.04.17 Quit goffa_ (Read error: 110 (Connection timed out)) 10.04.21 Quit n17ikh|Lappy () 10.04.34 Quit BHSPitMonkey (Remote closed the connection) 10.07.45 Join Nibbler [0] (n=Nibbler@e181083164.adsl.alicedsl.de) 10.19.50 Join PaulJam [0] (i=PaulJam_@vpn-3053.gwdg.de) 10.23.33 Join pondlife [50] (n=Steve@rockbox/developer/pondlife) 10.23.54 Quit jeffdameth1 (Read error: 110 (Connection timed out)) 10.25.17 # * B4gder hugs the Rockbox logo 10.25.41 # * pondlife kisses the Rockbox logo 10.25.44 Join jeffdameth [0] (n=jeff@dyndsl-091-096-061-043.ewe-ip-backbone.de) 10.26.07 # * scorche covers the children's eyes for the next steps 10.26.08 # damn wierdos! 10.26.23 # in a gentle and affectionate manner, nothing sexual. How old is the logo anyway? 10.26.29 # :) 10.26.32 # 4? 10.26.40 # * pondlife feels wrong 10.27.33 # http://web.archive.org/web/20020806063747/bjorn.haxx.se/rockbox/ 10.27.47 # that's 6+ years 10.28.20 # So we could just say "We're keeping it for historic reasons, but may consider a Rockbox Icon or Splash replacement"? 10.28.23 # I like the left-hand-side menu 10.28.47 # * scorche hugs the Rockbox site 10.29.23 # I actually didn't mind his site designs too much, but thought his "Rockbox" header and logo really kinda lacked life. 10.29.40 Quit ajonat () 10.29.55 # It was like "Some icon, and Rockbox written in a boring font" (subjectivity all mine) 10.29.59 # wow, there was a roadmap back then! 10.30.16 # hehe, we learnt... 10.30.23 # n1s: that was before they leanred their lesson ;) 10.30.30 # * Llorean wants to re-introduce a very basic roadmap-like concept. 10.30.37 # * scorche glartes at his keyboard 10.30.49 # n1s: And commits from Bagder and LinusN ;) 10.31.03 # haha 10.31.14 # :-) 10.31.15 Join lasser [0] (n=chatzill@Wa415.w.pppool.de) 10.33.42 # pondlife: I think if we have a non-mandatory roadmap, like just *saying* "We'd like 3.1 to be focused on getting the recording working better" or whatever in a way just keeps that topic in the air and maybe encourages people who are interested in those areas to pick now as a time to focus a little bit more of their time on Rockbox. 10.34.00 # Absolutely, I was just joking before.. 10.34.46 # And I think it might be nice to do something like that with the next 3 or 4 releases in mind, then people will see "in 3.3 they want theming improvements, maybe I should try to get my Patch X back into shape, and they might finally commit it for me" 10.35.08 # It encourages the community because they know we'll be looking for specific types of patch right after the prior release. 10.35.28 # I think it quickly gets very fuzzy when we say we want things done but don't know who wants to do it 10.36.00 # also,,, after recording what else is there? its pretty much "fix bugs"... 10.36.19 # Recording, FM, Playback, Theming, Stability, Features. 10.36.31 # wouldn't a list of things people are working on or "feel strongly about" be more concrete and just as useful? 10.36.40 # Coffee making, and beer brewing need to be on the list 10.36.50 # but what kind of beer? 10.36.52 # For example we could take one release and say "We'd like to introduce several new features for this one, so if you see patches of interest, bring them to our attention." We don't *have* to add new features, but it does help to have "a direction" even if it's not enforced. 10.36.52 # :-) 10.37.25 # Llorean: yeah RIGHT! there are too many anti-feature-adding people in the group... 10.37.39 # Zagor: There's something helpful, as a whole, just to say "we'd like to focus on X". It encourages the people who would normally work on it anyway, because you're saying "Now we actually NEED you", even indirectly. 10.37.41 # oh noes.. heaven forbid we have a red delta 10.37.47 # removing PLA (and improve some keymaps in general) 10.38.37 # PLA in their current form of course 10.39.11 # Zagor: Since this is all volunteer time, people drift here and back. If we spread the word that we're working on UI improvements in one release, we might get a lot of guys who've lost faith that there patches will ever get accepted becoming more active in trying to clean them up and get them in, for example. 10.39.26 # PLA isnt entirely bad.. it just needs either a rethink, or removal in some plugins 10.39.35 # You have to admit, there are a lot of people who've lost faith that we'll ever accept their patches. If we say "this time we'll, hopefully, look at patches in this category" it's encouraging. 10.39.42 # I think a simple "roadmap" is a fair idea to try for the next say two future releases 10.39.50 # Llorean: I'm sceptical, but I giess it's worth to try 10.40.06 # guess even 10.40.08 # Zagor: That's the best thing. If it doesn't work, I don't think we can be any worse off, since we're not forcing anyone to work on anything. 10.40.20 # It's very similar to the list of "3.0" bugs we had in the tracker. 10.40.22 # one thing though.. if its in the wiki it will quickly turn into a feature request 10.40.24 # It helped focus attention. 10.41.05 # JdGordon: How we present it is very, very important since we don't want to people to misunderstand it as well. 10.41.15 # sure 10.41.39 # there's a definite risk of confusing "roadmap" with "release promise" 10.42.31 # otoh we should never let PR issues dictate development 10.42.31 # I think something along the lines of "For 3.1 we're simply focusing on our usual stability and feature improvements. For 3.2 we're going to be looking at UI improvements, so get your UI patches in shape, and talk to us about what could be improved, over the next three months. For 3.2 we'd like to look at recording, so those of you who've been working on REP and other features, and despair ever seeing it in Rockbox, now is the time to star 10.42.34 # dont alot of projects have a "how can you helpout?" type page usually linked prominantly? we could add it to the front page under "why should you run.." and have it a static page 10.43.04 # .. the other thing is that we need to add timeframes onto releases for this to have any hope of working 10.43.04 # Then, *we* develop as usual, but encourage more community involvement. 10.43.15 # JdGordon: We're aiming for every 3 months still. 10.43.28 # yeah, but people dont nescacarily know that 10.43.37 # We can clarify it in a few places, soon. 10.43.55 # also, having people think they need to wait 6+ months for their patches to be even considered isnt goign to draw people in 10.44.09 # It is if you pitch it right. 10.44.29 # wanna put up a draft? 10.45.41 # JdGordon: Once I figure out exactly how to pitch it, maybe. :0 10.45.44 # :) even 10.47.55 # Something like "We try to pick out interesting patches for inclusion all the time. But with thousands of entries in the tracker it can get overwhelming very quickly. That's why with some releases, in addition to our usual oversight of the tracker we'll be looking for well created patches in specific categories that we'll pick for that release. That way we'll be looking at a smaller sampling, and you can know to clean up patches that may 10.49.25 # I think if you tell someone "We'd like your patch to be one of our release features, but it still needs X done" in some cases at least, it'll encourage them more than "We can't commit your patch until X is fixed" 10.51.11 # * pondlife just wants the tdspeed patch sorting out, so it doesn't use massive static buffers... 10.51.31 # tdspeed? 10.51.58 # http://www.rockbox.org/tracker/task/8894 10.52.09 # Ah 10.54.18 Join culture [0] (n=none@cpc1-bele3-0-0-cust658.belf.cable.ntl.com) 10.54.50 # * Llorean would kinda like that patch for his audiobooks. 10.54.59 # Sounds like some people are experiencing bugs with it too, though. 10.55.15 # Yes, but I haven't had a problem with it 10.55.28 # Not recently, anyway 10.55.39 # On a different architecture though. 10.58.54 Join JdGordon_ [0] (n=jonno@c211-28-145-198.smelb2.vic.optusnet.com.au) 10.59.53 Join fragilematter [0] (n=fragilem@92.81.254.122) 11.00.28 # Llorean: yeah that sounds ok.. 11.01.29 Quit JdGordon_ (Client Quit) 11.03.37 Join JdGordon1924 [0] (n=Miranda@c211-28-145-198.smelb2.vic.optusnet.com.au) 11.04.11 Join goffa_ [0] (n=goffa@216.220.23.105) 11.04.38 *** Saving seen data "./dancer.seen" 11.09.36 Quit JdGordon (Read error: 110 (Connection timed out)) 11.14.59 Quit goffa (Read error: 110 (Connection timed out)) 11.18.42 Join tvelocity [0] (n=tony@gw1.mycosmos.gr) 11.22.46 # amiconn: the 7700MB display thing is doesn't mean anything. The bootloader code that prints this out just assumes 512-byte sectors (and isn't involved in the actual mounting - this is just a display issue) 11.26.47 Quit culture (Connection timed out) 11.33.13 # * linuxstb thinks there's only one solution to the problem of rotting patches - experienced devs need to spend time reviewing them and encouraging the patch author to do things needed to get it committed. But none of us do... 11.33.39 # (or we take a decision that the feature isn't wanted, and close the task...) 11.35.12 Quit homielowe (Read error: 104 (Connection reset by peer)) 11.35.17 Join homielowe [0] (n=homielow@d206-116-134-81.bchsia.telus.net) 11.38.11 # linuxstb: well that still leaves the problem of devs with no time and little inclination for reviewing taks which they have no interest in 11.38.16 Nick JdGordon1924 is now known as JdGordon (n=Miranda@c211-28-145-198.smelb2.vic.optusnet.com.au) 11.39.23 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 11.39.32 Join culture [0] (n=none@cpc1-bele3-0-0-cust658.belf.cable.ntl.com) 11.40.46 Quit JdGordon (Read error: 104 (Connection reset by peer)) 11.41.37 Join mcuelenaere [0] (n=mcuelena@rockbox/developer/mcuelenaere) 11.42.58 # gevaerts: 9443 is pretty much a known artifact of the fact that it just filters by single tags, so there's only one album with a given name (the other solution would break compilation albums). It may be best to just say "This is how it has to work, give your albums unique names" 11.43.01 Join JdGordon [0] (n=jonno@c211-28-145-198.smelb2.vic.optusnet.com.au) 11.46.24 # Is pictureflow based on the database, or does it just scan files? 11.46.45 # database iirc 11.47.23 # yes, doesn't even work without the database enabled 11.47.37 # So the core problem is that the database doesn't identify albums correctly? 11.48.07 # linuxstb: It's impossible to. 11.48.38 Quit fragilematter ("Leaving.") 11.48.46 # You can have a single album with multiple artists, or multiple albums from different artists with the same name, and there's no way to distinguish them unless you have a separate unique "album ID" tag of some sort. 11.49.09 # Of course, but I can't recall people complaining about "album view" in the database - or have they? 11.49.33 # I suspect few people have two albums with the exact same name. 11.49.42 # it might be the way tagnavi.config is set up that it actually avoids the issue 11.50.06 # JdGordon: True, if you filter artists first, you'll never see the issue. 11.50.34 # you could check for the albumartist tag and group songs with the same albumartist tag into the same album. 11.50.38 # But of course "album name" shouldn't be taken as a unique identifier for an album - you want to use a combination all the "album-level" tags. 11.51.04 # linuxstb: "Album level"? 11.51.22 # * amiconn has no "album level" tags set apart from album name 11.51.25 # but then you won't see various artist compilations (maybe if you have a "vorious artists" album artist tag 11.51.56 # * pixelma was too slow 11.52.04 # Checking the year would at least reduce the likeliness to hit that issue though 11.52.29 # and can't type 11.52.43 # amiconn: Greatest Hits albums are very, very likely to have different years (and I suspect the most likely to have the same name) 11.52.47 # * linuxstb also includes a CDDB ID tag in his rips 11.52.49 # * amiconn actually has the year set for almost all albums, hence his previous statement wasn't entirely correct 11.53.20 # * linuxstb accepts that breaks with two-CD albums... 11.54.00 # * linuxstb wonders if the database attempts to assign a unique "album id" to tracks 11.54.21 # Not with my way of tagging 2-CD albums... 11.54.25 # linuxstb: What could you base it on? 11.55.05 # The only valid thing is "Album + Album Artist" and that assumes the existence of a tag not often in use. 11.56.25 # currently in rockbox if the albumartist tag is empty it gets the value of the artst tag. 11.56.32 # There are lots of albums with the same name, Llorean. And even if you meant "few people have two albums /by one artist/ with exactly the same name" there are still collisions. 11.56.34 # *artist 11.57.08 # PaulJam: Which would conflict with trying to use it with indetification. 11.57.45 Join moos [0] (i=moos@81-66-128-18.rev.numericable.fr) 11.57.57 # soap: I don't think I said few people have two albums with the same name. 11.58.36 # Llorean: why? the only problem would be if you have a compilation and no albumartist tag set, but then you could just tag the files correctly, so albumartist is something like "various artists". 11.59.00 # PaulJam: So you're demanding people add extra tags, that they may not even know exist, just so things "Sort normally"? 11.59.17 # Llorean: why? The pure artist tag won't help but at least you would have a chance, now it is the responsibility of the user to tag them 11.59.27 # Llorean: isn't that what we exect of them with the "The .." problem as well? 11.59.27 # It seems like it'd make more sense to have people with duplicate albums just name them "Bob's Greatest Hits" or "Joe's Purple Album" 11.59.31 # PaulJam: If you do that, 2 compilations with the same name would collide again 12.00.06 # markun: Except that there is no useful solution without that extra tag, and *not* having that tag won't break things that previously sorted one way before. 12.00.32 # well, you can't take care of everything I guess 12.00.39 # pixelma: PaulJam's suggestion would break *ALL* compilation albums until such time as someone retagged every compilation in their collection with the Album Artist "Various Artists" 12.00.49 # * GodEater sees that Apple has lifted the NDA around the iPhone SDK 12.00.51 # pixelma: I can't see as how drastically breaking current sorting is a _good_ thing. 12.00.56 # Llorean: It's obvious that album ids can't always be guessed by a database builder. But I think that one needs to be there - browsing by album is a fundamental feature of a music database, so we should try to find solutions, not say "it can't be done". 12.01.07 # Llorean: huh? 12.01.47 # pixelma: PaulJam's solution is to use "Album Artist" + "Artist" as a unique identifier, combined with "Use Artist as Album Artist if the latter isn't present". This results in single albums with multiple artists and no album artists being treated as multiple albums. 12.01.50 # they are not sorted correctly now too 12.02.17 # The only thing not sorted correctly right now is if you don't filter by Artist first, all albums with the same name are assumed to be one album with multiple artists. 12.02.49 # We'd be getting rid of that, and replacing it with "If you don't have Album Artist tags, all your compilation albums will be sorted incorrectly" 12.03.01 # Which, I think, would have a negative effect on a significantly higher portion of users. 12.03.02 # GodEater: That's a positive step... 12.03.29 # Llorean: as I understand it, this would have no impact on the "standalone" album sorting - just on artist > album 12.03.35 # linuxstb, GodEater: but not really rockbox related 12.03.38 # * amiconn doesn't like the guessing in the db anyway 12.03.58 # * linuxstb just uses the filesystem, to avoid all these issues... 12.04.07 # I have some tracks with no track number where the db guesses the track number from the artist name.... 12.04.18 # Llorean: and the "artist > album" sorting is now broken anyway with compilations 12.04.26 # pixelma: That would mean the "artist" filter works differently depending on what precedes it, I think that's even worse... 12.04.34 # Er, Album filter 12.05.00 # pixelma: Right now you can use "Album Artist" instead of "Artist" and if the AA tag isn't present, Artist will be used instead. 12.05.01 # * pixelma has the feeling we are talking about different things 12.05.20 # So while "Artist -> Album" seems broken, "Album Artist -> Album" will get the effect you want. 12.05.49 # If you've set the "various artists" tag. 12.06.49 # yes, isn't that what he (and me) said? 12.06.53 # No 12.06.58 # Well, I don't know about you 12.07.05 # But the original discussion was for uniquely identifying albums 12.07.10 # sorry, can't follow then 12.07.13 # As in, "being able to tell a single album, without filtering by artist first" 12.08.07 # And the suggestion was to use "Album Artist" as part of that (which I'm okay with) or assuming "Artist" if "Album Artist" is not present, but that latter half will break compilation albums into a dozen separate albums 12.08.22 # I think if "Album Artist" is not present, it should be assumed that "Album" alone is a unique identifier. 12.08.34 # Basically, "Tag your duplicates" rather than "Tag everything" 12.08.51 # It could use the year if album artist isn't present 12.09.12 # amiconn: Not useful on Greatest Hits, or other collections over time by a single artist. 12.09.49 # well, I think PaulJam and me just talked about "(Album) Artist -> Album" sorting, not using this as identification for "Album" only 12.10.08 # pixelma: Well, the original topic was "Album" only, because we were discussion a specific flyspray task. 12.10.16 Join tree [0] (n=tree@chello089078243195.chello.pl) 12.10.31 # So I didn't realize you weren't discussing what we were, since they're very, very similar. 12.11.01 # Llorean: why not? 12.11.04 # "Album Artist -> Album" sorting already uses "Album Artist" and falls back to "Artist" if you set your Tagnavi with AA. 12.11.11 # yes, but then I think you read too much into PaulJam's first post *I think* 12.11.30 # amiconn: Year is often the year of the song's recording, not the year of album publishing. 12.11.38 # oh? 12.11.47 # * amiconn always uses the album year there 12.11.58 # Yeah, but it's not safe to assume everyone does. 12.12.24 # pixelma: Well, I assumed since he was saying what Rockbox already did, that he was suggesting that it could be done in the area we were discussing too. 12.13.26 # Llorean: otoh all cd rippers I've seen only have a field for album year, not for each track 12.13.27 # I think the problem with trying to guess is that you can get false positives, and in my mind at least it's better to err on the side of "false positives are nearly impossible" and ask people to use unique tags if it's giving them problems, than to try to get too clever, and start having people file bugs because we're merging (or separating) their albums. 12.13.49 # true 12.14.01 # Same as with the track number guessing... 12.14.22 # Zagor: This is a valid point. I just think it's not solid enough to depend on though, is all. 12.14.43 # linuxstb: Is there a common tag for CDDB ID? 12.14.43 # pixelma: i was suggesting to use the album artist tag to decide if songs with the same album name should be grouped into the same album or different albums. 12.15.22 # Llorean: I'm not sure 12.15.45 # It seems like a truly unique identifier like that might be even better, though it'll split multi-disk albums. 12.15.54 # PaulJam: ok, then maybe I misunderstood 12.18.09 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 12.18.59 # the foobar2000 forums used to have a long (and long standing) thread on this sort of album sorting mess. There are notable holes in any scheme (outside an "album sort" tag), despite full standard tagging) 12.19.05 Quit tree ("leaving") 12.19.14 Join Nico_P [50] (n=nicolas@rockbox/developer/NicoP) 12.19.49 # And we'd get an "Album Sort" tag with the sort-tags patch anyway. 12.19.56 # Which could hold any sort of unique ID you wanted. 12.19.57 # full standard tagging assumes certain music styles, so holes are unavoidable 12.21.13 # you can do classical (the one I assume you are talking about) with stock ID3 tags. You end up putting lots of info in the track name, but...;) 12.22.08 # soap: you can make it fit somehow, but different people are bound to use different fitting mechanisms 12.22.11 # But yea, I'm not sure more than "full standard tags" (what you see in most rippers and the basic screen of most taggers) can ever be expected. 12.22.53 Join trisiak [0] (n=tree@chello089078243195.chello.pl) 12.23.10 # I think Itunes' solution is to secretly tag VA albums behind your back, itsn't it? 12.23.24 # hello, I have a sandisk sansa c250. I need to put an mi4 file in the 16 MB recovery partition. I am using Intel Macbook 10.4.11. I cannot use the GUI to do it. Could someone help me copy and paste the mi4 from the terminal, please? 12.31.27 # soap: I seem to reacall a "compilation" tickbox to indicate a track is part of a compilation. I've no idea what that does though.... 12.32.35 Join DerDome [0] (n=DerDome@141.71.76.43) 12.32.36 # I'm off to work. 12.32.54 # FS#9428 needs love. 12.33.22 # kushal_12_27_200: Why doesn't the GUI allow you? I wouldn't expect it to work in the terminal if it doesn't work in Finder... 12.34.01 # because the 16 MB partition is not mounted 12.34.42 # And your c250 is definitely in recovery mode? 12.35.23 Join vitja [0] (n=vitja@79.120.98.174) 12.36.46 # gevaerts: hi 12.37.18 Quit m0f0x () 12.37.30 # yes, afaik 12.40.18 # vitja: hello. I didn't commit anything yet, but my current work is at FS#9436 12.40.59 # gevaerts: ok i'll take a look 12.41.19 # It is in Mini-B->Device Mode 12.42.08 Join funman [0] (n=fun@AAnnecy-257-1-67-132.w90-36.abo.wanadoo.fr) 12.42.27 Join J-23 [0] (n=aldwulf@a105.net128.okay.pl) 12.44.08 # funman: Hi, I found some bugs in my patch from last night, and have just put a new one here: http://www.davechapman.f2s.com/rockbox/quick2.diff 12.44.40 # let me read it 12.45.58 # funman: I think it would also be nice to round things to a multiple of 4 bytes, and use ldr/str instead of ldrb and strb, but that can be after we get this change working... 12.46.45 # the decompression is fast enough, imo it is better to keep the code the simplest 12.47.29 Join JdGordon_ [0] (n=jonno@c220-237-62-18.smelb2.vic.optusnet.com.au) 12.47.54 # * linuxstb should test it without the deliberate delay loop, to see if there's a noticable slowdown when booting the oF 12.48.42 # also you can extend the firmware block to the maximum size possible 12.48.57 # there is no little profit ! 12.49.14 # Yes, there didn't seem any point, so I just keep it exactly the same size now. 12.49.49 # Also, maybe it's worth putting mkamsboot in tools/ , and link it with libucl 12.50.07 # Yes, I mentioned the other day that we should do that. 12.50.13 # I am still thinking of a way to transmit the e200 model from mkamsboot.c to test.S for the button check 12.50.38 # Maybe mkamsboot.c could write a 'model.h' with "#define CLIP" as a content for example 12.50.58 # It's *test*.S - so we shouldn't worry about that - users can just set a #define in the Makefile or something. 12.51.04 # and test.S (or another name) would have .ifdef CLIP .endif .ifdef e200 .. 12.51.33 # well we can now make a 100% safe bootloader 12.51.45 # We shouldn't try and duplicate the existing Rockbox build system - I think we've reached the stage to start hacking on the main RB source. 12.51.58 # exact 12.52.34 # but we need dual-boot 12.52.57 # I've been thinking that maybe we should also UCL compress the bootloader - as we're developing this code now, it would seem easier to do it now than later when we run out of space. 12.53.06 Quit JdGordon (Read error: 110 (Connection timed out)) 12.53.07 # that also 12.53.45 Nick JdGordon_ is now known as JdGordon (n=jonno@rockbox/developer/JdGordon) 12.53.46 # I mean the "test.S" will become our "dual-boot.S" 12.54.01 # linuxstb: That sounds suspiciosly similar to what the archos flash loader does... 12.54.06 # and it better should not stay a test, because it will be our recovery mode on Clip and similar 12.54.20 # amiconn: Does it always compress the RB bootloader, or is it optional? 12.54.35 # (or main Rockbox binary, whatever it stores...) 12.55.16 # It handles booting one of 2 images, depending on button presses (plus a serial monitor for low-level recovery work) 12.55.34 # Either image can be ucl compressed or uncompressed. 12.56.33 # linuxstb: your 2nd patch looks ok 12.56.45 # Typically the first (alternate) image is bootbox, ucl compressed, and the second (main) image is full rockbox, either compressed, or (on targets that still have enough room) uncompressed rombox 12.56.49 # funman: You've tried it in the emulator? 12.56.56 # yes in the emulator only 12.57.15 # Ok, let's give it to kugel to test on his fuze ;) 12.58.18 # funman: Is the button detection on the various V2s documented anywhere? 12.58.20 # do you want my scripts to test firmware integrity ? (I guess they will be needed a couple more times) 12.58.32 # < here it is very well documented 12.58.59 Quit Xerion (Read error: 113 (No route to host)) 12.59.07 # What about the wheel light on the Clip, or the LCD backlight? 12.59.10 # there is various code snippets on the forum / our git repository 12.59.20 Join Xerion [0] (n=xerion@cp198589-d.landg1.lb.home.nl) 12.59.27 # also in the patch I had posted on flyspray 12.59.43 Join fragilematter [0] (n=fragilem@92.82.99.51) 12.59.50 # you have to enable the gpio clock (set bit 16 of cgu_peri register) 13.00.09 # Do you disable that clock again before starting the OF? 13.00.16 # configure your pin as input to be on the safe side 13.00.16 # no 13.00.26 # I never restored the registers state 13.00.33 # and had no problem 13.00.37 # OK 13.01.09 # we should unconditionally check A3 (which is either usb or hold on all tested models) 13.01.24 # and a specific button for each model for dual booting without a computer handy 13.01.35 # Why "hold" ? 13.01.49 # well on the Clip A3 is the state of hold button 13.02.14 Join eight [0] (n=eight_@unaffiliated/eight/x-7825324) 13.02.15 # so safe way to boot OF: shut it down, turn hold on, plug it on usb 13.02.34 Quit UncleRemus ("leaving") 13.02.40 # A3 is usb on Fuze and E200 13.02.45 # funman: do you have the English translation of Skyeye - Internals? 13.02.48 # and might be hold on m200 13.03.00 # funman: Yes, but why do you want to boot the OF if hold is on? 13.03.25 # mcuelenaere: nope :/ but I found that skyeye.conf is documented in README of the tarball 13.03.43 # hmm bugger 13.03.52 # linuxstb: in case we want to flash another rockbox image on it 13.04.24 # funman: Huh? Isn't that covered by the "insert USB" or "press a specific button" ? 13.04.40 # you can't power the Clip if hold is set anyway (except if you powered it by usb) 13.04.41 *** Saving seen data "./dancer.seen" 13.05.10 # well it's only an extra safety 13.05.53 # button led is D7 on E200/Clip 13.05.57 # I don't remember on Fuze 13.06.35 # http://paste.ubuntu.com/53160/ 13.07.06 # Can you detect the "home" button on the Clip? That would seem an easy dual-boot button. 13.07.20 # yes it is B2 13.07.32 # but you want to check that on your side 13.07.52 # check the paste: it is the list of known buttons 13.08.28 # linuxstb: what can I do to not duplicate work ? 13.09.02 # I'm not doing anything at the moment... 13.09.12 # ok 13.09.38 # I'll move mkamsboot in it's own directory in tools/ 13.09.47 # My "quick2.diff" patch needs testing on target... ;) 13.09.52 # (and then I can commit it) 13.10.29 # IMO it's safer to test on e200 first 13.10.57 # no need to hurry :) 13.12.31 # hello, does anyone have the e200tool compiled compatible with Intel mac 10.4.11 13.14.53 # funman: How about powering off the Clip? Have you investigated that? 13.15.05 # kushal_12_27_200: I can compile it for you... 13.15.23 # linuxstb: what do you mean exactly ? 13.15.35 # Thank you very much JDGordon. How long does it take to compile it? 13.15.45 # funman: I mean how to make our code shut down. 13.15.56 # no I don't know 13.16.23 # You can force it to power off by holding the button if it's in a 'stuck' state 13.16.37 # kushal_12_27_200: 30s... if i remembered where it is :p 13.16.37 # oh, hmm... 10.4.11... ive got 10.5.something 13.16.58 # thanks a lot, JDGordon 13.16.59 # funman: OK, so that's good enough for now - we just end with an infinite loop and the user can shut down manually. 13.17.18 # hint: infinite blinking of the led is nice (maybe not for the battery) 13.17.55 # kushal_12_27_200: umm... e200tool? you need to recover it? 13.18.10 # Yes, maybe a "final" version of test.S before we start work on Rockbox itself could be to implement dual-boot button detection, with the "rockbox" option going into an infinite loop, flashing the LED. 13.18.10 # JDGordon, yes. 13.18.15 # :( 13.19.40 # arg, nup, no libusb on the mac... sorry 13.20.32 Join dan_a [0] (n=d917a37d@gateway/web/cgi-irc/labb.contactor.se/x-439892f72e7b9f06) 13.20.45 # * linuxstb spots a stranger with a Clip 13.20.51 # * dan_a waves 13.20.53 # (if he remembers right...) 13.21.02 # hey dan_a 13.21.11 # are you on a mac, JDGordon? 13.21.14 # Hi funman 13.21.29 # I wanted to ask you something for some time 13.21.38 # kushal_12_27_200: no, i have a mac.. im on linux atm 13.21.42 # you wrote the NAND driver for sansaV1 ? 13.21.51 Join mc2739 [0] (n=mc2739@cpe-67-10-238-175.satx.res.rr.com) 13.21.53 # Do we know anything about the I2C on the V2s yet? The version of the datasheet which I have doesn't talk about it 13.22.15 # funman: I did the initial version, based on MrH's work 13.22.31 # is the exact same code used both for NAND & SD cards ? 13.22.42 # do you delete files from your website often? do you think you still have a file from February this year on your website? 13.22.46 # There is no "nand" on the v1 13.23.05 # It all goes through the SD driver 13.23.08 # The internal flash basically is an SD card in a different package 13.23.16 # it's the same on the V2 13.23.42 # well it's a real NAND chip, but (apparently) connected to a SD-NAND interface chip made by SanDisk 13.24.28 # JDGordon, do you delete files from your website often? do you think you still have a file from February this year on your website? 13.24.44 # At least it's a 1000% better solution than the bare-metal nand interface on the various tcc targets 13.25.19 # well when this interface is documented :o) 13.25.21 # kushal_12_27_200: which was it? i can have a look 13.25.55 # c250repair-mac 13.26.08 # funman: Is it similar to the v1's SD chip, or don't we know? 13.26.14 # nup, looks like that was before i reformatted it... 13.26.26 # dan_a: no it appears to be a ARM PL180 13.26.28 # ok, thanks for looking it up for me 13.26.51 # (guessed from RE) 13.29.16 Quit bmbl ("Woah!") 13.29.40 # It has documentation on the ARM site. That is useful 13.29.49 # yes 13.30.09 # but I couldn't issue a read cid command to it :'( 13.30.31 Join LambdaCalculus37 [0] (n=LambdaCa@nmd.sbx09467.newyony.wayport.net) 13.32.40 # Did I read that someone was close to having an LCD driver ready? 13.32.54 # yes: fdinel on irc 13.33.21 Quit Nibbler (Read error: 113 (No route to host)) 13.33.22 # That will make things a lot easier 13.33.33 # What does "close" mean? Has he displayed anything on the LCD? 13.33.50 # no 13.34.13 Join JdGordon_ [0] (n=jonno@c220-237-62-18.smelb2.vic.optusnet.com.au) 13.35.10 # I must say I'm a bit confused by your 'quick' patch linuxstb 13.35.19 # Now I don't know what is where in the firmware 13.36.21 # funman: Ah yes, I need to update the comments... 13.36.47 # gevaerts: did you end up doing any investigation into that data abort? 13.36.50 # can you do that and highlight me with the patch please ? 13.36.59 # test.bin is at 0x0, and (ucl_unpack + ucl image) are together (in that order) at the end of the firmware block. 13.37.04 # I'm going, but should be there in the afternoon 13.37.18 # ok, it confirms my suspicions 13.37.35 # see you 13.37.36 # i.e. I just moved the ucl_unpack function to immediately before the compressed image, and extended the memcpy to copy both. 13.37.36 Join UncleRemus [0] (n=caj@78-69-154-184-no176.tbcn.telia.com) 13.38.05 # Later. 13.38.15 # fragilematter: Around to test something? ;) 13.39.13 # JDGordon, how could I get a header.txt? Do you know what that is supposed be? 13.39.42 # no idea what that is... 13.43.02 # gevaerts: im gonna need more info on that data abort.. it didnt happen on my sansa (although im not 100% sure i had a playlist to resume on boot...) 13.43.49 # gevaerts, I am flashing my sansa c250 right now with the c250reapir-mac tool. I have firmware.mi4, pribootLoader.rom, and c250repair-mac on my desktop but I am missing header.txt . Please advise. 13.49.07 Quit JdGordon (Read error: 110 (Connection timed out)) 13.49.11 Nick JdGordon_ is now known as JdGordon (n=jonno@rockbox/developer/JdGordon) 13.54.25 Quit LambdaCalculus37 ("Ka-chunka") 13.54.54 # JdGordon: I havent' looked yet. I ran out of time last night 13.54.56 # linuxstb: sorry for the delay, I was afk but now I'm back 13.55.12 # kushal_12_27_200: sorry, no time right now. I'm at work 13.55.14 Quit dan_a ("CGI:IRC (Ping timeout)") 13.55.23 # gevaerts: ok, got a link to the problem reports? i dont see it in my flyspray emails? 13.55.27 # fragilematter: Fancy testing something? 13.55.31 # hit me 13.56.25 # http://www.davechapman.f2s.com/rockbox/quick2.diff - apply to current SVN 13.57.03 # fragilematter: I don't know if you read the commit message (or the IRC logs), but the SVN version is now working for both me and funman on the Clip. 13.57.25 # thanks for letting me know, gevaerts 13.57.26 # So you could try that as well, but this patch improves it (removes the limitation on available firmware padding size) 13.57.32 # the one I tested last night? 13.57.41 # err, it was night for me ;)) 13.57.52 # This was about 14 hours ago. 13.57.56 # JdGordon: forums and IRC 13.58.09 # nope, I tested something more than 16-17 hours ago 14.00.30 Join mf0102 [0] (n=michi@85-127-21-116.dynamic.xdsl-line.inode.at) 14.02.48 # linuxstb: damn, I bricked it with the second test yesterday so I'll have to unbrick 14.03.27 # linuxstb: mind if we do the test in about 30 minutes, I have to go to lunch 14.03.38 # fragilematter: Sure, there is no rush. 14.03.55 # okay, tty in about 30 minutes or so 14.05.49 Join dan_a [0] (n=d917a37d@gateway/web/cgi-irc/labb.contactor.se/x-6d1d2b125125328b) 14.11.02 # I am flashing my sansa c250 right now with the c250reapir-mac tool. I have firmware.mi4, pribootLoader.rom, and c250repair-mac on my desktop but I am missing header.txt . Please advise. 14.11.30 # where is header.tx ever mentioned? 14.11.50 Quit mc2739 () 14.14.04 Join nplus [0] (n=nplus@141.25.globcom.net) 14.14.11 Quit mcuelenaere () 14.15.46 Quit at0m|c (Read error: 104 (Connection reset by peer)) 14.18.23 # linuxstb: tested and working with a 5 second delay on boot 14.18.50 # in fact about 8 seconds, but it's working 14.18.57 # fragilematter: SVN or the patch? 14.19.02 # patched 14.19.06 # http://www.rockbox.org/irc/rockbox-20080226.txt I quote "23.39.07 # You'll need the other files now. Make sure you have header.txt, firmware.mi4 and pribootLoader.rom on your desktop" 14.19.08 # quick2.diff 14.19.20 # fragilematter: OK, thanks. I'll test on my Clip now, and then commit (assuming it works...) 14.19.34 # linuxstb: fingers crossed 14.20.21 # JDGordon, do you think header.txt is not necessary? 14.23.00 # kushal_12_27_200: Are you the same person who did this in February? There is a conversation with gevaerts in the logs here - http://www.rockbox.org/irc/log-20080224 14.23.22 # (with a link to a header.txt) 14.24.33 Quit moos (Read error: 104 (Connection reset by peer)) 14.24.47 Join moos [0] (n=moos@81-66-128-18.rev.numericable.fr) 14.25.09 # fragilematter: Yes, works on my clip as well. 14.25.24 # linuxstb: great! 14.25.27 # thanks a lot, linuxstb, I am the same person. I tried looking up the old irc logs but somehow missed that day's log. 14.28.28 Quit tvelocity (Read error: 104 (Connection reset by peer)) 14.29.15 Join Mathiasdm [0] (n=Mathias@78-22-198-251.access.telenet.be) 14.29.44 Quit Mathiasdm (Read error: 104 (Connection reset by peer)) 14.33.30 Join wwall [0] (n=wwall@mcn063.wlan.sas.upenn.edu) 14.34.00 Quit Seed ("cu, Andre") 14.34.40 # re 14.35.44 # linuxstb: I think as a dual boot we should rely on A3 since we don't know buttons for all the models (and also because A3 is the only 'button' accessible for the Fuze), plus model-specific buttons; and remove the check for A3 when we have a reliable method for all other models 14.35.52 # s/other// 14.36.51 Quit JdGordon (Read error: 113 (No route to host)) 14.38.08 # funman: OK. I agree we can't be too safe at this stage. 14.38.37 # I've just committed quick2.diff, with a simplification to the memcpy added. It worked on my Clip, and before I changed the memcpy, on fragilematter's e200 14.40.55 # cool, I'll be able to use last clip firmware 14.41.49 Quit DerDome ("Leaving.") 14.42.10 Join tvelocity [0] (n=tony@gw1.mycosmos.gr) 14.42.26 Join Darksair [0] (n=user@221.221.146.2) 14.47.12 Part B4gder 14.47.17 Join JdGordon [0] (n=jonno@c220-237-62-18.smelb2.vic.optusnet.com.au) 14.47.59 Join J-23_ [0] (n=aldwulf@a105.net128.okay.pl) 14.50.49 Quit culture (Read error: 104 (Connection reset by peer)) 14.52.29 Quit JdGordon ("Konversation terminated!") 14.53.13 Join at0m|c [0] (n=at0m@78-20-136-118.access.telenet.be) 14.55.01 Join culture_ [0] (n=none@cpc1-bele3-0-0-cust658.belf.cable.ntl.com) 14.55.19 Join JdGordon [0] (n=jonno@c220-237-62-18.smelb2.vic.optusnet.com.au) 14.56.48 # thanks for the cool software 14.57.14 # I just put the manual on my ipod, because I wanted to read/have the manual on my player 14.57.41 Quit J-23 (Read error: 113 (No route to host)) 14.57.46 # I converted the html to text using html2text, it works but is a little messy. 14.58.06 # so my question is is there a better way to do this? 14.58.14 Nick culture_ is now known as culture (n=none@cpc1-bele3-0-0-cust658.belf.cable.ntl.com) 14.59.27 # hmm, I am not sure what I did but I did not get it right. 15.01.04 Join Twst [0] (n=mhesten@242.80-202-24.nextgentel.com) 15.03.08 Part sandsmark 15.04.45 *** Saving seen data "./dancer.seen" 15.07.45 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 15.10.14 Join DerDome [0] (n=DerDome@dslb-082-083-236-020.pools.arcor-ip.net) 15.10.40 # wwall: well, for reading on the ipod it neads be to be plain text format one way or the other 15.11.14 # i expect there are many ways of doing that 15.11.59 # there might even be a way of converting the raw latex source code to text 15.12.45 Quit J-23_ (Remote closed the connection) 15.13.21 # preglow: that's what I'm thinking of doing now 15.13.46 Join LambdaCalculus37 [0] (i=44a04303@gateway/web/ajax/mibbit.com/x-c485e506b2ed1c84) 15.14.13 # Ideally I'd want to convert it to reStructured or markdown 15.14.28 # to get some structure but still have it readable 15.17.14 Join J-23_ [0] (n=aldwulf@a105.net128.okay.pl) 15.17.24 Join tucoz [0] (i=528612c1@gateway/web/ajax/mibbit.com/x-4b9b8f86d69c6065) 15.17.29 # fragilematter: don't run away, I'll ask you to test my dual-boot in some time :) 15.17.30 Nick J-23_ is now known as J-23 (n=aldwulf@a105.net128.okay.pl) 15.17.50 # funman: I'll be around ;) 15.18.05 # wwall: Rockbox doesn't have any "structured text" viewer at the moment, although I think there are some unofficial patches around, for example a wikipedia viewer. 15.18.22 # wwall: you could try: make manual-txt 15.18.44 # funman: You're adding button detection etc? 15.19.30 # yes 15.20.04 # doesnt the wikipedia patch one good candidat for the future comming (hopefully) patch reviewing/commenting/commiting sessions? 15.21.11 # I really want to remove word-padding of ucl files, the current memcpy+decompression executes in less than 1/2s 15.22.05 # I pad the ucl file to ensure the ucl unpack function is aligned. What's the harm? 15.22.31 # oh I didn't think about the function 15.22.45 # Well it adds complexity on the code 15.23.10 # Yes, a little, but the code should be quite stable now - i.e. no reason to change things. 15.23.33 # I add support for a compressed rockbox image 15.24.25 # 40KB isn't enough for you? ;) 15.24.37 # :( 15.24.53 # linuxstb: that way we can create a rockbox image without caring about dual boot and decompression 15.26.53 # Yes, but it's easier to do it all in the bootloader - this way, we'll need to add an extra binary into the build system (the "dual_boot.bin"). But I think it makes sense to compress the bootloader, so we'll have to add that. 15.28.24 Join midgey [0] (n=tjross@c-68-42-68-108.hsd1.mi.comcast.net) 15.30.16 Join kugel [0] (n=chatzill@e178104165.adsl.alicedsl.de) 15.31.44 # funman: There's a "bin2c" tool in tools/, so if you add mkamsboot there, you can also add the "dual_boot.bin" and ucl unpack function, and convert them to .c arrays, and link directly into mkamsboot. There is also a "libucl.a" generated in tools/ucl/src, which can also be linked to mkamsboot - meaning we can do a simple "mkamsboot of.bin bootloader.bin patched.bin" 15.32.16 # Oops, seems bin2c isn't there, but in sansapatcher/ipodpatcher... 15.32.29 # ah I didn't think about the bin2c, but I wanted to link with libucl.a in a 2nd approach 15.32.56 # i.e. in 2 steps, for easier potential debugging 15.34.39 Quit Rob2223 () 15.34.54 Quit JdGordon ("Konversation terminated!") 15.36.42 Part tucoz 15.37.29 Quit dan_a ("CGI:IRC (Ping timeout)") 15.37.57 Quit fragilematter ("Leaving.") 15.43.15 Quit midgey () 15.50.42 Join JdGordon [0] (n=jonno@c211-28-145-198.smelb2.vic.optusnet.com.au) 15.52.30 Quit bmbl (Read error: 113 (No route to host)) 15.53.45 # Hours late, I know, but I'd certainly not like to assume that a year tag is related to albums at all. That assumption can only be made for "Album..." tags, IMHO - so "Artist" is no use either. I don't know if there was a conclusion, but I'd say that "Album artist"-"Album" is a reasonable key, but there should be no substitution or magic for a missing/blank "Album artist" tag; in that case just use "Album". 15.57.13 # there is always the option of adding some unique id to all files in a folder with the same album name 16.01.30 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 16.02.21 # hey domonoky 16.02.26 # hi 16.03.03 # im fudging with my routers so my mac is on and off the net atm... wanna get the rbutil compile done nowish? 16.04.16 # i dont need the mac access now, as we already built the new rbutil 1.0.7 mac version... But i will need it again, when its time for the next release... 16.04.40 # oh ok, cool 16.04.46 # i thought it wasnt done yet 16.04.59 # linuxstb, tucoz: I can't get make manual-txt to work right now ("Unknown option -no-numbering"), so the converted html will have to do for now 16.06.41 # domonoky: Are the old binaries of RBUtil archived anywhere? 16.06.57 # 1.0.7 for Windows is crashing for me 16.06.58 # pondlife: yes, all are on the download server 16.07.01 # They should still be on the download server - /rbutil/ 16.09.09 # Thanks, will try 1.0.6 16.09.19 # Ah, what's 1.0.7b ? 16.10.37 # anyway, I wanted to propose to have a text version of the manual included in the default installation, where is the best place to submit such a proposal? 16.10.59 # 1.0.7b is version 1.0.7 with the sapi bug fixed. :-) 16.11.07 # That might be my problem ;) 16.11.15 # Crash on SAPI config? 16.11.37 # pondlife: yes, crash/hang on everything that uses the sapi script... 16.11.43 # Great 16.11.54 # OK, problem solved 16.11.59 # wwall: I don't think there's a need to propose it - it's been discussed before, but it's just that no-one has yet found a good way to generate it automatically from the latex source code. 16.12.02 # the sapi script changed to expect utf16-le input/output, and we missed that in rbutil... 16.12.20 # Fastest fix yet, then, from my point of view.. 16.13.14 # pondlife: time to fix was -5days :-) 16.13.22 Quit coatman (Remote closed the connection) 16.14.19 # I must have picked up from the old wiki (maybe early on the 29th) 16.14.40 Quit vitja (Read error: 104 (Connection reset by peer)) 16.15.44 # Does http://www.rockbox.org/history.html hold the news that's dropped off the front page? I was expecting to see 3.0 mentioned for some reason. 16.16.29 Join coatman [0] (n=coatman@r01jvgmb7.device.mst.edu) 16.20.12 # is there no wps screenshot in the manual? 16.20.24 # is there any point? 16.21.07 # I don't know. I'm just updating our freshmeat entry and was looking for a few screenshots 16.21.40 # ah, grab some off the wiki maybe? 16.21.41 # Zagor: You can always take the WPS screenshot from the Wikipedia entry on Rockbox. 16.22.47 # LambdaCalculus37: that's a good one. thanks. 16.26.00 # linuxstb: ok, thanks. 16.26.13 # Zagor: You're welcome. :) 16.27.57 # Any Archos owners tried bookmarks recently? http://www.rockbox.org/tracker/task/9435 might be worth a look 16.28.59 # pondlife: Haven't used my Archos for a while now. Thanks for giving me an excuse to fire it up again. :) 16.29.15 # LambdaCalculus37: Shame on you ;) 16.29.40 # Hehehe 16.29.45 # I use it every time I start my car. don't think I've ever bookmarked anything on it though :) 16.30.07 Join fragilematter [0] (n=fragilem@92.82.99.51) 16.34.24 Part LinusN 16.36.01 Join funman_ [0] (n=fun@86.219.158.180) 16.37.46 Quit funman (Read error: 60 (Operation timed out)) 16.37.52 Nick funman_ is now known as funman (n=fun@86.219.158.180) 16.44.36 Quit amiconn (Nick collision from services.) 16.44.42 Join amiconn [50] (n=jens@rockbox/developer/amiconn) 16.47.20 Nick JdGordon is now known as JdGordon|zzz (n=jonno@rockbox/developer/JdGordon) 16.47.41 Part wwall 16.48.29 # fragilematter: ping 16.48.41 # funman: pong 16.48.57 # sorry for leaving earlyer, I had an urgent matter to attent do 16.49.11 # no problem 16.49.22 # can you test a patch ? (I just have to add button check) 16.49.29 # of course 16.50.53 # I tested it in the emulator first, it seems fine 16.51.20 Part J-23 16.51.20 # even if it doesn't that won't be a problem now :D 16.51.22 # just give me a button 16.51.34 # stick with A3 :D 16.52.24 Join J-23 [0] (n=aldwulf@a105.net128.okay.pl) 16.52.34 # pondlife: Bookmark creation didn't crash my Archos JBRv1. 16.53.01 Quit Zagor ("Client exiting") 16.53.05 Join Rob2222 [0] (n=Miranda@p4FDCE6CB.dip.t-dialin.net) 16.55.16 # fragilematter: http://paste.ubuntu.com/53209/ you can apply it with git-apply 16.55.35 # I'll have to sync the git forst 16.55.38 # first* 16.55.53 # default is "rockbox" (infinite blink of button led) 16.57.57 Join mf0102_ [0] (n=michi@85-127-182-114.dynamic.xdsl-line.inode.at) 16.59.30 # I got a "fatal: git-apply: bad git-diff - expected /dev/null on line 73" when trying to apply the patch 16.59.49 # hm 16.59.56 # and a bunch or trailing whitespaces, but those are no problem... 17.00.04 # if you have the rockbox git tree, you should be able to use git-am 17.01.03 # I applied it to the git tree from gitorious.org :)) 17.01.24 # I thought that was what you meant 17.01.25 # hehe no this tree is a bit old 17.01.48 # so, where's the rockbox git tree, I only have svn :D 17.02.11 # let me generate a proper patch for svn tree 17.02.21 # okay 17.02.29 Join toffe82 [0] (n=chatzill@h-74-0-180-178.snvacaid.covad.net) 17.03.06 Join Schmogel [0] (n=Miranda@p3EE21B6C.dip0.t-ipconnect.de) 17.03.49 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 17.04.47 *** Saving seen data "./dancer.seen" 17.05.26 Join Hillshum [0] (n=Hillshum@75-165-238-40.slkc.qwest.net) 17.05.54 Quit Hillshum (Client Quit) 17.06.06 # fragilematter: @@ 17.06.14 # ;;) 17.06.14 # http://paste.ubuntu.com/53210/ * (apply with patch -p4) 17.06.27 # on the root of the svn 17.06.35 # yes 17.06.40 # okay 17.07.31 Quit mf0102 (Read error: 104 (Connection reset by peer)) 17.07.33 Join Hillshum [0] (n=hillshum@75-165-238-40.slkc.qwest.net) 17.07.54 # funman: Any idea if all main firmware blocks (i.e. for the various devices) are less than 128KB? 17.08.03 # so far yes 17.08.14 # but the code wouldn't be hurt by sanity checks 17.08.21 # I think I only need -p 2 17.08.36 # fragilematter: That depends where you are when you apply it... 17.09.02 # the root of the svn, and it should be working with relative paths 17.09.39 # p1 then 17.09.51 # p1 worked 17.10.01 # git uses fictives a/ and b/ directories for original and modified files 17.10.35 # you used uclpack 2 times? 17.10.43 # I pack the 'rockbox' image also 17.11.21 # oops 17.11.24 # I made a mistake 17.11.32 # I didn't flash yet :D 17.11.45 # fragilematter: in boot.S GPIOA value is incorrect, should be 0xC80B0000 17.12.17 # corrected 17.12.30 # cleaned and made it again 17.12.51 # it boots the test code on A3 = #0 or A3 != #0? 17.12.58 # = #0 17.13.03 Part Hillshum 17.15.04 # upgraded... 17.15.04 # kugel: You could test SVN code on your fuze - it's working on the Clip and E200... 17.15.26 # normal boot: blinks like crazy 17.15.47 # wow 17.16.08 # * linuxstb thinks we're getting good at this ;) 17.16.29 # the blinking stopped quite fast on power button 17.16.38 # it wasn't like it had the time to reset 17.16.51 # but it boots normal on usb 17.16.54 # cool :) 17.17.09 # I'll add some code for model-specific button tests and ask you again 17.17.20 # okay :) 17.18.57 # fragilematter: choose a button for dual boot (one of the 4 directions) 17.19.08 # down 17.19.36 # you don't have to squeeze your finger between the others to press it :)) 17.19.38 # linuxstb: which player are you guys workig on? The sansa v2's? 17.19.51 Quit Schmogel (Read error: 104 (Connection reset by peer)) 17.20.10 # funman: To be consistent with Rockbox, you could add "TARGET=-DTARGET_NAME" in the Makefile, and then add $(TARGET) to the test.S compile command. e.g. -DSANSA_CLIP, -DSANSA_E200V2 17.20.15 # markun: Yes. 17.21.08 # linuxstb: the procedure is still the same? I.e. edit the make file to point to my fuze firmware file, then just make 17.21.50 # kugel: the test.S from svn has no safety check 17.22.00 # Yes, and then copy patched.bin to your device, renaming appropriately. 17.22.07 # fragilematter: What kind of safety check? 17.22.09 # so it is pretty much equal to bricking if you have no recovery mode 17.22.20 # button test for dual boot 17.22.35 Join Schmogel [0] (n=Miranda@p3EE21B6C.dip0.t-ipconnect.de) 17.22.39 # fragilematter: the svn has no dual boot either 17.22.49 # fragilematter: svn is tested on both clip and e200v2, so I guess there's little chance to brickage 17.23.14 # I forgot that it branches back to the of after delay 17.23.31 # I guess I got used to gpio checks in test.S :D 17.23.44 # linuxstb: ok weel, but I need to add the target first in the build management 17.23.59 # Anyone think I should disable the keyclick on PP targets in 3.0 ? 17.24.07 # funman: What build management? The "user" (i.e. developers...) can just modify the Makefile 17.24.37 # sure 17.25.07 # pondlife: Aren't you a bit late to ask that? ;) 17.25.14 # Yes ;) 17.25.16 # * linuxstb will be impressed if pondlife can do it 17.25.25 # I meant in SVN, sorry 17.25.35 # Jetlag and DVT - not good 17.25.45 # * kugel can't find his fuze 17.25.49 # as has no support for defines 17.25.59 # given on the command line I mean 17.26.21 # gcc -nostdlib -c would be fine 17.26.51 # funman: Ah yes... I had the same problem with the ucl function - took me a while to realise that arm-elf-as wasn't running cpp 17.27.11 # I don't think you need -nostdlib with -c 17.29.09 # * kugel needs a pointer to his fuze 17.29.45 # hum cpp replaces the defines: ".ifdef SANSA_CLIP" => ".ifdef " 17.30.19 # oh I must use the cpp #define, not as .define .. 17.30.37 # * fragilematter 's pointers are all out of range :( 17.31.08 # gevaerts: It might be difficult to find a M6T1/TP: meizu offered to exchange them for a newer model. 17.31.10 # linuxstb, funman: Just let gcc handle the .S files - it will run cpp and then as 17.31.20 # yes that's what I do 17.31.23 # Afaik this is how it's done in various parts of rockbox... 17.31.31 # linuxstb: 5s delay, then maybe some delay due to the decompression of the OF, then successful boot into the OF <-- is that supposed to happen? 17.31.45 # kugel: nope, your fuze should have been bricked ! 17.31.50 # our evil plan failed :( 17.32.05 # fragilematter: out of range was good, I found the fuze, but not where it was supposed to be 17.32.06 # amiconn: Yes, that's what I did. 17.32.22 # funman: I haven't done anything yet 17.33.06 # kugel: Yes, that's what we're hoping for... 17.33.13 # kugel: he ok, yes this is what should happen (the decompression is nearly not noticeable) 17.33.27 # "uclpack not found" 17.33.40 # you need to make uclpack in the tools dir 17.34.46 # fragilematter: http://paste.ubuntu.com/53219/ 17.34.55 # incremental? 17.35.23 # no 17.35.33 # okay, I'll clean up first 17.36.10 # I corrected a size check in mkamsboot.c, and added button checks in Makefile & boot.S 17.36.25 # you can run diff on the 2 diffs to get the incremental change ;) 17.36.44 # I cleaned up already 17.36.48 # or was it only a comment that I corrected .. :o 17.37.50 Join rasher_ [0] (n=rasher@0x5550f5a3.adsl.cybercity.dk) 17.37.59 Quit rasher_ (Client Quit) 17.38.00 # * kugel crosses fingers 17.38.06 # funman: do you want to check or should I go ahead with the test? 17.38.17 # fragilematter: test ! test ! 17.38.30 # :) 17.38.37 # success! 17.38.42 # great guys 17.38.57 # kugel: cool :) 17.39.05 # uncomented the e200 define and changed the infile name... gonna make it 17.39.08 # yes, cool. really! 17.40.17 # updating the sucker... 17.40.56 # normal boot by pressing power alone 17.41.15 # blinking like crazy on down 17.41.20 # hum I missed something then .. it should default to rockbox 17.41.37 # you set it the other way around :)) 17.41.59 # maybe the meaning of C6 is reversed (0 = button pressed) 17.42.16 # prolly 17.42.21 # i'll update my clip 17.42.37 # fragilematter: what if you change the bne into beq in boot.S ? 17.43.03 # beq boot_of 17.43.47 Join mcuelenaere [0] (n=mcuelena@rockbox/developer/mcuelenaere) 17.43.50 # hum my check for home button is broken 17.43.54 # (on the clip) 17.44.11 # meaning? 17.44.23 # it just boots the of all the time? 17.44.25 # I can't read it - but my check for hold button is correct so I can recover 17.44.34 # great then :D 17.44.35 # no it boots the 'rockbox' code 17.44.54 # I'll just use down, to be consistent with E200 17.45.17 # weird as hell 17.45.24 # it behaves like before 17.45.34 # * fragilematter is suspecting a bad flash 17.45.42 # ah no stupid me I forgot to uncomment the define in Makefile 17.46.11 # * fragilematter is stupid too, edited a different #define section 17.46.17 Quit wpyh (Remote closed the connection) 17.46.20 Join mf0102__ [0] (n=michi@85-127-38-241.dynamic.xdsl-line.inode.at) 17.46.32 Quit mf0102_ (Read error: 110 (Connection timed out)) 17.47.02 # fragilematter: so is this patch correct, or does the check for e200 button need to be changed ? 17.47.20 # funman: Let's keep booting into the OF by default. 17.47.21 # the down check is correct of you want it to boot the OF by default 17.47.37 # yep, I vote for OF by default too 17.47.52 # well I think for all the other ports it's rockbox by default 17.47.57 Quit petur ("work->home") 17.48.12 # when we'll have rockbox booting we can change it :D 17.48.20 # funman: but in early stages it's to the OF by default. We can change later when rockbox is in a usable state 17.48.37 # fragilematter: and if I want rockbox by default, does changing bne into beq at line 80 makes it behave the correct way ? 17.48.51 # I'll check it now, earlier I edited the clip code 17.48.51 # funman: See, a broken butten detection or forgotten 17.48.52 # kugel: how can you run rockbox on your fuze if you don't have any way to dual boot then ? 17.49.13 # forgotten #define can render the device into a brick, while we can reach the same without having this risk 17.49.25 # kugel: we still have usb/hold check as a failsafe 17.49.42 # kugel: no, in case anything goes wrong you can put on the hold button and plug your device over usb to run the OF (and update the firmware) 17.49.54 # usb for fuze & e200 17.50.03 # for e200 and fuze you don't need the hold button 17.50.26 # but that makes a procedure common to all sansaV2 models, maybe less confusing to newcomers 17.50.53 # funman: your @s are broken again 17.51.05 # But what if the USB detection is broken? I rather insert the USB to see the blinking LCD, instead of being dependent on the detection in order to boot into the of 17.51.23 # fragilematter: sorry ... you can change ' ' into ' ' 17.51.34 # I type the first 'space' with altgr+space 17.51.37 # kugel: it can't be broken, it is independent of the #defines 17.51.46 # lol 17.51.56 Join wpyh [0] (n=william@123.151.132.200) 17.52.09 # fragilematter: Didn't you agree with me some minutes ago? 17.52.41 # I wanted default OF so I won't have to do key combinations when I want to use the e200 :)) 17.52.55 # kugel: the USB detection is not broken, it's the very first check made 17.53.12 # and it is made unconditionally of the device (I have a brickable model too) 17.53.34 Join rasher_ [0] (n=rasher@0x5550f5a3.adsl.cybercity.dk) 17.53.44 # fragilematter: well just flash it with the OF when you're finished hacking 17.54.02 # in any case, I'd feel alot more comfortable if we boot into OF by default 17.54.27 # fragilematter's argument is very valid too 17.54.28 # funman: flashing the e200 takes a bit more than the clip and I'd rather not 17.54.44 # beq = reversed behaviour 17.55.02 # with beq it boots 'rockbox' by default ? 17.55.07 # yep 17.55.22 # ok 17.55.30 # I'll comply with your requests guys :) 17.55.37 # thanks 17.55.49 Nick rasher_ is now known as rasher (n=rasher@rockbox/developer/rasher) 17.56.09 # * fragilematter feared funman might have used a full clip on the disobeying crowd :)) 17.56.15 # funman: let me test the led blinking code. I'm keen on that for some time now :) 17.56.26 # kugel: just wait for the next patch then 17.56.33 # will do 17.57.32 # hm imagine that: 17.57.42 # my device has no battery 17.58.06 # gevaerts, would you be able to help me now? 17.58.07 # I plug it over usb to recharge it, but then our bootloader will execute 'rockbox' which doesn't support recharging over USB 17.58.12 # funman: "mov r2, #0x40000" that's the address in the ram we copy the compressed image too, sin't it? 17.58.24 # kugel: yes, it's the upper limit of our copy 17.58.47 # funman: the instruction manual says "press hold to recharge" :P 17.58.50 # so still, I'm reluctant to make OF by default 17.59.05 # we have a lot more ram available on the non-clips, how about moving it further behind for this targets? 17.59.06 # well for my Clip yes 17.59.10 # not for kugel's Fuze 17.59.17 # kugel: there is no point 17.59.48 # we can overwrite the compressed image since we don't use it anymore after booting 18.00.20 # okok, I was just asking :) Never change a running system is probably the better way here 18.00.20 # so, we're now down to sd & fat drivers 18.00.35 # lcd, audio, usb .. 18.00.46 # for the bootloader :P 18.01.02 # I assume the sd driver will be nearly the same as on e200v1 18.01.14 # we do have the bootloader now ! 18.01.28 # linuxstb: how about committing this http://paste.ubuntu.com/53224/ ? 18.01.38 # the bootloader that will boot rockbox from disk :)) 18.01.53 # kushal_12_27_200: in half an hour or so. I'm on my way home now 18.02.01 # fragilematter: we can put rockbox in the firmware file directly 18.02.08 # thank you 18.02.33 # flashing every new version would be less than ideal 18.02.48 # funman: How/where? 18.02.53 # funman: that's not the goal. we want to be able to update as easily as on existing targets 18.02.54 # very true 18.03.02 Part eight 18.03.07 # linuxstb: in svn ? 18.03.27 # kugel: patch -p 1 on the svn root 18.03.27 # funman: I was responding to "we can put rockbox in the firmware file directly" 18.03.38 # kugel: true, but for now we don't have a way to read from the nand 18.03.43 # fragilematter: did you test this version? 18.03.47 # yep 18.03.50 # funman too 18.03.51 # linuxstb: replace test.ucl by a compressed rockbox image 18.04.06 # funman: It won't fit - a full Rockbox binary will be a few hundred KB 18.04.11 # ah ok 18.04.15 # fragilematter: I assume funman changed something since the last pastebin 18.04.27 # right 18.04.36 # let me see... 18.04.51 # I only reversed the meaning of C6 button for e200 and removed the weird spaces 18.05.02 # funman: Although obviously it can't be for the Clip.... That's a problem for later though. 18.05.28 # I meant we can use it to test other code while waiting for a NAND/SD driver 18.05.46 # well, a nand/sd driver would probably be the test code :D 18.06.09 # funman: Yes, that's what the Rockbox bootloader will be used for - the bootloaders are just stripped-down versions of Rockbox itself, using the same drivers. 18.06.23 # funman: How about just trying the e200v1 SD driver and see if it works 18.06.25 # Since the AMS bootloader loads the SanDisk firmware from NAND, the nand could be already initialised when we start executing 18.06.34 # kugel: it's just not the same 18.06.43 # linuxstb: Ok 18.06.50 # funman: So the plan will be to start work on writing a Rockbox bootloader, and use that to test/develop the various drivers. Once those drivers are written (which are needed for Rockbox itself anyway), we can switch to loading a Rockbox binary from disk. 18.06.54 # kugel: and it might be dangerous 18.06.57 # funman: why exactly are you so sure? 18.07.18 # funman: And then we're done ;) 18.07.25 # kugel: because I read both code (in rockbox for V1 and in OF for V2) 18.07.30 # yeah.. 18.07.58 # funman: Better compare OF for v1 with OF for v2 18.08.01 # guys, I'll be out for about 30 minutes... any last words? :)) 18.08.19 # kugel: different processors = different OF 18.08.26 # fragilematter: Have you tested the latest pastebin patch? 18.08.38 # yep, tested and working 18.08.47 # fragilematter: it's both arm, not too different 18.08.59 # kugel: you can do that if you want but I think it's useless, the C driver of rockbox is much more readable 18.09.34 # both arm, but they have different hardware architectures 18.09.38 Quit BigBambi ("http://www.mibbit.com ajax IRC Client") 18.09.51 # I strongly assume Sandisk reused the SD interface from the v1 (since they've added it to the AMS package) 18.10.00 # anyways, I'll be back in a while 18.10.06 # fragilematter: see you 18.10.08 # * fragilematter waves 18.10.14 # linuxstb: now it's time to sync the flyspray patch adding the e200v2 target 18.10.18 Quit z35 ("Leaving") 18.10.40 # funman: Oh, there's a patch already?... 18.10.43 # and I think remove the assumptions that it shared drivers with as3514 18.11.20 # #8842 18.11.22 # #8843 * 18.11.24 # Hmm, April 2008... 18.11.28 # Why not prove that the assumptions are wrong first? 18.12.00 # kugel: well feel free to test ;) 18.12.17 # check which hardware is in the Fuze, etc 18.12.35 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 18.12.42 Quit goffa_ (Read error: 60 (Operation timed out)) 18.13.46 # I highly doubt that hth posted a nand driver without being at least 90% the driver is correct 18.13.47 Join bughunter2 [0] (n=Jelle@77.164.66.126) 18.13.50 # funman: I'm not sure about that patch - I think it's better to just commit things in much smaller pieces. 18.14.17 # 90% sure 18.14.47 # well it's tested 18.14.53 Join MethoS- [0] (n=clemens@host-091-096-209-237.ewe-ip-backbone.de) 18.15.06 # and now I'm not sure how I can split it 18.15.28 # funman: We're confused again - I'm talking about #8843 18.15.30 # ;) 18.15.33 # aah 18.15.46 # yes sure I agree 18.16.01 # but at least the defhardwa 18.16.08 # define for hardware registers* 18.16.11 # first* 18.16.17 # No, the hardware registers aren't defined in the Rockbox style. 18.16.25 # See the other files in firmware/export/ 18.16.28 # ok 18.16.40 Join goffa [0] (n=goffa@216.220.23.105) 18.16.54 Quit Schmogel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 18.17.00 # It looks very useful to use as a reference, but I don't think it's committable. 18.17.11 # I'll check the NewPort wiki page also 18.17.15 # see you later 18.17.17 Join Schmogel [0] (n=Miranda@p3EE21B6C.dip0.t-ipconnect.de) 18.17.41 Quit funman ("non pas myleeeeeeeene") 18.18.01 Quit Schmogel (Client Quit) 18.19.55 # * linuxstb spots a problem in tools/configure for the Clip - the "memory" variable assumes multiples of 1MB... 18.21.00 Quit tvelocity (Read error: 60 (Operation timed out)) 18.21.05 # linuxstb: what do you think? Couldn't it be possible that the sd interface is entirely the same with the v1? 18.21.30 # kugel: I have no idea, I haven't looked at either. 18.25.38 # linuxstb: Why is that a problem? Does the clip come with various different memory sizes? 18.25.51 # amiconn: It has 320KB of RAM 18.26.04 # Yes, but it *always* has that 18.26.09 # Yes. 18.26.22 # So set 'memory' in configure to 0 ... 18.27.15 # But that means hacking the .lds files to ignore it... 18.27.46 # But I guess the Clip will need some special lds anyway... 18.27.47 # Isn't the .lds target specific anyway these days? 18.28.44 # Potentially, yes. But it's generally architecture specific... 18.29.22 # hmm 18.29.47 # Well, the other option would be to change configure to use KB. That means touching all targets.... 18.30.38 # linuxstb: heh, "DOS addresses only 1 Megabyte of RAM because we cannot imagine any applications needing more." 18.30.51 # Yes, I was thinking of KB, but don't like doing those kind of changes... 18.31.03 # * amiconn is really curious how rockbox will be made to fit on the Clip... 18.31.16 # kushal_12_27_200: I'm here now 18.31.22 # yay 18.31.49 Quit fragilematter ("Leaving.") 18.32.49 # amiconn: Moving lots of things to plugins (that's basically what the OF works). Although I've no idea how that can be done cleanly... 18.33.03 # kushal_12_27_200: could you quickly summarize the state of your c200? 18.33.44 # linuxstb: Does the clip's CPU have an MMU? 18.33.44 # amiconn: But this work is applicable to all the SansaV2 targets, I just bought a Clip because it's the cheapest such device, and wanted to help get the port started. 18.34.01 # I think so. 18.34.01 # Do the others have more RAM? 18.34.15 # Well, if it has, you could use virtual memory... 18.35.02 # I think the others all have a "normal" amount of RAM. I don't know for sure though. 18.36.42 # Hmm. The clip seems to have the same OLED display as the Express 18.37.00 # This is actually monochorme (just with 2 differently coloured areas) right? 18.37.10 # Yes, it looks that way. 18.37.14 # funman reported that too 18.37.46 # Well, monochrome will already save quite some meory (smaller bitmaps, no album art...) 18.38.15 # Going thumb would probably help too 18.38.57 # Just compare with the archoses - they're monochrome, and thumb code should be comparable in size to SH1 code 18.39.08 # (SH1 istructions happen to be 16 bit too) 18.39.35 # How big is a typical archos binary? 18.39.36 # I have no doubt rockox can run on the clip 18.39.44 # Well, archos is hwcodec, but they still need a playback engine. Codecs are separate anyway (but need their buffer of course) 18.39.48 # kugel: Not by magic... 18.40.15 # linuxstb: sure. archos bin size is ~200KB btw 18.40.17 # Does the Clip have recording? Radio? 18.40.43 # fm recorder 260KB 18.40.46 # I've no idea... Let me turn it on... 18.40.54 # http://pastebin.com/f9aa23a2 18.40.56 # Smallest archos binary is the Player (193KB) but no radio and no recording, and charcell 18.41.11 # gevaerts http://pastebin.com/f9aa23a2 18.41.17 # Yes, it has FM 18.41.30 # Recorder is 248KB uncompressed 18.41.31 # And a "Voice" menu, which I assume is mic recording. 18.42.01 # This is just the binary though - it needs further ram for BSS 18.42.31 # And that's with dircache? 18.42.36 # without 18.42.43 # Ah yes, lowmem... 18.43.04 # kushal_12_27_200: after my repair tool you need to follow the instructions in http://www.rockbox.org/twiki/bin/view/Main/SansaE200Unbrick#Manufacturing_Mode 18.43.38 # ok 18.43.43 # * linuxstb sees the Archos losing the "lowmem" title in the future 18.44.01 # Unless the clip is just called "nomem" 18.44.15 # tinymem 18.44.47 # Well, I still wonder how the Openneo people managed to do it 18.44.54 # Call it "I'm sure there was some memory somewhere!" 18.45.10 # The neo has only 256KB RAM, and openneo is a fork of (very) early rockbox 18.45.10 # Or "fullmem" and "highmem" 18.45.36 # And here I thought that the iFP was already our "king of the lowmem targets", despite it not being a supported target. 18.45.50 # The neo doesn't need to be conservative with power though, as it's fed by a car battery... 18.46.18 # But they even added voice iirc... 18.46.46 Join create [0] (n=55443911@gateway/web/cgi-irc/labb.contactor.se/x-07feee34048d5bad) 18.48.34 # Maybe the Express is just a Clip in a different case? 18.48.51 # i am holding the record button. progress so far: http://pastebin.com/f43d79cc2 18.49.38 # kushal_12_27_200: you can enter recovery mode or not? 18.49.48 # amiconn: I know nothing about the Express - is that a third type of CPU? 18.49.53 # OK. Now it should be in recovery mode. Does it show anything on the screen? 18.49.56 # the screen is still blank 18.49.58 Join PaulJam_ [0] (i=PaulJam_@vpn-3019.gwdg.de) 18.50.19 # linuxstb: I mean the Sansa Express 18.50.24 # That's weird 18.50.43 # kushal_12_27_200: did you run "e200tool init" before? 18.50.48 # amiconn: I know - I meant to say "does that use a third type of CPU, or is it either PP or AMS"? 18.50.50 # no 18.50.57 # try that 18.51.18 # linuxstb: I don't know. But the technical data looks suspiciously similar to the Clip 18.51.18 # so can i let go of record button? 18.51.37 # kushal_12_27_200: once it's plugged in you don't need to hold any buttons 18.51.49 # oo 18.51.49 # amiconn: Seems to be sigmatel of some kind 18.52.09 Quit PaulJam (Read error: 110 (Connection timed out)) 18.53.00 # gavaerts, it seems like e200tool-mac is still alive. http://pastebin.com/f43d79cc2 18.53.15 Join jhulst [0] (n=jhulst@148.61.141.45) 18.53.28 # the process did not finish, afaik 18.53.42 # Press ctrl-C 18.53.42 Part pondlife 18.53.55 # ok done 18.54.40 # e200tool init gives command not found 18.55.01 # ./e200tool-mac init 18.55.45 # its doing a backward count 9 8 7 ... 18.55.50 # amiconn: Specifically, the Sigmatel 3630 - http://www.sigmatel.com/documents/3600-ProductBrief.pdf (300MHz ARM926EJ-S core!) 18.56.07 # not found, do I need to disconnect it and connect again? 18.56.10 # Yes 18.56.29 # Oh, hmm 18.57.54 Join funman [0] (n=fun@86.219.158.180) 18.58.10 # OK I did that. latest pastebin: http://pastebin.com/f5d208361 18.58.15 Join BigBambi [0] (n=Alex@rockbox/staff/BigBambi) 18.58.56 # well, now you should be able to use the recover command, but it seems to be stuck again 18.59.43 Join ea_suter [0] (n=easuter@ev2-84-90-182-83.netvisao.pt) 19.00.07 # * gevaerts doesn't really understand why it's stuck 19.00.44 # hi there 19.01.10 # is there a sudo/root equivalent on mac? I know on linux you need to run e200tool with root access 19.01.23 # There is sudo 19.01.24 # hmm , os x has sudo 19.01.29 # try this 19.01.43 # yesterday i had asked what I would need to help with the e200v2 porting, and one of the answers was to be able to "code for example". what does coding for example mean exactly?... 19.01.43 # do I need to control c first? right? 19.01.50 # yup 19.03.01 # ea_suter: write device drivers for the hardware 19.03.12 # ea_suter: Just that coding (programming) is one way you can help (i.e. an example of how you can help) 19.04.01 # linuxstb: Is there a way for me to get the datasheets for the as3525? 19.04.23 # kugel: you can ask them to Bagder 19.04.32 # well it's only 1 document 19.04.35 # ok, done! http://pastebin.com/f55f6befa 19.04.38 Join fragilematter [0] (n=fragilem@92.82.99.51) 19.04.48 *** Saving seen data "./dancer.seen" 19.05.01 # kushal_12_27_200: good, looks way better, now repeat the recover step 19.05.10 # kugel: What funman said 19.05.15 # ok 19.05.19 # Bagder: ping 19.05.41 # is it this one http://www.rockbox.org/twiki/bin/view/Main/SansaE200Unbrick#Recovery_Mode ? 19.06.02 # kushal_12_27_200: the "./e200tool-mac recover pribootLoader.rom" one, just with sudo this time 19.06.31 # do I need to disconnect and reconnect the cable for that? 19.06.38 # no 19.06.41 # ok 19.08.00 # It is searching for the device but no luck. :( latest: device not found. 19.08.48 # kushal_12_27_200: unplug and try again. I don't think the init step is really needed 19.09.05 # afaik it is 19.09.41 Join Thundercloud [0] (n=thunderc@cpc1-hem18-0-0-cust660.lutn.cable.ntl.com) 19.09.42 # but apparently it's not always finding the device. From the pastebin, the first init said not found, the second one directly after found it 19.09.53 # kugel: I've never needed it 19.10.59 # I recall someone (maybe barrywardell) saying that e200tool was generally unreliable on a Mac - it needs lots of attempts to get working, and possibly a reboot of the Mac. 19.11.00 # do I need to unloce before the recover step? 19.11.11 Join miepchen^schlaf [0] (n=miepchen@p579ECEB1.dip.t-dialin.net) 19.11.26 # unlock the hold 19.11.35 # does someone know by chance what font is used in the pegbox - title and game screen? 19.12.07 # pl thanks guys 19.12.07 Join Wictor_ [0] (n=Wictor@0x57366a52.bynxx19.dynamic.dsl.tele.dk) 19.12.10 # should the hold be orange or white when I do the recover? I am confused a bit 19.12.14 # kushal_12_27_200: No, keep it locked, and press REC immediately after the recovery command succeeded 19.12.20 # well, I have a little mips assembly knowledge 19.12.42 # kind of new to reverse engeneering stuff though 19.13.50 # gevaerts: btw, I've made the enum for FS#6800, is it what you expected? 19.14.01 # mcuelenaere: Is it normal that an Onda vx747 normal build doesn't build, and a bootloader builds but throws a lot of warnings? 19.14.25 Quit jfc (Read error: 104 (Connection reset by peer)) 19.14.29 # amiconn: yes 19.14.33 # kugel: a lot better, yes:) 19.14.37 # thanks. latest pastebin here : http://pastebin.com/f4859e0cd 19.14.43 # I haven't tried the normal build yet and bootloader build isn't ready for the build table yet 19.14.45 Join jfc [0] (n=john@dpc691978010.direcpc.com) 19.14.53 # Ok, so my crosscompilers on Interix are all working as they should 19.14.54 # it's, let's say, highly experimental ;) 19.15.02 # kushal_12_27_200: you are now in the recovery mode, aren't you? 19.15.04 # kushal_12_27_200: ok. Anything on the screen? 19.15.25 # Now I just need to write gpl'd replacements for stdint.h and inttypes.h, and then write down the instructions... 19.15.37 # Screen says: Mini-B->Device Mode (next line starts here)USB2.0 MSD (next line starts here)LUN0 locked 19.15.42 # gevaerts: You could just try the patch with your c200 19.15.48 Quit Wictor (Read error: 60 (Operation timed out)) 19.16.12 # kushal_12_27_200: ok, I expect it keeps adding LUN0 (un)locked lines? 19.16.12 # gevaerts, now I can see the 16 MB partition in disk utility 19.16.19 # kugel: I'll do that later, while I'm testing things on the c200 anyway 19.16.21 # just one line 19.17.00 # but I cannot mount the 16 MB partition 19.17.02 # kushal_12_27_200: Ok, I've experienced that it adds such lines for the time being. Anyway, you should be in recovery mode and see the 16MB FORMAT drive 19.17.10 # kugel: I'd like to try your newest revision of FS#6800 on my c200. Can you roll a build for me? My laptop is indisposed at the moment. 19.17.17 # ea_suter: maybe a first step is writing a lcd driver, there is some informations on http://www.rockbox.org/twiki/bin/view/Main/SansaE200v2 19.17.24 # LambdaCalculus37: of course! :) 19.17.25 # kushal_12_27_200: you need the mount lines from last time. Let me check 19.18.07 # yes, I see it but not in finder. only in the disk utility 19.18.35 # * funman thinks it's time for subscribing to rockbox mailing lists 19.18.49 # kushal_12_27_200: run "mkdir /tmp/sansa" 19.19.00 # funman: Join the club! ;) 19.19.21 # kushal_12_27_200: after that, "sudo mount -t msdos /dev/disk1 /tmp/sansa" 19.19.32 # file exists. Ok moving on to next step 19.19.57 # http://www.rockbox.org/twiki/bin/view/Main/PortingHowTo : the "tools/configure" section is a bit messed up, some problem with wiki update ? 19.20.06 # doesn't make feature automount? 19.20.23 # kugel: usually it does, but apparently not always. 19.20.28 # gevaerts, done, no output 19.21.06 # drop the firmware file, and empty sansa.fmt file and the bootloader file into that folder 19.21.19 # s/make/mac/ btw :S 19.21.23 # kushal_12_27_200: ok. Do you still have firmware.mi4 and pribootLoader.rom? 19.21.23 # funman: Looks like the layout is all wonked up. 19.21.38 # yes, gevaerts in desktop 19.21.42 # kugel: not that easy. /tmp/ won't appear in the finder... 19.21.44 Join herrwaldo [0] (n=waldo@ip-81-11-219-17.dsl.scarlet.be) 19.21.50 # funman: I'm going to fix the page now. 19.22.16 # LambdaCalculus37: Maybe some twiki plugin is missing? 19.22.21 # gevaerts: well, why did you tell him to create the mount point in tmp then? ;) 19.22.22 # kushal_12_27_200: ok. "sudo cp firmware.mi4 pribootLoader.rom /tmp/sansa" 19.22.23 # (or needs enabling for that page) 19.22.37 # hello all 19.22.40 # kugel: I don't have a mac here, so I don't know where else... 19.22.51 Join nuonguy [0] (n=john@c-71-198-1-139.hsd1.ca.comcast.net) 19.22.53 # kugel: also, I'm pasting from logs :) 19.22.59 # ah 19.23.11 # gevaerts, do I need header.txt? 19.23.32 # kushal_12_27_200: do you have it? If so, "sudo cp firmware.mi4 pribootLoader.rom header.txt /tmp/sansa" 19.23.35 # amiconn: I found %CODE{"bash"}% in the wiki page. 19.23.39 # If not, I don't think it matters 19.24.12 # has anyone had a look at my #9325 patch ? 19.24.24 # I think I saw other pages with the same problem 19.24.26 # kushal_12_27_200: after that, "ls -l /tmp/sansa", to verify that everything is there 19.24.28 # done, no output 19.24.45 # ok 19.24.58 # gevaerts, LambdaCalculus37: http://www.alice-dsl.net/simonemartitz/forlambda/rockbox-c200-bl-fading.zip <-- backlight fading build 19.25.03 Join perrikwp [0] (i=9821373a@gateway/web/ajax/mibbit.com/x-3332f25d915d5875) 19.25.32 # kushal_12_27_200: can you pastebin the output? 19.25.36 # latest pastebin : http://pastebin.com/f4a2b03d6 19.25.50 # oh, just the output? ok 19.25.56 # that's fine 19.26.06 # kushal_12_27_200: now "sudo umount /dev/disk1" 19.26.15 # funman: It's fixed now. 19.26.16 # you certainly don't need the header.tt 19.26.24 # thanks ;) 19.26.31 # kushal_12_27_200: add an empty sansa.fmt please 19.26.33 # no output 19.26.42 # kushal_12_27_200: now "sudo hdiutil detach /dev/disk1" 19.26.47 # kugel: no point 19.26.52 # amiconn: I replaced the %CODE{"bash"}% with the tags. The page appears correct now. 19.26.54 # kugel, I am quite illiterate in this matter 19.26.58 # kugel: sansa.fmt doesn't do anything on c200 19.27.02 # sure? 19.27.04 # yes 19.27.06 # ok then 19.27.53 # disk unmounted, disk ejected says terminal. disk unlocked, disk ejected says sansa 19.28.02 # kushal_12_27_200: ok. Now unplug 19.28.07 # ok 19.28.50 # reading main image, writing main image... it rebooted and I guess now I need to unlock the hold switch? 19.28.54 # Yes 19.29.20 # Once the OF boots, go to the Settings menu and ask it to format, to make sure 19.29.21 # it turned on to the sansa 19.29.43 # I am in language screen. I am choosing English and going to format 19.30.06 # * pixelma summons midgey 19.30.10 Nick gromit`` is now known as gromit_na_gromit (n=gromit@ALagny-154-1-12-13.w83-112.abo.wanadoo.fr) 19.30.12 # format complete. 19.30.22 # ok. Now it should be as good as new again 19.30.31 # thank you gevaerts! 19.30.45 # * kugel doesn't want credits 19.30.58 # thank you kugel 19.31.04 # I never forgot you either 19.31.06 # LambdaCalculus37: How's it? 19.31.09 # you guys are awesome! 19.31.17 # kugel: actually, the fact that sansa.fmt doesn't work is the entire reason you need special tools for the c200 19.31.44 # i just copied .rockbox into the root folder in sansa. 19.31.58 # kugel: The backlight fades out but doesn't fade back in. 19.32.07 # ok ttyl. bye for now! 19.32.15 # * gevaerts waves 19.32.25 # * kushal_12_27_200 waves back 19.32.32 Quit kushal_12_27_200 ("Leaving") 19.32.34 # LambdaCalculus37: really? 19.32.54 # kugel: As it's said, "ya rly". :) 19.34.05 # Well, actually my build contains a change which is not in the patch on the tracker 19.34.08 # in button.c 19.34.15 # jhMikeS: ping 19.34.48 # and obviously, backlight_is_on doesn't work so well (i.e. doesn't return false with off backlight) 19.35.23 # kugel: Can you roll another build without the other change? 19.35.27 Quit moos ("Rockbox rules the DAP world") 19.36.11 # sure, wait a moment 19.37.16 # LambdaCalculus37: I tell you why I didn't notice it on my e200 19.37.21 Quit fragilematter ("Relaxing with a bit of TeeWorlds gameplay") 19.37.30 # it turns on when I use the wheel 19.38.05 # jhMikeS: Why is backlight_on() in button.c on every button press even if the backlight is on? 19.38.42 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 19.39.03 Quit Wictor_ (Read error: 104 (Connection reset by peer)) 19.39.15 Join Wictor [0] (n=Wictor@0x57366a52.bynxx19.dynamic.dsl.tele.dk) 19.39.49 # LambdaCalculus37: there you go, same link 19.40.24 Join PaulJam__ [0] (n=PaulJam_@vpn-3017.gwdg.de) 19.41.40 Quit daurnimator ("Cyas later...") 19.43.01 # what's MODEL_NUMBER define in firmware/export/config-*.h ? c100 and ondavx747 have the same for example 19.44.32 Part ea_suter 19.45.27 # funman: It _should_ be a unique number... But it's not that important, I think it's just used in the header of main Rockbox binary to identify the model that binary is for. 19.46.09 # There are lots of duplicates already 19.46.19 # I assume it's the same id you add in the configure script in the model id field 19.46.37 # or should be* 19.47.11 # there is also target= in tools/configure 19.47.41 # target_id* 19.47.45 Quit Horschti (Read error: 110 (Connection timed out)) 19.47.58 # I was refering to that one 19.48.21 Join Horschti [0] (n=Horscht@p4FD4CE5A.dip.t-dialin.net) 19.48.28 # funman: That one is for the menus in configure... 19.48.47 # Ah, no, it's not... 19.49.11 Quit PaulJam_ (Read error: 60 (Operation timed out)) 19.50.36 # just realised that we shouldn't use the current pegbox images anyways... :\ 19.52.58 # kugel: This one works. 19.53.02 Join kronflux [0] (i=kronflux@blk-138-78-15.eastlink.ca) 19.53.16 Quit create ("CGI:IRC (EOF)") 19.53.17 # heyy everyone 19.53.27 # * bertrik waves 19.53.37 # Hi kronflux! 19.53.41 # LambdaCalculus37: nice 19.53.49 # * linuxstb fixes configure to make target_id unique 19.53.58 # LambdaCalculus37: how's the fading compared to the beast? 19.54.20 Join meven [0] (n=meven@lav35-1-82-236-137-162.fbx.proxad.net) 19.54.26 # kugel: Very smooth. 19.54.42 Quit MethoS- (Read error: 104 (Connection reset by peer)) 19.54.44 # better/worse? 19.54.56 # longer/shorter? 19.55.04 # Better/shorter. 19.56.22 Join MethoS- [0] (n=clemens@host-091-096-209-237.ewe-ip-backbone.de) 19.58.01 Quit Wictor (Read error: 104 (Connection reset by peer)) 19.58.12 Join Wictor [0] (n=Wictor@0x57366a52.bynxx19.dynamic.dsl.tele.dk) 19.58.15 Quit Darksair ("ERC Version 5.3 (IRC client for Emacs)") 19.58.53 Join setkeh [0] (n=setkeh@CPE-124-181-6-74.vic.bigpond.net.au) 19.59.02 # CONFIG_CPU in firmware/export/config.h has strange numbering, any specific meaning ? 19.59.10 # oh 19.59.12 # nevermind 20.00.41 # any one have anyidea where to start if im going to build a plugin for tv support for the 5g ipod video (i like the feature wanna add it to the box :P) 20.00.58 # LambdaCalculus37: Well. Currently it's configured to in/decrement the brighntess each HZ/25 20.01.45 # I was thinking of making it target dependent (or even global_settings dependent) 20.02.11 Join {phoenix} [0] (n=dirk@p54B465F7.dip.t-dialin.net) 20.02.34 Nick PaulJam__ is now known as PaulJam (n=PaulJam_@vpn-3017.gwdg.de) 20.02.39 # thats interesting. the chip the nano2g uses supports touchscreen. 20.03.46 # funman: I'm changing MODEL_NUMBER now in all the config files to make them unique. The next free one will be 40. 20.04.08 # I had chosen 69 to be sure ;) 20.04.12 # kronflux: Heh... I haven't seen it being used in a touchscreen target (although I'm thinking that it's the Meizu M8). 20.05.07 # LambdaCalculus37: How exactly do you mean better? 20.05.07 # any one have anyidea where to start if im going to build a plugin for tv support for the 5g ipod video (i like the feature wanna add it to the box :P) 20.05.14 # LabmdaCalculus37: so what are we trying to do with the info we gather for the lcd? you said collect anything related to the lcd.. so if I knew what we're trying to do, maybe I'd understand what I'm looking for more :p 20.05.25 # kugel: The effect is very smooth on my c240. 20.05.48 # You told me some days ago that it's smooth on the beast as well 20.05.53 # kronflux: I'm ordering a nano2G LCD screen. I need to see if there's any identifying numbers on it. 20.06.17 Quit {phoenix} (Remote closed the connection) 20.06.28 # LabmdaCalculus37: identifying numbers? 20.06.28 # can you order spare ipod parts ? 20.07.07 Join tvelocity [0] (n=tony@195.167.65.109) 20.07.10 # kronflux: Yes. Most manufacturers will usually label chips, ribbon cables, and LCDs with part numbers for identification. 20.07.22 # funman: From my favorite iPod repair shop. ;) 20.07.34 # LabmdaCalculus37: so what will the part numbers help with? 20.07.41 # LambdaCalculus37: answer please :) 20.08.52 # kugel: The effect is smooth on the beast as well. 20.08.58 Join {phoenix} [0] (n=dirk@p54B465F7.dip.t-dialin.net) 20.09.06 # But you said on c200 it's better 20.09.24 # better because it's smoother or better because it's faster (the latter one can be fixed easily) 20.10.11 # kugel: Better because it's smoother. The beast is smooth on lower brightness settings, but a wee bit clunky on higher settings. 20.10.18 # setkeh: We're assuming the TV-out is attached (and controlled by) the Broadcom video processor in the 5g. This chip is undocumented... 20.10.51 # kronflux: Punching part numbers into Google will usually get you information about said part. 20.10.52 # * setkeh scratches head 20.10.59 # LambdaCalculus37: come on. I asked you yesterday (or the day before) it's less smooth on higher settings, and you said "no" 20.11.02 # linuxstb, elaborate please mate 20.11.26 # I asked since I expected it to be less smooth 20.11.33 # setkeh: what exactly do you want to know? 20.11.37 # LabmdaCalculus37: good point :) 20.11.53 # kugel: I'm comparing again, and I have to revise because now I'm noticing that the effect *is* a teeny bit clunky on higher settings. 20.11.58 # setkeh: There's not much more to say... You'll need to reverse-engineer the Apple firmware to work out how to control this chip. A far from trivial task - which is why no-one has even started it in the two years those ipods have existed... 20.12.09 # markun, i wanna build a plugin to make tv out work for rockbox 20.12.52 # kugel: I'm also comparing again because I want to see how the effect is on the Sansa versus the beast, side-by-side. 20.13.22 # LambdaCalculus37: Ok, accepted :) Now I'd like to now if the shorter fade time on the c200 is preferably over the longer fade time on the beast (or vice-versa respectively) 20.13.28 # s/now/know/ 20.15.19 # kugel: Having a shorter fade time would be better. 20.16.06 # Ok, I can roll a build with a shorter time for the beast, if you want to test 20.16.21 # * LambdaCalculus37 has his beast ready to test 20.18.47 Join petur [50] (n=petur@rockbox/developer/petur) 20.20.40 Join Strife89 [0] (n=michael@204.116.245.152) 20.21.00 # export/system.h:197:27: error: system-target.h: No such file or directory 20.21.25 # where can I configure the location where this header is looked for ? 20.21.43 # there is one in target/arm 20.22.01 Quit Wictor (Read error: 104 (Connection reset by peer)) 20.22.07 # funman: It's in the target-tree - what you set the manufacturer, cpu etc variables to. 20.22.11 Join Wictor [0] (n=Wictor@0x57366a52.bynxx19.dynamic.dsl.tele.dk) 20.22.55 # I copied the e200 config-e200.h but there doesn't seem to be a system-target.h specific for sansav1 20.23.45 # hm 20.23.46 # LambdaCalculus37: http://www.alice-dsl.net/simonemartitz/forlambda/rockbox-beast-bl-fading.zip 20.23.51 # funman: This may give you a clue - it's the first commit of a new port (in this case the Logik DAX) 20.23.54 # http://svn.rockbox.org/viewvc.cgi?view=rev&revision=15339 20.24.38 # funman: You should create a directory "firmware/target/arm/as3525" and put the as3525 specific files there. 20.24.59 # shouldn't it be in sandisk/ ? 20.25.01 # You can then have target-specific subdirs under there - e.g. "clip", "e200v2" 20.25.51 # funman: No - we've discovered that devices with the same SoC are closer than devices from the same manufacturer. 20.26.00 # funman: the existing sandik should be renamed rather 20.26.31 Quit mf0102__ (Read error: 110 (Connection timed out)) 20.26.42 # svn commit 15339 is 0cb7a302d6dbe167ff981f2677edc5daae2c8312 in the git tree 20.27.07 # * linuxstb doesn't use the git tree 20.27.19 Join mf0102__ [0] (n=michi@85-127-21-147.dynamic.xdsl-line.inode.at) 20.27.22 Join fophillips [0] (n=fophilli@unaffiliated/fophillips) 20.27.47 # Any idea why my database only gets halfway through D when updating on my 80GB 5th gen. iPod? 20.28.51 # Using r18682-081002 20.29.03 # kugel: I've quickly tried your build, and it seems to work. Just fast enough to not notice, and slow enough to make it a smooth transition 20.29.23 # ßßß 20.29.26 # ???* 20.29.55 # gevaerts: You know, it depends on your brightness setting 20.30.04 # default settings :) 20.30.17 # so 6? at 6 it should look just fine 20.30.59 # 6, yes. It looks a lot better than I expected 20.31.15 # fophillips: Most common problem seems to be a corrupt filesystem - have you checked it for errors? 20.31.25 # yea, I'm also surprised again and again how good it looks with only 6 steps 20.31.34 # gevaerts: Which of kugel's builds? c200 or beast? 20.31.38 # c200 20.31.44 # linuxstb: I’ll check now 20.32.09 # LambdaCalculus37: have you tried the latest beast build? fading time should be ~halfed 20.32.29 # kugel: I'm extracting it right now. 20.32.37 # linuxstb: Am I right in thinking that vfat is the only supported FS? 20.32.43 # gevaerts: So, you think it's fading too fast? 20.32.52 # * Strife89 just popped in and wonders where he can find kugel's builds. 20.33.04 # kugel: no. It's just fine 20.33.12 # Strife89: depends on what build you're searching for 20.33.20 # Make it faster and it will start getting in the way I think 20.33.28 # Strife89: We're testing a backlight fading patch. Want to help? 20.33.36 # fophillips: Yes 20.33.38 # LambdaCalculus37: Sure. 20.33.42 # linuxstb: No errors 20.33.45 # LambdaCalculus37: Link it, please. 20.33.47 Quit Wictor (Read error: 104 (Connection reset by peer)) 20.33.58 # which target? 20.33.59 # Strife89: http://www.alice-dsl.net/simonemartitz/forlambda/rockbox-c200-bl-fading.zip <-- c200 with FS#6800 applied. 20.33.59 Join Wictor [0] (n=Wictor@0x57366a52.bynxx19.dynamic.dsl.tele.dk) 20.34.08 # kugel: c200 20.34.09 # kugel: Strife89 is a c200 man himself. 20.34.13 # fophillips: Then option 2 is harder to pin down - a specific track that causes Rockbox to choke.... 20.34.22 # oh, nevermind then :P 20.34.34 # kugel: beast backlight fading looks smoother and a little faster now. 20.34.44 # * funman is looking for c200v2 people 20.34.49 # linuxstb: I will try nuking the DB and starting again. Since I have already unplugged it :) 20.34.58 # * LambdaCalculus37 is a c200v1 person, sorry 20.35.01 # fophillips: I don't know much about the database though, so I'm not sure what ways exist to track it down, other than removing some files from your player and using trial and error... 20.35.09 # Okay. 20.35.12 # LambdaCalculus37: it should be as fast as on the c200 with the default setting 20.35.50 # LambdaCalculus37: Should I use _this_ download, or can I just grab and apply the patch? 20.36.01 # Strife89: download and install 20.36.11 # Alright. 20.36.26 # fophillips: If you do find one (or more) tracks that cause Rockbox to choke, then it would be very helpful if you could share it, so we can try and work out why. 20.36.29 # linuxstb: I'm looking at the diff of revision 15339 but I'm not sure I understand what to do 20.36.36 # * Strife89 backs up his current installation. 20.36.42 # firmware/SOURCES contains paths to C files only 20.36.47 # and firmware/FILES has disappeared 20.36.49 # kugel: It's now as fast as the c200. 20.37.07 # funman: Yes, firmware/FILES isn't needed any more. 20.37.26 # I think I must look in Makefiles for additional include paths 20.37.37 # funman: But there are lots of .S files referenced in firmware/SOURCES (in current SVN) 20.37.38 Join fragilematter [0] (n=fragilem@92.82.99.51) 20.37.42 Part J-23 20.38.20 # * Strife89 has put so many extras into his ./rockbox folder that it's 106 MB in size. 20.38.56 # funman: What have you set "t_cpu", "t_manufacturer" and "t_model" to? 20.39.00 # (in configure) 20.39.04 Join jfb9301 [0] (n=jfb9301@cpe-67-49-143-82.hawaii.res.rr.com) 20.39.18 # ah right, I need to change the manufacturer from "sandisk" to "as3525" 20.39.26 # Yes 20.39.42 # Build installed. Let me wait for this @%^#%* "Refresh Database". 20.40.02 # and t_cpu was set to "am" :( 20.40.35 # funman: The e200 is probably a bad example to base your changes on - because it is quite old and may not do things in the currently preferred way. Something like the m200 may be better. 20.40.45 # Strife89, there's ways to get rid of the refresh database thing 20.41.11 # alright 20.41.15 # bertrik: Yeah, I saw the Wiki not too long ago. 20.41.37 # bertrik: But how do you set "read-only" in Ubuntu? 20.41.51 # Booting my c200 now.... 20.43.05 # * Strife89 likes the fade effect. 20.43.27 # everyone likes it :D 20.43.48 # It's a little too quick at lower brightness settings IMO. 20.43.55 # But oh well. 20.44.04 # I usually keep it at 3. 20.44.20 # Strife89: Using the "mattrib" utility (part of mtools) 20.44.52 Quit MethoS- (Remote closed the connection) 20.45.28 # I take it the patch was improved recently? 20.45.29 Join MethoS- [0] (n=clemens@host-091-096-209-237.ewe-ip-backbone.de) 20.45.32 # Strife89: at 1, there won't be fading 20.45.58 # linuxstb: Well the DB initilisation has gotten further than last time 20.46.00 # that's because it's looping setting the de/incrementing the backlight by 1 20.46.10 # kugel: Ah, okay. 20.46.38 # and thus, it's less noticable and faster on lower settings 20.47.24 # Fine by me. 20.47.28 # :) 20.47.42 # this is done purely by setting the backlight brightness in the as3514 and not using any fancy PWM'ing, right? 20.48.39 # bertrik: well, it's using whatever the target uses to alter backlight 20.49.37 # Quick question: What's the best thing to do here? http://pastebin.com/m74d44a5a 20.50.33 # bertrik: on the beast, it's PWN fading actually 20.50.50 # since the brightness levels are implemented that way 20.51.32 Join faemir [0] (n=quassel@88-106-165-155.dynamic.dsl.as9105.com) 20.51.37 # Strife89: not entirely sure, that shouldn't happen 20.51.56 # have you already added the patch previously? 20.51.56 # kugel: I _have_ applied an older version of this patch. 20.52.07 # well, then remove that first :) 20.52.24 # kugel: I will - if I can find it. 20.52.43 # just do svn revert if that's the only patch 20.52.53 # it's not 20.53.02 # * kugel wonders why Strife89 has this patch applied previously if he's having a c200 20.54.31 # kugel: Because I mistakenly thought the patch worked for the c200. 20.54.45 # kugel: Obviously it didn't, and I forgot about it. 20.54.52 # Strife89: it was actually working for c200 all the time. just the proper #define was missing 20.55.09 # since c200 and e200 share their backlight code 20.56.00 # Looking at my terminal again. Should I assume -R, say no, or abort with [CTRL]+[C]? 20.56.19 # abort 20.56.41 # Now, to find that patch..... 20.56.49 # and skip the patch to config-c200 of you apply it again 20.56.55 # * funman notes how much he prefers git over svn 20.58.45 # when switching backlight timeout from off to on with my c240, the backlight comes on but the display is blank 20.59.16 # kugel: I might just use SVN revert and dig up patches again. http://pastebin.com/m4ade2637 20.59.43 # Strife89: I told you already to skip the patch to c200 if you reapply it 21.00.01 # so type n and then y 21.00.16 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 21.00.57 # kugel: Okay, it looks successful. http://pastebin.com/m5b923de 21.01.16 # oops 21.01.27 # you should've typed n again :S 21.01.39 # now you have the HAVE_BACKLIGHT_THREAD_FADING twice 21.01.51 # Oh. 21.01.53 # Crap. 21.01.57 # edit config-c200.h and delete one of them 21.03.04 # Location? 21.03.14 # which condition defines the building of sysfont.h ? 21.03.22 Join avacore [0] (i=nobody@1008ds1-rdo.0.fullrate.dk) 21.03.24 # I thought you're "the c200 man" 21.03.25 Quit reacocard (".") 21.03.44 # firmware/export 21.03.52 # kugel: Those were LambdaCalculus37's words, not mine. :) 21.04.04 # the terminal showed you where it is btw 21.04.14 # I already closed it. 21.04.52 *** Saving seen data "./dancer.seen" 21.05.53 # kugel: Edited. Preparing to compile. 21.07.28 # kugel: Making. I appreciate your help. :) 21.07.40 # You're welcome :) 21.09.34 # BTW, the other patches I have include the Mikmod patch, and the Sansa charging patch. 21.09.41 Join reacocard [0] (n=reacocar@WL-431.CINE.HMC.Edu) 21.10.00 # mikmod? 21.10.16 # http://www.rockbox.org/tracker/task/6800 21.10.31 # that's the wrong one .9 21.10.35 # :) rather 21.10.47 # Oops, 8806 21.11.04 # I had typed in a different address on that bar. 21.11.11 # change 6800 to 8806 21.11.47 # Such is the peril that comes from having umpteen tabs open. :) 21.12.02 # tabbed browsing is evil :) 21.12.13 Join dave__ [0] (n=dave@cpe-098-121-161-003.ec.res.rr.com) 21.12.19 # kugel: A necessary one. ;) 21.12.32 # as well as tabbed irc'ing, which caused me to talk about rockbox in -community 21.12.46 # several times 21.13.17 # I'm generally good at keeping tabs (pun intended) on which channel I'm in. 21.13.32 # * gevaerts thinks that tabs are off-topic here ;) 21.13.58 Quit jfb9301 ("Java user signed off") 21.14.01 # %*&$%$( 800MHz CPU....... 21.14.32 # hey, I submitted a theme to rockbox-themes.org about a week ago 21.14.38 # Make is working on Doom at the moment... so slow..... 21.14.51 # how long does it normally take for the theme to actually go up on the site? 21.15.04 # endlessly 21.15.11 # ha 21.15.35 # well, uploading has been enabled, so there's obviously been some kind of progress 21.15.42 # oh yea 21.15.45 # I just noticed 21.16.05 # but there's definitely old themes there 21.16.27 # that's not the new theme site, is it? 21.16.42 # is it older than the WPS gallery? 21.17.15 Join ]MrFWorK[ [0] (n=not@rrcs-24-73-254-209.sw.biz.rr.com) 21.17.30 # I thought rockbox-themes.org was like the 2.0 of the wiki's WPSgallery page 21.17.51 # I like the layout better, at least 21.18.17 # <]MrFWorK[> question, how to i quit doom on the ipod 5.5g i cant get the menu up 21.18.47 # ]MrFWorK[: Turn on the hold switch, then turn it off again 21.19.04 # <]MrFWorK[> thank you 21.19.08 Quit MethoS- (Read error: 104 (Connection reset by peer)) 21.19.52 # It's finally done. :) 21.20.32 # ]MrFWorK[: doesn't the manual mention it? ;) 21.20.57 # well if the maintainer for rockbox-themes.org needs any help putting themes up on the site, I might be able to help 21.21.10 Join MethoS- [0] (n=clemens@host-091-096-209-237.ewe-ip-backbone.de) 21.21.18 # dave__: That site was never official, and as far as I know is abandoned. 21.21.34 # really? 21.21.59 # dave__: Work has been started on a new, official themes site, but no-one is working on it at the moment... If you know php, you could help... 21.22.00 # so the WPSgallery is the place to go for the latest and greatest then? 21.22.12 # Yes 21.22.21 # Pretty much every theme on rockbox-themes.org is broken now. 21.22.35 # ha, funny you should mention PHP, I just started reading a tutorial last night 21.22.41 # AFAIK 21.23.19 Quit nplus (Remote closed the connection) 21.23.53 # linuxstb: is there a link to a work-in-progress type of thing, or is it not even up on the web yet 21.24.16 Join massiveH [0] (n=massiveH@ool-44c48a1e.dyn.optonline.net) 21.25.21 # dave__: I think there's a copy somewhere, but I forget the address. The actual PHP code for the new site is in the Rockbox SVN repository - you can browse that here - http://svn.rockbox.org/viewvc.cgi/themes.rockbox.org/ 21.31.31 Join Hillshum [0] (n=chatzill@75-165-238-40.slkc.qwest.net) 21.31.37 # funman: Did you find the SD driver in the Sansa _v1_ OF? 21.31.46 Quit MethoS- (Remote closed the connection) 21.32.00 # * LambdaCalculus37 casts a "Spell of Summon Swedes" 21.32.16 # cool 21.32.24 # :D 21.32.38 # * linuxstb thinks that works better when you mention their nicks... 21.32.38 # amiconn: I found it in rockbox svn repository 21.32.51 # Bagder: Ping 21.33.07 Quit ]MrFWorK[ () 21.33.16 # funman: That's not what I mean... 21.33.24 Join MethoS- [0] (n=clemens@host-091-096-209-237.ewe-ip-backbone.de) 21.33.31 # I certainly need to keep reading that tutorial on PHP, but the language looks pretty familiar (I've done stuff with C/C++ and Matlab) 21.33.50 # The driver in rockbox has a bug (not related to the SD protocol but probably related to some timing setup) 21.34.27 # I think it would be helpful to know how the OF initialises the PP SD controller 21.34.32 # which driver? 21.34.40 # what do you expect from me? 21.34.46 # I guess if I'm going to help, I need to learn how to use SVN as well 21.35.14 # dave__: http://www.rockbox.org/twiki/bin/view/Main/UsingSVN 21.35.27 # funman: I assumed you disassembled the v1 OF as well judging from an earlier comment... 21.35.42 # no sorry 21.35.59 # ok 21.36.03 # dave__: Also, see this; it has relevant information: http://www.rockbox.org/twiki/bin/view/Main/SimpleGuideToCompiling 21.37.24 # Strife89: thanks. I've actually been compiling my own build using SVN for a while now (since I used to throw patches into my builds) 21.37.45 # but I've never committed any code or anything like that 21.38.08 # dave__: Ah, alright. My bad on that, then. :) 21.38.49 # yeah, I think there is some information in the wiki about committing stuff into SVN though 21.39.01 # I'll look into it 21.44.03 Quit bmbl ("Woah!") 21.44.05 Join m0f0x [0] (n=m0f0x@189-47-65-118.dsl.telesp.net.br) 21.44.26 # I must say this build system is quite confusing 21.45.48 Quit jhulst (Remote closed the connection) 21.46.03 # only if you're not used to it :) 21.46.12 # sysfont.h is built in firmware/Makefile 21.46.24 # using convbdf, which itself is built in tools/Makefile 21.46.44 # I added convbdf in my 'toolset' but it's not called, and I can't see any condition in firmware/Makefile 21.47.12 # convbdf is built by the tools target 21.47.19 # you shouldn't worry about it 21.47.52 # on what are you working right now anyway? 21.48.13 # I try to create a target for the clip 21.48.50 # just have build tools before building the "binary" 21.49.06 # s/have/ 21.49.11 # they are built 21.49.20 # but sysfont.h isn't 21.50.58 # sysfont.h is created while building isn't it? 21.51.02 # it is 21.51.11 Nick fyre^OS is now known as fyrestorm (n=fyre@cpe-68-173-234-148.nyc.res.rr.com) 21.51.18 # see firmware/Makefile:52 21.51.21 # maybe you're just looking in the wrong folder :) 21.51.25 # ? 21.51.56 Join nutrientman [0] (n=45b57a7f@gateway/web/cgi-irc/labb.contactor.se/x-dcc51ad462c9e4ca) 21.52.59 Quit nutrientman (Client Quit) 21.53.37 # sysfont.h should appear in your build directory 21.54.35 Quit dave__ ("Ex-Chat") 21.54.42 # % rm -rf *;echo clip\\nB|../rockbox/tools/configure >/dev/null && make |& tail -3|head -2 21.54.49 # export/font.h:33:21: error: sysfont.h: No such file or directory 21.54.49 # make[1]: *** [/media/bordel/bootloader/firmware/powermgmt.o] Error 1 21.54.59 # it doesn't, else I wouldn't be looking for it :) 21.55.30 Join maddler [0] (i=maddler@static-217-133-171-24.clienti.tiscali.it) 21.55.39 # I built the e200 target, and indeed sysfont.h is built 21.56.22 # * Llorean does not really like the Patch of the Week idea. 21.56.46 Join nutrientman [0] (n=45b57a7f@gateway/web/cgi-irc/labb.contactor.se/x-a4ada9f1cf98bf68) 21.57.05 Join Wictor_ [0] (n=Wictor@0x57366a52.bynxx19.dynamic.dsl.tele.dk) 21.58.50 Quit nutrientman (Client Quit) 21.59.00 Quit LambdaCalculus37 ("http://www.mibbit.com ajax IRC Client") 22.00.31 # * gevaerts has mixed feelings about it. Focusing attention on patches is good, but so far I haven't seen any good idea on how to select which patches 22.00.34 # and since some files are built in the builddir, some in the sourcedir, I don't know how to force building of this file 22.00.56 # gevaerts: I think it's going to be really, really discouraging for some people. It kinda says "We'll only be looking at one patch at a time" 22.01.00 # Are you sure you are building firmware? 22.01.18 Join shotofadds [0] (n=rob@rockbox/developer/shotofadds) 22.01.27 # kugel: I'm building a bootloader 22.01.38 # still, you need firmware/ code for it 22.01.48 # gevaerts: And it encourages people *not* to come to us to discuss our patches the normal way. People are just going to nominate them for PoTW as if it's "the usual process to get them committed" rather than trying to discuss them at other times 22.02.25 # funman: a missing sysfont.h usually means you've included a file in SOURCES that doesn't exist 22.02.27 Join pondlife [50] (n=Steve@rockbox/developer/pondlife) 22.02.30 # There is that too, yes. I hadn't thought of those things yet 22.02.32 Part pondlife 22.02.37 # it's not a very helpful error message ;-) 22.03.06 # hm right, I didn't create the .c file in bootloader/ yet 22.03.30 # funman: You don't need to force anything, but check the dependencies, and files in the various SOURCES list 22.03.31 # but there's no difference 22.03.51 # gevaerts: I think the -dev mailing list is a good place for people to say "I think my patch is ready, could someone look at it", and I think people could be doing that all the time (since it's non-realtime discussion, devs can respond/look whenever they have time, and easily flag messages to look at later) 22.04.12 # I only changed bootloader/SOURCES 22.04.28 # I might need to modify firmware/SOURCES then 22.05.01 # Llorean: indeed. Except when people start spamming the -dev list about obviously incomplete and buggy patches 22.05.29 # if I look at SANSA_M200 in firmware/SOURCES for example I only see a list of drivers, nothing about fonts 22.05.40 # gevaerts: Well, if _they_ (being, hopefully, the author or person willing to work on it) don't know it's incomplete or buggy, it gives us a chance to tell them. 22.05.44 # funman: have a look at fs#7583 - it links to a Makefile change which should tell you which file is failing 22.06.06 # gevaerts: We can have a simple guideline, "don't post a patch to the list unless you're volunteering to address the issues that are brought up about it" 22.06.34 # Llorean: good idea. That should keep the crippled-build-people out at least 22.07.41 # thanks 22.08.08 Quit thegeek (Read error: 104 (Connection reset by peer)) 22.08.16 Join perrikwp [0] (i=d1a8d351@gateway/web/ajax/mibbit.com/x-d43c92db5c10101f) 22.08.35 # gevaerts: Someone always has to volunteer to do the work anyway. We could do "Patch of the Week" in here, but unless someone's willing to address our list of issues afterwards, it doesn't really matter what we discuss. 22.09.12 # in firmware/SOURCES, if CONFIG_CPU doesn't match a specified list, the firmware will be linked against target/arm/crt0.S which is non existent 22.09.30 # * linuxstb wonders if the bmp resize patch should be closed, as no-one is taking it in the right direction, so it will never (as it is now) be committed - http://www.rockbox.org/tracker/task/5697 22.09.52 # One option would be "Patches can only be nominated by someone agreeing in advance to fix what we list" but if we do that, I suspect we'll very quickly run out of patches. If we don't do that, I suspect we'll just slowly work our way through less and less interesting/valuable patches until we all agree it's just not that worth our time to get together weekly to discuss patches fixing typoes in comments. 22.10.25 # So I think, instead of doing it weekly, just interested coders saying 'I think this patch is ready, and I'll work on it if it's not' to the mailing list is the best idea. 22.10.32 # An ongoing process, rather than us cherrypicking. 22.11.14 # linuxstb: well, it's a bit stuck, since your demands aren't easy to implement 22.11.30 # kugel: They're not "my demands"... 22.11.55 # not your as in your personal 22.12.30 Quit reacocard (Read error: 104 (Connection reset by peer)) 22.12.44 # pretty much the same goes for multifont 22.12.46 # * gevaerts would reply "+1" to Llorean's mail if he were the sort of person who replies "+1" to mails 22.13.21 # linuxstb: Maybe we need a "good feature idea, implementation not appropriate for Rockbox" reason for closing. 22.14.30 # that sounds more of a reason for letting it rot, rather than closing 22.14.37 Quit Wictor (Read error: 110 (Connection timed out)) 22.14.47 # kugel: Why should we let it rot if it's not going to be fixed? 22.14.49 # no leaving it to rot is bad 22.15.09 # Llorean: that sort of reply needs to be well-motivated I think, so I'm not sure if a canned reason is appropriate 22.15.10 # kugel: Figured I'd let you know: the compile was successful, and the build works fine. (I let my Sansa charge, that's why it took so long.) 22.15.12 # If we close it, saying "we like the idea, but not the code" it makes it clearer that maybe it should start over from first assumptions. 22.15.39 # How can you know it's not going to be fixed? If the idea of the tracker entry is generally accepted, just the current implementation not, I see no reason to close it 22.15.58 Quit fragilematter ("query if you need me") 22.16.02 # * shotofadds wonders if the blank Flyspray pages will be fixed one day 22.16.13 # Thanks again. :) I need to go. 22.16.30 # Strife89: see you 22.16.31 Quit Strife89 ("Leaving") 22.16.33 # kugel: If someone fixes, they can open a new task with the fixed version of the patch. 22.17.15 # kugel: that basically would be equivalent to reopening the feature request tracker 22.17.16 # linuxstb: but what's the point of closing? isn't it better to have the whole history and reasoning in one task? 22.17.32 # there's a good idea to keep number of open patches low 22.17.35 # Bagder: LambdaCalculus37 was asking for Developer rights on the tracker earlier... 22.17.36 # to keep focus 22.18.05 # shotofadds: Have you seen the task in question? About 240 comments, with no real discussion of the issues, and a patch that is implementing the feature wrongly. 22.18.34 # s/240/206/ 22.19.30 Quit m0f0x () 22.19.45 # hmm.. you have a point ;-) (assuming you means the bmp resize patch) 22.19.56 # Yes 22.21.22 # * gevaerts doesn't see how this POTW patch selection would work 22.21.55 # random(3) ? 22.22.02 # the point for me is that the selection process wouldn't have to be complicated 22.22.10 # gevaerts: you could pick them for all I care 22.22.25 # it would help me get interesting patches to look at 22.22.32 # instead of wading through 400 22.22.37 # We all know about the interesting patches. 22.22.42 # * shotofadds mumbles "user vote" and runs... 22.22.43 # * linuxstb still wonders when the RSB is going to meet in order to arrange their first meeting 22.22.55 # The users use them in their unsupported builds. 22.23.11 # Llorean: then those should be fine first contenders 22.23.28 # Bagder: We've already discussed most of them, and listed things that get in the way on their entries, for a lot of them. 22.23.37 # I'm seeing how this could help me, that's all 22.23.55 Quit jeffdameth (Read error: 113 (No route to host)) 22.24.01 # The real problem, for nearly all the "interesting" patches, is that there's still work to be done and it's not always happening. 22.24.41 # Part of the problem may be that patch authors feel that after they've fixed the current complaints we will come up with new ones 22.25.17 # Which, we probably will. 22.25.21 Join jeffdameth [0] (n=jeff@dyndsl-085-016-233-180.ewe-ip-backbone.de) 22.25.21 # * gevaerts points out that Software USB is not a tracker patch ;) 22.25.26 # linuxstb: If I understood correctly, bmpresize isn't doing it entirely wrong. As far as I noticed there're 3 demands, a) fast b) smooth and c) on-load resizing. the latest implementation meets two of them. And on-load resizing sounds rather complicating for me, especially when smooth is also a demand 22.25.33 # gevaerts: There's an entry for it on the tracker, no? 22.25.34 # you could propose help on future problems to motivate the authors 22.25.39 # well, authors may believe that no matter what process we use 22.26.01 # We can't help but have future demands 22.26.11 # Until they write new code for the previous set of demands, we can't know what it's going to do now. 22.26.43 Join thegeek [0] (n=nnscript@s080a.studby.ntnu.no) 22.26.50 # But I really think a process by which an interested author comes forward and says "I'd like to get this patch in, let's initiate a discussion about it" will help, and the mailing list is good for that. 22.26.57 # linuxstb: There already are APE performance figures at http://www.rockbox.org/twiki/bin/view/Main/SoundCodecMonkeysAudio which I can confirm 22.27.12 # Llorean: yes, but that could happen already but never does 22.27.19 # Bagder: We don't ask people to do that. 22.27.20 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 22.27.28 # So the beast copes fairly easily up to -c3000, and would handle -c4000 at max. clock with svn code 22.27.30 # true 22.27.37 # We don't have, written somewhere, "once you think it's committable, and you're willing to fix any issues, post it to the mailing list" as part of our formal process. 22.27.38 # amiconn: Seems I did those ;) 22.27.39 # There are indeed always new demands, but at some point it's good enough to go in. Defining that point clearly in a discussion, and then committing if that point is reached, may well motivate people to actually work to reach that point 22.27.39 # It's especially confusing to me (and possibly other interested people as well), that the patch uses an algorithm which is in SVN, but didn't get itself into it, because it's using this algortihm 22.27.43 # people these days are too scared of mailing lists... 22.27.44 # I think just doing that could improve things vastly. 22.28.26 # * amiconn much prefers the ML over forums 22.28.28 # kugel: Isn't it used only for plugins? 22.28.38 # Yes, but still 22.28.42 # "But still" what? 22.28.47 # kugel: that's the explanation 22.28.47 # it's in svn 22.28.59 # plugins are our wild west 22.29.02 # kugel: There's code in SVN that's not even used in Rockbox (see RBUtil) 22.29.04 # you can do anything there ;-) 22.29.10 # Plugins should be considered "not Rockbox, but a separate application" 22.29.12 # closing a task for using a feature that is in svn, that's irritating for me 22.29.13 # kugel: Also, not everything in SVN is perfect, sometimes things sneak under the radar... 22.29.56 # kugel: So you're saying the patch should be committed as it is? 22.30.08 # kugel: there is an mp3 decoder in svn. That doesn't make it a good idea to use mp3 decoders for caching fonts 22.30.09 # I say it shouldn't be closed 22.30.16 # which patch are we talking about? 22.30.16 # * gevaerts likes extreme examples 22.30.25 # it's just one step to "committable" 22.30.31 # Plugins do a lot of things which aren't allowed in the core 22.30.34 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 22.30.50 # kugel: If it's "one step to" then obviously it isn't by your own words, committable. 22.30.56 # markun: bmp resize - http://www.rockbox.org/tracker/task/5697 22.31.34 # kugel: If there's nobody interested in working on it, we can close it with a _clear_ explanation until someone comes along and says "I want to fix it" at which point they can open a new task or we can reopen it. 22.31.41 # kugel: In such a situation, what harm does closing it do? 22.32.15 # kugel: The _feature_ isn't being rejected, simply that specific implementation. Other implementations can live in new tasks. 22.32.56 # kugel: Closing the task may even motivate someone to do it right.... 22.33.02 # closing this situation is _good_ 22.33.04 # in this 22.33.14 # * linuxstb wonders who wants to be the bad guy 22.33.36 # * Llorean is always willing to be the bad guy if nobody else wants to. 22.33.52 # well, you close the entire task, not just the patches. That looks like "we're rejecting the whole task, so we reject the whole feature". The task doesn't only consist of the code produced, but also for the general idea. 22.33.53 # People seem to enjoy sending me angry emails for closing tasks. 22.34.05 # kugel: we closed the feature request tracker... 22.34.10 # kugel: That's why there's a "reason for closing" in which you explain this. 22.34.15 # * amiconn wonders whether the armv6 simd instructions are sufficiently magic... 22.34.15 # what about closing the task and opening a feature request? 22.34.26 # And a task without an acceptable implementation is a feature request 22.34.35 # markun: where? 22.34.40 # Reason for Closing: Good feature, but this implementation isn't progressing in the direction necessary for including. Can be reopened or a new task started if work is to resume on an implementation fit for use in the core. 22.34.51 # gevaerts: ah yes, we don't do that in the tracker anymore.. 22.35.20 # then lets just hope someone in the future will actually search closed tasks, browse through loads of pages and happens to find the old bmp resize task, and then also realize that the feature is still wanted even though it was closed 22.35.46 # kugel: If they don't search in the first place, then they'll open a new task anyway. 22.36.00 # kugel: if it's really wanted, somebody will notice within three days 22.36.03 # kugel: If they DO search, they'll probably wonder why we rejected it. If they fall in the small group that doesn't, there's not much we can do. 22.36.08 Quit kronflux ("Leaving") 22.36.46 # * gevaerts is going to close the USB task. It's becoming more useless to keep open day by day 22.37.10 # * linuxstb will close the bmp resize task 22.37.34 # then close multifont too, the situation is similar 22.37.36 Join ompaul [0] (n=ompaul@gnewsense/friend/ompaul) 22.37.41 # even worse imo 22.38.52 # I wonder how long this open a new task will take to happen, maybe even with the old code 22.39.08 # I wonder how smooth resizing should work with on-load resizing. Don't you need to analyze the source to make it smooth? 22.39.29 # kugel: no, why would you? 22.39.32 # Do we still need FS#9376 after the release? 22.39.57 # no 22.40.39 # we might need one for 3.1 as well, but that'll be a new one by then 22.41.08 # * gevaerts votes to commit FS#8943 22.41.19 # kugel: I think you only need to know the input and output width and height and read enought pixels to calculate the output pixels. 22.42.05 # kugel: I'll think about it a bit, maybe I can come up with a nice algorithm 22.42.08 # gevaerts: seems fine 22.42.11 # well, you maybe don't need to analyze the full picture, but at least several rows 22.42.21 # gevaerts: I don't see any successful tests beyond "hosing the filesystem"? 22.42.27 # I think two output rows should be enough in theory 22.43.02 # Llorean: actually the "hosing the filesystem" issue was my fault, and due to a buggy workaround for FS#8663 22.43.18 # gevaerts: Ah, just as long as you're confident then. 22.43.19 # bertrik: I think it should be possible without that even 22.43.29 # markun: Just adjacent pixels? 22.44.20 # is memory usage much more important than speed? I think so, since it's only done on load, right? 22.44.23 Quit bughunter2 ("bye") 22.45.12 # markun: I'd have to agree, yes. 22.45.29 # markun: It's actually more going to happen once per buffering. 22.45.31 # markun, I think speed is mostly irrelevant 22.45.41 # And buffering takes long enough that even a few _seconds_ extra isn't going to be noticed by the user in the background. 22.45.52 # bertrik: within reason... 22.45.57 # ameyer: In this case. 22.45.59 # Not in general. 22.46.02 # kugel: I think I'll give it a go 22.46.25 # markun: Nice. And I'll glady help you 22.46.35 # what exactly is "this case" 22.46.41 # ameyer: Bitmap Resize patch. 22.46.44 # ahh 22.47.09 # markun: fast, post on the tracker, that you're going to do something, before it's closed :) 22.47.20 # nah :) 22.48.10 # kugel: He also knows he can start a new task, or re-open the old one, if he accomplishes something. 22.48.32 # kugel: clearly he wants a new task all for himself :) 22.48.39 # :) 22.48.51 # my idea is, to read XxY tiles of the original (into a small buffer), resize this tile, and put it into the output, then take the next tile. I don't think the result would look good though 22.50.21 # It would be rather artifactial I assume 22.50.23 # does the existing code use linear interpolation? 22.50.41 # I think so, yes 22.50.44 # * gevaerts checks if he needs to add the author of the FS#8943 patch to CREDITS 22.50.52 # but don't count on what I think 22.51.48 # Bagder: Maybe we could add a "Contribute" link above the patches link, and it could lead to a page that not only describes the contribution process for code, but has links to SimpleGuideToCompiling and other "useful" pages, and talks a little bit about the usual requirements we have for patches to meet. 22.52.23 # we could start with creating such a page 22.53.17 # Bagder: I'm going to post a mail to -dev to ask for feedback on what people think such a page should contain/say, then maybe write a text draft? 22.53.36 # a good plan! 22.54.17 # kugel: you could also try to get jhMikeS interested, but he's probably occupied with other things these days 22.54.35 # Why don't you try? 22.54.41 Join reacocard [0] (n=reacocar@WL-431.CINE.HMC.Edu) 22.54.41 # is there any point using tools/scramble for the SansaV2 ? 22.54.49 Join rsfgt [0] (n=rsnoob@22.251.190.90.dyn.estpak.ee) 22.56.32 Quit Hillshum ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092417]") 22.56.33 # linuxstb: so, you'll also close multifont now? 22.56.45 # would be rather inconsistent if not 22.57.21 Join kronflux [0] (i=kronflux@blk-138-78-15.eastlink.ca) 22.57.36 Quit kronflux (Client Quit) 22.57.45 Quit Wictor_ (Read error: 110 (Connection timed out)) 22.58.31 # kugel: who cares if we're inconsistent, we do all of this just to piss you off :) 22.58.33 Quit ompaul (Client Quit) 22.58.47 # an idea I've been thinking about is to simply step left-right top-bottom through the input pixels, and accumulate them in a pixel buffer the size of one output row. Possibly a bresenham-like way of stepping would easily tell us when a horizontal pixel boundary is crossed. On a pixel boundary crossing the input pixel is proportionally divided between the two output pixels. Vertically you could do a very similar thing and you wo 22.58.47 # uld need to buffer only two output lines, the current line and the next line. 22.58.57 # markun: But I'm not pissed off enough 22.59.05 Quit massiveH ("Leaving") 22.59.07 # kugel: I'm not the only person who can close tasks... bmp resize was just one that I've been following and posting comments to recently. But yes, multi-font probably could get closed with the same reason. 22.59.28 # kugel: I doubt the authors of that multifont patch care if we are consistent about that 22.59.51 Join webguest31 [0] (n=57bd56da@gateway/web/cgi-irc/labb.contactor.se/x-149b7322b4eca25c) 23.00.06 # but I am in the camp in favour of closing more! 23.00.46 # it's a new game category: "close'em all" 23.00.59 Quit Thundercloud (Remote closed the connection) 23.01.30 # poketask, gotta close'em all 23.02.29 # * linuxstb thinks Bagder should just run some more of his shell/perl scripts on the flyspray server 23.02.52 # "0 open patches" 23.02.52 Join Thundercloud [0] (n=thunderc@cpc1-hem18-0-0-cust660.lutn.cable.ntl.com) 23.03.03 # linuxstb: we want to close the tasks, not delete them :) 23.04.16 # funman: What will the bootloader do you're working on right now? 23.04.34 # nothing 23.04.39 # * domonoky begins to write a flyspray bot which automatically closes all tasks.. for ever :-) 23.04.42 # well it will build 23.04.49 Quit webguest31 ("CGI:IRC (Ping timeout)") 23.04.54 *** Saving seen data "./dancer.seen" 23.05.08 # funman: I guess you'll use it to run some test code? 23.05.18 # yes 23.05.45 # Why do you need a lds file? 23.06.09 # to link it, specifying where exactly are the stack, code, and stuff 23.06.38 Quit bertrik ("Leaving") 23.07.25 # and the built bootloader would then be passed mksmsboot to patch the firmware? 23.08.49 # exact 23.11.01 Join midgey [0] (n=tjross@c-68-42-68-108.hsd1.mi.comcast.net) 23.11.54 # time to rename mkamsboot into sansaV2pather, isn't it :) 23.12.01 # patcher, rather 23.12.20 # yes, next step :) 23.13.18 Quit petur ("*plop*") 23.16.55 Join ZincAlloy [0] (n=d9eed7e9@gateway/web/cgi-irc/labb.contactor.se/x-eb2e4ba2524749df) 23.17.16 Join {-phoenix-} [0] (n=dirk@p54B45ADD.dip.t-dialin.net) 23.21.56 # funman: I wonder if we would be able to not use an external firmware file, but the one on the flash, for patching the bootloader 23.22.06 Quit midgey () 23.22.10 # hm ? 23.22.12 Join webguest38 [0] (n=55b218db@gateway/web/cgi-irc/labb.contactor.se/x-9c752d1eb755fe42) 23.24.35 # now we patch a firmware file, put it on the player and rely on the OF's updating mechanism 23.25.04 # I think it's desirable to modify the firmware which is on the flash 23.25.34 # how could we do that ? and what's wrong with the OF firmware upgrade mechanism ? 23.26.13 Join Munkie [0] (n=alex@dsl-245-151-69.telkomadsl.co.za) 23.26.15 Quit tvelocity (Remote closed the connection) 23.26.28 # hello 23.27.09 Join midgey [0] (n=tjross@c-68-42-68-108.hsd1.mi.comcast.net) 23.28.12 Quit rsfgt () 23.28.45 # bootloader built ! 23.29.32 # funman: great! Do we need a e200v2 dude to test or do trust your code? 23.29.58 # well, should actually matter if the bootloader is bugged 23.30.22 Join denes [0] (n=denes@pool-1020.adsl.interware.hu) 23.30.24 # does it include the LED blinking? 23.30.26 # kugel: nothing to test 23.30.31 # it doesn't do anything at all 23.30.48 # then let it do something :) 23.30.54 # I didn't modify the mkamsboot, so I assume it still works :) 23.31.15 # markun gevaerts : so I will try to send in the m3 lcd code into flyspray during the weekend 23.31.17 Quit {phoenix} (Connection timed out) 23.31.48 # gevaerts: just fyi, I checked the qt1106 code on the m3, and it works on default clock 23.31.54 Quit webguest38 ("CGI:IRC (EOF)") 23.31.56 # denes: ah, great 23.32.09 # gevaerts: but on 200 MHz it is kind of buggy for some reason 23.32.14 # kugel: there is some (a lot of) work to do before that 23.32.28 # denes: even with the delay loops adjusted? 23.32.33 # markun: yes 23.32.43 # markun: the delay function was adjusted 23.33.02 Join AaronShort [0] (n=c6ec2b02@gateway/web/cgi-irc/labb.contactor.se/x-00e1f8f519b7392a) 23.33.04 # who is Paul Louden ? 23.33.09 # Llorean 23.33.15 # markun: I looked, but the reason for the bug didn't jump at me 23.33.25 # /whois let me think he was called "purple" 23.33.36 # * scorche|sh references the IrcNicks wiki page to funman 23.33.37 # denes: well, gevaerts will soon have his M3 to play around, maybe he finds something 23.33.48 # markun: great 23.34.18 # denes: there was another M3 owner here who wanted to help out with the port, but I forgot his nick 23.34.37 # funman: what work exactly? Don't you have such a thing as bootloader.c, in which you can insert your led blink code? 23.34.47 # Howdy. I'm new to rockbox and so far loving it. I'm a software developer. though i havn't done much c since college. I'd like to correct a few things on the wiki I found can someone please give me write access? 23.35.06 # denes: could you put your LCD code in the tracker now and then just update it later? Then maybe other people can start playing with it 23.35.10 # markun: meven , iirc 23.35.21 # AaronShort: What's your wiki account? 23.35.24 # yes, it was him 23.35.24 Join jhulst_ [0] (n=jhulst@unaffiliated/jhulst) 23.35.27 # AaronShort 23.35.40 Quit jhulst (Read error: 113 (No route to host)) 23.35.46 # markun: it's on my other computer 23.35.52 # ah, ok 23.36.19 # AaronShort: Done, don't spam! 23.36.31 # ... like kugel always does 23.36.35 Join webguest23 [0] (n=57bd56da@gateway/web/cgi-irc/labb.contactor.se/x-0ae1f16a122b448c) 23.36.39 # kugel: yes but I need to add the hardware registers into defines, and fix/implement some (a lot of) functions I just commented out to let the bootloader build 23.38.19 # I wont. I may even think of a minor patch or two. I'm at work and prob shouldn't stay on here so thanks and see you around. 23.38.25 # is there any tutorial or can any1 help me with programming plugins for rockbox? 23.38.33 Join saratoga [0] (n=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/x-0228bd64c0436103) 23.38.46 # theres some documentation for plugin writing on the wiki 23.38.52 # Munkie: http://www.rockbox.org/twiki/bin/view/Main/HowtoWritePlugins 23.39.06 # Thanks 23.39.12 # Munkie: there are wiki pages such as HowToWritePlugins, but please dont use such "words" as "any1"...we require real english in here 23.39.25 Quit AaronShort ("CGI:IRC") 23.41.04 # Munkie: it's also a good idea to look at the code of existing plugins 23.41.04 # sorry man. i understand that was a silly question but all i kept finding was "rockbox programming", not plugin programming 23.41.24 # Munkie: any plugin in particular you want to work on? 23.42.26 # regarding efficient resizing mentioned above, for linear interpolation, the best way to do it is to: 23.42.35 # I want to try create my own. the problem is i only know java, so i have to teach myself C 23.42.38 # 1) calculate how many source image rows are actually needed 23.42.48 Quit {-phoenix-} (Remote closed the connection) 23.43.05 # 2) step through the source image 1 row at a time skipping unneeded rows performing bilinear interpolation left to right 23.43.22 Quit UncleRemus ("leaving") 23.43.35 Quit webguest23 ("CGI:IRC (Ping timeout)") 23.44.14 # for example, to rescale an 800 by 600 image to 200 by 150, only every other row should be actually needed for bilinear 23.44.40 # so you would read in the first and and third row, and use them to compute the first output row of pixels 23.44.43 Join Dan89 [0] (n=598b3ce8@gateway/web/cgi-irc/labb.contactor.se/x-f5bca6b7ec706e2e) 23.44.48 # hello 23.44.52 # hy denes 23.45.33 # hi there, I have a question about my sansa e250 can you help me? 23.45.47 # doing this efficiently is actually not very hard, for a bilinear system the optimal algorithm is both simple and relatively computationally efficient 23.46.11 Quit maddler ("Lost terminal") 23.46.28 # *hahm* 23.46.41 # Dan89: If someone can help you, they'll answer. 23.46.58 # OK 23.47.00 # Or did you want all 150 other people here to say "no, I don't have any time right now" etc? 23.47.13 Join mmadia [0] (n=mmadia@pool-138-89-96-141.mad.east.verizon.net) 23.47.30 # denes: markun me i own a m6sl 23.47.41 # i want to transfer some movie to my sansa buy i cant see it in the player 23.47.42 # what can i do? 23.48.09 # saratoga: Did you already upload a patch? :) 23.48.23 # no i'm not very interested in it 23.48.40 # Dan89: Rockbox uses the original firmware's USB right now on that player, so if you can't see it you're having a problem between your computer and the original firmware. 23.48.46 # meven: hi 23.50.01 # no, I meant that i cant see it inside the "file" folder when i open my player. 23.50.06 # did you understand? 23.50.14 # meven: ah, my bad 23.50.20 # hi btw :) 23.50.44 # Dan89: What's your "show files" setting set to? 23.51.04 # what do you mean? 23.51.22 # how can i set it? 23.51.45 # Dan89: It's a setting in Rockbox, described by the manual. 23.53.13 # yes but how can i set the option for a folder? 23.53.28 # ^^ 23.53.37 Join webguest23 [0] (n=57bd56da@gateway/web/cgi-irc/labb.contactor.se/x-591b6016a02bf2fb) 23.54.05 # Dan89: You set it in general. It's in the manual. 23.54.26 # file wiew? 23.54.32 # view 23.55.31 # all 23.55.39 # Where did you put the file? 23.55.46 # And did you transfer it while in MSC mode? 23.56.01 # now i can see it 23.56.04 # thanks! 23.56.22 # but how can i play the movie? 23.56.29 # Click on it. 23.56.32 # Just like songs. 23.56.49 # but it dosent work 23.56.50 Quit reacocard (".") 23.57.02 # Dan89: Did you follow the instructions for converting it? 23.58.01 # there is a diffrent manual for this? 23.58.26 Quit herrwaldo ("Konversation terminated!") 23.58.32 # in the closed resizing patch, where did resize_bitmap get called from? 23.58.40 # Dan89: no should be in the manual 23.58.44 # try searching 23.59.01 # so how should i convert it?