--- Log for 20.02.110 Server: wolfe.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 8 days and 9 hours ago 00.00.08 # not at the moment, have to think about it 00.00.14 # %?St(setting) 00.00.40 Part anethema 00.00.53 # () is not nice as you will need %( and %) then and using braces is quite common 00.01.16 # not necessarily 00.02.35 # JdGordon_: Now I get 716 if (id < SYSTEMFONTCOUNT || id >= MAXFONTS-1) 717 return WPS_ERROR_INVALID_PARAM; 725 } 00.03.05 # the numbers are? 00.03.30 # sorry, one mo 00.03.40 Join Rob2222 [0] (~Miranda@p4FDCAF91.dip.t-dialin.net) 00.04.05 # oh, gdb output? that means the the font is being loaded into the id for the remote user font 00.04.31 # oh bloody hell 00.04.34 # * JdGordon_ appologises 00.04.44 # yeah, but that line back.. bloody stupid of me 00.05.00 # FFS :p 00.05.02 # heh, OK :) 00.05.15 # id -= SYSTEMFONTCOUNT; should be id -= FONT_UI 00.05.24 # right area, wrong fix :p 00.05.26 # and I still want preset name on it's own line or only with the preset number max as it is in SVN (line too long) 00.05.26 # OK, one mo 00.05.33 # and scrolling lines 00.06.39 Quit Bagder (Ping timeout: 260 seconds) 00.07.02 # oh, I said I'll take care of that... but only if own FMS don't need a hard reset for me 00.07.11 Quit Rob2223 (Ping timeout: 256 seconds) 00.07.31 # removing %pm from my FMS didn't help 00.07.38 # * JdGordon_ doesnt understand the but part? 00.08.10 # JdGordon_: p id $1 = 1 p font_ids[id] $2 = 3 00.08.32 # Should I see if it works now? 00.08.39 # yep, just hit c 00.09.10 # a hard reset is the only way to exit the radio screen with an own FMS is a hard reset currently (on my Ondio) so it's not nice to test FMSs 00.09.54 Quit perfectdrug (Quit: perfectdrug) 00.10.48 # * JdGordon_ heading home 00.11.00 # please nmentino that in the tracker incase I forget 00.11.05 Quit JdGordon_ (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 00.11.57 Quit ender` (Quit: Connection Reset by Gypsies with Wire Cutters) 00.13.44 Join kugel [0] (~kugel@rockbox/developer/kugel) 00.13.50 # JdGordon: It now gives an error on parsing if I misspell the font in the %Fl, but the wps still doesn't use it 00.14.04 # * pixelma wonders about something 00.21.20 Quit mt (Quit: ChatZilla 0.9.86 [Firefox 3.5.7/20091221164558]) 00.25.45 Quit MaadMan (Quit: Verlassend) 00.26.14 Join ecio_ [0] (~ecio@32.130.89.182) 00.26.31 Nick knine is now known as kaniini (~kaniini65@dyn75-70.yok.fi) 00.28.07 Quit freddyb (Ping timeout: 260 seconds) 00.29.59 Quit ecio (Ping timeout: 260 seconds) 00.30.00 Nick ecio_ is now known as ecio (~ecio@32.130.89.182) 00.30.40 # JdGordon: any own FMS with a FMS tag makes it break. I just tried "..." as the only things in the FMS and it works - whereas "%Tn" as the only thing doesn't 00.31.00 Join Farthen [0] (~chatzilla@p50988dd0.dip0.t-ipconnect.de) 00.31.14 Join Omlet05 [0] (omlet05@61.118-244-81.adsl-dyn.isp.belgacom.be) 00.31.32 # although it is correctly parsed and shows me the preset name 00.31.37 Quit Omlet05 (Client Quit) 00.33.00 Quit Tomis (Read error: Operation timed out) 00.33.27 Quit huelk (Read error: Operation timed out) 00.33.50 Join Sajber^ [0] (~Sajber^@93-252.anonymous.at.anonine.com) 00.34.18 Quit robin0800 (Remote host closed the connection) 00.34.25 # and not sure if it is relatad (guess not) but I still get unused variable warnings in radio.c (line 592, variables in question are "minutes" and "hours" 00.34.26 Join Tomis [0] (~Tomis@70.134.68.71) 00.34.28 Quit Omlet (Ping timeout: 276 seconds) 00.39.27 Quit piotrekm (Quit: piotrekm) 00.42.33 # gevaerts, I've tried to get the card in my mini to be as thick as the original hard drive, but I can't get the click working... do you by any chance have any other suggestions? 00.43.28 # I think people successfully used pieces of cardboard to fill the gap 00.44.39 # yeah, I'm trying but no... weird. guess I'll have to keep experimenting. 00.45.11 # AlexP: bloody hell :p 00.45.14 # umm 00.45.31 # New commit by 03funman (r24778): rbutil: link to the Sansa forums when the user is requested to download a Sansa AMS firmware 00.46.16 Quit petur (Quit: Zzzzzz) 00.49.19 # New commit by 03jdgordon (r24779): fix possible out-of-bounds error on remote lcd targets if they try loading a font to id==2 00.49.52 Quit Tomis (Read error: Connection reset by peer) 00.50.57 # TucknDar: I didnt use anything to fill the gap.. my clickwheel still works fine 00.51.07 Join Tomis [0] (~Tomis@70.134.68.71) 00.51.33 # my doesn't... another test now though. Thanks for your replies, btw! Appreciate it! 00.51.53 # minig1 or g2? 00.52.00 # g2 00.52.15 # same, yeah, some thick card should do the trick 00.52.33 # hopefully you didn't damage the cable? 00.52.37 Join Strife1989 [0] (~Strife89@adsl-220-102-6.mcn.bellsouth.net) 00.52.58 # don't think so, as it works with apple firmware, which I obviously don't want to use ;) 00.54.37 # New commit by 03jdgordon (r24780): and actually fix multifont on remote lcd targets also 00.54.53 # AlexP: there you go! 00.55.10 # thank you :) 00.55.13 # JdGordon: I just tested the pm on its own line theory with a test.wps containing %?mh<%pm|AAA> (and on a second line with %?mh to see if the hold tag works and it does) - and the first line always shows the peakmeters, whether on hold or not... 00.55.15 Join karashata [0] (~karashata@74-220-162-11.wightman.ca) 00.56.08 # ok, I guess thats not really surprising. did we ever expect %pm to work in conditionals? 00.56.44 # you seemed to :P 00.56.52 # apart from me :) 00.56.53 *** Saving seen data "./dancer.seen" 00.57.00 # (who knows nothing about actually using the skins) 00.57.17 Nick Strife1989 is now known as Strife89|Desktop (~Strife89@adsl-220-102-6.mcn.bellsouth.net) 00.58.06 Quit jgarvey (Quit: Leaving) 00.58.30 # JdGordon: ta, multifont works nicely now :) 00.58.37 # weeeee :) 00.59.01 # I'll try out fms shortly 01.02.04 Join crwl [0] (~crwlll@a88-112-134-63.elisa-laajakaista.fi) 01.05.10 Join CaptainKewl [0] (jds@207-237-117-89.c3-0.80w-ubr2.nyr-80w.ny.cable.rcn.com) 01.05.23 Join CaptainKwel [0] (jds@207-237-117-89.c3-0.80w-ubr2.nyr-80w.ny.cable.rcn.com) 01.07.22 Quit Strife89|Desktop (Quit: Log out, log in.) 01.08.31 Join Strife1989 [0] (~Strife89@adsl-220-102-6.mcn.bellsouth.net) 01.09.39 # ha the new mdct library flips the order of the input and output arguments 01.09.56 Join tomers [0] (~chatzilla@bzq-84-109-85-100.red.bezeqint.net) 01.10.00 Quit CaptainKewl (Ping timeout: 264 seconds) 01.12.07 Nick Strife1989 is now known as Strife89|Desktop (~Strife89@adsl-220-102-6.mcn.bellsouth.net) 01.14.38 Quit tomers (Client Quit) 01.16.22 Quit TucknDar (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 01.24.03 # JdGordon: limits exceeded! : 01.24.10 # Where do I increase them? 01.24.18 # which limit? 01.24.34 # probably apps/gui/skin_engine/skin_buffer.c at the top 01.24.54 # dunno, the sim just says ERR: Failed parsing on line 31 : ERR: Limits exceeded 01.25.03 # Although neither my wps or fms have a line 31 01.27.32 # yeah, probably that file ten 01.27.41 # hang on 01.27.43 Quit bertrik (Ping timeout: 246 seconds) 01.29.32 # New commit by 03saratoga (r24781): Use new MDCT library for libfaad. Speeds up AAC-LC by 2.5MHz. 01.30.20 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 01.32.06 # I guess we can remove the old MDCT now 01.32.12 # its not used for anything 01.32.28 # AlexP: are you using different backdrops for the 3 possible skins? (sbs/setting, wps, fms)? 01.32.47 # JdGordon: no sbs and at the moment the fms and wps are using the same one 01.32.52 # (or trying to) 01.33.05 # lots of images? or fonts? 01.33.26 # 1 additional font in the wps, two in the sbs 01.33.40 # and not many images, no - just vol, battery etc from cabbiev2 01.33.43 # 30K, shouldnt be such a big deal 01.34.10 # A slight ofddity is the error at line 31 - the wps has 24 lines, the fms 23 01.34.17 # we really need to get better debug info from skins :/ 01.34.26 # awesome! 01.34.28 # sorry, two additional fonts in the fms not sbs 01.34.38 # There is no sbs 01.34.41 # remote target though, so the remote maybe? 01.34.57 # ah, possibly - I haven't touched that yet 01.35.55 # yes, the cabbie rwps has 34 lines :) 01.36.19 # I'll cut that down into one of my own with a sngle line or something and see if it goes away 01.37.30 # yes, that was it 01.37.51 # but without remote wps or fms I'm already at 38620/44032 01.38.04 # without any images to speak of, and three additional fonts 01.38.21 # well, with a few images 01.38.26 # but not going mental :) 01.39.16 Join phanboy4 [0] (~benji@gate-20.spsu.edu) 01.39.58 # that seems too high 01.40.09 # amiconn: pong? 01.40.17 # I'll finish up and then upload somewhere 01.40.21 Join kimi-sharamin [0] (~karashata@74-220-162-11.wightman.ca) 01.40.28 # which target? 01.40.35 # H120 01.41.12 # Unhelpful: I don't understand your ARMv6 division optimisation (udiv32_arm.S lines 241ff) 01.41.56 # oddly enough on the nano2g rbutil said i already had a bootloader installed, and i'm pretty sure i didn't 01.42.15 # Your're using smmla (should be equivalent to the smlal with low word cleared used on ARM JdGordon: I'm going to bed in a bit - I'll have a play tomorrow then bug you on Sunday :) 01.42.44 # AlexP: easiest fix is apps/gui/skin_engine/skin_buffer.c line 58, change that 2* to 4* or something 01.42.45 # But then you're using smmul, which needs correction if the sign bit is set 01.42.46 Quit karashata (Ping timeout: 265 seconds) 01.42.51 # sounds good 01.43.31 # However, tst + not-taken branch + smmul is even one cycle more than just using umull 01.44.58 # amiconn: the reciprocal won't have the sign bit set, and the test ensures that the numerator does not either. this benches faster on beast, but whether it's faster in practice probably depends on the frequency with which the branch is taken. 01.45.02 Quit Tomis (Read error: Connection reset by peer) 01.45.26 # oh shit plugged my ipod into a sansa USB cable 01.45.52 # I understand what the test does, however, I would expect umull to be faster here, as it doesn't need the test + branch 01.46.38 # strange that they fit so well 01.46.43 # also both test and branch should fit into result delays for multiplies - the smmla uses the result of the mul, which means it can't execute for 3c (iirc) after the mul completes. 01.48.05 Quit Farthen (Read error: Connection reset by peer) 01.48.14 # and the smmla result is used in the following smmul, so the smmul will block for 3c if reached as well 01.48.49 # but unless i've misunderstood the arm1136 manual and ASDG the tst and bmi can execute without penalty during these delays? 01.49.31 # Hmm, that is true 01.50.02 # i should probably remove the note about this being an APE-specific optimization as well... from what i see it should be successful as long as the branch is not taken *too* often and is predicted successfully most of the time. 01.50.17 # This whole streak of multiplications depending on each other's result is rather bad for the arm11 pipeline 01.50.19 Join Tomis [0] (~Tomis@70.134.99.142) 01.51.18 # What I don't understand as well is why this case would only account for 1 in 10^7 cases 01.51.22 # it is, but it give me lots of places to put tests and branches for special cases. 01.51.47 # ah, well, it does on APE (i counted) which is why i said i should remove the note about this being APE-specific. 01.52.17 # hmm 01.52.39 # I would expect this to occur much more often with random test data 01.54.31 # the test set my benchmark uses isn't random, either.... but are neither are most actual divisions, and i suspect that in typical uses sign bit is set <50% of the time. values in actual use are probably more likely to be evenly distributed among lengths than across all possible values 01.57.07 Quit BHSPitMonkey (Remote host closed the connection) 01.58.19 # but even if the branch is taken exactly half of the time, it shouldn't be a *huge* expense... ASDG gives branch as taking 1c on correct prediction, 4c on incorrect prediction, but it's in a 3c delay slot already. also the failed-prediction case is given as needing flags 2c early, but since the smmla between tst and bmi is a 2c instruction, that should be satisfied as well. 02.00.36 # the test set i used for benchmarks consists of 1-bit, 2-bit, 3-bit, etc up to 32-bit values, one of each, and each repeated at each possible left-shift position... so there is exactly 1 1-bit value in the set, 2 2-bit values, 3 3-bit values, etc. the benchmark divides every possible combination of values in the set. i could easily run with a pre-generated array of random numbers, instead, though. 02.08.32 Quit moos (Ping timeout: 260 seconds) 02.12.35 # there's also another way to handle the "main" division path (the one followed if none of the special-case branches occur). a goldschmidt divider takes two multiplies per iteration, but they can be done independently. this should reduce stalling on arm11 and should be almost free of stalls on arm9e, and can use the same initial-estimate table as the N-R version (and therefore the same trick of using the estimate-table value directly for 02.12.35 # large enough divisors). 02.13.50 # *however* goldschmidt does not converge as quickly as N-R - two iterations are required to get as good an approximation, and the second one would need to use umull on arm9e. 02.17.07 # if it's placed carefully perhaps a test/branch could cheaply avoid the second iteration when the divisor is the right size. i never got to tuning the goldschmidt divider that finely, and then the implementation got lost (i hadn't committed what i *thought* i had comitted) 02.18.09 Quit komputes (Remote host closed the connection) 02.29.53 Quit GeekShadow (Read error: Connection reset by peer) 02.34.29 Quit kimi-sharamin (Read error: Connection reset by peer) 02.35.30 Join Kitr88 [0] (~Kitr88@BSN-182-6-34.dial-up.dsl.siol.net) 02.36.30 Join karashata [0] (~karashata@74-220-162-11.wightman.ca) 02.37.19 Quit kugel (Remote host closed the connection) 02.37.58 # funman: i modified your test to print amount written every 256B while writing to iram. it never prints anything. now trying with print every iteration... 02.38.18 # hangs after writting 0x20 bytes 02.38.35 Quit Kitar|st (Ping timeout: 252 seconds) 02.40.28 Quit Kitr88 (Ping timeout: 272 seconds) 02.45.36 Join Kitar|st [0] (Kitr88@BSN-142-90-236.dial-up.dsl.siol.net) 02.46.02 # the last address it writes to successfully seems to be 0x81000018 02.49.09 Quit archivator (Quit: Leaving) 02.51.22 # leavittx: *real* 3d accel support? or only some 2D blend/blit/scale stuff like the beast's IPU can do? if it can draw textured tris or quads, even with only 2D coordinates, that might at least be something to start with. 02.56.56 *** Saving seen data "./dancer.seen" 03.04.59 # New commit by 03uchida (r24782): commit FS#10424 and FS#10425 ... 03.07.56 Join ucchan [0] (~ucchan@softbank219205175105.bbtec.net) 03.11.12 Part fleebailey33 03.15.56 # Thereis a question. My task(FS#10424, FS#10425) cannot be close because the authority doesn't exist. 03.16.00 # How should I do to close my task? 03.19.51 Quit nimak (Ping timeout: 256 seconds) 03.22.58 Join robin0800 [0] (~quassel@genkt-050-078.t-mobile.co.uk) 03.23.08 Join nima [0] (~nima@adsl-75-45-231-54.dsl.sfldmi.sbcglobal.net) 03.24.32 Quit ps-auxw (Ping timeout: 248 seconds) 03.25.04 Join ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123) 03.26.28 Quit robin0800 (Client Quit) 03.26.55 Join robin0800 [0] (~quassel@genkt-050-078.t-mobile.co.uk) 03.27.45 # ucchan: are they committed, or is there some reason they ought to be rejected without further consideration? 03.42.08 Quit GodEater (Ping timeout: 248 seconds) 03.43.12 Quit robin0800 (Remote host closed the connection) 03.44.11 # I committed the patch that exists in these tasks, then I want to close them. 03.44.51 Quit Adnyxo (Quit: Leaving) 03.48.00 Quit ps-auxw (Ping timeout: 248 seconds) 03.50.53 Join ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123) 03.52.16 Quit ucchan (Quit: Leaving...) 03.57.39 Join Schmogel [0] (~Miranda@p3EE214B2.dip0.t-ipconnect.de) 04.05.21 # ah... you probably need developer rights on the tracker 04.09.38 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.2.227) 04.11.40 Quit TheSeven (Disconnected by services) 04.11.53 Join The_Seven [0] (~theseven@rockbox/developer/TheSeven) 04.12.03 Nick The_Seven is now known as TheSeven (~theseven@rockbox/developer/TheSeven) 04.16.18 Quit phanboy4 (Read error: Connection reset by peer) 04.20.57 Quit mikroflops (Remote host closed the connection) 04.21.04 Join mikroflops_ [0] (~yogurt@217-208-157-242-no112.tbcn.telia.com) 04.26.37 Quit Schmogel (Read error: Connection reset by peer) 04.33.53 Join DerPapst1 [0] (~DerPapst@p4FE8E8D8.dip.t-dialin.net) 04.35.39 # saratoga: do you know what pins are different? I'm considering getting a radio with dtwo docks but want sansa and a touch to work. it would also be interesting to see AAP support on the sansas 04.36.01 Quit DerPapst (Ping timeout: 248 seconds) 04.41.49 Quit efyx_ (Remote host closed the connection) 04.43.20 Quit S_a_i_n_t (Quit: There are 10 types of people, those who understand binary, and those who don't.) 04.45.48 Quit MethoS- (Remote host closed the connection) 04.46.31 Join Barahir [0] (~jonathan@gssn-5f754de5.pool.mediaWays.net) 04.49.55 Quit Barahir_ (Ping timeout: 252 seconds) 04.51.39 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.3.1) 04.53.39 Nick jfc^2 is now known as jfc (~john@dpc6682208002.direcpc.com) 04.54.56 Quit DerPapst1 (Quit: Leaving.) 04.57.00 *** Saving seen data "./dancer.seen" 05.05.01 Quit ecio (Quit: Colloquy for iPhone - http://colloquy.mobi) 05.05.29 Join ecio1 [0] (~Moo@244-108.202-68.tampabay.res.rr.com) 05.07.44 # Unhelpful: I don't know details. Even google didn't helped me. But it seems to me that real. :) 05.09.30 Part froggyman 05.50.09 Quit tmzt (Ping timeout: 248 seconds) 05.51.05 Join tmzt [0] (~tmzt@adsl-99-164-34-42.dsl.akrnoh.sbcglobal.net) 05.51.45 Quit shai_ (Ping timeout: 248 seconds) 06.00.54 Nick ecio1 is now known as ecio (~Moo@244-108.202-68.tampabay.res.rr.com) 06.31.43 Quit karashata (Quit: The fluffy dragon has left completely!) 06.35.29 # amiconn: i tried replacing the 528 selected values with 528 random ones. handling large numerators in a separate branch is still faster, though only marginally. the random values were generated in python, which uses MT, so they should be quite random enough. 06.56.01 Quit panni_ (Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )) 06.57.04 *** Saving seen data "./dancer.seen" 07.04.08 Join CPICH_ [0] (~Moo@244-108.202-68.tampabay.res.rr.com) 07.05.28 Quit ecio (Ping timeout: 246 seconds) 07.17.58 Join ecio [0] (~ecio@32.130.89.182) 07.18.55 Quit CPICH_ (Ping timeout: 245 seconds) 07.21.33 Quit nima (Read error: Connection reset by peer) 07.21.34 Join nimak [0] (~nima@adsl-75-45-231-54.dsl.sfldmi.sbcglobal.net) 07.24.35 Join moos [0] (moos@rockbox/staff/moos) 07.27.19 Quit martian67 (Ping timeout: 268 seconds) 07.29.27 # New commit by 03unhelpful (r24783): Clarify comments in ARMv6 divider regarding special-case handling of large (high bit set) numerators. 07.35.14 Join Horschti [0] (~Horscht2@xbmc/user/horscht) 07.39.02 Quit Horscht (Ping timeout: 268 seconds) 07.39.13 Join Guest88353 [0] (~martian67@over.the.cat) 07.42.48 # New commit by 03tomers (r24784): Comment out lcd_drawline() DEBUGF messages which show in various simulators 07.46.00 Join CaptainKewl [0] (jds@207-237-117-89.c3-0.80w-ubr2.nyr-80w.ny.cable.rcn.com) 07.49.35 Quit CaptainKwel (Ping timeout: 252 seconds) 07.54.45 Join tomers [0] (~chatzilla@bzq-84-109-85-100.red.bezeqint.net) 08.03.00 Join stoffel [0] (~quassel@p57B4D107.dip.t-dialin.net) 08.05.35 Quit liar (Ping timeout: 245 seconds) 08.09.59 # tomers: Those debug messages were there for a reason. 08.10.23 # amiconn: what what the reason? 08.10.56 # amiconn: s/what/was/ 08.11.03 # Several plugin developers just used lcd_drawline() in places where they should have used lcd_hline() or lcd_vline() for performance reasons 08.11.39 # amiconn: Should the 'user' of the simulator have to see all these debug messages? 08.11.46 # Those plugins showed *massive* output from these messages, so I was able to find and fix them 08.12.20 # I left those messages in place in case it will happen again 08.12.40 # but it does happen often today 08.12.58 # does those prints indicate something is wrong? 08.13.12 # or need to be addressed to? 08.13.46 # you use the simulator for your own reasons and then you get all that debug output which seems irrelevant... 08.13.58 # Of course there are some calls to lcd_drawline() which do *occasionally* show this message (because a random line is exactly horizontal or vertical by coincidence) 08.14.29 # so do you want me to revert? 08.14.56 # don't we need to keep the simulator output clean? 08.15.15 # The latter is unfortunately unavoidable for this optimisation hint, the former is something that should be fixed in the plugin 08.16.17 # Why should we need to keep the simulator out put clean? The simulator is meant for developers, and debug output should point out problems 08.17.03 # yeah but most developers want the output to show whatever is relevant for them. 08.17.22 # The question is whether this optimisation hint should be kept enabled all the time, but if you really found plugins which output lots of those messages, you should rather check those plugins whether they can be optimized... 08.17.22 # they don't want to get usb messages, lcd messaged, storage messages, etc. 08.19.16 # i think that most developers (like me) are not aware of that, and even if they see it they don't really know it is a hint for them to use lcd_[vh]line for optimisation. I guess that from time to time someone should enable these messages and review all plugins 08.19.34 # but that's not going to happen, i guess 08.20.16 # maybe i'll wrap these messages with #ifndef HIDE_LCD_LINE_WARNING or something? 08.21.19 # Nah. There are already more than enough ifdefs 08.21.24 # so i guess i should revert this commit so that these messages will show by default? 08.22.28 # Hmm. I would tend to say yes, but your other concern is also valid. 08.23.02 # I wonder if there are other similar debugging aids which are forgotten by now because they're disabled 08.23.43 # (this one is an optimisation hint though, it doesn't point out functional bugs) 08.25.01 # Do you remember which plugins printed this message a lot? 08.25.21 # amiconn: maybe we should re-enable these prints, and change the message to something like ':: consider using lcd-[hv]line instead...', and use a single macro for that 08.25.33 # amiconn: I can't remember. sorry. 08.26.12 # What would 'filename' and 'line' be? 08.26.24 # __FILENAME__ and __LINE__ 08.27.02 # e.g. firmware/drivers/lcd-16bit-vert.c:361 08.27.21 # Those would always be the same for a certain sim, e.g. lcd-16bit.c and 354 or 361 08.28.34 # But that would be misleading imo. The caller (e.g. a plugin) should use the specialised versions if possible 08.28.55 # Current message, "lcd_drawline() called for vertical line - optimisation.\n" is rather confusing. 'optimisation' sounds like it notifies you of an optimisation that took place, not that you should consider using other function for performance reasons. 08.29.31 # It does both 08.30.01 # oh 08.30.14 # I don't understands ^^^, can you elaborate? 08.30.51 # lcd_drawline() takes this optimisation, and notifies you that you can save the decision overhead if you call lcd_hline() and lcd_vline() directly 08.31.47 # i got that part, but I didn't get what you said about the caller (e.h. a plugin), do you mean that it should print "bubbles:100" instead of lcd-16bit.c:200 ? 08.31.58 # it looks like goldschmidt can produce an inverse in 4 multiplies, the same number as newton-raphson. pros: multiplies in goldschmidt are on two values and can be carried out (somewhat) independently, for large-enough divisors we could potentially do one iteration instead of two. cons: there are some shifts require between iterations if we don't want to see performance destroyed. 08.31.59 # s/bubbles/bubbles.c/ 08.32.25 # Yes that's what I meant, but afaik this is not possible 08.33.28 # amiconn: it's *somewhat* possible - wrap lcd_drawline in a macro of the same name that tests and prints the message. since the macro exists at the callsite it should output the correct filename/line. 08.34.06 # But the idea of printing the location where a debug message comes from is good, imo. 08.34.23 # It makes it easier to identify them if you know where they come from 08.35.51 # Unhelpful: (1) That won't work for plugins though, as they are loaded dynamically 08.36.04 # s/\(1\)// 08.36.13 # * Unhelpful will try implementing goldschmidt in arm asm again and see where it gets him 08.36.46 # amiconn: i wonder what happens if you try to #define rb->lcd_drawline(...) ... nothing nice probably. 08.37.15 # I would expect that the preprocessor complains 08.37.32 # - and > are not valid in macro names afaik 08.37.51 # indeed they're not. 08.39.01 # Hmm. Enabling the debug messages now is more difficult than disabling them if they're enabled by default 08.39.10 # you could also have lcd_drawline take the filename and line number as args on simulator builds, and then the same define would work for plugins. 08.40.01 # ie #define lcd_drawline(args) lcd_drawline(args, __FILENAME__, __LINE__) 08.41.51 # Not always 08.42.38 # There are plugins which call lcd_drawline() via a function pointer 08.42.50 Join petur [0] (~petur@rockbox/developer/petur) 08.43.46 # At least these plugins are calling several lcd_* functions via pointer - I'm not sure whether lcd_drawline() is among those. 08.47.14 Nick kaniini is now known as knine (~kaniini65@dyn75-70.yok.fi) 08.56.45 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 08.57.07 *** Saving seen data "./dancer.seen" 09.02.08 # the cutoff point for stopping at 1 goldschmidt iteration appears to be divisors >= 0x9e000 (that's the smallest such cuttoff that is a valid arm immediate, anyway). 09.05.05 Join flydutch [0] (~flydutch@host154-132-dynamic.15-87-r.retail.telecomitalia.it) 09.09.21 Quit CaptainKewl (Ping timeout: 272 seconds) 09.19.22 # Devs: why didn't you finally swiched to git? 09.19.45 # The git mirror of svn is nice, but... 09.21.53 # leavittx: serial numbering of revisions for one thing - you can always tell if one build is newer/older than another. and it's already svn. and devs who want to use git already can - it's not like being able to git push would be so very much easier than git svn dcommit. 09.22.05 # also i believe the majority of devs prefer to use svn 09.23.06 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 09.23.59 Join TopyMobile_ [0] (~topy@f048242082.adsl.alicedsl.de) 09.27.47 Quit TopyMobile__ (Ping timeout: 256 seconds) 09.44.11 Quit tomers (Ping timeout: 272 seconds) 09.48.26 # * pixelma wonders if USB HID should really be enabled by default 09.50.31 # after experiencing myself that some OSs can't cope with it (which is why the option to turn it off was implemented) and reading some reports from other people, I start thinking that the default should be off - at least for the release 09.51.24 Quit Zarggg (Ping timeout: 264 seconds) 09.52.06 # HID is a plus and I never heard of any other MP3 players that offers it, whereas USB data connection is something everyone expects to be working 10.06.58 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 10.14.27 Join Bagder [0] (~daniel@rockbox/developer/bagder) 10.16.18 # pixelma: I don't know about the effects of having the player as HID, but the hard disc accelerometer being presented as a joystick device caused some troubles for me on LInux 10.17.16 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 10.27.05 Join ender` [0] (krneki@foo.eternallybored.org) 10.37.20 # Why doesn't rb->lcd_clear_display(); clear display after rb->splash? 10.39.24 # ok, how to clear display after rb->splash()? 10.39.41 # You need to update afterwards 10.40.27 # lcd_clear_display() only changes the framebuffer, like all lcd_* drawing functions 10.43.29 # amiconn: what do you mean by "update afterwards"? 10.43.47 Join DerPapst [0] (~DerPapst@p4FE8F6DE.dip.t-dialin.net) 10.44.19 # lcd_update() 10.48.49 # * stripwax doh's - new MDCT doesn't have an icode_attr - that'll give an extra MHz-or-so bonus.. 10.49.36 # stripwax: you mean rb->lcd_update, right? Not helps. Look smb on my code plz: http://dpaste.org/Wuww/ 10.50.42 # leavittx - I don't see you calling rb->lcd_clear_display - you need to call both lcd_clear_display AND lcd_update, right? 10.51.04 # ah 10.51.06 # I don't know what "look smb on my code plz" means. Please use real words in this channel, helps. 10.51.57 # Sorry, will not repeat anymore :-\ 10.53.55 Join m3dlg [0] (~m3dlg@212.183.140.53) 10.57.10 *** Saving seen data "./dancer.seen" 10.58.17 # looks like wma about 5.5Mhz faster on coldfire (h120) with icode_attr in new mdct. will double check vs unchanged, but can't believe we missed that! 11.00.04 # Nice! 11.00.45 # in fact it can *almost* run unboosted at 40Mhz at 96kbps .. 11.00.55 # Question: after calling lcd_clear_display() display becomes black. How do I restore normal rockbox background with logo? 11.10.45 Quit m3dlg (Ping timeout: 240 seconds) 11.11.35 # leavittx - if you can think of another (existing) rockbox plugin that has the behaviour that you want to copy, then you can look at the sourcecode for that other plugin and see how it is done.. 11.12.55 # I guess you have to keep an eye on the drawmodes (and foreground/background definitions) 11.15.38 # New commit by 03uchida (r24785): libpcm: linear pcm decode logic separates according to each bitspersample, endian, and signess. 11.24.36 Quit stoffel (Remote host closed the connection) 11.50.46 # correction - it runs almost unboosted at 40Mhz at *128* kbps. h120 wma at 96kbps only 37MHz 11.52.10 Join Buschel [0] (~ab@p54A3B16E.dip.t-dialin.net) 11.52.21 # stripwax: \o/ 11.52.42 # stripwax: what clock was needed before mdctexp? 11.54.46 # Buschel - 43Mhz or more I think. I actually don't think I still have those timings to hand though :( 11.55.02 # That's 43Mhz for 96kbps. 11.55.42 # I'm tempted to do a rebuild of the old code and put a definitive comparison on the wiki page .. 11.58.24 # hrm, so the estimated division result may be low by as much as 2, or high by as much as 1. wonder how best to correct that... 11.59.28 # Excellent, ICODE gives us another 0.5Mhz boost on arm also. So 96kbps on ipod video now 24.99MHz :) 11.59.38 # committing.... 12.00.19 # New commit by 03stripwax (r24786): Adding ICODE for imdct (and its constituent ifft bits) gives 0.5MHz boost on arm (ipod video) and about 5MHz boost on coldfire (H120) 12.01.42 # that svn comment really makes no sense at all, sorry. 0.5MHz boost on ipod vorbis, and 5MHz on h120 wma. 12.02.10 # (measuring ipod wma improvement now, suspect minimal though) 12.02.18 # stripwax: the results are really impressive! :o) 12.02.20 # good work! 12.02.41 # thanks! 12.03.21 # * Buschel needs to optimize mpc again to keep the performance headroom to "other" codecs :) 12.13.02 # Buschel - according to this, we're now a clear 2MHz faster on coldfire vorbis, and 7MHz faster on coldfire wma, versus 3 months ago. http://www.rockbox.org/wiki/CodecPerformanceComparison 12.13.33 # a bit surprised that coldfire vorbis hasn't seen as big an improvement, but I have a suspicion about that (revtab being in ram not iram..) 12.15.50 Quit bertrik (Ping timeout: 276 seconds) 12.19.06 Join m3dlg [0] (~m3dlg@212.183.140.2) 12.19.29 Join kugel [0] (~kugel@rockbox/developer/kugel) 12.19.46 # stripwax: I think most of the time you should s/arm/PP/ 12.21.06 # have you tested on arm9tdmi, arm9e, and arm11? arm9tdmi has 1c loads (with delayed result availability) and arm9e/arm11 have the 2c multiplier w/ respectively 1c and 2c delay for result after the multiply completes execution 12.21.54 # kugel - probably right, good point 12.22.11 # on all three you can benefit from loading data well before it's needed, and on the last two putting in non-dependent ops around multiplies will help 12.22.21 # Unhelpful - nope. I have tested only on the targets I have access to (h120 and ipod video). Can you, please? 12.22.54 # luckily I didn't hand-optimise *everything*, so gcc should be able to do some suitable scheduling 12.23.30 Quit m3dlg (Ping timeout: 245 seconds) 12.24.00 # stripwax: i'll try to find time this weekend, then. there aren't any very-working arm9e targets, and i don't have any arm9tdmi, but i can benchmark on the beast... just checkout the mdct_exp branch and build? 12.24.46 # it's in trunk now I believe 12.24.56 # yep, it's all in trunk... 12.25.21 # so you'd probably be best to test_codec before you upgrade (or build an old version, or something) 12.25.39 # oh... hrm, i assume we made sure it was at least not slower on non-PP before moving it to trunk? ;) 12.25.57 # if you pester somebody w/ nano2g i believe that's arm9tdmi 12.26.14 # Yes, we made sure it was faster on both PP and coldfire (I tested h120 and I believe someone else tested H340) 12.26.38 # yes, but not all ARM targets are PP ;) 12.26.38 # Unhelpful - oh, cool! 12.27.02 Join MethoS- [0] (~clemens@134.102.106.250) 12.27.09 # TheSeven - would you be able to check test_codec performance on nano2g versus a few revisions ago? (i.e. before mdctexp committed to trunk)? 12.27.13 # fx and samsa are 9tdmi also 12.27.25 # Unhelpful - right. saratoga tested some kind of e2x0 12.27.31 # I don't know if that's pp 12.27.55 # stripwax: sure, if you can name me an exact revision number that i should test 12.28.16 # if you look in tools/configure targets that are arm9xx*bunchofjunk*e are arm9e, other arm9 targets are arm9tdmi 12.28.26 Join Omlet [0] (omlet05@76.152-242-81.adsl-dyn.isp.belgacom.be) 12.29.17 # and can anybody point me to a link to those codec test files? they are being referred to on the codec performance page, but there is no link (or i didn't find it) 12.29.39 # Unhelpful, stripwax: ARM9e is e.g. Cowon D2, and the D2 is usable for this kind of tests 12.29.42 # TheSeven - fab. ok so r24786 versus r24711 (although I see some nano2g fixes put in after 24711 so I don't know if 24711 works for you) 12.29.45 # thegeek: http://download.rockbox.org/test_files/ 12.29.59 # ^theseven 12.30.07 # ah, i did miss the underscore when guessing :-) 12.30.12 # Afaik the D2 can even be used to play music from SD, just the internal flash isn't usable (ftl missing) 12.30.22 # thegeek: sorry :( 12.30.45 # anyone other than shotofadds have a D2? 12.30.47 # amiconn: that might need some fixing to test_codec? doesn't it always write logs in /? 12.30.47 # stripwax: should all be minor stuff (power management etc.) 12.30.53 # or, shotofadds, if you're listening.. 12.31.01 # TheSeven - ah ok 12.31.08 # Unhelpful: Well, gevaerts did several tests on D2 for me already 12.31.20 # stripwax: tomers, gevaerts and Llorean have one 12.31.22 # And ARM9 v4 can be tested on Gigabeat F/X 12.31.39 Join stoffel [0] (~quassel@p57B4D107.dip.t-dialin.net) 12.31.44 # amiconn: remind me to bother him about these dividers, he needs more excuses to make up division puns, anyway :) 12.32.12 # although i guess i can benchmark them well enough on clipv2, just not via the plugin i wrote for it. 12.32.32 # stripwax: should i test with/without eabi? 12.32.41 # Keep in mind that the D2 has no iram (actually it does, but afaik nobody found out how to use it properly) 12.32.57 # TheSeven - whatever works best for you. I didn't use eabi 12.33.03 # So no small-dividers special table... 12.33.06 Join piotrekm [0] (~piotrek@unaffiliated/piotrekm) 12.33.43 # stripwax: they both work fine - so i'll probably do all 4 combinations, so that we also have a result whether eabi makes a difference 12.33.46 Join TheSphinX^ [0] (~cold@p54A5BBEB.dip.t-dialin.net) 12.33.50 # amiconn: we don't use that on arm9e anyway 12.33.57 # Gigabeat F/X also uses no iram - iirc the reasoning was that it's too small to be of use on swcodec 12.34.30 # 4k only 12.34.44 # Iirc the S3C2440 has 4KB of IRAM. On SH1, which has the same amount, we do use it though - and it's very beneficial 12.34.57 # But then SH1 has no cache 12.35.20 # maybe it's used for target specific stuff, I can imagine rolo runs from it 12.35.31 # that s3c2440 actually is only present because they need it as as steppingstone buffer :-) 12.35.48 # the only divider specialization for APE on arm9e/arm11 is that if there's iram a copy of the divider goes there and is used by the UDIV macro 12.35.54 # that iram on* 12.39.22 # It's very interesting that the benefit of using ldm varies wildly between arm versions and variants 12.39.53 # On arm7tdmi it is *very* useful in that a single load takes 3 cycles, whereas ldm takes n+2 cycles 12.39.55 # initially i wrote the branch-for-large-numerator optimization only for APE, because i knew it would be so rarely taken there... but it turned out to bench faster in general as well. 12.40.10 Quit ecio (Ping timeout: 245 seconds) 12.40.49 # On arm9 (both v4 and v5) this advantage (almost) vanishes as a single load is 1 cycle (as long as you don't use it in the next cycle), and ldm is n cycles 12.40.56 # Of course it still reduces code size 12.41.50 # On armv6 it becomes very useful again, because a single load is 1 cycle, and ldm is *also just one cycle, as the fetches happen in the background 12.42.27 # Of course this needs proper design wrt latencies 12.43.07 # the bulk of the arm-specific code is optimising register (re)usage and ldm/stm - but since it was tested for arm7tdmi I don't know what impact will be on arm9/arm6 - sounds like there could be some scheduling problems if I ldm followed by using it immediately 12.43.55 # damn, my internet connection is faster than copying the test files to the ipod 12.44.17 # Iirc I squeezed quite a bit of performance out of the ape predictor on armv6 by just reordering instructions, without negative impact on the earlier arm versions 12.44.50 # reordering doesn't really matter to arm7... and only barely to arm9tdmi 12.45.46 # and i don't think reordering that will help arm9e/arm11 will ever hurt arm9tdmi, will it? 12.45.54 # Ah yes - r19210; 20% speedup 12.46.01 # stripwax: what files would I test? 12.46.03 # what targets use armv6? 12.46.04 # No it shouldn't 12.46.05 # kugel - ? 12.46.12 # for the mdct comparison 12.46.12 # stripwax: Just Gigabeat S 12.46.18 # ah 12.47.22 # stripwax: I mean which type of files are relevant for this? 12.47.39 # wma,ogg. what else? 12.47.45 # kugel - Start with vorbis and wma for now, just for ease of comparison 12.48.30 # really all that use the mdct are relevant. so atrac3, cook, a52. But I don't know how well those are represented in the existing test_files downloadable stuff 12.53.55 Join anewuser [0] (anewuser@unaffiliated/anewuser) 12.57.13 *** Saving seen data "./dancer.seen" 12.58.28 Quit kugel (Ping timeout: 265 seconds) 13.00.08 # erm, does make reconf lose the information that a build dir is supposed to use eabi? 13.00.43 Join Farthen [0] (~chatzilla@p50988dd0.dip0.t-ipconnect.de) 13.04.25 # ok, after some build problems, test_codec is finally running. on r24711-noeabi for now 13.05.43 # 64kaahce roughly realtime, does that make sense, or are we having boosting problems again? 13.06.41 # 190.13 MHz 13.08.29 Join teru [0] (~teru@KD059133108225.ppp.dion.ne.jp) 13.09.37 # grr, doom fails to build again 13.14.03 # ape c2000: 66.4 MHz, ape c4000: 301.16 MHz 13.16.27 # c3000: 102.7 MHz 13.16.52 # * amiconn wonders how large the filter coefficients in demac can become 13.16.55 # TheSeven - can you try vorbis and wma first please - ape doesn't use mdct so wouldn't have any delta to pre-mdctexp changes 13.17.23 # If 15 bits were enough, the swar stuff could be sped up 13.17.27 # * stripwax tries to fix red - atrac3 iram full on a handful of targets 13.18.00 # (for armv5) 13.18.51 Join kugel [0] (~kugel@e178088187.adsl.alicedsl.de) 13.18.55 Quit kugel (Changing host) 13.18.55 Join kugel [0] (~kugel@rockbox/developer/kugel) 13.19.07 # stripwax: old: http://pastie.org/834085 ; new: http://pastie.org/834086 13.19.20 # Oh, and for coldfire too of course 13.19.54 # kugel - cheers - remind me what target that is for? 13.20.00 # fuze 13.20.15 # I can't test higher bitrates due to limited ram (and the fact that test_codec doesn't handle it) 13.20.29 # but it's at least 3-4MHz faster 13.23.31 Join stripwax_ [0] (~Miranda@87-194-34-169.bethere.co.uk) 13.24.25 Quit stripwax (Ping timeout: 240 seconds) 13.24.45 Quit anewuser (Quit: http://xrl.us/WinterChipV =ooo ϢINTER ϾHIP 5iVE is OOON!!) 13.25.14 # stripwax: regarding reds caused by iram in atrac3 -> try to remove iconst_attr for several array in atrac3data_fixed.h, but keep window_loopup[]. 13.27.05 # Buschel - yep, I can do that, but unfortunately I don't have a target to test/compare. But I'll do whatever is needed for it to continue to build .. 13.27.25 # stripwax: if this still isn't sufficient, define the iram usage for imdct in a way that it is only used on targets with large iram (like PP5022) 13.27.27 Quit AlexP (Remote host closed the connection) 13.28.33 # BUschel - I'm (re)using the same define that was already in place for the old mdct (the Tremor one). So it's already defined per-target, etc. I don't want to change that unless I really have to. 13.29.15 # after all, all of the other codecs are fine, and iram is a major speedup for wma for example. so I'd rather just hobble atrac3 rather than hobble any other codecs. 13.29.43 # atrac3 still needs more optimising, anyway 13.30.08 # stripwax_: that's right 13.31.33 # hmm, it is only red for PP's, right? 13.31.41 # Buschel - building for a new target is so slow (on a netbook, running cygwin..) 13.32.02 # Buschel - I don't know about mrobe, vibe or the samsungs.. 13.32.37 # PP5020 13.33.02 # I guess they all have a bit less iram than the 5022? 13.33.10 # yes 13.33.23 Join tomers [0] (~chatzilla@bzq-84-109-85-100.red.bezeqint.net) 13.33.32 # 96KB vs. 128KB 13.33.37 # quite a lot 13.34.19 # atrac3 only recently got changed to use the new imdct - and I suspect subsequently some ICODE/ICONST got added to atrac3 (when it should have been added to the imdct). 13.34.51 # anyway, when I've got a build that works, I'll commit the changes. I think atrac3 is all mt/saratoga right now 13.34.54 # it was :o) I did it :) 13.35.02 # oh! hahahaha 13.35.31 # I am also just starting to compile for h10... 13.37.28 # btw, I'm also buidling on a slow notebook... will take 10min 13.40.20 # got it compiling for h10 with a small change 13.41.07 Quit Guest88353 (Read error: Operation timed out) 13.41.41 # ok cool. gain_tab1 looks a bit silly, by the way .. 13.42.26 # it's just 1<<(20-i) 13.42.26 # remove ICONST_ATTR for qmf_48tap_half_fix[], matrixCoeffs_fix[], channelWeights0[] and channelWeights1[9 13.42.49 # Buschel - are they likely to have the least impact on speed? 13.42.52 Join AlexP [0] (~ap@rockbox/staff/AlexP) 13.43.00 Quit kugel (Ping timeout: 264 seconds) 13.43.30 Quit cjcopi (Ping timeout: 268 seconds) 13.43.40 # only matrixCoeffs_fix[] could have an impact for JointStereo files. all other are irrelevant 13.44.54 # ok, matrixCoeffs_fix[] can still be iram'ed for h10 13.44.54 # New commit by 03stripwax (r24787): Remove ICONST_ATTR from some tables, to fit into PP5020 iram (now that mdct is in iram it's a bit of a squeeze). (per Buschel on irc) 13.45.02 # pah, too late! 13.45.04 # :) 13.45.05 # :) 13.45.20 # let's see what the tables will look like in a few minutes ;) 13.46.05 # I confirmed it built ok for ipod1g/2g 13.46.22 Join Omlet05 [0] (omlet05@165.159-241-81.adsl-dyn.isp.belgacom.be) 13.46.23 # so, the chance is good 13.46.36 # I'm going to blow away gain_tab1 and replace it with 1<<(20-i) in the code, if no objections? 13.49.07 # no objections from my side. delete the array and readd ICONST_ATTR for the matrix-array :) 13.49.15 # re-add* 13.49.25 Quit Omlet (Ping timeout: 276 seconds) 13.49.36 Join Omlet [0] (omlet05@54.105-244-81.adsl-dyn.isp.belgacom.be) 13.49.36 # green :) 13.49.53 Join Guest88353 [0] (~martian67@over.the.cat) 13.51.03 Join efyx_ [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 13.51.28 Join cjcopi [0] (~craig@charon.craig.copi.org) 13.51.49 # matrixCoeffs_fix also looks like a bit of a silly table.. does that really need to be a lookup? there's not a lot of information in it... 13.52.16 Quit Omlet05 (Ping timeout: 260 seconds) 13.52.16 # What's the range of i? 13.53.14 # Depending on the stupidity of gcc, it might be better to use (1<<20) >> i 13.53.15 Quit flydutch (Quit: /* empty */) 13.53.42 # But this requires i to be non-negative 13.53.49 # amiconn - I'm actually using (ONE_16<<4)>>i . which I think is consistent with what you said, as ONE_16 is defined as 1<<16 13.54.03 # i is definitely no-negative (given that it was an index into a table?) 13.54.13 # amiconn: actually, the D2 does have read-only ftl code that works fine for most people. It just doesn't have write support 13.54.32 # range is 0<=i<=15 13.55.30 Join TucknDar [0] (~Miranda@168.146.16.62.customer.cdi.no) 13.55.38 # New commit by 03stripwax (r24788): Reinstate ICONST_ATTR for matrixCoeffs_fix ; remove (silly) gain_tab1 and replace with a simple bitshift in the code 13.56.05 # stripwax_: as JointStereo decoding is still buggy I would like too keep those lookups until the code has been debugged. otherwise it becomes harder to find the error... 13.56.14 # which lookups? 13.56.31 # stripwax_: Yes it is 13.56.39 # Buschel - gain_tab1? 13.56.55 # stripwax_: the silly matrixCoeffs_fix[] 13.57.24 # A table index may be negative, depending on the table. Not common in C, but I'm using this in the SH1 bitswap 13.57.30 # Buschel - oh yeah, no problem with leaving that in place. That one at least has *some* information in it compared to gain_tab1 :) 13.57.59 Join GodEater [0] (~bibble@rockbox/staff/GodEater) 13.58.04 # amiconn - the code was gain_tab1[ index ] and the code is now (1<<20)>>index 14.02.07 # amiconn - (I'm still struggling to see how a table index can be negative -- unless your table 'pointer' is something other than the start of the table, e.g. the middle) 14.02.18 # I guess I could read the SH1 bitswap to find out :) 14.02.34 # Yes, the table base is in the centre 14.02.39 # neat! 14.03.14 # This is because SH1 sign-extends by default. Making the table work this way saves a separate extend-unsigned instruction 14.04.05 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 14.04.58 # This table is defined in asm, but also used from C code on Ondio, and then the table index is an explicit 'signed char' 14.05.29 # JdGordon: ping 14.06.01 # amiconn: that will need watching with new gcc versions 14.10.32 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 14.13.23 Quit stripwax_ (Ping timeout: 265 seconds) 14.13.34 Join ecio [0] (~ecio@244-108.202-68.tampabay.res.rr.com) 14.14.56 Quit Guest88353 (Ping timeout: 268 seconds) 14.16.58 Join Guest88353 [0] (~martian67@over.the.cat) 14.24.44 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 14.25.31 # TheSeven - did you get a chance to do test_codec on vorbis/wma ? 14.25.57 Quit Buschel (Ping timeout: 265 seconds) 14.26.52 # New commit by 03tomers (r24789): WPS: Use helper local variable instead of its value (no functional change) 14.28.12 Join Horscht [0] (~Horscht2@xbmc/user/horscht) 14.28.16 Quit Frampis (Ping timeout: 240 seconds) 14.28.21 # tomers: Did you see the comments about your commit message yesterday? 14.28.30 Quit Horschti (Ping timeout: 252 seconds) 14.28.39 Join Frampis [0] (famas@noppakerho.com) 14.29.11 # tomers: "Some changes for brickmania" even with the flyspray number isn't very descriptive. It would be nice to describe what those changes were in the commit message 14.29.28 Quit shaggy-h (Ping timeout: 240 seconds) 14.33.15 Join robin0800 [0] (~quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 14.34.13 # gevaerts, thanks for the pointers about increasing the thickness of the CF card in my iPod mini, yesterday. Finally got it working and I can now enjoy a 2g 16gb ipod mini with Rockbox! :) 14.34.26 Join TheSeven|Mobile [0] (~theseven@rockbox/developer/TheSeven) 14.34.54 # excellent! 14.35.54 Quit Guest88353 (Ping timeout: 268 seconds) 14.36.00 Join dfkt [0] (dfkt@unaffiliated/dfkt) 14.36.48 # luckily I had two minis, cause I managed to break one :p 14.36.59 # but I only need one anyway ;) Thanks again. 14.37.23 Quit killan_ (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) 14.39.05 Join killan [0] (~nnscript@c-38fd70d5.06-397-67626721.cust.bredbandsbolaget.se) 14.39.15 # AlexP: I agree. Sorry for that 14.39.26 # no worries :) 14.40.42 Join Guest88353 [0] (~martian67@over.the.cat) 14.42.25 Quit stripwax (Quit: http://miranda-im.org) 14.42.42 Join funman [0] (~fun@rockbox/developer/funman) 14.44.43 # Unhelpful: thanks for the test, the IRAM might be disabled on clipv2, can you add a CGU_PERI |= (1<<25) before the test ? 14.45.07 # funman: i can later. :) 14.45.45 # the datasheet says it should be default enabled but perhaps they disable it and then enable it only in some use case 14.47.12 # still weird that nothing happens, i'd think the data abort mode would be entered 14.47.47 Join mirak_ [0] (~mirak@85-171-108-41.rev.numericable.fr) 14.49.07 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 14.54.25 Quit Guest88353 (Ping timeout: 268 seconds) 14.56.14 Join Guest88353 [0] (~martian67@over.the.cat) 14.57.17 *** Saving seen data "./dancer.seen" 15.00.59 Join kugel [0] (~kugel@rockbox/developer/kugel) 15.01.13 Quit kugel (Read error: Connection reset by peer) 15.01.23 Join kugel_ [0] (~kugel@e178088187.adsl.alicedsl.de) 15.01.29 Nick kugel_ is now known as kugel (~kugel@e178088187.adsl.alicedsl.de) 15.01.41 Quit kugel (Changing host) 15.01.41 Join kugel [0] (~kugel@rockbox/developer/kugel) 15.05.31 Quit Guest88353 (Ping timeout: 268 seconds) 15.06.37 Quit robin0800 (Remote host closed the connection) 15.06.56 Join Guest88353 [0] (~martian67@over.the.cat) 15.11.56 Quit funman (Quit: free(random());) 15.14.19 # * kugel grumbles at FS#11041 15.18.14 # it happened to me yesterday too, but not in the week of testing prior to committing 15.20.40 Join webguest [0] (~5563422f@giant.haxx.se) 15.20.59 # there seem to be more people than usual who can't reset their ipods :( 15.21.19 # would it be controversial to suggest we enable bootloader usb on ipod? 15.22.03 # on all pp please then :) 15.22.29 # Torne: I don't think there would be objections, it just wasn't needed yet 15.22.32 # i guess the only reason not to is size 15.22.36 # and sure, its' not technically needed 15.22.43 # but i think it would be easier for some people to recover from mistakes that way 15.23.01 # but with rockbox usb and the ability to completely replace the of (including bootloaders) there should be a bootloader recovery mode 15.23.04 Quit TheSeven|Mobile (Ping timeout: 240 seconds) 15.23.05 # is size really an issue on the usual pp targets? 15.23.11 # gevaerts: don't think so 15.23.21 # also, does bootloader usb always go into usb mode if the cable is inserted? 15.23.27 # because we probably don't want that on ipod 15.23.34 # for the same reason that usb isn't enabled in release builds 15.23.48 # it would be nice if it was just if the main binary was not loadable 15.23.54 # it happened to me once that I trashed my rockbox installation so that I needed e200tool to get it running again. that wouldnt be needed with bootloader usb 15.24.30 # there just seem to be a lot of people lately who can't reset their ipods 15.24.42 # yes, it's weird 15.24.46 # and i'm wondering if the reset keys are really as bulletproof as we claim 15.24.48 # :) 15.26.00 # so I definitely vote for it 15.27.06 # i assume that it does always go into usb mode, though 15.27.19 # which could be undesirable 15.27.54 # yes, that's the main problem 15.28.27 # i guess it shouldn't be too hard to arrange for it to only go into usb mode when it would otherwise display a boot failure message 15.28.36 # and maybe on a button press? dunno. 15.28.45 # both would be nice 15.30.11 Join Schmogel [0] (~Miranda@p3EE214B2.dip0.t-ipconnect.de) 15.30.22 # yah 15.31.03 # actually i guess you'd just have to patch out the check for usb connected on start? 15.31.17 # and leave usb insertion as it is 15.34.30 Quit tmzt (Ping timeout: 268 seconds) 15.36.39 Quit webguest (Quit: CGI:IRC) 15.43.46 # it would surprise me if my buffering commit had any impact on a 64MB device (FS#11041) 15.45.16 Quit Strife89 (Read error: Connection reset by peer) 15.54.38 # [15:21] but with rockbox usb and the ability to completely replace the of (including bootloaders) there should be a bootloader recovery mode 15.54.49 # you mean flashing the nor on older ipods? do we do that? 15.55.31 # no 15.55.48 # hrm, I think ipodpatcher offers some advanced installation procedure overcoming the of but it's not the default, sansapatcher has something similar 15.55.55 # but if you drop rockbox into OSOS then turninghold on to boot the OF won't get you the disk mode either 15.56.25 # holding the button combo should do so 15.56.51 # it would, except there seem to be quite a few people on the forums who can't reset their ipods 15.56.56 # and have great trouble as a result 15.57.23 # how would bootloader usb help there, if the ipod is stuck in a state where it's locked up and you can't reset it? 15.57.33 # or do you mean that the reset fails when the bootloader fails to load rockbox? 15.57.35 # because it's not stuck in such a state 15.57.43 # they just cocked up the install and don't ahve .rockbox on there 15.57.50 # but they now can't reset to get into disk mode 15.58.05 # one guy got it sorted by letting the battery run right down then turning hold on and connecting usb 15.58.59 # has anyone ever investigated how that reset works? 15.59.03 # don't know. 15.59.09 # we have always assumed it's "hardware" 15.59.16 # which is a great non-answer 15.59.26 # maybe someone knows, but i haven't heard :) 15.59.34 # on the nano2g it seems to be 100% bullet-proof, the clickwheel seems to signal the pmu that it should shut off the cpu's power for half a second 15.59.53 # as far as my experience goes it's 100% bullet proof on all the others as well 15.59.58 # but on the nano4g, there seems to be a way to inhibit a reset, ipod is doing that during a restore 16.00.06 # well, all the PP ipods 16.00.17 # but there seem to be people having trouble anyway 16.00.26 # previously they mostly went "oh right" when we told them to hold it down for longer 16.00.38 # but the last two or three occurrences on teh forums they just can't make it work 16.02.21 # anyway, my point was that there are cases wher bootloader usb might help, and i don't think there's much reason *not* to add it :) 16.02.54 Join tmzt [0] (~tmzt@99.164.34.42) 16.03.35 # * kugel thinks the use of size_t in buffering.c is generally wrong 16.05.02 Quit teru (Quit: Quit) 16.08.36 Quit tomers (Ping timeout: 252 seconds) 16.13.55 # New commit by 03kugel (r24790): Use a helpfer function to avoid ugly casting and correct some data types (no functional change). 16.18.17 Nick Guest88353 is now known as martian67 (~martian67@over.the.cat) 16.18.30 Quit martian67 (Changing host) 16.18.30 Join martian67 [0] (~martian67@about/linux/regular/martian67) 16.31.02 # TheSeven: Torne: I have *once* had an issue (nano2g) where the OF crashed and I couldn't reset it using menu+select, had to let the battery drain completely also (which didn't take too long actually as it froze on a full white screen with the backlight on ;) ). 16.31.22 # apart from that *one* time, the reset key combo has worked perfectly. 16.31.53 # hm, can one shut off the clickwheel power in the pmu? 16.32.06 # i haven't managed to do that yet at least... 16.36.10 Quit stoffel (Ping timeout: 256 seconds) 16.43.19 Join Blue_Dude [0] (~chatzilla@64.134.184.121) 16.45.17 # Can anyone confirm that r24782 fixed FS#11038? It seems to be OK now. 16.47.53 Join mt [0] (~mtee@rockbox/developer/mt) 16.49.15 # RE: Nano 1/2g Themes, the original of my Radiance theme had to go (copyright issues), so I'm guessing the guy that mixed it up and used all the art from the original's theme has to go too? I hadn't looked at the theme site in ages. 16.51.24 Quit petur (Quit: time!) 16.57.20 *** Saving seen data "./dancer.seen" 17.01.47 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 17.05.30 Quit dmb (Quit: No Ping reply in 180 seconds.) 17.07.03 Quit piotrekm (Quit: piotrekm) 17.07.07 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 17.09.49 Join dmb [0] (~dmb@unaffiliated/dmb) 17.19.28 Quit kugel (Ping timeout: 260 seconds) 17.21.44 Quit S_a_i_n_t (Quit: "PC Restart") 17.22.13 Join stripwax_ [0] (~Miranda@87-194-34-169.bethere.co.uk) 17.23.54 Quit stripwax (Ping timeout: 245 seconds) 17.25.05 Join marcol [0] (~4e6222cd@giant.haxx.se) 17.25.51 Quit marcol (Client Quit) 17.25.54 Join marcol [0] (~4e6222cd@giant.haxx.se) 17.26.45 Join tomers [0] (~chatzilla@bzq-84-109-85-100.red.bezeqint.net) 17.26.52 Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.5.8/20100202165920]) 17.28.36 # hi there 17.30.39 # TheSeven: r24725 breaks rockboy(stkov main) 17.31.50 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.10) 17.36.01 Quit simabeis (Quit: leaving) 17.36.08 Join simabeis [0] (~simabeis@lobmenschen.de) 17.37.30 Join CaptainKewl [0] (jds@207-237-117-89.c3-0.80w-ubr2.nyr-80w.ny.cable.rcn.com) 17.37.56 Join CaptainKwel [0] (jds@207-237-117-89.c3-0.80w-ubr2.nyr-80w.ny.cable.rcn.com) 17.38.34 Quit TucknDar (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 17.39.29 Join FOAD_ [0] (~dok@dinah.blub.net) 17.42.21 Quit CaptainKewl (Ping timeout: 272 seconds) 17.42.48 Quit FOAD (Ping timeout: 260 seconds) 17.42.48 Nick FOAD_ is now known as FOAD (~dok@dinah.blub.net) 17.43.54 Quit liar (Ping timeout: 245 seconds) 17.49.58 Join ecio1 [0] (~ecio@244-108.202-68.tampabay.res.rr.com) 17.51.49 Quit ecio (Ping timeout: 245 seconds) 17.54.05 Quit marcol (Quit: CGI:IRC) 17.54.58 Quit stripwax_ (Quit: http://miranda-im.org) 17.57.20 # liar: i already wondered whether that would happen, but as it didn't break pictureflow which is also prone to stkov's and i don't have any roms, i assumed it should work 17.57.53 # * TheSeven wonders why rockboy doesn't just allocate it's own stack from plugin ram if it needs more stack than everything else in rockbox 18.03.37 Quit fyre^OS (Quit: Ur skills' fireproof like a wooden panel -- U got feds talking leet on your IRC channel!) 18.05.39 # liar: could you have a look into this? 18.06.31 Join toffe82 [0] (~chatzilla@adsl-75-12-168-22.dsl.frs2ca.sbcglobal.net) 18.07.04 Join kugel [0] (~kugel@rockbox/developer/kugel) 18.07.20 # TheSeven: I think it's because plugins run within the main thread 18.07.58 # i can see no reason why it should need that much stack. it just *must* be possible to move something from the stack to the heap to fix this 18.08.15 # i really don't want to waste several kilobytes of iram because of rockboy 18.15.47 Join fleebailey33 [0] (fleebailey@unaffiliated/fleebailey33) 18.17.29 # btw: 4MHz improvement on vorbis, 11MHz on WMA 18.18.09 Quit Xerion (Ping timeout: 246 seconds) 18.34.12 Quit martian67 (Remote host closed the connection) 18.37.06 Join saratoga_ [0] (~463f90ed@gateway/web/freenode/x-gesbelhyftqbzrbe) 18.41.32 Join Adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 18.44.29 Join martian67 [0] (~martian67@about/linux/regular/martian67) 18.44.45 Join CGL [0] (~CGL@190.207.226.111) 18.48.23 Join toffe82_ [0] (~chatzilla@adsl-70-235-226-240.dsl.frs2ca.sbcglobal.net) 18.50.51 Quit toffe82 (Ping timeout: 260 seconds) 18.53.52 Join MaadMan [0] (~MaadMan@188-194-48-219-dynip.superkabel.de) 18.57.23 *** Saving seen data "./dancer.seen" 18.58.29 Quit AlexP (Remote host closed the connection) 18.58.56 Join AlexP [0] (~ap@rockbox/staff/AlexP) 18.59.48 Quit AlexP (Remote host closed the connection) 19.03.23 Join AlexP [0] (~ap@rockbox/staff/AlexP) 19.04.26 Quit toffe82_ (Remote host closed the connection) 19.08.43 Join flydutch [0] (~flydutch@host154-132-dynamic.15-87-r.retail.telecomitalia.it) 19.10.17 # TheSeven: the nano2g has a lot more IRAM we could use for codecs right? 19.14.03 Quit CGL (Remote host closed the connection) 19.18.24 Join CGL [0] (~CGL@190.207.226.111) 19.24.42 Join flyback [0] (~teac@c-98-219-129-239.hsd1.pa.comcast.net) 19.25.38 Join phanboy4 [0] (~benji@adsl-219-59-106.asm.bellsouth.net) 19.26.33 Join sudoman [0] (~d8ecfceb@gateway/web/freenode/x-lsjuxyvrzcudjtft) 19.28.08 Quit tomers (Quit: ChatZilla 0.9.86 [Firefox 3.5.8/20100214235838]) 19.28.15 Join toffe82 [0] (~chatzilla@adsl-70-235-226-240.dsl.frs2ca.sbcglobal.net) 19.28.29 # saratoga_: With some optimizations, we could give up to 128K to the codec 19.29.26 # TheSeven: that would be nice 19.29.33 # how much is available right now? 19.30.12 # currently it's a 64/96 split, but I don't know which way round 19.30.22 # the core easily fits into 64k though 19.30.47 # and some time ago i managed to squeeze it into 48k as well 19.32.24 # i got a nano2g now 19.32.34 # i should look at some codecs and see how much is really useful 19.33.00 # more then 80KB would certainly be nice, though i don't know if we need the full 128k 19.36.35 Join jordan` [0] (~jordan@78.235.252.137) 19.47.27 Join Xerion [0] (~xerion@82-170-197-160.ip.telfort.nl) 19.49.05 # can someone check if http://pastie.org/834425 builds fine (a manual patch)? 19.53.06 Join grndslm [0] (~grndslm@174-126-14-4.cpe.cableone.net) 19.53.36 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 19.54.39 # * kugel isn't able to install half a GB of latex stuff right now 19.55.14 # AlexP, pixelma. mc2739 ^ ? 19.57.46 Quit saratoga_ (Quit: Page closed) 20.01.03 # kugel: checking... 20.02.06 # everything ok :-) 20.02.42 Quit moos (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158]) 20.03.46 # great, which manual did you build? 20.04.44 # nano2g, pm'ed you a link to the pdf 20.04.44 # the change was under "4.3 While Playing Screen" in the e200 manual (4.3.3 to be precise) 20.05.01 # ah nice 20.05.31 # is this specific to e200? 20.06.42 # New commit by 03kugel (r24791): Playlist Viewer Changes to bring consistency: ... 20.06.45 # New commit by 03kugel (r24792): Update the manual according to the playlist viewer changes 20.06.49 # no, it's alright :) 20.07.09 # TheSeven: the numbers might be different on other manuals though 20.08.56 # hmm, is things like moving tracks now in the same submenu as the playlist viewer settings? 20.09.19 # the location of the playlist viewer settings changed 20.09.49 # it's now in the context menu (along with moving etc) 20.10.44 # I'm trying to imagine if I would expect it there 20.11.33 # where should it else be if not in the context menu? 20.11.46 # on the button which goes to the main menu everywhere else? 20.11.49 Join SeismicMike [0] (~seismicmi@adsl-76-235-41-169.dsl.dytnoh.sbcglobal.net) 20.12.35 # the context menu in the playlist viewer just dealt with the track you invoked it on, the viewer's settings are more general 20.12.38 # btw. does anybody know what the "m" (manual) option in configure is doing? 20.12.56 # i can't find any difference to "n" (normal) 20.13.08 # TheSeven: it's an old relict 20.13.14 # make will always do a normal build, and make manual will always build a manual... 20.13.16 # I'm eyeballing this Coby 4GB mp3 video player at Walmart.com for $30... does anyone know if Rockbox will run on it? 20.13.26 Join Buschel [0] (~ab@p54A3EBB4.dip.t-dialin.net) 20.13.26 # probably not 20.13.34 # see the list of supported devices on the front page 20.14.33 # there was a time where you didn't need "make manual" and could configure a manual target and just "make". It doesn't work anymore since the parsing of features.txt to options in the manual 20.15.12 Join HBK [0] (~hbk@HBK.broker.freenet6.net) 20.16.05 # I think the reason is rather the make remake 20.16.25 # btw, is there anyone who wants to start a nano4g port? 20.16.29 # it's not 20.16.57 # make always builds the first target in a make file. prior to the remake the makefile was generated, now it's not anymore (just a file that sets a few variables) 20.17.21 # maybe it stopped working before that though 20.17.33 Quit KBH (Ping timeout: 268 seconds) 20.17.54 # TheSeven: heh, yes! If you have time and a nano4g for me :p 20.18.07 # /data/rockbox-trunk/apps/plugins/lua/loslib.c: In function ‘os_exit’: /data/rockbox-trunk/apps/plugins/lua/loslib.c:176: warning: no return statement in function returning non-void 20.18.24 Quit MethoS- (Remote host closed the connection) 20.18.24 # why doesn't this yellow show up in the build table? 20.18.57 # kugel: http://svn.rockbox.org/viewvc.cgi?view=rev&revision=16304 20.19.19 Quit flydutch (Quit: /* empty */) 20.19.32 # TheSeven: you're building eabi with a newer compiler, right? I've seen this warning too but not under the default toolchain 20.19.47 # oh yes 20.20.14 # pixelma: ah, interesting. thanks 20.20.16 Quit Torne (Ping timeout: 240 seconds) 20.20.35 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 20.21.16 Quit amiconn (Disconnected by services) 20.21.17 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 20.21.26 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 20.21.27 Quit pixelma (Disconnected by services) 20.21.41 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 20.21.44 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 20.22.03 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 20.29.06 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 20.30.48 Quit Schmogel (Ping timeout: 272 seconds) 20.33.23 Join Torne [0] (torne@rockbox/developer/Torne) 20.33.25 Join Schmogel [0] (~Miranda@p3EE214B2.dip0.t-ipconnect.de) 20.35.11 Quit Buschel (Ping timeout: 264 seconds) 20.38.04 Quit Torne (Ping timeout: 245 seconds) 20.40.21 # New commit by 03kugel (r24793): Remove a few unused defines 20.41.02 Quit stripwax (Quit: http://miranda-im.org) 20.42.02 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 20.44.13 Join stoffel [0] (~quassel@p57B4E1EB.dip.t-dialin.net) 20.47.24 Join Torne [0] (torne@rockbox/developer/Torne) 20.48.00 # New commit by 03kugel (r24794): Fix up Fuze's radio keymap a bit. 20.49.20 Quit sudoman (Quit: Page closed) 20.49.39 Quit bmbl (Quit: Bye!) 20.53.08 Quit Torne (Ping timeout: 252 seconds) 20.56.28 # haha, I know see what a mess radio.c is 20.56.37 # it's really disturbing 20.57.17 Join toffe82_ [0] (~chatzilla@adsl-70-137-197-2.dsl.frs2ca.sbcglobal.net) 20.57.19 Quit toffe82 (Ping timeout: 260 seconds) 20.57.25 *** Saving seen data "./dancer.seen" 21.12.55 # It seems to me that rockbox just killed my beloved Cowon I7 :((( 21.14.33 # I made patched firmware with mktccboot, it updated, after that my cowon doesn't switches on at all 21.14.37 # wtf? 21.15.00 # /sorry for offtopic 21.15.34 # leavittx: yea, I can imagine that happens 21.15.42 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 21.16.02 # nobody is working on that port 21.24.13 # kugel: then what this target is doing in tools/configure? 21.24.33 # And is there any way to re-alive my i7? :) 21.24.54 Quit Kitar|st () 21.25.10 # it worked at some time 21.25.31 Join robin0800 [0] (~quassel@genkt-050-207.t-mobile.co.uk) 21.25.52 Quit stoffel (Remote host closed the connection) 21.26.20 # no idea how you could unbrick it 21.26.33 # but broken now. heavy broken 21.26.57 # leavittx: it's under "unusable", you shouldn't have been installing it in the first place 21.27.16 # I think that it will be good to remove this from tools/configure 21.27.29 # I don't see why 21.27.38 # it's clearly not our fault 21.27.42 # ok 21.27.57 # is there any info about this port? 21.28.31 # have you visited our site at all? 21.29.04 # http://www.rockbox.org/wiki/CowonIaudio7Info 21.30.26 Join phanboy_iv [0] (~benji@c-24-98-43-198.hsd1.ga.comcast.net) 21.30.36 # Sad, sad, sad 21.30.41 # you can run rockbox on the i7 without installing it using ttctool 21.30.47 # i think thats what you are supposed to do 21.31.00 # you could probably use that now to put the OF back and fix your player 21.31.14 # but i don't know how, or even if anyone has done it 21.31.35 # "Flashing: The OF does the flashing, so a bad flash will ruin the player until we figure out how to do the USB boot mode properly." 21.31.54 # i suggest reading through the i7 and d2 info 21.32.17 # TheSeven: he hasn't read it prior to installing 21.32.31 # damn on me 21.32.58 # rb on my cowon d2 works so perfectly, so... 21.33.54 Quit phanboy4 (Ping timeout: 245 seconds) 21.35.14 # i still think you should be able to fix it with tcctool 21.35.35 # the dfu mode thing probably doesn't need an intact OF, otherwise it would be pretty useless 21.36.40 Quit toffe82_ (Ping timeout: 272 seconds) 21.37.08 # TheSeven: hilariously the sandisk connector fits nicely into a nano2g 21.37.11 # although it doesn't break it 21.37.29 # at least not if you only do it for a couple seconds :) 21.38.01 # have you checked the pinout? 21.38.05 # might it be even compatible? ;-) 21.39.11 # no they're definitely not compatible 21.39.21 # putting a sansa into an ipod cable bricks it 21.40.21 Join Kitar|st [0] (Kitr88@BSN-142-86-131.dial-up.dsl.siol.net) 21.41.57 # saratoga: i tried to run ./tcctool -d iaudio7 ../../i7_boot/I7_FW.BIN 21.42.00 # not helped 21.42.12 # it says Ensure your TCC device is in USB boot mode and run tcctool again. 21.42.20 # how do i do this? 21.43.00 # "USB Boot Mode: The iAudio7 has a USB boot mode, you can enter it by holding down the 'mode' button while plugging in the USB connector. The Vendor/Product id changes to a TCC specific pair (Vendor=140e ProdID=b021), it is then possible to upload code to the device via tcctool (source available in svn tree: http://svn.rockbox.org/viewvc.cgi/trunk/utils/tcctool/ ). " 21.43.03 # see the wiki... 21.44.55 Join m3dlg [0] (~m3dlg@212.183.140.51) 21.47.45 Join mitk [0] (~tomekk@chello089078013146.chello.pl) 21.48.04 # leavittx: like I said I have no idea how to do this . . . 21.48.36 Join hebz0rl [0] (~hebz0rl@dslb-088-065-062-030.pools.arcor-ip.net) 21.49.31 Quit S_a_i_n_t (Quit: There are 10 types of people, those who understand binary, and those who don't.) 21.51.10 # damn, my nano's lcd controller is dying 21.51.22 # it's getting more and more bad GRAM cells 21.51.26 Quit m3dlg (Ping timeout: 252 seconds) 21.52.38 Join m3dlg [0] (~m3dlg@212.183.140.51) 21.53.14 # New commit by 03kugel (r24795): Quickscreen for the radio screen. I added a keymap for almost all targets. I couldn't find a nice one (i.e. one that's consistent with the wps/menu ... 21.58.50 # TheSeven: time to work on the 4g port ;) 21.59.53 # heh we have no recent PP ipod battery benchs 22.00.30 # TheSeven: I feel like an absolut noob, BUT what is the 'mode' button? 22.02.13 # leavittx: everybody here is as clueless as you are... 22.02.36 # leavittx: I've never even seen an i7, i just read what the wiki says 22.02.40 # you're probably the only one in this channel thats ever seen an i7 22.03.25 # but there is no such button 22.03.45 Quit robin0800 (Remote host closed the connection) 22.04.19 # there are power+hold button, menu, +, -, and some sensor buttons. Also reset. 22.05.22 # try all 22.06.45 # did you check google? 22.06.45 # already ;) 22.06.48 # yep 22.06.52 # nothing 22.06.52 # theres lots of guides to fixing bad flashes 22.06.55 # none of them worked? 22.07.07 # no, I tried only tcctool 22.07.33 # http://iaudiophile.net/forums/showpost.php?p=231920&postcount=1 22.07.33 # I can't get to USB boot mode 22.07.44 # this one says to use the "mode/menu" button 22.07.47 # did you try that 22.08.06 # hmm, I think, yes 22.08.33 # apparently a few other people have fixed this problem, maybe you could try asking one of them 22.08.38 # I wonder if it makes sense to transform the preset list into a playlist 22.08.53 # to enable saving, moving things around, other funny stuff 22.09.00 # also, what is the issue with supporting 240GB players in standard builds? 22.09.14 # saratoga: I guess binsize... 22.09.39 # didn't zagor and amiconn talk about it recently? i remember seeing it in the logs 22.09.41 # surely thats not a serious problem on the ipod video or gigabeats 22.10.21 # saratoga: you know that some rockbox devs just get crazy when someone pulls their binsize trigger :-) 22.11.19 # binsize is important but it needs to be considered in context 22.14.44 # shouldn't the recent font stuff go into MajorChanges 22.18.37 Quit Omlet (Read error: Connection reset by peer) 22.20.26 Join Omlet [0] (omlet05@119.159-241-81.adsl-dyn.isp.belgacom.be) 22.22.48 Quit m3dlg (Ping timeout: 260 seconds) 22.25.19 # http://www.mediafire.com/file/1zwetvuzmdy/nano2g_test_codec_results.pdf 22.25.28 # eabi seems to have a rather weird impact... 22.26.30 # saratoga: thanks, this helped me a little. Now what do i do after this message from tcctool: "[INFO] Patching application uploaded successfully!" ? How to says "copy 3 firmware files onto your i7 root folder" but how do i access root forder? 22.27.11 # look i have no idea 22.27.13 # stop asking me 22.27.25 # =) 22.27.59 # TheSeven: do you have a script for parsing the test_codec files? 22.28.02 # i was just about to write one 22.31.07 # saratoga: a trivial 5-liner 22.31.17 # i should write a proper one 22.31.22 # the rest was openoffice magic :-) 22.32.06 # ok i'll do it now then 22.32.12 # this is easy in perl 22.32.33 # New commit by 03kugel (r24796): Factor out some drawing code. 22.32.53 # TheSeven: I don't think eabi has much impact 22.32.59 # I would blame the compiler version 22.33.11 # it has been reported that 4.4.x doesn't work well on arm 22.33.32 # it isn't always worse, it's also better on some codecs 22.33.40 # ape is funny ;-) 22.33.46 # the results aren't much different except for mpc which is a little better 22.33.47 # sorted it properly: http://www.mediafire.com/file/mdtt12nz0yq/nano2g_test_codec_results.pdf 22.34.00 Quit CGL (Remote host closed the connection) 22.34.37 # the lower ape compression levels are faster on eabi, the higher compression levels are slower 22.35.05 # do we actually want to show this: 175906 of 175906 | Decode time - 36.43s | File duration - 175.90s 22.35.11 # seems like we could cut that out of the wiki 22.35.13 # low is better? 22.35.27 # yes, it's the mhz value 22.35.43 # yea, expected w.r.t to the eabi toolchain 22.36.06 # seems so 22.36.08 # generally: flac performs much worse, others vary within +-2% 22.36.33 # I really want to try 4.4.3 and the last 4.3.x release 22.37.00 # and some other compilers also :) 22.37.45 Quit phanboy_iv (Read error: Connection reset by peer) 22.38.03 # * TheSeven wonders if it would be worth the effort to 1) add the device, build type and revision to the test-codec output, 2) make a website where one can upload the logs, 3) make an analyzer tool for the gathered results :-) 22.38.13 # feel free to add your results to CodecPerformanceComparison 22.38.33 # kugel: the code sourcery gcc branch is supposed to be better for arm then stock 22.38.43 # I heard that too 22.39.20 # I would also like to try that other compiler that blog (forgot the names) mentioned 22.39.23 # kugel: I think that many results get lost because most people are too lazy to work out how this weird wiki works... 22.39.44 # I wonder how much effort you need to compile rockbox with a non-gcc-like compiler 22.39.56 # and if you do a full test_codec, copying and pasting all the values will take quite a lot of time 22.39.57 # TheSeven: almost got a perl script together for that 22.40.46 # especially msvc for targeting windows mobile with raap 22.40.53 Join toffe82 [0] (~chatzilla@adsl-70-137-199-73.dsl.frs2ca.sbcglobal.net) 22.41.51 # might not even be worth trying looking at windows phone 7 (I heard it only accepts managed .net apps) 22.42.25 Join pamaury [0] (~pamaury@sal63-1-82-243-96-220.fbx.proxad.net) 22.42.26 # TheSeven: the nano2g is pretty slow it seems? samsas have better results 22.42.32 # windows moble is a hard target because of all the annoyances of working with gnu stuff on windows 22.47.15 Join Torne [0] (~torne@rockbox/developer/Torne) 22.47.59 # kugel: not much cache, slow IRAM 22.48.24 # uncached iram accesses seem to need 2 cycles, even if the result is just thrown away 22.48.31 # I think the samsas have less cache and even slower iram 22.48.50 Quit AlexP (Remote host closed the connection) 22.48.56 # and test_codec is of course running at the full cpu speed 22.49.01 # 2x8k and the iram is basicallly as fast as the dram 22.49.04 # it might be more efficient when it isn't boostig 22.49.13 # boosting* 22.49.36 # (because it will run in fastbus mode then, while it is running in asynchronous mode when it needs to hurry) 22.49.42 # what cpu is in the nano2g? 22.49.47 # ARM940T 22.49.54 Join AsaelReiter [0] (~d44c72e0@giant.haxx.se) 22.49.56 # TheSeven: http://pastebin.com/m1538eb51 22.50.14 # takes 1 or 2 test codec results and will either compare them or just print one, either way formatted for the wiki 22.50.45 # so it's 2x4k cache only 22.51.21 # TheSeven: we use synchronous mode, that might make a difference. arm docs say asynchronous imposes performance penalties for synchronizing 22.51.50 # ok, that's less cache, I guess that's it 22.52.26 # i couldn't make out any real differences in the docs between sync and async mode, the penalties seemed to rougly the same if it's running at an int multiple anyways 22.52.27 # a ldr should still only take 1c on all arm9 IIUC 22.52.34 # (with result delay) 22.52.43 # the problem is just that it immediately locks up if i switch it to sync mode, no matter what 22.53.02 # haven't yet found out why (1:4 factor between the clocks) 22.53.17 # if the arm bus and the memory bus don't have an integer relationship, then there pretty much has to be 1 clock delay 22.53.51 # firing semi-random ldrs one after another, 256 of them in a loop takes ~520 clocks with caches disabled and the accesses hitting iram 22.54.16 # (CPU at 192MHz, bus at 96MHz, async mode) 22.54.32 # ah we run at 248, another reason 22.54.43 # bus at 62 22.54.45 # that shouldn't affect the mhz values though 22.55.19 # actually your bus to cpu ratio is worse, so the ipod should be better 22.57.27 *** Saving seen data "./dancer.seen" 22.57.38 # the IRAM on the AMS players is really slow 22.57.43 # its basically just DRAM 22.57.49 # so performance is more like the gigabeat F 22.58.23 # TheSeven: every target does worse it seems. PP is so fast compared to other arm targets looking at codec performance 22.58.55 # PP needs 10MHz less than samsa for vorbis, for example 22.59.12 # I think that's because the iram is as fast as the caches 23.00.08 Quit mitk (Quit: Ex-Chat) 23.01.15 # PP's custom IRAM implementation makes a huge difference 23.01.25 # since it makes memory accesses basically free for most codecs 23.03.10 # D2 should probably be faster then PP if it really has SRAM and armv5e 23.03.10 Quit AsaelReiter (Quit: CGI:IRC (EOF)) 23.03.17 # though i heard we don't use the IRAM yet 23.09.02 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 23.10.16 Join AlexP [0] (~ap@rockbox/staff/AlexP) 23.10.37 # saratoga: The main problem with supporting those 240GB disks is the large sector mess 23.11.07 # New commit by 03bluebrother (r24797): If the Ipod has been recognized as MacPod always consider no bootloader installed. 23.11.09 # New commit by 03bluebrother (r24798): Update an outdated comment. 23.11.15 # New commit by 03bluebrother (r24799): Recognize and handle MacPods during autodetection. ... 23.11.51 # Torne: The PP based ipods *can* apparently reach a state where reset doesn't work, but this is rare 23.12.04 # I had this happen once on my Mini G2 23.12.12 # hm 23.12.14 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 23.12.19 Quit bluebroth3r (Ping timeout: 276 seconds) 23.12.24 # that shouldn't be happening for people who have just forgotten to put .rockbox on the player though 23.12.41 # Letting the battery run down helped (took a few days) 23.13.07 Quit AlexP (Remote host closed the connection) 23.13.14 # This only happened once, among probably hundreds of times I had to reset the ipod for various reasons 23.14.20 Join m3dlg [0] (~m3dlg@bb-87-81-252-83.ukonline.co.uk) 23.14.47 Join robin0800 [0] (~quassel@genkt-057-078.t-mobile.co.uk) 23.14.47 # Normally, if the reset doesn't work first time, it helps to flip the hold switch, flip it back, and try again 23.15.29 Quit hebz0rl (Read error: Connection reset by peer) 23.15.55 Join AlexP [0] (~ap@rockbox/staff/AlexP) 23.15.57 Join anewuser [0] (anewuser@unaffiliated/anewuser) 23.17.38 # TheSeven: hrm, ldr on arm9tdmi is supposed to be 1c... 23.19.39 # it looks like the build system got slower after attaching my client 23.19.40 # possibly not if the bus is slower and it's getting swamped with them? (every single instruction in that loop was an ldr) 23.19.42 # although perhaps when async it can't actually fetch every cycle? 23.20.56 Quit robin0800 (Remote host closed the connection) 23.22.36 Join Buschel [0] (~ab@p54A3FA48.dip.t-dialin.net) 23.22.40 # TheSeven: hrm, what if you interleave w/ nops? i bet it stays about the same... 23.23.10 Join CGL [0] (~CGL@190.207.226.111) 23.26.46 # New commit by 03kugel (r24800): Correct ActionFMPreset manual entry for the Fuze. 23.29.09 # gah, we really need to generate those button maps from the actualy source files :( 23.32.15 # Unhelpful: the ARM9TDMI load/store unit adds one cycle of latency 23.32.28 # that doesn't mean the bus and DRAM accesses are free however 23.33.05 # (if thats what you were asking) 23.33.39 Join petur [0] (~petur@rockbox/developer/petur) 23.37.24 Quit kugel (Remote host closed the connection) 23.40.23 Quit pamaury (Quit: abort();) 23.40.30 Join hebz0rl [0] (~hebz0rl@dslb-088-065-062-030.pools.arcor-ip.net) 23.42.42 Quit AlexP (Ping timeout: 240 seconds) 23.43.57 # TheSeven: Did your back-to-back ldr instructions use different destination registers? 23.44.54 Join AlexP [0] (~ap@rockbox/staff/AlexP) 23.46.57 # New commit by 03bluebrother (r24801): Add missing class prefix to logging call. 23.47.00 # New commit by 03bluebrother (r24802): Be more strict when when resolving devices and allow hfs too. ... 23.48.44 # amiconn: not sure, probably not 23.48.52 # amiconn: not sure, probably not 23.51.24 Quit m3dlg (Ping timeout: 245 seconds) 23.52.05 # I'm not sure, but using the same destination register might also cause an interlock. Alternating between two destination registers should be enough 23.52.24 # ..to avoid that 23.54.56 Quit Buschel ()