--- Log for 19.05.104 Server: anthony.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16p1 Started: 3 days and 6 hours ago 00.04.50 # This is of course a start. 00.05.34 # The idea behind my search: 00.06.28 # Without the library approach, one has to include the source of e.g. grayscale framework to use it. 00.06.51 # hence the library 00.07.07 # If he does so, he can throw out functions that are not needed to save space (the plugin space is only 32 KB after all) 00.07.55 # If all this is put into the library, the whole framework is static, so all functions are included even if only a couple of them are used. 00.08.02 # i know all this 00.08.24 Quit AciD ("Il vaut mieux douter de ses certitudes que d'être sur de ses doutes.") 00.09.04 # The whole grayscale framework is rather large (for a total 32 KB of available ram) 00.11.52 # Another thing that I could not yet solve in a clean way - the framework needs a pointer to the plugin api structure 00.12.19 # How can I supply this without relying on specific variable names? 00.15.10 # why not rely on variable names? 00.17.37 # The only way I got this to work (well at least compile without errors) is defining the variable within library code (grayscale.c) and then referencing that *in the plugin* by declaring "extern struct plugin_api* rb;" 00.17.43 # This is dirrrty.... 00.18.16 # why is it so dirty? 00.18.35 Join midk [0] (mk@ACC364FC.ipt.aol.com) 00.18.57 # hi evb 00.19.03 # hi 00.19.13 # LinusN: All hell would break loose if either (1) the plugin author forgets to declare it "extern" or (2) wouldn't call it "rb" 00.19.39 # so he would have to correct his mistakes...so what? 00.20.11 # it's no different from relying on specific function names imho 00.20.57 # hmm, with the makefile isn't there a way to "make plugins"? 00.21.00 Join top_bloke [0] (~ekolb_pot@0-1pool36-14.nas12.oakbrook1.il.us.da.qwest.net) 00.21.04 # i thought this could be done a while ago 00.22.21 # Imho this is simply unintuitve and bad style, much like having code in .h files, because although the variable is declared in grayscale.c, it has to be set in the plugin code, without an obvious hint that this is necessary 00.22.56 # amiconn: was the grayscale framework ever going to be placed in rockbox itself, or just plugins? 00.22.58 # (of course I could add a check to *every* function...) 00.23.39 # midk: Until now there are no plans to place it in the core 00.24.05 # i was going to try some grayscaled status bar icons / dir browser icons 00.24.07 # how about having a xxx_init(struct plugin_api *rb) function for each framework? 00.24.25 # grayscaled progressbars and peakmeters would be pretty cool 00.24.44 # the grayscale framework will not end up in the core code 00.25.03 # so basically no core grayscale? 00.25.10 # exactly 00.25.17 # linusn is such a party pooper. :) 00.25.30 # that's me 00.25.35 # jk 00.26.54 # LinusN: How would that xxx_init() be called? Do you think of it as a convention, or is there a way to automate it? 00.27.36 # a convention 00.33.50 # Hmm. Either this way, or every framework declares a struct plugin_api *xxx_rb variable, which has to be set by the plugin by convention 00.34.09 # (same approach, only without the need for an extra function) 00.34.20 # i like the init function better, since many frameworks may still need one for other reasons 00.34.33 # setting up frame buffers etc 00.35.02 Join Strath [0] (~mike@dgvlwinas01pool0-a213.wi.tds.net) 00.36.08 # Agreed. 00.36.58 # The grayscale framework actually has some kind of init function, but it can be called multiple times (after previous de-initialization), and needs a number of parameters 00.37.22 # So this one cannot serve as the framework init 00.40.15 # LinusN: Another qn concerning conventions: 00.41.46 # How to name the functions to avoid name clashing? Shall we establish a convention to call the xyz_ within the "xyz" framework? 00.42.20 # Should internal functions be named the same way, or would _xyz_ be more appropriate? 00.44.37 # "internal" == static? 00.46.18 # Does using "static" hide that function from the symbol table of the lib? 00.46.34 # (I always wondered waht "static" does for functions...) 00.46.40 # *what 00.47.01 # want the static lesson? 00.48.42 # I know what it does for variables within functions, but... 00.48.50 # static always hides the symbol 00.49.16 # when you declare a local variable static, it becomes global, but with a hidden symbol 00.49.39 # the same mechanism applies to variables/functions in a global scope 00.50.18 # Ahh 00.52.17 # So if I use static for a function, that function is only visible from within the module? The of course that part of the problem didn't ever exist. 00.52.24 # *Then 00.52.48 # exactly 00.53.03 # The other part (naming functions for public use) still does 00.53.14 # i like the prefix 00.53.28 # grayscale_xxx() 00.53.33 # or maybe gs_xxx() 00.54.12 # So I think I will rename the framework files to gray.c and gray.h. Every function will have a gray_ prefix (most of them already do) 00.54.34 # sounds ok 00.55.13 # Shall I commit the Makefile? Bagder didn't do it yet, but only posted it on the ml for testing 00.55.36 # i am working on it now, i'll commit it soon 00.55.52 # Already added my changes? 00.55.57 # yes 00.56.18 # working on the dependencies 00.56.24 # tricky 00.56.43 # yup. As I called it, makefiles are magic ;) 00.56.53 # not magic at all 00.58.03 # lol 00.58.40 # Oh? Make files, you mean the magic things that just let me blindly type make install? Then have shiney new stuff(tm) on my computer? 00.58.52 # s/Make files/makefiles/ 00.58.57 # kaboofa: yes 00.59.13 # the principle is sooooo simple 00.59.18 # I know. 00.59.34 # <3 /usr/ports/make search name=softwareTomWants 01.01.13 Quit top_bloke (Read error: 54 (Connection reset by peer)) 01.03.17 # oh wow 01.03.25 # i just found out something evil that my history teacher did. 01.03.32 # ooh 01.03.34 # let's hear. 01.03.36 # OK! 01.04.08 # We had this mock trial thing, it was 'right after vietname war' and captian ernest medina was on trial. 01.04.21 # yeh yeh get to the good stuff 01.04.42 # We (meaning myself and everyone else on the jury) found him innocent, the procecution didn't prove their point. 01.05.10 # Everyone on the procecution got a 64 as a test grade :X 01.05.13 # one point below passing. 01.05.37 # Everyone on the Defence got like a 115 or some insane crap 01.06.27 # AHAHAHAH 01.07.08 # Hmm, need to grep for the charger for my mobile... the battery is about to die ;\ 01.07.22 # dude tight. 01.08.03 # hmmm 01.08.20 # found the charger for my archos... not the right voltage, but the right idea... 01.08.38 # kaboofa: recorder or studio? 01.08.39 # if i find out who took me phone cable i'm going to rip out their trachea! 01.08.40 # :D 01.08.44 # midk: recorder 01.08.45 # lol 01.10.51 # what keeps messing up my /etc/resolv.conf 01.10.55 # this is really getting to me 01.11.16 # its me 01.11.18 # *stops hacking 01.11.49 # I think it's cron 01.12.48 # Hmm 01.12.50 # it's not cron 01.13.07 Quit midk (Read error: 104 (Connection reset by peer)) 01.13.29 # :( 01.14.34 Join midk [0] (mk@172.142.90.139) 01.18.06 # amiconn: makefile changes committed 01.18.51 # Nice. 01.19.10 # *forcefully reminded of LinusN after he tried breakout 01.19.37 # midk: i am considering exporting button_read() to the plugins 01.19.38 # I already have a "void gray_init(struct plugin_api *rb)" function. 01.19.45 # yay 01.19.53 # erm 01.19.56 # button_read? 01.20.14 # raw key reading, no queues and shit 01.20.36 # no button stackup? 01.20.43 # LinusN: If you do, please add font_get() on the go, so this doesn't require an extra version bump. 01.20.43 # exactly 01.20.47 # YAY 01.21.05 # one caveat, though 01.21.07 # also is button_set_repeat getting put in? 01.21.29 # the button driver will still send key events to the queue 01.22.04 # so you still need a loop to get all the key events, but you can throw them away 01.22.29 # and that's what i'm good at. forgetting the user. 01.22.33 # ah just to keep them from getting buffered? 01.23.18 # midk: exactly 01.23.29 # sounds ok 01.23.35 # i think i may be able to handle that 01.23.59 # the drawback is of course that you have to handle everything yourself, key repeat, button up/down etc 01.24.18 # in your case, it shouldn't be any problems at all 01.24.24 # erm wait? 01.25.30 # LinusN: The xyz_init() approach is indeed very good, because I can check later in gray_init_buffer() if rb is already set. 01.25.59 # why? 01.26.04 # LinusN: so... can you tell me what really needs to be done differently with this button_read function 01.26.31 # If it is not, the grayscale buffer won't get initialized, which in turn is checked by the graphics routines. 01.26.33 # midk: button_read() merely returns the current status of the buttons 01.26.50 # amiconn: and what does it do if it isn't set? 01.27.20 # linusn: as opposed to button_get_w_tmo...? 01.27.31 # i mean, is there a point in wasting code space and cycles on looking for programming mistakes? 01.27.46 # It simply returns zero, like for any other error. 01.27.57 # amiconn: yes, but why? 01.28.51 # midk: button_get_w_tmo() gets the next message from the queue, not the current button status 01.28.52 # It cannot initialize the grayscale buffer, because for that it needs rb-> functions itself. It would crash badly if that isn't set. 01.29.00 # so just 01.29.08 # amiconn: then let it crash 01.29.11 # switch(rb->button_read) and going on like normal will do? 01.29.37 # midk: when i think of it, it's not that simple... 01.30.12 # amiconn: my point is: why check for programming mistakes in runtime? 01.31.03 # once the programmer fixes the bug, the check only wastes memory and cpu 01.31.09 # LinusN: Why do you check bounds in the core graphics routines? 01.31.54 # (As it is now, without clipping support I mean) 01.32.05 # good point 01.32.16 # ;) 01.32.43 # AHAHAHA 01.32.48 # coolies. 01.33.47 # I think *some* check should be done to avoid bad crashes. Of course I wouldn't check everything. 01.34.22 # erm 01.34.31 # did i just yell "ahahahaha coolies" 01.34.37 # ...why? 01.37.11 Join Blacklabelskater [0] (~chatzilla@rdu74-175-250.nc.rr.com) 01.37.19 # sup 01.39.06 # amiconn: afaics, only lcd_bitmap() does a bounds check 01.39.40 # hi 01.39.54 # LinusN, I have quick question for you 01.39.59 # shoot 01.40.13 # with your rs232 01.40.23 # can't i use exteral power? 01.40.31 # instead of voltage regulator? 01.40.36 # http://rockbox.haxx.se/mods/rs232.html 01.40.42 # of course you can 01.41.29 # i only did that to make it compact and simple 01.41.35 # ok 01.41.39 # poopy 01.41.56 # so.... just connect Vcc from 3.3 source and just ground it? 01.42.21 # but what about DTR? where do i connect that? 01.43.42 # or, just connect Tx, Rx, GND without DTR? 01.43.56 # dtr is the voltage source for the regulator 01.44.51 # ok.... I'm using this powersupply which I can adjust to any voltage 01.45.00 # then you don't need dtr 01.45.04 # cool 01.45.11 # LinusN: lcd_update_rect, lcd_roll, lcd_putsxyofs, lcd_drawrect, lcd_invertrect do bound checks as well. Within lcd_putsxyofs it isn't even necessary. 01.45.35 # wow 01.46.21 # (Since lcd_putsxyofs uses lcd_bitmap for drawing, which does check for itself) 01.46.38 # some of these checks may be good, because the coordinates may come from a bad font file 01.47.05 # and the clipping will of course change the situation 01.47.45 # i'm normally against runtime checks of programming mistakes (remember the xor discussion in the recording code?) 01.47.54 # yup 01.48.10 *** Saving seen data "./dancer.seen" 01.48.30 # The check in lcd_putsxyofs does only check if the line would go past the lower display margin, which isn't necessary, as lcd_bitmap would already clip there -> partial last line is already possible with text 01.48.38 # especially when it's the same programmer (or programming team) that writes all code 01.49.33 Join midknight2k3 [0] (mk@AC8E5A8B.ipt.aol.com) 01.49.37 # can it clip the entire blit? i mean, can the entire bitmap be off screen? 01.49.49 # (I only counted checks that are pure bound checks, not ones that are necessary for the function's behaviour) 01.49.52 Quit midknight2k3 (Remote closed the connection) 01.50.21 # LinusN: See lines 475-476 in lcd-recorder.c 01.51.30 Quit mecraw_ ("Trillian (http://www.ceruleanstudios.com)") 01.51.39 # And no, this wasn't added by me. 01.53.36 # lcd_bitmap does not yet support negative coordinates though, but it shouldn't be hard to add. For x it is _very_ easy 01.55.08 # good 01.55.19 Quit midk (Connection reset by peer) 01.55.54 # get working on the grayscale lib now, the daily builds are red when there is no code to build in plugins/lib :-) 01.56.35 # i have to sleep now, good nite 01.56.50 # jakesir: good luck with the rs232 01.57.12 Part LinusN 01.57.30 # I should probably update to uh.. daily.. cvs 01.57.33 # or something or other 01.57.39 # so my plugins run again. 01.59.18 # * kaboofa goes off to listen to aphex twin, and to update his bulids 02.02.53 Join midk [0] (mk@ACC24589.ipt.aol.com) 02.04.39 Quit BlueChip (Read error: 60 (Operation timed out)) 02.06.16 Join BlueChip [0] (~bluechip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com) 02.06.44 # http://www.freewebs.com/midknight2k3/rockbox.JPG 02.07.01 # woah 02.07.05 # what is that thing? 02.07.08 # that's awesome 02.08.04 Join sunpower [0] (solaris@pool-151-196-54-17.balt.east.verizon.net) 02.08.14 # lol 02.08.16 # a watch? 02.09.28 Quit jakesir (Read error: 104 (Connection reset by peer)) 02.10.16 Quit midk (Read error: 104 (Connection reset by peer)) 02.17.31 Part amiconn 02.59.52 Quit Nibbler (Read error: 104 (Connection reset by peer)) 03.48.12 *** Saving seen data "./dancer.seen" 04.20.21 Join Nibbler [0] (nibbler@port-212-202-78-119.dynamic.qsc.de) 05.05.26 Join asfafds [0] (~lkpo3@24.174.133.27) 05.05.27 Quit kaboofa (Read error: 104 (Connection reset by peer)) 05.05.35 Nick asfafds is now known as mharmon (~lkpo3@24.174.133.27) 05.05.40 # is anyone around for questions? 05.07.14 Quit mharmon (Client Quit) 05.12.36 Join midk [0] (mk@172.195.89.124) 05.15.38 Quit midk (Read error: 54 (Connection reset by peer)) 05.21.36 Join midk [0] (mk@AC806A3C.ipt.aol.com) 05.44.12 Quit midk (Read error: 104 (Connection reset by peer)) 05.48.13 *** Saving seen data "./dancer.seen" 05.51.11 Join midk [0] (mk@AC9E6129.ipt.aol.com) 06.00.13 Join scott666_ [0] (~scott666@c-24-245-59-203.mn.client2.attbi.com) 06.00.14 Quit scott666 (Read error: 54 (Connection reset by peer)) 07.08.19 Quit Nibbler (Read error: 54 (Connection reset by peer)) 07.29.01 Join resc [0] (~tgs@smitht-01.res.carleton.edu) 07.35.05 Join amiconn [0] (~jens@pD9E7E869.dip.t-dialin.net) 07.36.23 # ami. 07.40.26 Quit resc ("meh") 07.48.18 *** Saving seen data "./dancer.seen" 08.40.35 Join Nibbler [0] (nibbler@port-212-202-78-119.dynamic.qsc.de) 08.58.30 Quit Nibbler (Read error: 54 (Connection reset by peer)) 09.24.15 Join AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) 09.34.43 Quit AciD (Read error: 54 (Connection reset by peer)) 09.48.19 *** Saving seen data "./dancer.seen" 09.48.43 Join amiconn_ [0] (~jens@pD9E7F17F.dip.t-dialin.net) 09.53.58 Quit adi|home (Client Quit) 09.57.15 Quit amiconn (Read error: 60 (Operation timed out)) 09.57.16 Nick amiconn_ is now known as amiconn (~jens@pD9E7F17F.dip.t-dialin.net) 10.01.22 Join adi|home [0] (~adi|home@as5300-9.216-194-23-16.nyc.ny.metconnect.net) 10.40.53 Join Nibbler [0] (nibbler@port-212-202-78-119.dynamic.qsc.de) 10.51.54 # nite all 10.52.09 Quit midk ("its NITE") 10.53.37 Join Bagder [241] (~dast@labb.contactor.se) 10.53.49 # hi Bagder 10.53.55 # hi 10.54.00 # thought I'd better drop in ;-) 10.54.38 # I've seen that you were a bit impatient to get rid of the red builds ;-) 10.54.48 # hehe, yes 10.55.01 # but I'll keep my fingers away now 10.55.22 # I had already prepared the grayscale library inernally, and renamed it as discussed with Linus. 10.55.39 # Originally I wanted to do some tests before committing 10.56.06 # sorry for bursting in like that, I should've joined here first 10.56.42 # Btw: the jpeg plugin now produces two warnings. This is because not everything in the grayscale lib is really public 10.56.57 # So I will switch to gray.h, then it should go away 10.57.13 # May I delete grayscale.(c|h) from lib? 10.57.16 # feel free to clear up my mess 10.59.32 # There is a third plugin using grayscale - mandelbrot.c. I really would like to change that in the evening in order to be able to do some tests. 11.01.09 # (I can't do tests atm because I left my usb cable at home - special one for recorder v1) 11.02.26 # take your time, I'll refrain from ruining this anymore for a while ;-) 11.02.32 Join limbus [0] (~manuel@kernel.cycos.net) 11.03.50 # Grr, I cannot change jpeg.c to simply use gray.h, since it uses sizeof(tGraybuf), which is private to the grayscale lib... 11.04.24 # well, perhaps you can export a function or variable thay provides the size? 11.05.14 # Yes, this is something I've already planned, but not yet done. 11.10.44 # Bagder: Please see the irc log for plugin library issues I've discussed with Linus (Especially the necessity of an xyz_init() function) 11.15.35 Join cjnr11 [0] (dfd@bobillot-5-82-224-193-23.fbx.proxad.net) 11.15.40 Part cjnr11 11.16.58 # well, since the plugin library can provide pretty much anything, I guess *init() functions should be provided for those areas that need them 11.27.12 # Hi Badger: I see some patches are moving into cvs. nice. 11.28.14 # foot time! 11.28.19 # food even 11.28.22 # Bagder: This is of course clear, but one thing will be almost always needed - the plugin api pointer. This should be done with a xyz_init(struct plugin_api *) function by convention 11.28.40 # good point 11.28.44 # * Bagder runs away 11.34.44 Join AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) 11.48.21 *** Saving seen data "./dancer.seen" 12.12.45 Join Salokyn [0] (~Nicolas@lns-th2-4f-81-56-190-52.adsl.proxad.net) 12.15.08 Part Salokyn 12.15.19 Join Salokyn [0] (~Nicolas@lns-th2-4f-81-56-190-52.adsl.proxad.net) 12.15.23 Part Salokyn 12.15.45 # * Bagder fixes his reds 12.27.59 Join pfavr [0] (pfavr@t3o61p301.telia.com) 12.47.00 # daily-build table ala "xmas-tree look" 12.47.30 # lol 12.53.47 # Bagder: Would you mind me delaying the jpeg fix until the evening? 12.54.10 # not at all, you take your time 12.54.41 # Then the yellow build will stay until I got my things done 12.54.46 # yes 12.54.59 # I'll fix the reds 12.57.06 # I have another optimization for grayscale in mind, and want to fix a potential dangerous instruction sequence along the way. 12.57.54 # In grayblock() I have two asm blocks, the first pushing something on the stack what the second one consumes. 12.58.37 # If something in between accesses variables expected at defined positions on the stack -> kaboom 12.58.58 # :-) 12.59.37 # This may occur just if the compiler decides to do the optimization a bit diferently (already got that) 13.03.28 # ok, only those yellows ones left in the build now 13.10.42 Quit pfavr ("ChatZilla 0.9.52B [Mozilla rv:1.6/1]") 13.41.07 Join Salokyn [0] (~Salokyn@lns-th2-4f-81-56-190-52.adsl.proxad.net) 13.41.07 Quit Nibbler (Read error: 54 (Connection reset by peer)) 13.48.26 *** Saving seen data "./dancer.seen" 14.07.22 Quit scott666_ ("i'll be back...eventually...") 14.20.16 Join Hes [0] (~hessu@he.fi) 14.44.45 # http://security.e-matters.de/advisories/072004.html might affect rockbox anonymous cvs, I guess 14.45.25 # it does, yes 14.46.17 # me update 14.46.58 # good 8-) 14.47.14 # but... 14.47.31 # I find no newer version 14.48.56 # ouch 14.49.09 # 1.11.15 is the latest cvshome.org provides 14.49.15 # in the stable branch 14.50.00 # Hmm. 14.50.16 # CVS stable release <= 1.11.15, CVS feature release <= 1.12.7 says the release, I'm wondering if it should read < 14.50.44 # http://ftp.cvshome.org/ indicates that .7 and .15 came out 14th of april 14.50.58 # oh, sorry, forget that 14.51.05 # which is before they found this flaw, yes 14.51.08 # the advisory dates are in may 14.51.25 # * Hes has wooden eyes 14.52.35 # Hmm, where is the CVS of CVS? 8-) 14.52.47 # http://ccvs.cvshome.org/source/browse/ccvs/ 14.53.03 # amiconn: what other optimitzations are you planning for the grayscale framework? 14.57.18 # elinenbe: Font support (already done locally), slight speedup for any depth, moderate speedup for "special" depths (8/16/32 bitplanes) 14.58.30 # Furthermore: api change - no more handing over all parameters, but having functions to set draw mode, foregorund & background pens 14.58.42 # This will also reduce code size 14.59.21 # *foreground even 15.04.16 # ok, just dropped in to say hi, and thanks, the improvements made in recording & the speedups have made me happy a few times lately! 15.05.08 # the image viewers / grayscale / video work are amazingly funny hacks although i haven't really needed them 8-) 15.11.34 Join Nibbler [0] (nibbler@port-212-202-78-119.dynamic.qsc.de) 15.43.33 Join edx [0] (edx@pD9EAA4AE.dip.t-dialin.net) 15.48.28 *** Saving seen data "./dancer.seen" 15.57.29 Join quelsaruk [0] (~WzY@193.136.159.158) 15.57.35 # hi 15.57.41 # howdy 15.57.51 # :) 16.06.11 Quit BlueChip (Read error: 104 (Connection reset by peer)) 16.16.56 Join MeeBit [0] (meebit@64-40-51-50.ncplus.net) 16.19.47 Part MeeBit 16.22.19 # cu! 16.22.22 Part quelsaruk 16.38.01 Join MeeBit [0] (meebit@64-40-51-50.ncplus.net) 16.38.02 # amiconn: sounds great! how long until the commit? 16.38.50 # brb 16.38.53 Quit elinenbe (" HydraIRC -> http://www.hydrairc.com <- The dawn of a new age") 16.47.23 Part MeeBit 17.09.54 Join mecraw_ [0] (~mecraw@69.2.235.2) 17.13.08 Part Bagder 17.15.50 Join BlueChip [0] (~bluechip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com) 17.16.07 Quit sunpower ("—I-n-v-i-s-i-o-n— 2.0 Build 3515") 17.16.13 Join jakesir [0] (solaris@pool-151-196-54-17.balt.east.verizon.net) 17.18.51 Join KoRnfReaK [0] (~kornfreak@p83.129.177.127.tisdip.tiscali.de) 17.19.12 # Hello 17.19.20 # yo 17.21.21 # planning to put in 2300mAh accus into my AJB6000 17.22.18 # anyone changed accus already ? 17.22.29 # accus? 17.22.53 # sry im german 17.23.08 # batterys wich you can charge again 17.23.18 # NiMh batterys 17.23.32 # aha - yes, many have put in more powerful batteries 17.23.54 # There is a setting in Rockbox so that the meter will stay accurate 17.24.08 # ive seen already 17.24.18 # you changed batteries ? 17.24.33 # not yet, 12 hours is enough for me :) 17.24.42 # I will when they finally die though 17.25.08 # im thinking about putting in those batteries http://reichelt.de/inhalt.html?SID=14QHRmtdS4AQ4AAFeQS7ke7fa9124edc849c98e10a7f4eb1f3628;ACTION=3;LASTACTION=4;SORT=artikel.artnr;GRUPPE=D52;WG=0;SUCHE=2300%20mAh;ARTIKEL=NH%25204X2300%2520CEL;START=0;END=15;STATIC=0;FC=667;PROVID=0;TITEL=0 17.26.24 # you can get bigger than 2300, but any NiMH will work okay 17.27.00 # there are 2400mAh batterys but i think that 2300 are okay too 17.27.54 # i will order them in a few days 17.28.09 # my father put then in them ;) 17.28.29 # i thik it roxx if my player runs for 15 hours or more ;) 17.31.48 # you know the gp32 ? 17.32.12 # is that the open platform game unit? 17.32.53 # yes 17.33.16 # in which case ...YES :) 17.33.45 # http://www.lik-sang.com/list.php?category=126& 17.33.53 # this little devil ^^ 17.34.17 # I've given Lik-Sang far too much money in my life :) 17.35.40 # lol 17.35.46 # you have got the gp32 ? 17.36.10 # no, I've been enjoying writing games for the Archos personally 17.36.17 # hehe 17.36.33 # im happy owner of gp32 and AJB6000 17.36.42 # ;D 17.36.44 # written much for the gp32? 17.37.02 # no im 13 years old 17.37.42 # but i start learning c/c++ in a few months 17.37.57 # JEEZUZ your english is good - why is it that most "foreigners" speak better English than most Enlish people I know?? 17.38.31 # dont know 17.38.35 # At 13 I was just learning "ich bin BlueChip" 17.38.43 # hehe 17.39.04 # Anyway, no reason you cannot learn to speak C - far easier than English imho 17.39.42 # i had my first pc with 7/8 years and that was the beginning with english ;) 17.41.01 # Well, so long as you can understand that data is stored in memory at an address which is just a number and the data is different from a thing which POINTS at the data, you will get along with C just fine :) 17.43.32 # i think im born into a situation like this 17.43.43 # parents are programmers? 17.44.02 # my brother built something like this http://www.bobblick.com/techref/projects/propclock/propclock.html 17.44.17 # and much more 17.44.19 # coooool 17.45.16 # my father build me a amplifier for my boxes ... 17.45.39 # my brother codes and builds and my father is expert in mechanic knowledge 17.45.50 # you get what i mean ? 17.45.56 # understood :) 17.46.12 # So what cool thing do you plan to write? 17.46.25 # i dont know 17.46.31 # an emulator or something 17.46.41 # he KoRnfReaK: The maximum setting for Batteries within Rockbox is 3200 mAh 17.46.49 # WOW Start Big! 17.47.18 # i mean in the future 17.47.24 # not at the beginning 17.47.32 # don't forget to reset/check that setting everytime you had your rockbox without batteries or you load a new firmware 17.47.41 # Maybe start by writing a chip8 emulator, they are quite simple 17.47.41 # @limbus but i dont know where to get thema cheap 17.48.31 *** Saving seen data "./dancer.seen" 17.50.34 # to get what cheap ? thos batteries ? I got some at ebay: 8 pieces of 2300mAh for 8 ¤uro + 4 ¤uro transport 17.51.53 # and don't believe what they say over there. I'm gettin always better results with decharging them 17.52.30 # my brother build a rotation per minute displayer for his trabant (if you dont know http://www.volipindarici.it/appunti/germania1/trabant.jpg ) 17.53.03 # yeah, I know traband. I'm from belgium and work in germany 17.53.06 # but we had to sell the car ;( 17.53.08 # err, trabanT 17.53.16 # what a bummer 17.54.28 # my brother build a gameboy linker with 2 cartridges (4mbit) 17.54.55 # i think thats enough to describe the situation ;) 17.58.13 # and what are you doing all the day ? 17.59.03 Part Salokyn 18.05.01 Part KoRnfReaK 18.05.01 Join KoRnfReaK [0] (~kornfreak@p83.129.177.127.tisdip.tiscali.de) 18.06.21 DBUG Enqueued KICK BlueChip 18.06.21 # 04[17:06] *** CTCP: KoRnfReaK pinged you. 18.06.21 # [17:06] *** CTCP: KoRnfReaK requested your version.01 18.06.31 # lol 18.06.55 # If KoRnfReaK tries to hack me, KoRnfReaK is in for a nasty surprise 18.07.24 # im not trying to hack you 18.07.30 # just look around mIRC 18.07.38 # ok ;) 18.07.50 # im 13 -_- i cant hack 18.07.58 # sorry for beeing afk 18.08.13 # and i dont want to hack someone 18.08.49 # KoRnfReaK: I am somehow developing software all the day, or that's what they pay me at least 18.08.53 # it's fun ...but you'd be better picking someone from a non-techie group :) 18.09.11 # lol 18.09.43 # please dont hack me 18.09.48 # heh 18.10.01 # You're safe dude, far better things to do with my time ;) 18.10.14 # puhhh 18.10.21 # shit its 18.09 18.10.29 # out of interest, did you get a reply to your ping? 18.10.30 # so late -.- 18.10.39 # yeah 2 secs 18.10.58 # strange ;) 18.11.26 # strange - must be some weird IRC ping thing - pings are generally blocked here 18.12.19 # BlueChip: This _is_ an irc ping: /ctcp ping 18.14.44 # aha! 18.15.20 # And this way you can find out about the irc client: /ctcp version 18.17.12 Quit KoRnfReaK () 18.56.23 Join Winner^Sh [0] (~ozkano@dsl81-215-55247.adsl.ttnet.net.tr) 18.56.28 # hi all 18.56.39 # i want to know 18.57.01 # can i add external cdrom to my archos jukebox 18.57.14 # via usb port 19.00.38 # hi 19.01.05 # no, the usb port on the archos jukebox recorder/player/studios can only be used a client. 19.01.23 # sorry, "as client" 19.04.19 # Winner^Sh: see http://rockbox.haxx.se/docs/nodo.html#4 19.33.03 # there is a small device that you can link two masters together with - someone posted in on the ml the other week - not sure if it's up to that though 19.37.15 # so it is hopeless :) 19.37.17 # err. no. we need a device linking two "slaves" or usb-devices together. that device then will be a master (usb controller, usb-host) 19.37.31 # sorry, yes, slaves, not masters - my bad 19.37.49 # you mean the device does what Winner^Sh needs ? 19.38.25 # is there any way to play wma on archos ? 19.38.27 # both jbr & cd are slaves, so yes, but the device I saw was specced for cameras and the likes 19.38.32 # no 19.38.55 # it may be possible, but we need more info on the MAS chip 19.39.55 # BlueChip: That device may work then. It is a host-controller and has some logic for file-systems and how to copy. 19.40.11 # and do you advice to write rockbox to device eprom or load to ram on every boot up ? 19.40.14 #