--- Log for 18.06.104 Server: anthony.freenode.net Channel: #rockbox --- Nick: @logbot Version: Dancer V4.16p1 Started: 1 month and 3 days ago 00.02.52 Join amiconn [0] (~jens@pD9E7F485.dip.t-dialin.net) 00.03.18 *** Saving seen data "./dancer.seen" 00.08.16 Quit Zagor ("Client exiting") 01.00.10 Quit Nibbler (Read error: 54 (Connection reset by peer)) 02.03.21 *** Saving seen data "./dancer.seen" 02.06.03 Join Guest1 [0] (~jirc@ABordeaux-251-1-18-191.w82-125.abo.wanadoo.fr) 02.06.15 # Hi everybody, I need help 02.06.21 # is there someone here ? 02.17.34 Quit Guest1 (Read error: 104 (Connection reset by peer)) 02.36.49 Join Nibbler [0] (nibbler@port-212-202-78-119.dynamic.qsc.de) 02.42.29 Quit AciD` ("http://frbattle.free.fr/mixs/samedi%2012%20juillet%2013-14%20heures%20angle%20mort/AciD%20vs%20Formax%20-%20Live@prun'%20radi) 02.43.47 Join mecraw_ [0] (~mecraw@67.176.127.191) 03.51.08 Quit mecraw_ ("Trillian (http://www.ceruleanstudios.com)") 03.51.08 Quit Nibbler (Read error: 54 (Connection reset by peer)) 03.53.53 Part amiconn 04.03.22 *** Saving seen data "./dancer.seen" 04.25.02 Join Guest1 [0] (~jirc@pcp05996581pcs.epensb01.pa.comcast.net) 04.25.07 # Hello 04.25.37 # Does anyone know how to clear directory buffer... 04.26.08 # my jukebox wont allow me to create any directories 04.30.42 # Guest1: what happens when you try to create a directory? 04.44.21 # It creates the directory and shows in windows file explorer 04.44.30 # but not in the archos display 04.44.35 # it does not appear 04.45.54 # Guest1: do you see any errors on rockbox? such as dir buffer full? 04.46.22 # Yes: it says that exact message upon startup 04.46.29 # Guest1: make sure you do a "safe remove" of the archos after you create the directory too... right click the "hardware" icon in the system tray and safe remove the jukebox 04.46.46 # Guest1: increase the dir buffer in rockbox settings, and then reboot 04.46.50 # rockbox. 04.47.48 # elinenbe: how can i get to these settings? 04.49.39 # Menu->General Settings->System->Limits->Max files in dir browser 04.51.00 # see also: http://rockbox.haxx.se/docs/faq.html#76 04.51.44 Quit hardeep ("[BX] Elvis has left the building") 04.52.29 # Thanks a lot! 04.52.32 # it works now 04.52.40 Quit Guest1 ("Leaving") 05.11.50 Quit elinenbe (" The IRC Client of the Gods! -> http://www.hydrairc.com <- HydraIRC") 05.14.47 Join Nibbler [0] (nibbler@port-212-202-78-119.dynamic.qsc.de) 05.21.48 Join elinenbe [0] (elinenbe_@207-237-224-177.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 05.54.17 Quit Nibbler (Read error: 54 (Connection reset by peer)) 06.03.25 *** Saving seen data "./dancer.seen" 06.12.17 Join [IDC]Dragon [0] (~idc-drago@p50861A2A.dip.t-dialin.net) 06.29.27 Join BlueChip [0] (~bluechip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com) 06.31.37 Join LinusN [200] (~linus@labb.contactor.se) 06.33.06 # LinusN: early start 06.33.12 # ditto 06.33.26 # JUST finished getting the new devkit going :) 06.33.36 # already? :-) 06.33.46 # :) 06.33.56 # thanks for all your help 06.34.11 # gotta find a way to report that site to cygwin 06.34.12 # you're welcome 06.34.58 # now to try cvs :) 06.35.08 # again 06.35.10 # lol 06.36.02 # want me to walk you through it? 06.36.42 # That'd be great if you have the time - I will need to copy the files over as I go, so I may be a little slow at this end 06.37.06 # <[IDC]Dragon> 'morning guys 06.37.18 # mornin' [IDC]Dragon 06.37.49 # BlueChip: whenever you're ready 06.38.07 # awaiting your words of wisdom... :) 06.38.16 # <[IDC]Dragon> LinusN: I have the new settings stuff coded now, saves >7KB 06.40.04 # can i review the patch? 06.40.16 # <[IDC]Dragon> I'd love to 06.40.16 # BlueChip: have you installed cvs? 06.40.32 # i can type cvs without errors now 06.40.43 # not sure if prams will require more files though 06.40.45 # <[IDC]Dragon> ;-) 06.40.46 # wow! three letter without errors! :-) 06.40.55 # three files required ;) 06.41.08 # lol 06.41.35 # i tend to introduce bugs around 5 or 6 characters, so I tend to play it on the safe side 06.41.38 # * LinusN cut his index finger yesterday, so his typing is lousy :-) 06.41.46 # ouch 06.41.49 # * [IDC]Dragon is emailing the new code to LinusN 06.42.06 # the index finger is also my typing finger :-) 06.42.19 # lol ...in the singular 06.42.49 # will I need to create a .cvspass file 06.42.54 # <[IDC]Dragon> how do you shift then? 06.42.55 # well, do you know the basic concepts behind cvs? have you worked with other version control systems? 06.43.21 # sadly the thing I used at my last company was a weird in-house thing 06.43.35 # <[IDC]Dragon> LinusN: code is on the way 06.43.52 # ...knocked up one lunchtime - judging by the interface 06.44.03 # [IDC]Dragon: gr8 06.44.39 # ok, BlueChip, the cvs server keeps a Repository, where all the files reside 06.44.51 # ok 06.45.07 # they are divided into groups, called Modules 06.45.12 # ok 06.45.24 # I read about those on the rockbox page 06.45.32 # in Rockbox, "apps" is one module, "firmware" is one etc 06.46.05 # we have also grouped several modules together in larger, virtual modules 06.46.11 # yep 06.46.12 # <[IDC]Dragon> you guys go ahead, I'll check back in a few minutes then (would like to discuss a few things about the settings with Linus) 06.46.13 # rockbox, rockbox-all etc 06.46.25 # i presume these files are progrssive diff files (for lack of the correct term) 06.46.42 # *progressive 06.47.14 # when you check out a module, all files are copied to your file system, along with some CVS special stuff, in a dir called CVS 06.47.50 # will this update existing files, or replace them? 06.48.08 # one of the key points is: everything in CVS is about diffs 06.48.16 # cool 06.48.38 # let's get some hands-on experience 06.48.42 # go 06.49.14 # * BlueChip is waiting in /home/rockbox 06.49.31 # what is in /home/rockbox ? 06.49.48 # a single tarball ...and a single dir of that tarball with a patch applied 06.49.58 # "rockbox" is your cygwin user? 06.50.08 # sorry, yes 06.50.17 # (there is also the patch file in that dir) 06.50.32 # ok let's start with checking out the "rockbox" module 06.50.54 # that will create a directory with the same name as the module, in this case "rockbox" 06.50.55 # ok 06.51.17 # where is it standard to keep this directory? 06.51.26 # (on my machine) 06.51.31 # cvs -d:pserver:anonymous@rockbox.haxx.se:/cvsroot/rockbox co rockbox 06.51.53 # it's ok to have it anywhere, i have it in my home dir 06.53.14 # working... 06.54.06 # the dir name will always be the same as the package yes? 06.54.20 # done 06.54.24 # yes 06.54.26 # ok 06.55.33 # open apps/main.c in your favourite editor 06.55.49 # yep 06.56.22 # remove the sleep(HZ/2) in init() 06.56.42 # done 06.56.42 # and save the file 06.56.45 # done 06.57.11 # ok, now cd to rockbox 06.57.22 # yep 06.57.38 # and do "cvs diff -u apps/main.c" 06.58.19 # whoops - my editor has trimmed all the trailing spaces 06.58.32 # naugthy editor 06.58.54 # they'll add "ignore trailing whitespace" to diff one day 06.59.13 # should I redo the edit, or continue with a big diff 06.59.53 # let's continue 07.00.20 # ok... I presume it is easy to replace that file from cvs 07.00.35 # let's do that 07.00.39 # cool 07.00.42 # delete the file 07.00.52 # done 07.00.58 # cvs up -dP 07.01.08 # from which dir? 07.01.11 # "up" is short for "update" 07.01.32 # as long as you are above or in the apps dir, you're fine 07.01.40 # great 07.01.49 # as long as you are in the repository, that is 07.02.23 # great, although I can now see a complaint about "missing .cvspass" 07.02.53 # try this: "touch ~/.cvspass" 07.03.50 # great - complaint gone :) 07.04.13 # ("touch" creates an empty file) 07.04.40 # (yes, i noticed, clever, much cleaner than "copy con") 07.04.41 # (or updates the modified date if the file exists) 07.05.37 # ok, did you notice the "U" before the file name in the cvs output? 07.06.40 # sorry, lost it off the screen now :( 07.06.58 # U == "Updated" 07.07.17 # ok, edit the file again 07.07.31 # Right. I must say the output seemed quite clear that it had noticed the missing main.c and replaced it 07.07.42 # file edited 07.07.51 # do the update again 07.08.08 # the update, not the diff 07.08.21 # yes 07.08.32 # "M" this time 07.08.34 # notice the "M" in front of the file name 07.08.36 # yes 07.08.40 # M = Merged 07.08.47 # here's the beauty of cvs 07.09.25 # the update procedure merges your files with the repository 07.09.44 # or "patches" if you like 07.10.06 # your changes are always intact 07.10.31 # bloody impressive - so how did it know not to add that sleep() back in again? 07.10.56 # it sees that your file differs from the repo 07.11.06 # and your edits have precedence 07.12.04 # what it does is that it creates a patch from the differences between the file version you have edited and the file version on the server, and then it applies that patch on your file 07.12.54 # now if someone has changed exactly that line and committed that change, there will be a conflict 07.13.45 # right, so i will get a diff file to apply by hand? 07.14.19 # the update procedure puts markers in the file, showing the conflict 07.14.32 # and you will have a "C" in front of the file name 07.14.42 # vey nice 07.14.50 # let's leave the conflict for now 07.14.57 # ok 07.15.48 # this is basically it, the "update" procedure patches your repository with the latest changes on the server 07.16.20 # so you can happily edit your files, and do "update" every once in a while to keep up with the latest changes 07.16.33 # i think I am confused only on one point, and that is technical rather than of useage 07.16.39 # shoot 07.17.07 # how does it know that my file is lacking a line and not be confused with the cvs has a line added - i get the feeling there could be a timing issue at hand? 07.18.43 # it keeps track of which version of the file that is in your repository 07.18.56 # aha! of course ...the CVS directory ;) 07.18.59 # in this case, 1.86 07.19.31 # apps/CVS/Entries 07.19.41 # Great, I presume conflicts are marked with #error or similar? 07.19.56 # it's something like: 07.20.02 # <<<< 1.86 07.20.04 # bla bla 07.20.22 # ---- main.c 07.20.24 # blo blo 07.20.25 # >>>>> 07.20.49 # and you have to manually select which part you want 07.21.00 # cool - so it will throw nice compiler errors if I miss it during the update :) 07.21.06 # exactly 07.21.24 # let's edit another file, tree.c 07.21.39 # ok 07.21.55 # remove the ".mpa" file type on line 76 07.22.07 # done 07.22.18 # go to the "rockbox" dir 07.22.33 # yep 07.22.35 # let's create a patch 07.22.55 # cvs diff -u 07.23.04 Quit silencer (Read error: 60 (Operation timed out)) 07.23.07 # (ahhh, this is the stuff - a standardised patch) 07.23.08 # you will see both changes 07.23.09 Join silencer [0] (~silencer@nino.via.ecp.fr) 07.23.30 # yep 07.23.38 # cvs diff -u > mypatch.patch 07.23.46 # *bing* 07.24.41 # unusual looking patch - that will apply okay with patch.exe ? 07.24.50 # unusual? 07.25.01 # different from those I have made in the past 07.25.10 # ....goes hunting 07.25.48 # there are a few different formats for patches 07.25.58 # this is the "Unified" patch format 07.26.16 # this one has all the files underlined with "="s which I think is the most notable change 07.26.35 # also has "? filename.pat" as the first line 07.27.04 # it actually ignores lots of that info 07.27.24 # yes, I guess so, it just makes the file look quite different ...more readable 07.27.39 # ok, remove main.c and tree.c and update again 07.28.36 # U main & tree .... ?patch.pat :) 07.29.09 Join adi|home [0] (~adi|home@as5300-9.216-194-23-57.nyc.ny.metconnect.net) 07.29.46 # Well, that all seems pretty straight forward :) ....is that it, or are there more surprises in store? 07.30.57 # patch -p0 < mypatch.patch 07.31.25 # and you're back! 07.31.34 # blinding ! :) 07.32.07 # as you may have noticed, the uisimulator module is not part of the "rockbox" module 07.32.46 # so, in the "rockbox" dir, do "cvs co uisimulator" 07.33.47 # great 07.33.56 # that's basically iy 07.33.59 # it 07.34.30 # cool - Linus, I owe you a large beer for that help - I have wasted hours trying to suss that in the past ....I will play for a bit and write up our conversation as an edited transcript 07.34.50 # glad to help 07.34.59 # Thank You 07.35.15 # [IDC]Dragon: you're next :-) 07.35.22 # <[IDC]Dragon> #2 07.35.27 # * BlueChip goes off to play with his new knowledge 07.35.35 Join Nibbler [0] (nibbler@port-212-202-78-119.dynamic.qsc.de) 07.35.48 # <[IDC]Dragon> got the code? 07.36.03 # BlueChip: feel free to add a CVSForDummies in the Wiki 07.36.23 # [IDC]Dragon: yes 07.37.15 # <[IDC]Dragon> do you want to comment on it, or should I jump in some details? 07.37.15 # it looks much like i had in mind myself 07.37.33 # <[IDC]Dragon> ah, good sync 07.38.31 # <[IDC]Dragon> the focal point is the two tables, rtc_bits and hd_bits 07.38.41 # it will perhaps raise the bar a little for those who want to add options 07.39.02 # but it was quite intimidating in the earlier version too :-) 07.39.04 # <[IDC]Dragon> lower, you mean? 07.39.17 # both, actually 07.39.41 # this way will help to remove the "manual" bit fiddling 07.40.08 # <[IDC]Dragon> help to? It removed it. 07.40.10 Join midk [0] (Zakk@c-67-160-88-198.client.comcast.net) 07.40.26 # yes 07.40.28 # <[IDC]Dragon> you only need to decide how many bits you need 07.40.33 # exactly 07.41.01 # <[IDC]Dragon> some shortcomings: 07.41.21 # <[IDC]Dragon> the .cfg files are looking very plain now. 07.41.36 # (shortcoming?) 07.41.42 # <[IDC]Dragon> no min/max checking of a value 07.41.54 # <[IDC]Dragon> do you prefer them plain? 07.42.12 # <[IDC]Dragon> the old ones had some comments as block captions 07.42.24 # ah, yes 07.42.50 # <[IDC]Dragon> the order in the .cfg file is now always the same as in the tables 07.43.46 # one nasty shortcoming is that the setting block becomes incompatible for every tiny change 07.43.56 # <[IDC]Dragon> no 07.44.06 # <[IDC]Dragon> not for adding stuff 07.44.23 # <[IDC]Dragon> the first entry sayshow many bits are valid in the block 07.44.25 # true 07.44.43 # i don't see that as much of a problem anyway 07.44.57 # <[IDC]Dragon> is only loads values up to there, leaving the others at default 07.45.17 # <[IDC]Dragon> next time the block is saved, those will be valid, too 07.45.41 # hmm, did i really call it "rec_base_directory", how silly of me 07.45.59 # i should lose the underscores 07.47.02 # <[IDC]Dragon> I think that's not used any more 07.47.30 # what isn't? 07.47.51 # <[IDC]Dragon> oops, sorry, other modules use it as external 07.49.14 # * [IDC]Dragon tries to understand 07.49.57 # i mean the string in the settings file 07.50.03 # <[IDC]Dragon> there may be a problem 07.50.10 # me == stupid 07.50.18 # ignore me 07.51.12 # <[IDC]Dragon> global_settings.rec_directory is a bool flag 07.52.08 # well, it's a 1-bit index, actually 07.52.51 # <[IDC]Dragon> rec_base_directory should be moved to recording.c 07.53.16 # why? 07.53.19 # <[IDC]Dragon> settings.c does not use it (any more) 07.53.36 # it never has 07.54.12 # <[IDC]Dragon> anyway 07.54.21 # i chose to put it in settings.c because more than one file uses it, and it is a setting 07.54.32 # <[IDC]Dragon> ok 07.54.35 # i could just as well put it in recording.c 07.55.27 # <[IDC]Dragon> what I really wanted to check with you: 07.55.39 # <[IDC]Dragon> I do no min/max clipping as of now 07.56.14 # that shouldn't matter 07.56.17 # <[IDC]Dragon> because that would add 2 32 bit members (worst-case size) to the struct 07.56.54 # what's the deal with the SIGN() macro? 07.57.06 # <[IDC]Dragon> it marks a value as signed 07.57.27 # <[IDC]Dragon> so after bit extraction, it will get sign-extended 07.58.05 # <[IDC]Dragon> if we e.g. have a range of +/- 15, this member needs 5 bits 07.58.26 # <[IDC]Dragon> extracting it will result in 0...31, a positive int 07.58.46 # i would rather write it as (SIGNED | 32, S_O(..... 07.58.58 # <[IDC]Dragon> if we know it's signed, we can check the "MSB" and extend 07.58.59 # #define SIGNED 0x80 07.59.09 # <[IDC]Dragon> ok 07.59.15 # brb 07.59.18 Quit midk (Read error: 104 (Connection reset by peer)) 07.59.24 # feels more straight-forward 07.59.59 # i'm not too happy about the S_O macro either, but i can see that it saves space and reduces the possibility of errors 08.00.31 # <[IDC]Dragon> yep 08.00.43 Join midk [0] (Zakk@c-67-160-88-198.client.comcast.net) 08.00.52 # i think we can (and should) remove the DEFAULT_xxx macros 08.01.08 # or? 08.01.09 # <[IDC]Dragon> why? 08.01.34 # they are only used once, as far as i can see 08.01.56 # <[IDC]Dragon> ah, they are in settings.h, I see 08.02.07 # <[IDC]Dragon> then it doesn't make much sense 08.02.09 # and only a few of the settings have DEFAILT_ macros 08.02.19 # it just complicates things 08.02.27 # <[IDC]Dragon> I thought they are with the respective modules 08.02.28 # let's clean that up while we're at it 08.02.32 # <[IDC]Dragon> OK 08.03.13 # <[IDC]Dragon> a nice cleanup would be to remove val2phys/phys2val ... 08.03.19 # let me do that 08.03.23 # <[IDC]Dragon> but let's do this first 08.03.29 *** Saving seen data "./dancer.seen" 08.03.37 # yup 08.03.47 # <[IDC]Dragon> the code has some quirks to compensate 08.03.55 # <[IDC]Dragon> which can be removed then. 08.04.27 # <[IDC]Dragon> next subtopic: 08.04.47 # <[IDC]Dragon> I was thinking about inserting zero bitlength members 08.05.07 # <[IDC]Dragon> (some kind of escape value) 08.05.25 # <[IDC]Dragon> to be treated as a comment line for .cfg writing 08.05.51 # not a bad idea 08.06.45 # <[IDC]Dragon> but we can only group as much as it's grouped in the array 08.07.07 # ah 08.07.19 # <[IDC]Dragon> if you e.g. add an LCD setting later at the end, it will be at the end 08.07.30 # one tiny thing, why do you include "rtc.h" in the middle of the file? 08.07.30 # <[IDC]Dragon> not in "its" group 08.07.41 # <[IDC]Dragon> not my code... 08.07.57 # oh, then move it up where it belongs 08.08.08 # <[IDC]Dragon> or? 08.08.22 # <[IDC]Dragon> maybe copy/paste error 08.08.25 # on second thought, let's skip the comments in the settings file 08.09.40 # <[IDC]Dragon> too cumbersome? 08.10.50 # yes, and the grouping is difficult 08.11.39 # <[IDC]Dragon> which brings me to the next subtopic: 08.11.48 # <[IDC]Dragon> I'd welcome some thoughts for the RTC/HD choice 08.12.24 # <[IDC]Dragon> I tried to maintain groups, so in doubt there's too much in the RTC 08.12.39 # <[IDC]Dragon> my general philosophy would be to put values in the RTC if: 08.12.56 # i'd say that almost everything but the resumt info can go to disk 08.12.56 # <[IDC]Dragon> - they are constantly changing, like the resume index 08.13.19 # <[IDC]Dragon> - they are needed/helpful early, before the HD 08.13.49 # <[IDC]Dragon> - they are changed often by the user, and he would lose that if not waiting for the next spinup 08.14.08 # <[IDC]Dragon> (that's it) 08.14.39 # a good philosophy 08.14.55 # <[IDC]Dragon> now help me to review it with that in mind 08.15.13 # that will be the charging, backlight, resume and sound parameters 08.16.07 # <[IDC]Dragon> the RTC is almost full, so I hay move some more to the HD 08.16.09 # scroll stuff -> disk 08.16.25 # scroll_speed...bidir_limit 08.16.26 # <[IDC]Dragon> s/hay/may 08.16.35 # will you allow for full audio-prams? 08.17.18 # think so 08.17.56 # talk stuff -> disk 08.18.30 # "show icons" -> disk 08.18.57 # "fade on stop" -> disk 08.19.38 # "caption backlight" -> disk 08.19.53 # * [IDC]Dragon is resorting... 08.20.34 # "max file in..." could be on disk, but having them in rtc save a lot of trouble 08.21.59 # "play selected" -> disk 08.22.40 # "ff_rewind..." -> disk imho 08.28.14 # <[IDC]Dragon> disk poweroff/spindown? 08.33.10 # -> disk? 08.33.19 # <[IDC]Dragon> so I thought 08.40.58 # LinusN: at 07.01.49, you said "as long as you are in the repository, that is" by "repository" did you mean the "rockbox" directory ...(to ease confusion, I have changed my login to "guest") 08.41.45 # BlueChip: yes 08.42.10 # thanks 08.42.41 # so would I be correct in saying that the uisimulator directory will not update from the rockbox directory 08.42.57 # *uisimulator files 08.44.40 # they should, try it 08.45.23 # I will when I get the files back on my system - working the transcipt as I edit it 08.45.51 # <[IDC]Dragon> LinusN: I should reserve some more bits for the runtime values 08.46.44 # <[IDC]Dragon> 16 bits is only good for ~9 hours 08.47.22 # <[IDC]Dragon> what's topruntime good for anyway? with ac connected, it can be arbitrary long? 08.50.31 # no idea 08.50.59 # <[IDC]Dragon> how many bits should I give it? 08.51.35 # why not scale it instead? 08.52.15 # <[IDC]Dragon> then it needs to be scaled in global_settings as well 08.53.24 # i think 18 bits would be ok 08.53.52 # <[IDC]Dragon> very well 09.01.05 # <[IDC]Dragon> I don't use #ifdef HAVE_LCD_CHARCELLS 09.01.05 # <[IDC]Dragon> {3, S_O(jump_scroll), 0, "jump scroll", NULL }, /* 0...5 */ 09.01.05 # <[IDC]Dragon> {8, S_O(jump_scroll_delay), 50 "jump scroll delay", NULL }, /* 0...250 */ 09.01.05 DBUG Sent KICK [IDC]Dragon to server 09.01.05 # <[IDC]Dragon> #endif 09.01.06 Kick (#rockbox [IDC]Dragon :No flooding!) by logbot!~bjst@193.15.23.131 09.01.24 # who opped logbot! 09.02.20 Join [IDC]Dragon [0] (~idc-drago@p50861A2A.dip.t-dialin.net) 09.02.33 # <[IDC]Dragon> oops, wrong clipboard content 09.03.03 # <[IDC]Dragon> I don't use set_sound() any more, is that OK? 09.03.30 # <[IDC]Dragon> will settings_apply() do the job instead? 09.04.13 # set_sound is internal to settings.c, so remove it if it's obsolete 09.04.18 # <[IDC]Dragon> I guess it's main purpose was the phys2val conversion, which I do 09.05.19 Join Zagor [242] (~bjst@labb.contactor.se) 09.08.03 # <[IDC]Dragon> Hi Björn! 09.27.12 # hi 09.28.37 # <[IDC]Dragon> is 18 bits enough for your runtime value? ;-) 09.30.17 # yeah :) 09.34.21 Nick midk is now known as midk|here|sleep (Zakk@c-67-160-88-198.client.comcast.net) 09.34.29 Nick midk|here|sleep is now known as midk|sleep (Zakk@c-67-160-88-198.client.comcast.net) 09.48.23 Join Bagder [241] (~dast@labb.contactor.se) 09.49.03 # hi bagder 09.49.10 # hey ho 09.58.15 # openjukebox is truly an irony 09.58.52 # which what? 09.58.58 # lol 09.59.10 # dwihno: openjukebox.free.fr 09.59.20 # "open" source for xclef 09.59.24 # just not open 09.59.28 # and no source ;-) 09.59.31 # NAHAHAHAHAHA IT LOOKS SUCKY 09.59.36 # *waits for page to load 09.59.38 # i'm quite tempted by the xclef hd-800 09.59.44 # me too 09.59.58 # so do it 10.00.02 # and we'll hack it 10.00.15 # any nice swedish resellers? 10.00.20 # haven't found any yet 10.00.22 # maybe the donations can come to use... 10.00.34 # *donates a few spare coins 10.00.44 # i'll ask jon for help 10.00.47 # i have some old credits engine code if you would like it 10.01.39 # i hope the donations can finance my ulcer medicine as well :-) 10.01.58 # haha 10.02.07 # have a seperate donations page for linux 10.02.08 # linus* 10.03.31 *** Saving seen data "./dancer.seen" 10.03.46 # the LinusAID project 10.04.03 # we sing for your ulcer? 10.04.14 # * Bagder starts singing 10.04.23 # * midk|sleep joins in, ruining the whole thing 10.04.41 # "he is da maaaaan, he has an ulcer...." 10.04.54 # that doesn't rhyme well 10.04.58 # nice try. 10.05.25 # "he is the one who makes a better jukebox, so let's start hacking" 10.05.48 # "we are the geek, we are the nerd-heads..." 10.05.51 # * midk|sleep suspects that LinusN will soon have a job as a rapper 10.06.08 # "unknown improvements and fixes" 10.06.12 # well, Band Aid didn't rap... 10.06.39 # zagor and linusn will form a small group and become big time stars 10.06.47 # linus, email winging it's way to you 10.06.58 # midk|sleep: we already have :-) 10.07.16 # i mean, big time rapper stars. 10.07.28 # yeah, rapping is really our thing 10.07.41 # BlueChip: saw it, thx 10.07.43 # i can tell by your "rhymes" i just read 10.07.50 # you're a natural 10.07.57 # "Best Price - 18 Jun 2004: £219.00" 10.08.10 # hd800 that is 10.08.19 # except that it was supposed to be sung to the melody of "We are the world" :-) 10.08.20 # this opensource thing looks very stupid... 10.08.46 # i knew that! 10.10.04 # "the remote control ... generates sound interference every time its little LCD display changes" 10.10.06 # hehe 10.10.15 # YAY 10.10.16 # here we go ;-) 10.10.19 # interference 10.10.26 # bagder will get right on it 10.11.15 # very few buttons 10.11.28 # *jumps on it so it shatters into multiple pieces 10.11.31 # pong will be very hard! 10.11.50 # Bagder: there are 4 keys and a jogdial on the side 10.11.58 # ah, on the side 10.12.00 # pl 10.12.02 # ok 10.12.13 # biggish lcd 10.12.27 # 160 x 105 10.12.32 # doesnt look that bad 10.12.34 # 105 is truly odd 10.12.36 # but it still sucks 10.12.36 # and the buttons can light up individually in 3 different shades (wooo) 10.12.42 # YAY COLORED BUTTONS 10.12.50 # lol 10.12.52 # *waits for zagor to hack it to combine colors to create lots of new colors 10.13.13 # http://www.austinv.com/cpg121/thumbnails.php?album=18 10.13.24 # it can only record at max 128kbps 10.13.34 # there's an update that does up to 320 10.13.41 # aha 10.14.36 # it does look a bit nice... 10.14.52 # gray lcd? 10.14.55 # * midk|sleep is almost sold 10.15.37 # http://www.austinv.com/cpg121/displayimage.php?album=18&pos=36 10.15.38 # OMGZ 10.15.41 # it's my new clock mode 10.15.45 # tye letters. 10.15.46 # type* 10.19.05 # Bagder: looks liek a nice thingy 10.19.41 # <[IDC]Dragon> why not the Gmini 220? 10.20.02 # 1. it's an archos 10.20.19 # hear hear 10.20.20 # 2. it's too proprietary. the xclefs use standard motorola chips with full docs available 10.20.29 # <[IDC]Dragon> c'mon, they have haptically improved alot 10.20.36 # yes 10.20.45 # but we're done sponsoring them 10.20.47 # we've already inflated their sales way more than they earned 10.20.48 # imho 10.21.02 # agreed 100% 10.21.14 # <[IDC]Dragon> the new model will have an ARM CPU 10.21.14 # its time to sponsor someone else! ;-) 10.21.18 # Zagor: xclef official url? 10.21.25 # see twiki 10.21.29 # googel. 10.21.34 # http://www.xclef.com/pro08_e.htm 10.21.42 # thanks bag. 10.21.54 # http://www.advancedmp3players.co.uk/shop/product_info.php?products_id=196 10.21.55 # bag ahaha 10.22.01 # seems to be a cheap place to buy it 10.22.14 # <[IDC]Dragon> the Gmini 220 has 160*160 display and a CF slot 10.22.21 # and it does official grayscale 10.22.30 # or does it 10.22.43 # *spots archos stealing idc's blit code 10.23.17 # <[IDC]Dragon> they like it, I know of that 10.23.31 # :D 10.23.33 # they do? 10.23.49 # * Bagder wakes midk up 10.24.08 # whuh! not for eating? 10.24.08 # Bagder: yumyum. 10.26.57 # <[IDC]Dragon> cu guys later 10.27.03 # Bagder: the only thing I am a bit scared of is the battery issue... I mean, sooner or later, the batteries will wear out. Then what? 10.27.07 # I agree 10.27.08 # bye idc 10.27.10 Quit [IDC]Dragon () 10.27.20 # then it will be obsolete anyways 10.27.33 # hmm, did you ever consider the rio karma? 10.32.11 # yes, but they use the portalplayer chip (same as in ipod) which is top top top secret 10.33.32 # Zagor: do you think there would be heta potatisar if you were to tame the beast? 10.33.36 # I notice ipod can't play gapless 10.34.09 # Are there any hard disk players that use "regular" batteries, except the earlier archos models? 10.34.17 # Bagder: correct. they add nearly a full second of silence between tracks! 10.34.28 # dwihno: none that I know 10.34.40 # " I hadn't seen a single complaint about the iPod (these days I know where to look :-/). All the advertising and articles made it sound fantastic. It was an expensive device. It was made specifically to play music. I was sure they would have made it able to play albums properly -- it seems a basic requirement of a music player to me -- and so I bought one. How wrong I was." 10.35.25 # Zagor: A full second? Man, that sucks! :/ 10.35.28 # don't you love marketing? 10.35.38 # not to mention zombie customers 10.35.48 # sheep 10.36.00 # Luckily there are better shepherds. 10.36.23 # what about the dude who got linux running on his i-pod ? 10.36.57 # he managed to run linux on the cpu, but the decoder dsp is out of reach 10.37.05 # righty 10.37.06 # last I heard they were working hard on playing mp3 in real-time 10.37.17 # lol 10.37.25 # http://ipodlinux.sourceforge.net/ 10.37.56 # aha - thought it was a track-gap dig ;) 10.38.42 # BlueChip: no, they were having problems with cpu not being strong enough to decode mp3 (since they can't use the dsp) 10.39.14 # haven't checked in a while though 10.39.23 # "The Tremor player is running at about 80% real-time." 10.39.26 # lucky they have any access to the audio at all :( 10.39.38 # "Intel has a highly optimised library for the ARM processor that includes MP3 decoding support. Their sample player runs quite well however it isn't perfect." 10.43.28 Join lImbus [0] (lImbus@55.169-136-217.adsl.skynet.be) 10.43.37 # If only the DSP was usable. 10.43.47 # Hi BlueChip, are you on air ? 10.43.57 # 10-4 10.44.54 # lol 10.46.55 # is that your current pong score? 10.50.24 Join AciD` [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) 10.53.22 # added NonArchos 10.54.17 # hey, i get to document my clock on the twiki don't i 10.54.34 # you get to document anything you think is missing 11.00.21 # I think we should drop the numbers of the FAQ questions 11.00.30 # the wiki 11.00.45 # that makes it more difficult to say "read faq xx" 11.01.03 # yes, but it makes it easier to provide a URL to a specific Q 11.01.09 # that'll live 11.01.11 Quit AciD` (Read error: 104 (Connection reset by peer)) 11.01.31 # true. hmm. 11.01.34 Join AciD` [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) 11.01.38 # numbers change more often than the actual question 11.02.48 # just browse old mails that refers to FAQ entries 11.02.51 # they are never right 11.03.56 # on the other hand the auto-generated anchors change if we ever spellfix a headline, for instance 11.04.06 # yes 11.04.34 # but a spellfix break one link 11.04.44 # new numbering breaks many 11.06.51 # * Bagder spots a new plugin 11.06.55 # ooh where 11.07.00 # in cvs 11.07.05 # just now 11.07.27 # dont tell me! 11.08.15 # i see none... 11.08.39 # patches? 11.08.42 # or merged? 11.08.52 # http://rockbox.haxx.se/viewcvs.cgi/apps/plugins/chessclock.c?rev=1.1&content-type=text/vnd.viewcvs-markup 11.09.14 # i have to go now 11.09.27 # if i'm lucky, you can call me Captain in a few hours :-) 11.09.38 # * Bagder stands straight in preparation 11.09.54 # aye aye cap'n 11.10.23 # if I prefer "uber-captain", will that do? 11.10.28 # :-) 11.11.08 # chessclock? 11.11.08 # that'll do 11.11.18 # wait 11.11.20 # lucky at what 11.11.23 # what did i miss 11.11.59 Join [IDC]Dragon [0] (~c2af7555@reladm.kharkov.net) 11.13.19 # nite. 11.13.21 # linus is going for captain-status 11.13.21 Quit midk|sleep ("yo yo yo cya later YO YO YO wasa wasa!") 11.13.52 # "skepparexamen" in swedish 11.14.08 # are you still here? :) 11.14.20 # nag, nag 11.14.30 # cu folx, wish me luck 11.14.38 # Break a leg dude :) 11.14.52 Part LinusN 11.15.37 # <[IDC]Dragon> why Captain? 11.16.33 # <[IDC]Dragon> why luck? 11.16.49 # Linus is gonna do write a test today, aiming for a "captain license" or whatever the name would be in english 11.16.49 # <[IDC]Dragon> sailing exam, aha 11.17.32 Quit lImbus (" HydraIRC -> http://www.hydrairc.com <- Get hot chicks here!") 11.19.22 Join amiconn [0] (~jens@pD9E7F0B4.dip.t-dialin.net) 11.19.45 # hi all 11.19.52 # hi jens 11.20.27 # hey 11.21.48 # hi 11.35.24 # I've already tried my idea for varying backlight brightness via interrupt driven software pwm 11.35.39 # aaaaand...... 11.35.44 # * BlueChip holds breath 11.36.08 # While the result looks nice so far, I have once severe problem I don't know how to solve 11.36.19 # s/once/one/ 11.36.55 # For the software pwm to work, I have to call rtc_write() from within an interrupt 11.37.19 # sorry, why is that bad? 11.37.19 # rtc_write() in turn uses i2c, which is protected with a mutex 11.37.23 # ah 11.37.34 # hmm 11.38.40 # So if rtc_write() is called from the isr while the mutex is locked, the whole thing locks up because the mutex won't be unlocked while in interrupt context 11.38.56 # indeed 11.39.07 # i presume the rtc controls the leds? 11.39.36 # I have done a proof-of-concept plugin which fades the backlight up/down continuously. 11.40.20 # This ran fine for several hours without playing music 11.44.32 # However, if you run the plugin in parallel with playing music, it will lock up after some time 11.46.03 # could you check the mutex before calling? 11.46.31 # I'm thinking about that, but what should I do _if_ it is locked? 11.47.23 # Simply omitting the backlight switch at that point will lead to visible glitches, and delaying is difficult 11.48.20 # Btw: I settled for having 64 steps; the base frequency is 128 Hz, so I have 256 ints/sec 11.50.05 # WOW 64 is MORE than sufficient 11.50.27 # Too bad the backlight isn't simply connected to an i/o port (for the recorder, on the player it is) 11.51.06 # hmmm, there has to be a solution 11.51.13 # If it would use a port (tested it with the red led, which is connected to a port), I wouldn't have these problems 11.51.25 # <[IDC]Dragon> hi amiconn ! 11.51.40 # Hi Jörg! 11.51.50 # <[IDC]Dragon> I2C within interrupt is not a good idea, iirc. 11.51.54 # do we have control over the green led? 11.52.12 # I don't think so 11.52.32 # [IDC]Dragon: Why? (except of the mutex problem) 11.52.38 # <[IDC]Dragon> no. Only if you power off the box... 11.52.40 # BlueChip: No, it is hardwired 11.52.59 # <[IDC]Dragon> amiconn: port bit assignment 11.53.08 # <[IDC]Dragon> checking... 11.53.42 # [IDC]Dragon: As is said, it works perfectly as long as you don't play music in parallel 11.54.04 # This is because the mas control then also uses i2c 11.54.11 # <[IDC]Dragon> or use the display 11.55.22 # <[IDC]Dragon> http://rockbox.haxx.se/docs/ports.html 11.55.34 # urps 11.55.51 # <[IDC]Dragon> I2C uses bits from both upper and lower half 11.57.37 # * amiconn thinks he is not playing by the port guardian rules then 11.58.36 # Too bad, a "light organ" plugin would be nice, however, this makes it (almost?) impossible on recorders because of the backlight control 11.58.48 # <[IDC]Dragon> when I did my software TX for the alpine plugin, I had to change all code using PBH to atomic and/or instructions 11.59.15 # On players, it is also impossible due to the lack of sound level info from the mas 11.59.47 # <[IDC]Dragon> you can do a hardware mod to have software brighness control 12.00.24 # <[IDC]Dragon> by changing the frequency which the RTC uses to drive the pin 12.00.56 # Yes, but then the plugin would only be for those geeks who mod their hardware 12.01.12 # <[IDC]Dragon> as with all hardware mods, yes 12.02.07 # Too bad i2c even uses PBL; making this interrupt-save would require reverting the lcd driver to an ultra-slow version :( 12.02.19 # *safe even 12.02.48 # <[IDC]Dragon> not ultra-slow, but the way we had it, with locking interrups per byte 12.03.35 *** Saving seen data "./dancer.seen" 12.04.40 # This would still be considerably slower than it is now, because in addition to the int en-/disabling the precalculation has to be done for every byte then 12.05.40 # <[IDC]Dragon> lunchtime 12.07.45 # me too 12.12.07 # mmmmmmm, foood 12.12.12 Nick BlueChip is now known as BC|food (~bluechip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com) 12.24.48 # anyone know how to get the fonts out of cvs? 12.25.04 Nick BC|food is now known as BC (~bluechip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com) 12.26.32 # BC: cvs co fonts 12.27.21 # thanks 12.27.29 # you might like to add that to: http://rockbox.haxx.se/twiki/bin/view/Main/UsingCVS 12.27.39 # and maybe rockbox-devel ? 12.28.31 # yup 12.29.20 # I transcribed and edited Linus' real-time tutorial this morning - I'm sure that'll help people :) 12.30.04 # nice 12.30.30 # I emailed it to linus for proof reading 12.32.00 # would you like a copy? 12.36.04 # nah, i'll let him do the work ;) 12.36.19 # lol :) 12.48.54 Quit ze (anthony.freenode.net irc.freenode.net) 12.48.54 NSplit anthony.freenode.net irc.freenode.net 12.48.54 Quit Bagder (anthony.freenode.net irc.freenode.net) 12.48.54 Quit Hes (anthony.freenode.net irc.freenode.net) 12.48.54 Quit dwihno (anthony.freenode.net irc.freenode.net) 12.48.54 Quit Ka_ (anthony.freenode.net irc.freenode.net) 12.50.14 NHeal anthony.freenode.net irc.freenode.net 12.50.14 NJoin Bagder [241] (~dast@labb.contactor.se) 12.50.14 NJoin ze [20] (psyco@adsl-67-123-40-187.dsl.lsan03.pacbell.net) 12.50.14 NJoin Ka_ [0] (~tkirk@pcp04776551pcs.howard01.md.comcast.net) 12.50.14 NJoin dwihno [0] (~dw@81.8.224.89) 12.50.14 NJoin Hes [0] (~hessu@he.fi) 13.00.18 Join pfavr [0] (~Peter_Fav@c076102a.s-oe.bostream.se) 13.00.19 # <[IDC]Dragon> back again 13.00.33 # re Jörg 13.02.15 Quit Hes (anthony.freenode.net irc.freenode.net) 13.02.15 Quit dwihno (anthony.freenode.net irc.freenode.net) 13.02.15 Quit Bagder (anthony.freenode.net irc.freenode.net) 13.02.15 Quit Ka_ (anthony.freenode.net irc.freenode.net) 13.02.15 Quit ze (anthony.freenode.net irc.freenode.net) 13.03.31 NJoin Bagder [241] (~dast@labb.contactor.se) 13.03.31 NJoin ze [20] (psyco@adsl-67-123-40-187.dsl.lsan03.pacbell.net) 13.03.31 NJoin Ka_ [0] (~tkirk@pcp04776551pcs.howard01.md.comcast.net) 13.03.31 NJoin dwihno [0] (~dw@81.8.224.89) 13.03.31 NJoin Hes [0] (~hessu@he.fi) 13.24.33 Quit Nibbler (Read error: 54 (Connection reset by peer)) 13.30.21 Quit pfavr ("ChatZilla 0.9.52B [Mozilla rv:1.6/1]") 13.53.21 Join darbsllim [0] (jirc@u80n84.syd.eastlink.ca) 13.53.34 Quit darbsllim (Client Quit) 13.53.44 Join darbsllim [0] (jirc@u80n84.syd.eastlink.ca) 13.53.48 # hey 13.53.53 # hi 13.53.53 # hey 13.54.14 # what's going on with the av300 hacking scene? 13.54.40 # => avos.sf.net 13.55.39 # ah, cool, thanks =) 13.56.12 # holy crap! 13.56.20 # they've got a lot since I've last checked! 13.56.41 # last time I checked they were having problems from Archos trying to 'dissuade' them from going ahead with the project 13.57.23 # yeah, we kind of helped them out of that :) 13.58.05 # yeah? Awesome, what did you guys do? 13.58.12 # I keep getting a message saying: 13.58.31 # ###### Unregistered copy, evaluation only. 13.58.40 Quit AciD` (Read error: 54 (Connection reset by peer)) 13.58.43 # we wrote and released our own descrambler, so archos couldn't bitch on avos about that 13.58.44 # ###### Please ask webmaster to register it. 13.58.45 # darbsllim: use a proper irc client instead 13.59.43 # sounds good 13.59.44 # heh 13.59.49 Quit darbsllim ("Leaving") 14.00.26 Join darbsllim [0] (darbsllim@u80n84.syd.eastlink.ca) 14.00.33 # much better 14.00.37 # :-) 14.00.40 # guys, is the currently playing track stored in variable "id3" ? 14.00.51 # depends on where you look :) 14.01.40 # hmmm. i want to get the path of the currently playing track 14.01.48 # from where? 14.01.59 # are you writing a plugin, or patching the wps? 14.01.59 # struct mp3entry *id3 = mpeg_current_track(); 14.02.02 # so you guys wrote a descrambler? What's that for, might I ask? 14.02.14 # ta bagder 14.02.22 # darbsllim: archos firmwares are scrambled to prevent us from doing things like this 14.02.31 # zagor: using this for context sensitive wps stuff 14.02.49 # c0utta: ok. see bagder's note then 14.03.38 *** Saving seen data "./dancer.seen" 14.04.22 # so you wrote a descrambler so that archos doesn't have to reveal their secrets to us? They don't have to worry about someone using their code or something? 14.05.03 # Arhos never had to do anything 14.05.23 # they do worry anyway though ;-) 14.05.26 # darbsllim: they don't have to worry, since using their code would be illegal 14.06.15 # but they were threatening avos over their descrambler for multimedia, that's why I decided to write my own and release it. to call their bluff. 14.08.04 # Yay for Z! 14.08.43 Join AciD` [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) 14.09.07 # oh, hah, awesome man...good goin =P 14.09.18 # tonnes of people signed that petition and they haven't responded yet or what? 14.09.35 # i guess not. i never expected they would. 14.09.48 # I would be very surprised if they did 14.12.10 # ah wel 14.12.24 # so when do you guys think the avos will be up and running? 14.12.41 # depends on what you want. it is up and running already. 14.12.59 # but last I heard, they did not plan to make a better mp3 player firmware 14.13.17 # their plan was to get linux running and thus get a pocket computer of sorts 14.13.33 # but that was a while ago, it may have changed 14.14.21 # i'd like to use their research to port Rockbox to it, but I don't seem to ever get some spare time :( 14.15.36 # that would be awesome. The av300 has so much potential 14.15.56 # it's such a beast, hah...you could probably make a mouse for it too eh 14.16.25 # and if people were dedicated enough, I bet it could be turned into like a portable internet phone and stuff 14.16.33 # yes, but it also has a lot of secrets. the documentation is very hard to get, so programming for it can be troublesome. it is unclear if we could ever make it play movies, for instance 14.18.20 # yeah I guess there's nothing really out there like it 14.18.35 # it must be like trying to learn a new language without help or references 14.18.37 # 0th January 2004 dogger 14.18.37 # Have bought a PDA keyboard, and successfuly used it on the av300 14.18.47 # that's awesome 14.18.56 # darbsllim: ...and without ever hearing or reading it 14.21.47 # yeah, like a blind man fumbling in a beautiful flaural greenhouse for a seed 14.22.17 # let's keep playing the metaphore game 14.22.19 # haha, jk 14.22.55 # hehe 14.23.51 # so how long has rockbox been around, like 3 or 4 years hasn't it? 14.25.14 # the name was set in jan 2002 14.25.33 # the efforts started for real in dec 2001 14.26.27 # May 3rd 2002: "We have sound." 14.26.41 # =P 14.27.47 # that's awesome guys. I know it probably doesn't mean much coming from a stranger, but I'm glad there's people like you guys to do work like this. I hope the av300 hacking project goes as good as rockbox. 14.28.26 # me too 14.29.18 # tomorrow there's the 2 year aniversary for sound on the recorder! 14.29.21 # I hope that we can get things like better recording resolution...i'm not a fan of the old mpeg4 14.31.40 # but also, being able to use it like a computer 14.31.43 # that's crazy 14.31.52 # so has there been any new advancments in the rockbox os lately? 14.31.59 # pong! 14.32.03 # * Bagder giggles 14.32.30 # the file/plugin association was the latest major change 14.32.41 # nothing really fancy for a while 14.32.55 # (it's rather hard to beat [IDC]Dragon's movie player... ;) 14.33.05 # and jpeg viewer 14.33.13 # * [IDC]Dragon giggles 14.33.31 # I think the grayscale framwork is rather cool too 14.34.14 # yeah 14.34.26 # lib support for plugins is new 14.34.38 # a real crowd-pleaser 14.34.53 # a movie player eh? 14.34.58 # cool 14.35.04 # yup 14.35.14 # other than that I don't know much about what you guys just said 14.35.14 # haha 14.35.28 # we can play movies on the mp3 players, but not on the movie devices ;) 14.39.59 # haha 14.43.57 Join morano2 [0] (morano2@diderot-11-82-224-182-35.fbx.proxad.net) 14.44.29 Join lImbus [0] (~manuel@kernel.cycos.net) 14.45.35 Quit morano2 (Client Quit) 14.46.12 Join morano2 [0] (morano2@diderot-11-82-224-182-35.fbx.proxad.net) 14.46.15 Quit AciD` (".L") 14.49.19 Join AciD` [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) 14.50.26 Quit darbsllim () 14.51.32 # whee, xclef firmware is plain-text 14.51.43 # "FM->BM Firmware Read OK! & Firmware Upgrade..." 14.53.32 # "Powerdown status received from Fm..." 14.54.13 # "Ogg init start" 15.02.10 # Zagor: That's the way it should be 15.02.14 # yup 15.02.22 # makes me all warm :) 15.02.38 # <[IDC]Dragon> ;-) 15.02.48 # now the only question is: how can it recover from a failed upgrade? 15.03.06 # <[IDC]Dragon> uart-boot? ;-) 15.03.33 # well there must be some way, or they are in for very expensive support 15.03.38 Join Nibbler [0] (nibbler@port-212-202-78-119.dynamic.qsc.de) 15.03.43 # <[IDC]Dragon> well, maybe it doesn't update all 15.04.01 # it does. i read the upgrade instructions for this firmware file. 15.04.17 # you just copy it to the disk, in a specific directory. boot up, and it reflashes and reboots. 15.04.36 # <[IDC]Dragon> maybe a bootloader stays, which includes file read this time 15.05.07 # we'll have to ask roland to break un upgrade ;) 15.05.10 # an 15.05.47 # <[IDC]Dragon> Roland, can you please cut the power while it updates? 15.06.00 # :) 15.17.11 Quit morano2 () 15.25.34 # Captain Linus passed his exam 15.26.22 # <[IDC]Dragon> yeah 15.27.19 # * [IDC]Dragon whistles some sailing tune 15.28.44 Quit AciD` (".L") 15.30.43 # "Troubleshooting: Q: The operating time is noticeable shorter than normal. A: Replace the battery with a new one" !!! 15.31.17 # does that mean they sell spare batteries? 15.31.53 # <[IDC]Dragon> still fascinated by the xclef? 15.32.02 # yeah, it looks like it could be fun 15.32.37 # <[IDC]Dragon> Bad boy: you haven't finished your AV3x0, but crave for a new toy. 15.32.40 Join AciD` [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) 15.32.43 # haha 15.33.28 # <[IDC]Dragon> how does size&weight compare to the Gmini220? 15.33.38 # i'll check 15.33.49 Part Bagder 15.35.31 # "Recording time : 68hours at 128 Kbps" what limit is that? hardly battery life, and definitely not disk space... 15.36.30 # gmini220: 67,5 x 78 x 23 mm, 170 gram 15.37.00 # xclef hd800: 66.5 x 99.5 x 22 mm 15.37.27 # looking for weight 15.38.33 # 180 gram 15.38.46 # <[IDC]Dragon> aha, thanks 15.38.58 # have you found any hardware info about the gmini220? 15.39.06 # <[IDC]Dragon> a bit longer, 10gram more 15.39.20 # <[IDC]Dragon> like what? 15.39.32 # cpu, dsp etc. photos ideally. 15.39.41 # is it the same as the bigger gmini? 15.39.51 # <[IDC]Dragon> I think so, yes 15.39.53 # ok 15.40.28 # <[IDC]Dragon> it uses a different kind of 1.8" drive, the "half-brick" 15.40.59 # <[IDC]Dragon> like our 2.5", but cut in half 15.41.31 # right, same as rio karma 15.42.13 # <[IDC]Dragon> the xclef seems to use the pcmcia type 15.42.22 # <[IDC]Dragon> like the ipod 15.42.40 # yeah 15.43.16 # <[IDC]Dragon> maybe it can be upgraded to 40GB with a "spacer ring" for the enclusure ;-) 15.43.43 # there are 60gig disks available already 15.43.53 # probably cost an arm an a leg though :) 15.44.00 # <[IDC]Dragon> imressive 15.44.12 # <[IDC]Dragon> impressive, I mean 15.45.13 # did you say there's a new arm-based gmini on the way? 15.45.59 # <[IDC]Dragon> yes, to tackle DRM 15.46.18 # <[IDC]Dragon> they need more horsepower for that 15.49.57 Join RV|WRK [0] (~RobVoxWrk@host217-35-84-54.in-addr.btopenworld.com) 15.50.08 # hello all 15.50.12 # ne1 in ? 15.50.14 # hi 15.50.29 # can i ask a really daft question ? 15.51.11 # bearing in mind i dont use linux at all, how do i apply a patch ? 15.51.42 # have you read http://rockbox.haxx.se/twiki/bin/view/Main/WorkingWithPatches ? 15.52.05 # yes 15.52.14 # do i have to patch the sorce code and then compile the patched source 15.52.17 # then you need to ask a more detailed question :) 15.52.22 # yes 15.52.35 # :) thought so 15.52.54 # easy in linux bit more involved in win 15.54.22 # like most things :) 15.55.56 # lol im not going into that argument 15.56.15 # chicken ;) 15.57.31 # i would really like to use linux but it would take me 10 mins longer to do everything as i am a complete noob, personally, i dont need most of the stuff that linux can do so i stick with win 15.58.19 # doing this compiling is the 1st time that ive NEEDED linux 16.02.44 Join Ski1 [0] (~jirc@205-156-36-12.ssmcnet.noaa.gov) 16.03.39 *** Saving seen data "./dancer.seen" 16.03.50 # hello 16.08.31 # hi 16.09.48 # i assume the source is in C, what processor ? 16.12.45 # RV|WRK: sh7034 16.13.02 # a.k.a Hitachi sh-1 16.13.33 # ok will try to find a w32 compiler for it 16.14.32 # http://rockbox.haxx.se/twiki/bin/view/Main/DevelopmentGuide 16.15.27 # christ ! ta 16.43.10 # has anyone had a trouble with their archos where it won't shutoff? 16.43.21 # Ski1: do you have your charger connected? 16.43.34 # no 16.43.43 # yesterday, I had the charger plugged in 16.44.02 # and then I pulled it out and instead of shutting like it normally would, it started up 16.44.18 # and then later when I held down the off button, it wouldn't turn off 16.44.24 # I had to pull out a battery 16.44.27 # odd 16.44.39 # and as soon as I put the battery back in, it starts back up! 16.45.01 # they do taht 16.45.02 # that 16.45.19 # <[IDC]Dragon> cu later 16.45.24 # oh, I didn't know that. I haven't had it long enough to have to replace the batteries yet 16.45.25 Quit [IDC]Dragon ("no fate but what we make") 16.45.40 # Ski1: trust me. i've had mine since 2001 :) 16.45.55 # I never said you were wrong :) 16.47.40 # I just want it to shut off :( 16.47.59 # I tried turning on the idle shutdown, but it still didn't turn off 16.53.22 # are you still having this problem? 17.02.53 # oh wait, actually instead of turning off after the idle poweroff time limit, it froze 17.03.00 # yeah I still am 17.05.21 # which model do you have? 17.07.57 Quit Ski1 (anthony.freenode.net irc.freenode.net) 17.07.57 NSplit anthony.freenode.net irc.freenode.net 17.11.49 Part RV|WRK 17.17.21 NHeal anthony.freenode.net irc.freenode.net 17.17.21 NJoin Ski1 [0] (~jirc@205-156-36-12.ssmcnet.noaa.gov) 17.20.41 # Zagor: which xclef are you dealing at ? 17.20.46 # the hd-800 17.20.50 # looking at / dealing with 17.20.58 # ok, tnx. looking for pics 17.21.11 # but the hd-500 appears *very* similar, so if we decide to work on it we can probably support both with little extra effort 17.21.45 # http://rockbox.haxx.se/twiki/bin/view/Main/XclefInfo 17.24.06 # 120 Mhz ? should be able to decode ogg then 17.24.44 # yes it can 17.25.57 # and fuck these devices actually LOOK good. no compare to the clumsy AJB 17.26.24 # have you ever heard of that problem Zagor? 17.27.14 # Ski1: yes, i have a vague recollection of it. not sure what, if any, we made of it though 17.30.19 # gotta go 17.30.21 Part Zagor 17.54.07 Join jakesir [0] (jakesir@pool-141-157-116-157.balt.east.verizon.net) 18.03.43 *** Saving seen data "./dancer.seen" 18.05.29 Join Doensen [0] (~Doensen@228-34.240.81.adsl.skynet.be) 18.07.37 # hi Doensen. all right ? 18.17.42 # can anyone tell we the cause why a NEW AJBR20 (with usb2 and all the stuff) shows ?? on hw-info-flash ? 18.18.00 # that would mean it is not flasheable 18.20.30 Quit Ski1 ("Leaving") 18.22.08 # lImbus: Talking to yourself? 18.27.32 # amiconn: I would be glad if somebody could answer me :-) 18.28.14 # I mean: these are NEW, why should they not be flasheable ? 18.30.35 # Iirc this has nothing to do with old vs. new, but only what type of flash chip Archos had available for production 18.30.51 Join Ski1 [0] (~jirc@205-156-36-12.ssmcnet.noaa.gov) 18.34.39 # grrrrrrr 18.35.04 # I should take in consideration to solder in a new chip then 18.58.21 Quit lImbus () 19.02.22 Join midk [0] (Zakk@c-67-160-88-198.client.comcast.net) 19.15.04 Join mecraw_ [0] (~mecraw@69.2.235.2) 19.16.55 Quit Ski1 ("Leaving") 19.21.45 Quit jakesir () 19.35.29 Join morano2 [0] (morano2@diderot-11-82-224-182-35.fbx.proxad.net) 19.38.33 Join Lear [0] (~Lear@h192n7c1o1019.bredband.skanova.com) 19.53.35 Part Lear 20.03.44 *** Saving seen data "./dancer.seen" 20.04.31 Quit morano2 () 20.20.09 Join ka [0] (~tkirk@65.216.194.2) 20.28.52 Join Neurosupherot [0] (~f@AStrasbourg-106-1-27-44.w81-250.abo.wanadoo.fr) 20.28.56 # hi 20.29.07 Part amiconn 20.38.04 Quit ka ("Leaving") 20.46.15 Join amiconn [0] (~jens@pD9E7F0B4.dip.t-dialin.net) 20.48.36 Join mecraw__ [0] (~mecraw@69.2.235.2) 20.54.48 Quit mecraw_ (Read error: 60 (Operation timed out)) 20.54.55 Join uski [0] (~uski@gandalf.digital-network.org) 20.55.14 # moo 20.56.11 # hi 20.56.36 # I'm busy doing my hd upgrade... 20.56.42 # whatsup :) 20.56.45 # ooo 20.56.47 # you're lucky :) 20.56.58 # oohyah 20.57.00 # i'm waiting for my solder paste so as to upgrade my RAM and the FLASH 20.57.13 # (with my new hot air soldering gun :)) 20.57.19 # Next thing I want to do is the white backlight mod 20.57.25 # mwehehe 20.57.27 # ooh white backlight 20.57.29 # i think i'll do that first 20.57.30 # looks a bit hard 20.57.31 # it's very easy 20.57.34 # nope 20.57.35 # i like that idea though 20.57.38 # oh, 20.57.43 # is there a page tutorial? 20.57.45 # midk you jsut have to rewire a bit the leds 20.57.50 # yes a tutorial! 20.57.52 # hmmm i may write one ;) 20.57.54 # i will be great! 20.57.56 # go uski 20.58.00 # but it's not because there is a tutorial that it will be easier 20.58.00 # i want to do it 20.58.10 # actually if you have the required skills to do that you don't need a tutorial 20.58.27 # if you need a tutorial, it means that you have 0 electronic experience and i wouldn't recommand you to do the mod' then 20.58.29 # just not sure what i need to get or what i need to do 20.58.41 # i wonder what effect will produce white leds 20.58.54 # oh, i thought you meant replacing the leds 20.58.56 # i never see white backlight 20.58.59 # 4 white SMD leds, forward voltage 3.6-3.8V, package size "1206" 20.59.16 # where can you cuy it? 20.59.18 # buy 20.59.22 # www.digikey.com 20.59.29 # www.ebay.com, some ppl sell them for mobile phones 20.59.52 # i also bought 2 orange leds to replace the red/green ones 21.00.08 # black bumpers, gray box, orange leds, and white backlight = very cool look i think ;) 21.00.15 # orange and gray is a very cool color combination 21.01.21 # blah 21.01.22 # guess what 21.01.25 # i'll do that this evening :P 21.01.31 # lemme take my digital camera ;) 21.01.40 # :D 21.02.00 # will you put the tutorial and the photos on the rockbox site? 21.02.01 # i have it 21.02.03 # see ya :P 21.02.07 # gimme 2 hours 21.02.08 # probably ;) 21.02.30 # it'll be another contribution from me for rockbox, but the first that is clearly "visible" :) 21.02.33 # i hope you'll apreciate it 21.02.34 # brb 21.04.59 # :) 21.05.18 # what is milicandela rating ? 21.05.52 # i want to see 21.13.04 # Neurosupherot: If you want an impression how white backlight will look, see http://joerg.hohensohn.bei.t-online.de/archos/backlight.jpg 21.13.05 # there is so many colors that i dont know what to choose if ill buy it 21.13.37 # OMGZ 21.13.44 # i want the one in the middle 21.14.09 # GREAT!! 21.14.12 # thx 21.14.24 # go uski 21.14.40 Join diddystar5 [0] (~lee@IC104.library.oregonstate.edu) 21.14.58 # i dont think that put differents colors will be great effect 21.15.47 # and i hesitate to change leds because i dont wanna destroy my archos 21.19.04 Quit adi|home (Client Quit) 21.24.57 Join [IDC]Dragon [0] (~idc-drago@p50861A2A.dip.t-dialin.net) 21.25.05 # hi Jörg 21.25.11 # hi idc 21.25.16 # <[IDC]Dragon> hi Jens 21.25.26 # <[IDC]Dragon> did I miss uski? 21.25.28 Join jakesir [0] (jakesir@pool-141-157-116-157.balt.east.verizon.net) 21.25.46 # [IDC]Dragon: yes (but he said brb) 21.25.48 # <[IDC]Dragon> jake has got a trigger on me 21.26.05 # <[IDC]Dragon> scripted? ;-) 21.26.07 # hi 21.26.11 # hmmmm 21.26.12 # I just upgraded my hd (only have to close the box again) :)) 21.26.13 # i don't know 21.26.34 # <[IDC]Dragon> jakesir: ho's it going? 21.26.44 # not good 21.26.49 # not much progress 21.26.56 # I cut that line 21.27.04 # and connected to ground 21.27.28 # put it together and when pressing on 21.27.55 # <[IDC]Dragon> it exploded? 21.27.59 # i see light come on and running boot doesn't work 21.28.23 # with this setup, my hd doesn't start smooth 21.28.28 # <[IDC]Dragon> boot=serial boot, or Archos? 21.28.29 # btw: The bug in Rockbox (booting from flash) when the drive is completely empty is still there - it says "panic! disk: null" and USB is not usable. 21.28.44 # it starts and stops several times and finally stays on 21.29.32 # <[IDC]Dragon> starts and stops? flaky power? 21.29.37 # but running uart_boot doesn't get me any where 21.29.41 # yeah 21.30.08 # <[IDC]Dragon> amiconn: is F1+On giving you USB? 21.30.23 # Yes, I knew that solution. 21.30.25 # so, i was worried about my soldering job I tested with running that wire to 3v source and same thing 21.30.58 # <[IDC]Dragon> amiconn: not meant as a solution, but as diagnostics 21.31.00 # so, i resolder it back to the original and it's acting normal 21.31.05 # The Archos firmware is more clever in that case: It says that there is no partition and that you have to format the drive 21.31.43 # <[IDC]Dragon> amiconn: interesting report 21.32.17 # so, my question is... How do i let it serial boot? 21.32.19 # <[IDC]Dragon> can you fix it and commit an update? ;-) 21.32.34 # <[IDC]Dragon> jakesir: one moment please 21.33.18 # ok.... at least I know my soldering is OK 21.33.22 # <[IDC]Dragon> amiconn: hard for "normal" developers to reproduce and test that 21.33.36 # I'm gonna seperate that point again 21.35.03 # can we change the voltage délivered to the backlight's leds? 21.36.40 # [IDC]Dragon: As I told you earlier I also want to change the leds. I measured the size of the original ones (as I want to use a similar size) 21.37.38 # The original leds are close to 0805. It is a bit difficult to get white 0805 leds. (I don't want to resort to ebay) 21.38.09 # uski> 4 white SMD leds, forward voltage 3.6-3.8V, package size "1206" 21.38.48 # I found one German provider for them, however they only sell to business customers. I'll see how I can solve that. 21.39.49 # <[IDC]Dragon> amiconn: why not ebay? 21.40.56 # I don't like ebay, and have neither bought nor sold anything on ebay up to now. 21.41.11 # <[IDC]Dragon> I did many times 21.41.17 # <[IDC]Dragon> (buy) 21.41.24 # <[IDC]Dragon> was OK every time 21.42.01 # (1) I don't like auctions in general. (2) I hate all those ebay popup and banner ads. 21.42.20 # <[IDC]Dragon> how about 50 LEDs for EUR13? 21.42.54 # <[IDC]Dragon> that's true, they pollute the internet and google search results 21.45.44 # <[IDC]Dragon> jakesir: what exactly happens if you enable uart boot? 21.46.11 # <[IDC]Dragon> (it should just appear frozen, disk spinning) 21.46.29 # it looks frozen 21.47.01 # <[IDC]Dragon> ok, does it react to uart_boot? 21.47.07 # maybe the battery is destroyed? 21.47.09 # no 21.47.41 # <[IDC]Dragon> with what command line? 21.47.54 # just about any command 21.48.01 # i don't think it's responding 21.48.17 # <[IDC]Dragon> it has to 21.49.14 # uart_boot -r -p COM1 -h -b 21.49.26 # <[IDC]Dragon> you have to set up the serial wiring fist, the switch it on with in uart boot mode, then run the command 21.50.24 # <[IDC]Dragon> looks ok 21.50.37 # yeap, and it's saying downloading monitor.... 21.50.41 # forever 21.51.09 # <[IDC]Dragon> ah, and FMs as I know then shut down a few moments after you release On 21.51.23 # <[IDC]Dragon> is that the case? 21.51.28 # and if I let go ON, then the whole thing shuts off 21.51.44 # <[IDC]Dragon> you need to hold On until the command is through 21.51.44 # and I get the message saying... 21.52.01 # error tranmitting monitor byte 0x48, got 0x0 21.52.24 # <[IDC]Dragon> yes, tlking to an off box is no good 21.52.28 # <[IDC]Dragon> talking 21.52.42 # lol 21.52.54 # how long do i wait? 21.53.03 # 'til it's finished talking? 21.53.12 # I held it on for more than 1-2 min 21.53.14 # <[IDC]Dragon> maybe your serial out from the box is not working? 21.53.27 # i tested with teraterm 21.53.43 # <[IDC]Dragon> yes, but only your adapter 21.53.59 # <[IDC]Dragon> we don't know if the serial mod is OK 21.54.17 # i wish I can send this to ya 21.54.36 # this thing is bugging the hell out of me 21.54.49 # <[IDC]Dragon> usually, the start phase of uart_boot (downloading the monitor) is pretty quick, a few moments 21.55.12 # <[IDC]Dragon> where are you located? 21.55.16 # is your warranty always ok? 21.56.05 # in maryland,usa 21.56.22 # <[IDC]Dragon> not very practical 21.56.27 # washington DC 21.56.34 # your in europe 21.56.36 # <[IDC]Dragon> I know, been there 21.56.44 # bye, thankx and rockbox rocks! 21.56.49 Quit Neurosupherot () 21.57.00 # <[IDC]Dragon> I'm in germany, yes 21.58.55 # i'm running out of ideas.... LOL 21.59.13 # let me recapture this setup 21.59.17 # <[IDC]Dragon> triple-check your serial mod 21.59.32 # Evenin all ...does anyone know who "kjer" is ...it is who cvs'd the chess clock? 21.59.50 # my next plan is to get external power to the max3232 22.00.14 # and if that doesn't work, I'm done, I'll use jbr w/o rockbox 22.00.18 # arghhhhhhh 22.00.38 # BC: ...does anyone know who "BlueChip" is ... ;) 22.00.39 # <[IDC]Dragon> BC: Kjell Ericson 22.00.58 # <[IDC]Dragon> rumplestiltskin 22.01.30 # what is the chess clock anways 22.01.40 # ohh 22.01.43 # He just commented "no simulator environment" and I wanted to track him down and correct the problem 22.02.03 # my set up is... from resistor to ground and press and hold ON button, run the command line 22.02.06 # <[IDC]Dragon> jakesir: I understand your frustration 22.02.06 # is that right? 22.02.15 # thaks guys 22.02.30 # <[IDC]Dragon> jakesir: yes 22.02.32 # can you have not enough power to max3232 22.02.54 # let me check the operating voltage 22.02.55 # <[IDC]Dragon> your loopback worked, so I guess it's OK 22.03.33 # argggggghhhhh 22.03.46 *** Saving seen data "./dancer.seen" 22.03.48 # <[IDC]Dragon> ? 22.03.59 # kicking myself.... 22.04.00 # lol 22.04.32 # [IDC]Dragon ...did you find some kind of hui (even text mode gui) for gdb? 22.05.13 # <[IDC]Dragon> yes. cygwin or win32? 22.05.31 # <[IDC]Dragon> hui = hellish user interface 22.05.35 # cygwin 22.06.07 # thanks 22.07.06 # <[IDC]Dragon> BC: type "insight" into the shell 22.07.09 # lol - just googled for HUI ....I think I need more caffeine 22.08.11 # Grrr, so many windows, so little desktop space... 22.09.58 Quit Doensen (Read error: 104 (Connection reset by peer)) 22.10.15 # [IDC]Dragon: "insight" ...I shall have to install it, is it part of the gdb package? 22.10.36 # <[IDC]Dragon> part of cygwin, I guess 22.13.30 # hmmm, do you think the baud is too fast and that the jbr doesn't receive?? 22.13.48 # <[IDC]Dragon> no 22.14.08 # <[IDC]Dragon> you don't have a choice of baudrate, it's fix 22.14.26 # what the rate at? 22.14.53 # <[IDC]Dragon> it starts with a very weird rate, the switches to 115200 22.15.02 # hmmm 22.15.06 # <[IDC]Dragon> s/the/then 22.18.32 # sorry to ask, but are you sure this uart boot works on JBR2? 22.20.46 # <[IDC]Dragon> it's an FM, yes 22.20.54 # no 22.21.01 # it's jbr2.0 22.21.09 # <[IDC]Dragon> or you have a ROM-less box 22.21.15 # but the board says jbr-fm v2.2 22.21.17 # <[IDC]Dragon> then it won't work 22.21.52 # <[IDC]Dragon> let's check for ROM-less 22.22.14 # ok 22.23.21 # * [IDC]Dragon looks for the FM PCB scan on haxx 22.24.05 # http://joerg.hohensohn.bei.t-online.de/archos/uart_boot/FM_Overview.jpg 22.24.41 # one interesting thing is that the box starts normal with the uart boot mod w/o wire connected to GND 22.24.59 # <[IDC]Dragon> it does? 22.25.12 # <[IDC]Dragon> didn't you say it freezes? 22.25.20 # when I say normal, it only starts in archos mode with F1+on 22.25.47 # <[IDC]Dragon> w/o, sorry 22.25.50 # when I press just ON, it looks as if frozen 22.26.14 # <[IDC]Dragon> so, wire to Gnd: freeze, wire open or to 3V: normal start? 22.27.11 # let me re-phrase 22.27.38 # wire to nothing: ON= freeze, ON+F1=archos 22.28.23 # wire to GND: ON=freeze, On+F1=freeze 22.29.12 # <[IDC]Dragon> looks good then 22.29.12 # with wire to nothing+ON+F1, after it loads i can release ON and it'll stay on 22.29.29 # LOL 22.29.55 # <[IDC]Dragon> good=having a boot ROM reacting to the pulldown 22.31.02 # so, my boot_mod is good, level converter is good..... 22.31.08 # connections are good.... 22.31.14 # running out of idea... 22.31.44 # <[IDC]Dragon> repeating myself: I suspect your serial mod 22.31.53 # lol 22.32.14 # how much power do i need on tx/rx end to talk to jbr> 22.32.23 # > = ? 22.32.47 # <[IDC]Dragon> nothing significant 22.32.49 # talking about pin 11 & 12 end on max3232 22.33.04 # ~3v is enough? 22.33.19 # <[IDC]Dragon> worst case, you drive a 1kOhm pullup, so 3mA 22.33.32 # <[IDC]Dragon> voltage is 3V, yes 22.40.07 # about that rom less, mine look almost like that picture 22.40.21 # except for FM daughter board 22.41.01 # bye all 22.41.09 Quit midk ("yo yo yo cya later YO YO YO wasa wasa!") 22.41.12 # l8rz mk 22.44.28 Part BC 22.48.55 # <[IDC]Dragon> jakesir: have a look at this one: http://rockbox.haxx.se/internals/fmrec_bottom_hires.jpg 22.50.02 # looks same except for FM daughter board 22.50.16 # <[IDC]Dragon> I know. 22.50.34 Join BC [0] (~bluechip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com) 22.51.04 # <[IDC]Dragon> I'd like to direct you to a detail, do you see your board now? 22.51.28 # yeap 22.51.59 # <[IDC]Dragon> below the right pin row of the flash, there are 3 open pads 22.52.15 Join mattzz [0] (~mattzz@c227176.adsl.hansenet.de) 22.52.29 # <[IDC]Dragon> under those is a resistor array, similar to that you soldered to 22.53.13 # <[IDC]Dragon> do you see the 3 pads (in a kind of triangle) ? 22.53.52 # hmmm 22.54.42 # <[IDC]Dragon> looking at the picture, not necessarily your board 22.54.51 # flash = 39VF020?? 22.54.59 # <[IDC]Dragon> yes 22.55.34 # right = right when upsided down or right sided down 22.55.52 # <[IDC]Dragon> I was referring to the picture 22.55.54 Quit diddystar5 (Read error: 104 (Connection reset by peer)) 22.55.57 # ok 22.56.13 Join diddystar5 [0] (lee@IC104.library.oregonstate.edu) 22.56.27 # <[IDC]Dragon> found the pads? 22.56.49 # i think so... right next to 000 resistor 22.56.59 # <[IDC]Dragon> exactly 22.57.22 # <[IDC]Dragon> are those pads empty at your PCB, too? 22.57.54 # well the 3 squares are with solder 22.57.56 # <[IDC]Dragon> and the 0 Ohm resistor present? 22.59.01 # yes, 000 resistor I'm thinking it's 1K?, is present 22.59.25 # <[IDC]Dragon> and no component on the 3 pads? 22.59.27 # but on the picture only right square is with solder, mine has all of them with solder 22.59.28 # bye bye 22.59.37 # other than that, everything is same 22.59.41 # <[IDC]Dragon> that won't matter 22.59.54 Quit diddystar5 (Client Quit) 22.59.59 # <[IDC]Dragon> then you have a box with boot ROM, for sure 23.01.06 # <[IDC]Dragon> because the ROM-less ones need a double-diode there, and no 0 Ohm resistor 23.02.06 # ok, that's a good news than 23.10.42 Part BC 23.15.47 Quit midk|gone (Read error: 104 (Connection reset by peer)) 23.15.52 Join midknight2k3 [0] (~Zakk@c66-235-14-120.sea2.cablespeed.com) 23.26.38 Join hardeep [0] (1098@208.247.65.237) 23.49.23 Quit Nibbler (Read error: 54 (Connection reset by peer)) 23.55.38 Quit mecraw__ ("Trillian (http://www.ceruleanstudios.com)") 23.57.45 # im bavck 23.57.46 # -v 23.57.57 # i did my backlight mod' 23.58.02 # but i changed my initial plans 23.58.10 # instead of doing white B/L, orange leds 23.58.21 # i did orange backlight with white status leds 23.58.25 # why ? two reasons: 23.58.38 # 1) I prefer an orange backlight after trying 23.58.50 # (i tried with some T1 white leds to see how it would look like)