--- Log for 10.01.105 Server: niven.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 2 months and 1 day ago 00.00.23 # It thought this was temporary so I didn't care too much 00.00.37 # same as for the entire built process 00.01.16 # so why the make.inc changes? 00.01.20 # I put my changes in the diff so you can see what I've done... But I'm perfectly aware it must be changed to accomodate 00.02.16 # Well, that not strictly necessary (and I'm not sure at all it is the best method to achieve my goal) ... 00.02.38 # but since I work with an experimental compiler I often need to check the intermedate ouptuts 00.02.41 # (.i & .s) 00.02.56 # so I spliced in ad-hoc stuff 00.03.24 # fair enough, but that shouldn't be committed... 00.03.31 # sure 00.04.37 # Though if you have a clean method to generate intermediate targets that would be cool to provide it 00.05.02 # we don't 00.05.05 # Regarding the sizeof(int) problems: What about simply changing the places where 4 byte integers are necessary to use long instead? This wouldn't hurt the other platforms 00.05.09 # but I agree it would be good 00.05.25 # amiconn: I think we should do that, yes 00.06.24 # int should then be used in places where 2 bytes might be enough, but 4 bytes won't hurt either. The compiler can then decide depending on the platform 00.06.55 # Sure 00.07.12 # In this case it is often better than explicitly use short, because the code sometimes gets considerably larger. 00.07.28 # yes, we should avoid using short when int is fine 00.08.03 # I specified only u32 or s32, and only where that was necessary 00.08.25 # but still it can be replaced with long 00.08.29 # I vote for using long and unsigned long 00.08.37 # So it should be easy to replace this with unsigned long resp. long, and all would be fine. 00.08.57 # :) 00.09.33 # jyp: other minor nits: we use /* C comments */ 00.09.43 # Oh yes... 00.10.12 # When I realized that was too lazy to change before submitting the patch :P 00.10.19 # haha ;-) 00.11.16 # Also, do you insist on C style, as opposed to C99 ? 00.11.19 # Bagder: I never really got why this is a requirement, but since this is rockbox style, I stick to it. In fact, this is sometimes useful, in that I put my debugging comments in // C++ style. This way they are easy to spot. 00.11.37 # jyp: yes 00.11.55 # amiconn: it started as a requirement to make it possible to build with older plain C compilers 00.12.05 Join lImbus [0] (lImbus@200-167.244.81.adsl.skynet.be) 00.12.10 # but now it is mostly for consistent style 00.12.10 # good evening 00.12.17 # hi lImbus 00.12.21 # go for K&R style :P ;) 00.12.33 # let's not overdo it ;-) 00.15.46 # (short or char vs. int) I tried this while developing the grayscale lib, in order to slim down the control structure a bit. The code grew by more than 500 bytes, which was roughly 10% of the whole library... 00.16.41 # ...of course I reverted it. 00.16.47 # :-) 00.18.35 # jyp: does hwgmini.h really fit in the export/ dir? 00.19.05 # don't know 00.19.19 Quit pfavr ("ChatZilla 0.9.61 [Mozilla rv:1.7.5/20050105]") 00.19.23 # maybe it should not exist at and be merged with other files 00.19.35 # That's something I wanted to ask... 00.19.46 # And there's debug stuff in there too 00.19.50 # I removed the include of it from the cpu.h header file now 00.20.01 # didn't seem to fit the pattern from the other cpu includes 00.21.51 # jyp: what's the emu_ functions for in kernel.c ? 00.22.02 # hmmm; that's debug stuff 00.22.18 # want me to ignore that or move it into the tcc370 section? 00.22.21 # again I put those anywhere... 00.22.31 # ok, so I remove that for now 00.22.32 # They are spotted by the emulator 00.23.06 # which outputs the message 00.24.05 # jyp: Did you update the calmrisc gcc? 00.24.14 # yes 00.24.25 # not perfect but better than the original 00.24.47 # I currently use it to compile my stuff 00.24.48 Quit midk (Remote closed the connection) 00.27.17 # I spotted a mistake in ata.c 00.27.31 # you spelled the cpu TC730 in the initial #if 00.27.45 # mmm, that shouldn't have made it to the patch 00.28.09 # purely work in progress ;) 00.28.17 # thanks for the info though :P 00.28.50 # I'm thrilled by your fast development 00.29.20 # heh ;) 00.29.44 # We spent a lot of time preparing for a sudden jump ;=) 00.29.47 # Bagder: I have a small question concerning mp3_playback.c... 00.29.53 Join Ka [0] (~tkirk@pcp0010732484pcs.howard01.md.comcast.net) 00.30.06 # amiconn: try me! 00.30.18 # Joking aside, having a "full fledged" emulator makes things easier 00.31.22 # i'm thrilled by jyp :) 00.31.39 # ...concerning mp3_init(). Is there a reason why for MAS3507, mpeg_sound_channel_config() is called before all other settings (line 1019), while for the other MAS' it is called much later (line 1036)? 00.32.30 *** Saving seen data "./dancer.seen" 00.32.44 # oh 00.32.53 # I have absolutely no idea! ;-( 00.33.39 # that's Linus and Jörg's area 00.34.33 # jyp: in thread.c:create_thread() 00.34.43 # shouldn't there be a store_context() for tcc730? 00.34.50 # no 00.35.05 # I have a slightly different approach 00.35.10 # I need to mess with that in order to get the variable stereo width in. In fact, I even see no reason why this is a separate function, while all other settings are handled by mpeg_sound_set() 00.36.50 # Ah no, I just found that this is used both ways... 00.37.12 # jyp: any particular reason? 00.38.37 # jyp: you've added emu_debug() calls in the middle of generic code 00.38.39 # The problem faced was that I needed an address register to store the context 00.39.07 # perhaps you should use DEBUGF() for your emulator stuff 00.39.33 # since DEBUGF is already used in the cod for debug output 00.39.35 # code 00.39.36 # that was difficult so I changed it to store on the stack, which in turn led to the other changes 00.39.44 # Ok 00.39.55 # I'll use DEBUGF then 00.40.18 # Sorry, newbie here :@ 00.40.26 # no worries 00.40.54 # please don't take this as complaints, there are just remarks on how to get your code mixed with the existing in a better way 00.41.14 # Heh, alright ;) 00.50.37 Quit Ka (Read error: 60 (Operation timed out)) 00.50.51 # I don't like the 'DISKLESS' and 'NOPOWERMGT' defines in config-gmini120.h 00.51.04 # Of course 00.51.19 # that was just to make the stuff compile 00.51.37 # compiling is good! ;-) 00.51.57 # ... a requirement to run ;) 00.59.40 # I gotta go to sleep now 00.59.47 # me too 00.59.49 # I committed a bunch of files 00.59.58 # alright, thanks 01.00.02 # some of them slightly edited by me 01.00.31 # good night 01.00.40 # Shall I re-submit a cleaned up patch for the rest ? 01.00.49 # please do 01.00.53 # ok 01.00.57 # see you 01.00.59 # good night 01.01.03 # night! 01.01.11 Part jyp ("Leaving") 01.02.59 # Bagder: You broke the sim builds, and caused a warning for Ondio... 01.03.06 # I noticed 01.03.22 # I think I fixed at least some of them afterwards 01.04.43 # I wonder why it was necessary to take out the led() call from panic.c. led() was empty anyway if HAVE_LED was undefined (Ondio) 01.05.13 # I think jyp is a bit quick to remove function calls that don't do anything 01.05.37 # I'll revert that change 01.07.02 # ok, then it should get all green again 01.07.16 # I plan to add some indication for MMC activity to the Ondio version, using the led() calls that are already there to switch a flag. The status bar function would then use this flag to show an icon. 01.07.49 # Ok, maybe this is unnecessary (and even won't work) from panic.c... 01.07.56 # hehe 01.08.18 # sleep time! 01.08.35 # The MMC-USB bridge is able to signal activity to the controller, so Ondio can also show if there is activity while on USB 01.08.42 # Nite, btw 01.09.04 # nite 01.09.54 # I think I'll follow the example. Goodnight. 01.10.10 Join scott666 [0] (~18f53a30@labb.contactor.se) 01.10.20 # nite 2, amiconn 01.10.23 Part amiconn 01.10.36 Join Ka [0] (~tkirk@pcp0010732484pcs.howard01.md.comcast.net) 01.10.54 # do I read the change log correctly? is the gmini120 really supported now? 01.11.34 # there are some people working on it, yeah 01.11.59 # is it finished? or just new code in preparation for it? 01.12.01 # namely 'jyp' 01.12.09 # preparation. 01.12.22 # but they seem to work fast 01.41.04 # he is magic :) 01.42.22 Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) 01.58.33 Quit Stryke` (Read error: 110 (Connection timed out)) 02.00.04 Quit scott666 ("CGI:IRC") 02.32.31 *** Saving seen data "./dancer.seen" 02.33.08 # :) 02.42.20 # that was random 02.55.02 Quit midk ("Leaving") 03.06.18 Join lImbus_ [0] (lImbus@200-167.244.81.adsl.skynet.be) 03.07.14 Quit lImbus (Read error: 54 (Connection reset by peer)) 03.07.14 Nick lImbus_ is now known as lImbus (lImbus@200-167.244.81.adsl.skynet.be) 03.17.29 Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) 03.27.04 Join Stryke` [0] (~Chairman8@24-168-110-99.si.rr.com) 03.27.30 Quit Stryke` (Remote closed the connection) 04.32.33 *** Saving seen data "./dancer.seen" 04.36.38 Join ze__ [0] (psyco@adsl-67-123-43-94.dsl.lsan03.pacbell.net) 04.36.52 Quit ze (Nick collision from services.) 04.36.57 Nick ze__ is now known as ze (psyco@adsl-67-123-43-94.dsl.lsan03.pacbell.net) 06.17.07 # hi 06.20.52 Quit Strath ("Client closed") 06.32.34 *** Saving seen data "./dancer.seen" 06.45.16 Quit jkarns ("Leaving") 07.16.28 Join TexJoachim [0] (~TexJoachi@pD955F728.dip.t-dialin.net) 07.32.52 Join LinusN [0] (~linus@labb.contactor.se) 07.33.20 # hola señor 07.36.51 # buenos dias 08.04.08 # You got a fat directory sorting utility? :) 08.07.14 # a what? 08.12.21 # well, an utility which will sort the directories by name, as opposed to using old DOS "defrag /sn" 08.12.52 # as a kind of file system optimization? 08.13.00 # you could say that 08.13.14 # why? 08.13.34 # The iriver firmware won't do the sorting for me (dumb, dumb dumb) 08.13.55 # seriously? 08.14.17 # yeah 08.14.23 # fascinating 08.14.45 # Haven't found a menu option for it (and I've checked the entire settings menu) 08.14.51 # wow 08.15.06 # I _could_ read the manual, but something tells me I won't find anything there. 08.16.31 # you know what CPU the ifp models use? 08.17.11 # i have no idea 08.17.18 # ok 08.18.18 # As a quick test, I've reformatted the unit and now I'm copying the files to the unit chronologically 08.19.41 # Do you think there is such an utility btw? 08.21.28 # check this: http://www.geocities.com/andreigaceff/DefragNT.html 08.30.17 Quit midk ("poof") 08.32.36 *** Saving seen data "./dancer.seen" 08.41.03 Join Zagor [242] (~bjst@labb.contactor.se) 08.56.16 Join Bagder_ [0] (~daniel@1-1-5-26a.hud.sth.bostream.se) 09.10.35 Join LePoulpe [0] (~lpos@AMontpellier-251-1-31-32.w83-113.abo.wanadoo.fr) 09.11.53 # Hi all 09.11.58 # hi 09.12.02 # salut 09.12.23 Quit Bagder (Read error: 110 (Connection timed out)) 09.14.44 # oh crap, we'll need to to a monster commit to make all code 16-bit safe to run on the gmini 09.15.02 # uh 09.15.17 # * lImbus braces for commit 09.15.29 # not yet :) 09.15.34 # yeah, isn't it wonderfulö 09.16.03 # i'm not sure what I think is the least ugly way to do it 09.16.58 # typedefs for types ? or is it more cpu-specific ? 09.17.48 # i really don't like typedefs 09.18.18 # defines ? *duck* 09.18.19 # me neither 09.18.29 # i see two options 09.18.36 # 1) use typedefs 09.18.53 # 2) use "long" whenever a 32-bit type is required 09.19.48 # is there a way to influence padding and packing outside of structs ? 09.20.11 # lImbus: gcc has a few command line options for it 09.20.26 # i think 09.20.38 # as much as I dislike typedefs, 2) is far from obvious when reading the code and would likely result in many bugs 09.20.50 # probably 09.21.45 # when we started the rockbox project, it was such a relief when we didn't have to bother about 16-bit targets :-) 09.22.04 # yes 09.22.32 # and now we're back in type size hell 09.24.21 # apparently jyp didn't hit many 16bit problems yet 09.24.25 Nick Bagder_ is now known as Bagder (~daniel@1-1-5-26a.hud.sth.bostream.se) 09.25.04 # Bagder: but he/we will. so we need to think about how to handle them. 09.25.11 # indeed 09.26.10 # I think I vote for using long for 32 bits and int for 16/32 09.28.14 # * lImbus thinks a bignum-approach for > bit numbers drops out due to lack of cpu-power... 09.28.19 # i'm not sure what I think yet. i'll need to meditate over this a while. 09.28.23 # > 16 bit that is 09.28.45 # lImbus: how do you mean? 09.29.20 # well, bignums. used on "normal" architectures to handle numbers > 32 bit 09.29.35 # there, where you don't have __int and so on 09.30.01 # AND where you need precision, there where float does not meet your needs as well 09.30.13 # basically the values are stored in strings... 09.30.17 # we have no choice but to use bignums on the 16-bit platforms. we cannot (will not) rewrite all code to use 16 bits only 09.30.28 # of course 09.30.50 # plus it takes lot of cpu-power... 09.30.52 # it has 32 bit longs 09.31.13 # Bagder: ah, it does? that's good. 09.38.47 # using long will solve the problem 09.42.51 # <- checking your IriverPort page. looking mighty fine. Will everything have to be 100% before it's usable ? 09.43.36 # what do you call useable 09.43.37 # ? 09.43.47 # for music, nearly, but remote control-stuff 09.44.48 # the first version will probably not support the remote lcd 09.45.06 # playing a mp3 and listen to it, is remote support a big thing (tm) to make ? 09.45.07 # "usable" to me means "mp3 playback works" 09.45.38 # to me too 09.46.03 # remote lcd is not technically difficult, but it requires quite a lot of changes in the rockbox architecture, since rockbox currently only supports one lcd 09.46.23 Quit TexJoachim ("Bye!") 09.47.11 # the iriver remote is a completely new interface, which requires multiple instances of the dir browser, wps etc 09.47.58 # okie. which mp3 decoder are you gonna use? Any clue if it is more or less efficient than the iriver fw one ? 09.48.29 # we'll use libmad 09.48.59 # and i don't know if it is more efficient than the iriver one 09.49.05 # it probably isn't 09.49.08 # it will most likely be less efficient, at least to begin with 09.49.34 # before you optimize the hell out of it 09.49.40 # exactly 09.49.58 # the Foobar mpeg decoder is very much optimized btw 09.49.59 # also it will most likely be better quality 09.50.21 # pike: isn't that floating point? 09.50.31 # probably, let me check 09.51.59 # I own a 20gig iriver myself, and lately I've started thinking of upgrading the HD. I filled it long ago and realize I want more space 09.52.39 # you need to wait for the new slim 40 gig drives. current 40 gigers are thicker and don't fit in the h120 09.53.01 # 5mm vs 7mm iirc 09.53.27 # yeah saw that. any idea what pricerange such a hdd would land in? 09.53.34 # no idea 09.53.47 # I suspect very expensive unless you buy large quantities 09.53.59 # problably 09.54.15 # but the 1900mAh replacement batteries seems interresting 09.54.53 # although 2100mAh seems even more interresting, but they're 1mm thicker 09.58.56 # fb2k's decoder is 32bit FP, figures :p 09.59.21 # most decoders use floating point, for obvious reasons 09.59.34 # except portable players 10.00.07 # right. and they mostly use proprietary codecs optimised by the processor manufacturer 10.01.00 # shame motorola didnt opensource theirs :) 10.02.06 # their license for it is rather nice, actually. you get it for free and can distribute all you want. but you only get binaries, no source. 10.04.07 # so there is no way to include it in rockbox ? 10.04.22 # we're not very fond of binary-only code 10.05.08 # no, I mean there is no way to lib/link it ? 10.05.18 # do you mean technically or legally? 10.05.25 # both I guess 10.05.33 # mhmm. both. I don't know a lot of GPL 10.06.04 # it would violate GPL, yes 10.06.30 # technically I would assume it could be done. legally we can't link to it since it is not gpl compatible. 10.06.31 # damn gpl.. (we got the same rules for XBMC) 10.06.36 # so with GPL you're not allowed to distribute even free closed source ? 10.06.50 # nope 10.06.59 # in this particular case, i don't care 10.07.11 # don't slam the gpl. it works like this for good reasons. 10.07.19 # i wouldn't want to use the motorola binary even if i could legally 10.07.25 # LinusN: i agree 10.08.11 # I wouldn't slam GPL as long as I'm not sure I understood it fully. It's just that I thought including free closed source would be ok. 10.08.18 # using a binary black box for the mp3 codec is a no-no if it can be avoided 10.09.10 # plus I suppose we don't need the cpu-power saving. what would you want to do during music listeing ? 10.09.24 # +n 10.09.30 # you could run the CPU slower 10.09.33 # well, less cpu means longer playtime 10.09.34 # to save battery 10.09.35 # lImbus: the purpose of GPL is the promote Free Software, meaning software including source code. closed source, even freely distributable, is not Free Software. 10.09.48 # ah, of course. variable cpu-speeds 10.10.26 # I suppose that inclusion would work with lGPL then ? I know the other way round is allowed. 10.11.12 # yes, with lgpl it is allowed 10.14.20 Join Lynx_ [0] (HydraIRC@134.95.189.59) 10.14.55 Join MooMaunder [0] (~paul@cpc1-stkp4-5-0-cust117.mant.cable.ntl.com) 10.15.32 # what cpu did the iriver have ? 10.15.53 # Coldfire Motorola 10.15.54 # motorola coldfire 10.15.56 # hehe 10.16.06 # how many mHz ? 10.16.08 Join amiconn [0] (~3edc1c11@labb.contactor.se) 10.16.11 # mips etc 10.16.31 # wonder if it's similar to what si used in ie their A925 phone 10.16.38 # 140MHz 10.16.45 # sounds like it 10.16.52 # Symbian UIQ compatible ? 10.16.58 # but we will probably run it somewhere in the 70MHz range 10.17.18 # i have no idea if symbian runs on it 10.17.20 # pike: i don't even know what that means. but i would assume it's listed on motorolas pages about it. 10.18.17 # hi 10.18.34 # hi amiconn 10.19.04 # hi 10.20.15 # är Coldfire ARM9 baserad ? 10.20.19 # oops sorry 10.20.30 # is Coldfire ARM9 based? 10.21.07 # no, coldfire is the core. you could call it a boosted 68k 10.21.36 # * Bagder spotted some swedish slipping through! ;-) 10.21.58 # ok, then they are not compatible, pardon my swedish, hehe 10.32.38 *** Saving seen data "./dancer.seen" 10.49.24 Join golot [0] (~chatzilla@212.29.252.122) 10.49.39 # Hey all 10.49.42 # anyone here? 10.49.52 # yup 10.49.53 # hi 10.51.48 # oh :) whats up? 10.52.09 # we rock our boxes! 10.52.51 # I wanna start in saying how grateful I am for your great effort in making a so-so product (archos rec with archos firmware) into the best HDbased player in the market (archos Rec with ROCKBOX) ! 10.53.11 # is there any docs accessible somewhere that describe how the MDB works? 10.53.58 # I wondered if the Archos is capable of charging 2600mah batteries.? 10.54.31 # (some charged only charge up to XXXXmah - is the archos box different?) 10.56.31 # Lynx_: afaik only the micronas datasheet 10.57.02 # golot: i doubt there is any problem charging 2600 batteries unless they are a different type 10.57.42 # type = like NiMH and so on? 10.57.47 # yes 10.57.56 # I mean NiMH 2600... 10.58.00 # ok, sounds cool :) thx 10.58.03 # Zagor: is that accessible? i just want to know the general principle out of interest... 10.58.47 # Lynx_: i was wrong. linus has written a short description here: http://www.rockbox.org/twiki/bin/view/Main/MicronasDynamicBass 10.59.38 # Bjorn - do you have any spare Jukebox recorder Front buttons (my On-Off buttons are broken) ? do you know where I can start looking for this? 11.00.08 # Zagor: thx, that's what I wanted to know 11.01.00 # golot: www.newmp3technology.net sells spare parts. maybe they have buttons too. 11.01.30 # cool 11.02.46 Join [IDC]Dragon [0] (~d90a3255@labb.contactor.se) 11.03.10 # oh :( they dont have any spare buttons... 11.03.37 # golot: try emailing them. they might know where to find any. 11.05.20 # <[IDC]Dragon> I could solder a button off 11.05.48 # what do you mean? 11.05.57 # the button is made of plastic 11.09.25 # [IDC]Dragon: ? 11.09.40 # hehe, now tell me Dragon is not monitoring this channel via current.txt :-) 11.09.48 # <[IDC]Dragon> ;-) 11.10.09 # <[IDC]Dragon> golot: I thought you bean the switch 11.10.14 # <[IDC]Dragon> mean 11.10.21 # ahh cool, thx... 11.10.34 # <[IDC]Dragon> the plastic part I don't have 11.10.44 # yeah... 11.11.14 # anyone here replaced his jukebox light color? I saw someone asking what type to get but does anyone know how to do it? could be cool... 11.11.51 # <[IDC]Dragon> you mean, the backlight? 11.11.58 # i have white backlight 11.12.06 # <[IDC]Dragon> me too 11.12.10 # yeah backlight* 11.12.22 # is it complicated to a total noob like me? 11.12.29 # yes :) 11.12.33 # gotta go, bbl 11.12.34 # lol :) 11.12.38 # bye 11.13.14 # <[IDC]Dragon> golot: so what button part do you need? 11.13.15 Quit lImbus (" HydraIRC -> http://www.hydrairc.com <- *I* use it, so it must be good!") 11.13.18 # white gotta look WOOOT!!! 11.13.20 # I've soldered for the first time since my good old school days! 11.13.27 # Although I forgot about "flussmedel" :) 11.13.36 # <[IDC]Dragon> flux 11.13.40 # ammm I need the On\Off button 11.13.50 # [IDC]Dragon: is that really needed? 11.13.57 # <[IDC]Dragon> the switch or the knob? 11.14.03 # and I could use a Play button... but not "must"... 11.14.19 # the plastic part, (what you actually press on)... 11.14.29 # <[IDC]Dragon> then I can't help 11.14.53 # <[IDC]Dragon> dwihno: you do, it's included in the solder 11.15.26 # dont you guys have like 2000000000000 jukeboxes lying around just like that? ;) 11.16.04 # [IDC]Dragon: it is? aah, nice :) 11.16.16 # [IDC]Dragon: In my old school days, we applied it by hand 11.16.42 # lol how old are you - 150 ? :) 11.18.09 # wasn't there a webpage on the backlight mod? Can't seem to find it now. 11.18.24 # golot: ayy! ye olde landlubber! ;) 11.19.05 # hehehe :D 11.19.13 # soldering is fun... although you should keep a stable blood sugar level or you will have a hard time soldering while shaking more than a vibrator on steroids 11.19.27 # LoL 11.20.11 # Now if I could get my hands on a 2.5mm stereo connector 11.20.15 # anyone can reccomend on really good NiMh batteries? 11.20.27 # the GP batteries are good 11.20.32 # oh, I have many of those, all kind of connectors... 11.20.43 # yeah, I have the 2000 GP... 11.21.05 # you dont know how cool I made my jukebox look 11.21.23 # a portable christmas tree? :)= 11.21.40 # I scrobbed the metal part and its now shinning and looks amazing :) 11.21.41 # Zagor, Bagder, LinusN, do you think clas ohlson keep 2.5mm stereo connectors? 11.21.54 # golot: pics! pics! :) 11.21.57 # not gone that far :D making a Xmas tree 11.22.12 # dwihno: I'd say very likely 11.22.24 # My jukebox is topless now but Ill take some pictures anyway... 11.23.08 # Bagder: ah, okay... I'll check after work 11.26.19 # Pictures are coming! 11.30.10 # Bagder: seems like CO doesn't have them :( 11.34.50 # http://www.geocities.com/golot_boots/jukebox/index.html <--- look ! 11.35.33 # not so good pictures, but you get the idea... :) its really shinny and looks cool, Im really proud of myself... 11.35.39 # <[IDC]Dragon> haha 11.38.06 # comments? 11.38.24 # you should really see it, not in pictures... in real, its so cool... :D 11.38.25 # shinny :D 11.38.54 # 2 better pictures are comming in a minute 11.38.57 # <[IDC]Dragon> I rarely look at the underside of my JB 11.39.37 # <[IDC]Dragon> the Ipod has a shiny back, so you can see the fingerprints better ;-) 11.39.43 # yeah, lol, but its also the sides and the up and down sides (where you connect stuff to it) 11.40.00 # <[IDC]Dragon> apart from that, I see no benefit 11.40.14 # fun making it ? :) 11.40.24 # <[IDC]Dragon> ok, sure 11.40.48 # I wish they would make the front panel and the battery covers out of metal too 11.40.53 Join quelsaruk [0] (~50678515@labb.contactor.se) 11.40.58 # then I could have one shinning jukebox :D 11.41.05 # hi, good morning to all 11.41.13 # http://www.geocities.com/golot_boots/jukebox/DSCN0033.JPG 11.41.18 # http://www.geocities.com/golot_boots/jukebox/DSCN0034.JPG 11.41.33 # oh no, the first one is bad 11.42.04 # second one is better 11.42.13 # look at this: http://www.geocities.com/golot_boots/jukebox/DSCN0034.JPG 11.46.15 # amiconn, Bagder : Archos is finally going to replace my jukebox :) 11.48.47 # golot get a better host.. 11.49.06 # its down? 11.49.09 # oh :( 11.49.52 # Im uploading to a different account! 11.55.00 # cu l8r! 11.55.24 Part quelsaruk 12.01.00 Join lImbus [0] (~manuel@kernel.cycos.net) 12.01.01 # Look - http://www.geocities.com/golot2001/DSCN0034.JPG 12.12.50 Join Kultivator [0] (Taxi@oslo-dhcp-248-180.bluecom.no) 12.32.42 *** Saving seen data "./dancer.seen" 12.33.25 # "With the ARCHOS patented retro-recording system, it is possible to record the radio after the song has already started." 12.33.38 # patented? 12.33.39 # patented being the word 12.33.40 # :-) 12.34.34 # I bet you guys have seen the archos linux based player stuff :) 12.34.53 # I have 12.35.07 # there is a linux based player now? 12.35.10 # yes 12.35.14 # Archos' latest 12.35.20 # PMA400 12.35.23 # well, to be released still, but yes 12.35.29 # http://www.archos.com/products/overview/pma_400.html 12.35.31 # and they are giving out a "full SDK", whatever that means 12.35.53 # word is they use qtopia 12.36.07 # yeah, they even say it 12.36.11 # ok 12.36.15 # I sense NDA 12.36.27 # dwihno: not likely since this is all based on linux 12.36.44 # Bagder: Was thinking about the SDK 12.36.45 # I bet they ship a prebuilt gcc version for cross-compiles 12.38.29 # or possibly, they'll never deliver their promise :-) 12.38.39 # I mean, they are Archos after all 12.39.50 # yeah, remains to be seen 13.19.28 # <[IDC]Dragon> I'm getting mailing list postings now from rockbox@rockbox.org instead of rockbox@cool.haxx.se, is that the new way? 13.19.53 # <[IDC]Dragon> If so, I have to adjust my mail filter, no problem 13.20.34 # sounds like a bug to me 13.21.25 # I get them from @cool.haxx.se 13.21.35 # or, rather, this one person sent his mail to rockbox.org instead of cool.haxx.se and we didn't bounce it 13.21.52 #